Subject: RE: [Ipsec] Invalid Cookie

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 Oct 2005 11:55:49 +0300

Sawkins, Steve 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.
> 
> If the cookie generation secret is changed, do we need to abort any main
> mode whose cookie used that secret and negotiate a new one or can we
> issue another cookie for the existing main mode?

The idea of cookie is to prove that the other end can reach your
packets, meaning if the other end has been able to send you valid
cookie (or any other message which proves they have seen your packets)
at any time, that is fine, and that IKE SA exchange can continue. This
includes all valid IKE_AUTH packets, i.e there is no point of tearing
down any IKE SAs processing IKE_AUTH packets or any IKE SA which are
already up.

If the IKE_SA_INIT packet has cookie that is not valid (i.e. cookie
generated by too old secret, or IP-addresses/ports do not match or
something else), then you simply request a new cookie. That is fast
operation, and does not consume resources.

When to change cookie generation secret is really implementation
dependent, but the best is probably change it every n seconds. This
will fix the case where attacker collects valid cookies over long
time. This will also fix the case where attacker floods lots of
exchanges to you and make you to generate new secret (in case you used
number of generated cookies as a limit) thus invalidating old valid
exchanges too fast.

You want to keep the cookies valid for several seconds, so that even
the slowest round trip times links have time to be able to use the
generated cookie.

If you allow previous cookie secret too, then you can use shorter time
period, as changing the cookie secret does not disrupt any valid
on going exchanges. In that case 2-10 seconds would be suitable time
period.

If you do not allow previous secret, then you should change it less
frequently, but just when the new exchange starts (i.e. just when the
new cookie is generated), so you can give maximum time for that
exchange to finish. The old exchanges are already invalidated, so
better give this one max time. I.e. when generating new cookie, check
if the last secret generation time was more than n seconds ago, and if
so generate new secret, and set the generation time to be current
time. 
-- 
[email-masked]

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