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