|Main Archive Page > Month Archives > ipsec archives|
At 10:43 AM -0700 11/2/07, Narayanan, Vidya wrote:
>> -----Original Message-----
>> From: Jari Arkko [mailto:firstname.lastname@example.org]
>> Sent: Thursday, November 01, 2007 10:26 PM
>> To: Narayanan, Vidya
>> Cc: email@example.com; firstname.lastname@example.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
>> 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.