Re: Ikev2 IKE-SA rekey collision

["David Faucher" <dfaucher@lucent.com>]

I had thought about collisions on initial establishment but
came to the conclusion that this is not a problem and may even
be desired.

- collision on initial establishment don't have the problems
of a rekey collision because there are no child-SAs present.

- two endpoints may choose to have logically separate IKE-SAs
for different identities.

David

----- Original Message -----
From: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@Sun.COM>
To: <ipsec@lists.tislabs.com>; <dfaucher@lucent.com>
Sent: Friday, May 03, 2002 7:21 PM
Subject: Re: Ikev2 IKE-SA rekey collision


| 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...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
|
|