Re: RE: [Mobike] TS updates in MOBIKE

Efficiency is overrated.

But all joking aside, the UPDATE_SA notify payload is part of an 
informational exchange. Informationals do not contain the necessary 
payloads to "update an SA" such as TS, KE, and even SA payloads.

The alternative is to allow the UPDATE_SA notify payload to be part of a 
CREATE_CHILD_SA message. If so, it must be further specified that there 
are now 2 ways to UPDATE_SA: a regular end-point update via an 
informational, and a end-point + TS + [etc.] update via a create child sa.

Since this is a reasonably major change to the MOBIKE spec, which is 
already an RFC, you may need a compelling use-case scenario.

A saving of 2 additional packets (for the extra rekey to change the TS) 
may not be sufficient reason to blur the current functional boundaries.

Chinh

--
http://www.certicom.com

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
> 
> 
>> Jari
>>
>> Narayanan, Vidya kirjoitti:
>>> Hi,
>>> RFC4555 only allows updates to tunnel endpoint addresses and not 
>>> selectors, etc.  Does anyone know why TS updates are not 
>> permitted?  
>>> If MOBIKE allowed what an SA rekey would allow, what is the problem?
>>>
>>> Thanks,
>>> Vidya
>>> _______________________________________________
>>> Mobike mailing list
>>> [email protected]
>>> https://www.machshav.com/mailman/listinfo.cgi/mobike
>>>
>>>
>>>   
> 
> 
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipsec