Chinh Nguyen | 7 Nov 2007 15:59

Re: RE: [Mobike] TS updates in MOBIKE

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

Gmane