7 Nov 2007 15:59
Re: RE: [Mobike] TS updates in MOBIKE
Chinh Nguyen <cnguyen <at> certicom.com>
2007-11-07 14:59:23 GMT
2007-11-07 14:59:23 GMT
>> However, this can be mitigated by having the IKEv2 peer use >> only the SPIs to track IKEv2 exchanges and ignore src/dst addresses. >> > > This gives the impression that the IP address to which the IKE_SA is > tied is not important. That is the address that is going to serve as > the tunnel endpoint for tunnel mode SAs and hence, has some consequence. > I would think that typical implementations reject CREATE_CHILD_SA > requests for rekeying an SA, sent from a different IP address than to > which the IKE_SA is currently tied - is that not true? RFC4306 is not > clear about this. From a MOBIKE view, IKE_SA cannot be tied to IP addresses. The entire premise of an UPDATE_SA is that it may originate from a new endpoint, different from the endpoints stored in the current IKE_SA. As such, a MOBIKE peer should allow this for all IKEv2 exchanges, including CREATE_CHILD_SA (as noted by Pasi RFC 4555 section 3.3). Whether or not a non-MOBIKE IKEv2 implementation should do the same is another question. I vote for yes as the SPIs and successful authentication/decryption (correct IKE_SA) is sufficient to validate "peer identity".
RSS Feed