Subject: RE: [Ipsec] Invalid Cookie

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 26 Sep 2005 02:53:43 -0700

Hi Alejandro,

The IKE draft states that:-

   An IKE implementation SHOULD implement its responder cookie
   generation in such a way as to not require any saved state to
   recognize its valid cookie when the second IKE_SA_INIT message
   arrives.

Also

   responder uses minimal CPU and commits no state 

This would mean in case an unexpected cookie value is received, the responder would just ignore the packet.

I think option 3 would not help as an IP Address can be easily spoofed.

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alejandro Perez Mendez
Sent: Monday, September 26, 2005 2:40 PM
To: [email-masked]
Subject: [Ipsec] Invalid Cookie

Hi. I need some clarifications about cookies, please.
What is the spected behaviour when an invalid cookie is received?

There are three options:
a) Omit request until initiator spend all its retransmitions.
b) Send the correct cookie to the initiator. 
c) Ban the source IP address for a time to avoid DoS attacks.

I think the most adequate option is c) or a) adequate, because 
b) whould falls in DoS attacks.

Regards.

Alejandro Pérez
Pedro J. Fernández

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Mon, 26 Sep 2005 17:47:13 +0300

> b) whould falls in DoS attacks.

The only correct choice is b: if the responder receives an
invalid cookie, the cookie is just ignored, and a new cookie
is sent.

(Option c is an especially bad idea: an attacker who knows
my IP address could prevent me from opening connections
just by sending bad cookies continuously...)

Best regards,
Pasi

---

From: "Stephane Beaulieu \(stephane\)" <[email-masked]>
Date: Tue, 27 Sep 2005 13:55:56 -0400

> 
> Alejandro Perez Mendez writes:
> Note, that there are valid cases when the cookie can be 
> changed too, i.e. if you change your cookie generation 
> secret, all previous cookies are invalidated, and if someone 
> just happened to have exchange going with you that cookie 
> will be changed too. Another option is in case the NAT 
> decided to change the mapping after sending the first request 
> and before the message with cookie was sent.

Just a clarification... One CAN keep info from previous cookie secrets
for X amount of time to allow a seemless cookie secret chageover.  It
may not be worth doing as you can just re-challenge with the new cookie
if the peer fell into your cookie refresh window, but it is fairly
simple to do if you want to have accurate logging for real failures vs.
bad timing failures.

> 
> Also note that if you omit future requests, even when they 
> later have valid cookie, then attacker can cause DoS by 
> simply sending one message with invalid cookie before the 
> real peer can do that. 
> 
> I think this should be the default. Cookie generation should 
> be so fast that generation of them do not matter. Also there 
> is no amplification factor there, so you can simply answer 
> with one packet to each one packet request you get. 
> 
> This would allow very easy DoS done by the attacker, i.e. 
> just start sending random cookies to the host with IP address 
> taken from the VPN box of the other end, and you can forbid 
> connections between the boxes. 
> 
> C would be really bad, A would be better, but B is the one 
> that is meant to be used.
> 
> Note, that A and C both would require responder to store 
> state to be able to filter packets out, so those are at least 
> partly against the
> IKEv2 draft too.
> --
> [email-masked]
>