|Main Archive Page > Month Archives > ipsec archives|
>> 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".