RE: RE: [Mobike] TS updates in MOBIKE

> >=20
> > Why it cannot happen in paralleal with UPDATE_SA exchange? IKEv2=20
> > already has mechanisms defined for using bigger window for=20
> IKEv2, so=20
> > you just need to enable using of window size of 2 or larger in the=20
> > IKEv2, to be able to do UPDATE_SA and CREATE_CHILD_SA in paralleal,=20
> > thus now latency hit at all. Or is there some other reason=20
> they cannot=20
> > be done in paralleal?
>=20
> A IKEv2 peer may choose to reject a CREATE_CHILD_SA if it=20
> arrives from an "unknown" endpoint (SPIs + src/dst addresses=20
> are used to track IKEv2 exchanges). In such case, the=20
> CREATE_CHILD_SA will fail if a. the CREATE_CHILD_SA arrives=20
> before the UPDATE_SA exchange or b. the CREATE_CHILD_SA=20
> arrives while the peer is doing a route check to complete the=20
> UPDATE_SA exchange.
>=20

Yes, this is what I was getting at. =20

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

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.=20

Thanks,
Vidya