[Hipsec] Cookies cookies

On Sunday we had a brief discussion about the cookie design. Here I try to reherse the argument given, and go forward.

As we all know, the purpose of the cookie mechanism is to protect the Responder from DoS attacks. Now, there are at least two different threats that we want to protect the Responder from: memory space exhaustion and CPU starvation.

A way to protect the Responder from memory space exhaustion is to allow it to handle I1s in a stateless manner. That is, when the Responder receives an I1, it just replies with an R1 and then forgets about the whole transaction. If the Responder were required to create state for each I1, we would have the equivalent of a TCP SYN attack.

Now, if the Responder acts in a completely stateless manner in responding to I1s, the burden is transfered to the CPU processing needed to check I2s. Since the Responder currently needs to compute one SHA-1 hash digest to check that the Initiator has indeed solved the cookie puzzle, an attacker can send a stream of I2s to a stateless Responder and burn its CPU on useless applications of SHA-1.

On the other hand, if the Responder *can* create state when receiving I1s, it can check the puzzle only on those I2s that it expects. Obviously, this brings back the memory space exhaustion threat. Thus, the best way would probably be to remember a number of I1s, and whenever that space is exhausted, to switch over to the stateless operation. In that way an attacker is forced to send *both* I1s and I2s, thereby doubling the effort required on the attacker's side.

There is a third threat in the original design. If the Responder acts in a stateless manner, it only remembers the I and K sent out in R1s. It has no idea to whom it has sent the R1s. In the original design, that would allow an attacker to solve the puzzle once, and then send a large number of I2s, each with different IP addresses and HITs, all with a valid puzzle solution but an invalid signature. Since the cookie check would pass, the Responder would burn even larger amounts of CPU in doing the failing signature checks.

In the revised cookie scheme that I proposed the puzzle explicitly includes the HITs and IP addresses used. That forces the attacker either to solve the puzzle multiple times or to use constant IP addresses and HITs. If the attacker tries to use constant IP addresses and HITs, the Responder can record the fact that it has received a valid cookie but a bad signature with those parameters, and cease to check the signature after a couple of failures. Thus, it would be protected from unnecessarily burning CPU cycles on signature verifications. It can simply ignore the I2s coming with those IP addresses and using the specific instance of the puzzle.

Going forward, if we agree to include the HITs and IP addresses into the puzzle, there is no reason for the Responder to check that the puzzle is solvable any more. That also means that the puzzle solution can be just defined in the terms of zeros the hash result must contain. That is, instead of requiring that

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

   Ltrunc ( SHA-1 ( I | ... | J ), K ) == Challenge

we just require

   Ltrunc ( SHA-1 ( I | ... | J ), K ) == 0

Would everybody be happy with just using zero bits?

Still going forward, the current design has the problem that the Initiator cannot currently check if the received R1 is a genuine R1 sent by the Recipient, or if it is an old packet send by an attacker trying to lure the Initiator into churning CPU cycles.

Now, one way of solving that problem might be including a timestamp into the R1 packet. What do you feel, would that be useful?

--Pekka Nikander