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: Tero Kivinen <kivinen_at_nospam>
Date: Mon Nov 05 2007 - 14:12:06 GMT
To: "Narayanan, Vidya" <vidyan@qualcomm.com>


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?

> Well, depending on the environment we are talking about, byte savings
> and particularly latency becomes important.

There is no latency problem, so the only problem is the extra 80 bytes sent and received.

> Does the removal (or relaxing) of these tight functional boundaries
> really cause any issue? If not, I think allowing this can really
> help some use cases like the above.

As there is already efficient ways to do that in the IKEv2, I do not see any reason to add another different way to get the same results only to save 160 bytes every time transition from trusted to untrusted network happens (most likely at maximum few times per day...) -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec