[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