Subject: [Ipsec] Invalid Cookie

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 26 Sep 2005 11:10:04 +0200

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Sep 2005 13:22:01 +0300

> a) Omit request until initiator spend all its retransmitions.

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.

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. 

> b) Send the correct cookie to the initiator. 

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. 

> c) Ban the source IP address for a time to avoid DoS attacks.

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. 

> b) whould falls in DoS attacks.

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]