Re: [IPsec] RE: TS updates in MOBIKE

Chinh, Steve, Tero,
Thanks for all the responses.  I'm just taking Chinh's email here to
make a few observations. 

> -----Original Message-----
> From: Chinh Nguyen [mailto:[email protected]] 
> Sent: Friday, November 02, 2007 12:34 PM
> To: Narayanan, Vidya
> Cc: Jari Arkko; [email protected]; [email protected]
> Subject: Re: [IPsec] RE: [Mobike] TS updates in MOBIKE
> 
> Efficiency is overrated.
> 

Well, not that overrated over licensed wireless spectrum :) 

> 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.
> 

Yes, that is true.  I guess what I was really asking was what you were
getting at immediately below. 

> 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.
> 

Yes, but, I'm not sure if that's a big deal.  It is, after all, a notify
payload and the processing of the payload itself doesn't change.  So, in
essence, we would just be lifting the mandate to only allow it to be
carried in an informational exchange. 

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

The use case that I presently have in mind is the following.  IPsec is
used in some cases to protect Mobile IPv6 (MIP6) signaling.  Some
systems differentiate between trusted accesses and untrusted accesses
and while IPsec is always used for MIP6 signaling protection in both
cases, additional data protection using IPsec may be needed over
untrusted access networks (between the same endpoints).  When a mobile
is moving from a trusted to untrusted access, its IP address changes,
but, it also, at the same time, needs to update its SA to start
protecting all traffic.  At the moment, the mobile, just to handle this
handoff case, needs to do a MIP6 signaling exchange, a MOBIKE exchange
and a CREATE_CHILD_SA exchange.  The first two are unavoidable and can
happen in parallel, while the third one has to occur after the MOBIKE
exchange completes.  This is a latency hit in the critical path that can
be avoided if the UPDATE_SA notify payload can be part of the
CREATE_CHILD_SA exchange. 

> 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.
> 

Well, depending on the environment we are talking about, byte savings
and particularly latency becomes important.  Does the removal (or
relaxing) of these tight functional boundaries really cause any issue?
If not, I think allowing this can really help some use cases like the
above. 

Regards,
Vidya

> 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
>