|Main Archive Page > Month Archives > ipsec archives|
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.
Narayanan, Vidya wrote:
> Hi Jari,
>> -----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
> 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.
>> 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 >>> Mobike@machshav.com >>> https://www.machshav.com/mailman/listinfo.cgi/mobike >>> >>> >>>
> IPsec mailing list
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec