RE: [Mobike] TS updates in MOBIKE

Stephen Kent <[email protected]> Fri, 2 Nov 2007 17:02:38 -0400
Newsgroups gmane.ietf.ipsec,gmane.ietf.mobike
Message-ID <p06240514c3514072d814@[128.89.89.71]>
At 10:43 AM -0700 11/2/07, Narayanan, Vidya wrote:
>Hi Jari,
>
>>  -----Original Message-----
>>  From: Jari Arkko [mailto:[email protected]]
>>  Sent: Thursday, November 01, 2007 10:26 PM
>>  To: Narayanan, Vidya
>>  Cc: [email protected]; [email protected]
>>  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.
>
>Regards,
>Vidya

Vidya,

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.

Steve