Re: RE: [Mobike] TS updates in MOBIKE

Tero Kivinen wrote:
> Narayanan, Vidya writes:
>> The use case that I presently have in mind is the following.  IPsec is
>> used in some cases to protect Mobile IPv6 (MIP6) signaling.  Some
>> systems differentiate between trusted accesses and untrusted accesses
>> and while IPsec is always used for MIP6 signaling protection in both
>> cases, additional data protection using IPsec may be needed over
>> untrusted access networks (between the same endpoints).  When a mobile
>> is moving from a trusted to untrusted access, its IP address changes,
>> but, it also, at the same time, needs to update its SA to start
>> protecting all traffic.  At the moment, the mobile, just to handle this
>> handoff case, needs to do a MIP6 signaling exchange, a MOBIKE exchange
>> and a CREATE_CHILD_SA exchange.  The first two are unavoidable and can
>> happen in parallel, while the third one has to occur after the MOBIKE
>> exchange completes.  This is a latency hit in the critical path that can
>> be avoided if the UPDATE_SA notify payload can be part of the
>> CREATE_CHILD_SA exchange. 
> 
> Why it cannot happen in paralleal with UPDATE_SA exchange? IKEv2
> already has mechanisms defined for using bigger window for IKEv2, so
> you just need to enable using of window size of 2 or larger in the
> IKEv2, to be able to do UPDATE_SA and CREATE_CHILD_SA in paralleal,
> thus now latency hit at all. Or is there some other reason they cannot
> be done in paralleal?

A IKEv2 peer may choose to reject a CREATE_CHILD_SA if it arrives from 
an "unknown" endpoint (SPIs + src/dst addresses are used to track IKEv2 
exchanges). In such case, the CREATE_CHILD_SA will fail if a. the 
CREATE_CHILD_SA arrives before the UPDATE_SA exchange or b. the 
CREATE_CHILD_SA arrives while the peer is doing a route check to 
complete the UPDATE_SA exchange.

However, this can be mitigated by having the IKEv2 peer use only the 
SPIs to track IKEv2 exchanges and ignore src/dst addresses.