ipsec November 2007 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: RE: [IPsec] RE: [Mobike] TS updates in MOBIKE

RE: [IPsec] RE: [Mobike] TS updates in MOBIKE

From: Narayanan, Vidya <vidyan_at_nospam>
Date: Wed Nov 07 2007 - 01:31:33 GMT
To: "Chinh Nguyen" <cnguyen@certicom.com>, "Tero Kivinen" <kivinen@iki.fi>


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

Thanks,
Vidya



IPsec mailing list
IPsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec