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