[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Rekey of IKE-SA



I would think that in the event of a rekey collision that both IKE SAs could
be used.  It is a little bit wasteful of resources to have 2 where only 1 is
needed, but there should be no functional difference.  After all, you still
need to be able to handle the time in which there is an overlap between the
old SA and the new one.  So, if you have to handle that anyway, there is
probably no point in adding any functionality to the protocol.  If that
should occur, you just have to make sure you only rekey (on the next rekey),
one of those 2 IKE SAs.

Adding a good jitter to your expiry should greatly reduce the number of
collisions (except maybe in the lab with very small lifetimes).

If you have a specific proposal that is VERY simple then I might change my
mind Otherwise I'm inclined to say that it's really not complicated to deal
with in the event it does happen, and should be rare enough to forget about
the resource impact.

Stephane.

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of David Faucher
> Sent: Monday, November 25, 2002 12:22 PM
> To: ipsec@lists.tislabs.com
> Subject: Rekey of IKE-SA
>
>
>
> I believe IMHO, that there needs to be a mechanism for
> avoiding a collision on an IKE-SA rekey. In its absence
> nodes may end up assigning ownership of the child-SAs to
> different IKE-SAs.
>
> This subject has been brought up before (May 2002) but
> without a firm resolution.
>
> David