|Main Archive Page > Month Archives > ipsec archives|
> > 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.
Yes, this is what I was getting at.
> 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.