Re: Ikev2 IKE-SA rekey collision

[Jan Vilhuber <vilhuber@cisco.com>]

On Fri, 3 May 2002, Radia Perlman - Boston Center for Networking wrote:

> Actually, one could have the same problem you point out, on establishment of
> the original IKE-SA. The spec does say that one should randomize
> the rekeying time to minimize the likelihood of duplicate
> SA's resulting from rekeying. I think your suggestion
> would work...

I'm all for writing something like this into the spec. While it
trivial to do and implement, it's impossible to retrofit without
standard-support, since iut'll wind up being non-interoperable, if
everyone does it differently (one picks the larger nonce, the other
the smaller nonce, and you wind up with nothing).

Any objections to writing this into the standard?

jan


>if you notice you have duplicate SAs, then drop
> the one with the larger initiator nonce. With that rule, it also
> works if there's a collision on the initial IKE-SA (where there
> isn't a unique initiator, since each of the duplicate SAs would be initiated
> by one end).
>
> Radia
>
> David Faucher said:
> 	Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying:
>
> 	If there is a collision where both sides attempt to
> 	rekey an IKE-SA at the same time, which one ends up
> 	owning the child-SAs?
>
> 	It is possible to avoid this condition all together by
> 	simply using some value within the messages to determine
> 	who will "win" the rekey. For example, the side whose
> 	nonce has the greater value. Alternatively, one could
> 	use the initiator of the current IKE-SA to determine
> 	who "wins" the rekey.
>
> 	David
>
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

http://www.eff.org/cafe