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

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

From: Stephen Kent <kent_at_nospam>
Date: Fri Nov 02 2007 - 21:02:38 GMT
To: "Narayanan, Vidya" <vidyan@qualcomm.com>

At 10:43 AM -0700 11/2/07, Narayanan, Vidya wrote:
>Hi Jari,
>> -----Original Message-----
>> From: Jari Arkko [mailto:jari.arkko@piuha.net]
>> Sent: Thursday, November 01, 2007 10:26 PM
>> To: Narayanan, Vidya
>> Cc: mobike@machshav.com; ipsec@ietf.org
>> Subject: Re: [Mobike] TS updates in MOBIKE
>> Presumably because MOBIKE is a mobility and multihoming
>> facility for IPsec clients and gateways, i.e., you can change
>> the outer IP addresses. Its not a general SA renegotiation facility.
>Yes, I understand that that is the purpose of MOBIKE. But, I don't see
>a good reason to prevent other updates from happening as part of that
>same exchange. For e.g., let's say that when my address changes, I want
>to update the SA (or rekey) to start encrypting some additional traffic
>(fitting different selector criteria) using the same SA - the initiator
>now has to do separate MOBIKE and rekeying exchanges, which is not
>really efficient.
>> Yes, it could be done, but I'm not sure that's really within
>> the scope of the feature. Unless we are talking about
>> extension to deal with transport mode, which has been
>> something at least a few people were interested in.
>I think the above point of updating the SAs applies equally to transport
>and tunnel mode, but, extending MOBIKE for transport mode is
>independently useful in my view.


So long as the only change is to the outer headers, this is viewed as a MOBIKE issue, not a core IPsec issue. If you want to make TS changes, then this becomes an IPsec architecture issue and needs to be more closely examined. So, I think the agreement was to let IKE continue to do the more invasive SA management.


IPsec mailing list