[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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