Re: [MEXT] Support of route optimization in *absence* of HA

[Behcet Sarikaya <[e-mail]>]

Wow, I was puzzled about what state addressing was.

It was SLAAC. Thanks for clarifying Julien :-).




> 
>Georg,
> 
>Regarding #1 I haven’t decided yet I would like the group to discuss more. The 
>authorization of the MN to use a given HA could be asserted in a couple of  
>different ways, including but not limited to, a) the HA only allows creation of 

>initial binding for on-(home)-link MN, b) the HA only allows creation of initial 
>
>bindings for on-site MNs, i.e., CoA in a provider prefix block, and c) the HA 
>has access to a list  of CGA public keys that are authorized to create 
bindings.
> 
>Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet System 
>mandates stateless address autoconfiguration for global addresses. Only the 
>link-local  address is generated from the IID sent by the GW.
> 
>Best,
> 
>--julien
> 
>From:Hampel, K Georg (K Georg) [mailto:[e-mail]] 
>Sent: Friday, January 21, 2011 11:22 AM
>To: Laganier, Julien; Hampel, K Georg (K Georg); [e-mail]
>Cc: Klein, Thierry E (Thierry)
>Subject: RE: Support of route optimization in *absence* of HA
> 
>Julien,
> 
>Thanks for the info. I like your proposal. CGA provides cryptographic security 
>without need for trust-relationships, PKI, pre-shared keys, etc.
> 
>1) When IPsec is replaced by CGA, MN only proves the authenticity of its HoA to 

>the HA. It does not authenticate itself in absolute terms, i.e. via means of 
>strong authentication  as required by IPsec or TLS. How would the HA know that 
>this MN is authorized to use the HA’s services?  
> 
>2) Do we have any idea to what extend stateless addressing is “supported”? Does 

>(or will) 3GPP allow stateless addressing?
> 
> 
>-Georg
> 
> 
>
________________________________

>From:Laganier, Julien [mailto:[e-mail]] 
>Sent: Friday, January 21, 2011 1:06 PM
>To: Hampel, K Georg (K Georg); [e-mail]
>Cc: Klein, Thierry E (Thierry)
>Subject: RE: Support of route optimization in *absence* of HA
> 
>Georg,
> 
>Thanks for clarifying, this is what I thought. FWIW, I’ve tried to extend the 
>RFC 4866 to secure bindings between the MN and the HA in 
>http://tools.ietf.org/html/draft-laganier-mext-cga-01
> 
>--julien
> 
>From:Hampel, K Georg (K Georg) [mailto:[e-mail]] 
>Sent: Thursday, January 20, 2011 5:25 PM
>To: Laganier, Julien; [e-mail]
>Cc: Klein, Thierry E (Thierry)
>Subject: RE: Support of route optimization in *absence* of HA
> 
>Julien,
> 
>The intentions of Homeless MIPv6 are similar to those of our proposal. 
> 
>In contrast to Homeless MIPv6, our proposal requires only minimal upgrades to 
>the present standard and implementation. (Homeless MIPv6 requires changes to the 
>
>TCP/UDP  and requires AH, for instance).
> 
>Here’s the core idea of HA-free R/O: 
>1)     When starting a session, the MN self-declares its current IP address as 
>the “HoA” for this session. This automatically means that it resides in its 
>“home network”  and can conduct the home test directly with CN, i.e. no home 
>registration required.
>2)     All further BU/BA signaling is done directly with CN according to RFC 
>4866.
>3)     All further signaling with HA is simply omitted.
> 
>Our proposal builds on “enhanced route optimization” (RFC 4866), which provides 

>a nice security solution for R/O and creates the ground for HA-free operation.
>Little changes are required: e.g. MN must be able to deregister its HoA at CN, 
>etc.
> 
>Regards,
> 
>Georg
> 
>
________________________________

>From:Laganier, Julien [mailto:[e-mail]] 
>Sent: Thursday, January 20, 2011 4:27 PM
>To: Hampel, K Georg (K Georg); [e-mail]
>Cc: Klein, Thierry E (Thierry)
>Subject: RE: Support of route optimization in *absence* of HA
> 
>Georg,
> 
>Is it correct that functionally your proposal is similar to Homeless Mobile 
>IPv6:
> 
>http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01
> 
>Best,
> 
>--julien
> 
>From:[e-mail] [mailto:[e-mail]] On Behalf Of Hampel, K 
>
>Georg (K Georg)
>Sent: Thursday, January 20, 2011 12:07 PM
>To: [e-mail]
>Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry)
>Subject: [MEXT] Support of route optimization in *absence* of HA
> 
>All,
> 
>We would like to add a proposal to MEXT that permits the mobile to engage into 
>route-optimization in *absence* of a home agent. 
>
> 
>Such a feature adds robustness to route optimization in case the HA is 
>temporarily unavailable. Under some circumstances, route optimization *without* 

>HA may be beneficial  for performance reasons. Our proposal requires “enhanced 
>route optimization for Mobile IPv6” (RFC 4866) as pre-requisite.
> 
>We would like to obtain some feedback from the MEXT community via this mailing 
>list before we submit the proposal as a draft to the workgroup. For this 
>purpose, we have enclosed  a high-level outline below. Thanks.
> 
>Regards,
> 
>Georg Hampel
>Networking & Networks Domain
>Bell Laboratories
>Alcatel-Lucent
>============================================
> 
>Proposal: Support of Route-Optimization in Absence of Home Agent
> 
>ABSTRACT:
>The proposal allows the mobile to engage into route optimization (R/O) in 
>*absence* of a HA. This feature increases robustness when the HA becomes 
>temporarily unavailable.  Under some circumstances, R/O *without* HA may be 
>beneficial for performance reasons. This proposal requires “enhanced route 
>optimization for Mobile IPv6” (RFC 4866) as pre-requisite. 
>
> 
>MOTIVATION:
>In route optimization (R/O), traffic packets are directly exchanged between 
>hosts without passing the HA. The mobile, however, still has to interact with 
>the HA. The HA provides  (1) location service, (2) a fallback path in case the 
>direct path breaks, (3) a fallback in case the correspondent does not support 
>the protocol and (4) security support for R/O-related signaling (i.e. home 
>test). These functions come at the following cost:
>·       Handovers may fail when the link to the HA or the HA itself are down or 

>congested. Mobility is not supported, when the mobile does not have a HA.
>·       When the mobile starts a session outside of its home network, it must 
>use a HoA pertaining to its home network even if it engages into R/O. This 
>requirement adds  air-interface overhead due to mobility headers and processing 

>overhead on the mobile. This upfront cost incurs even if the mobile does not 
>move during the session.
>·       Signaling handshakes have to be conducted between mobile and HA at every 
>
>mobility event.
> 
>Currently, the Mobile IPv6 standard family forces the mobile to bear these 
>disadvantages in R/O even if the HA functions are not needed. This specifically 

>applies to scenarios  where: 
>
>·       Traffic is based on mobile-initiated requests to public servers 
>(majority of present mobile internet traffic). The HA’s location service is not 

>needed for such traffic.  Location service may also be provided by other means 
>such as Dynamic DNS or on application layer (e.g. SIP registrar).
>·       The fallback path through the HA has little value when it shares the 
>weakest link with the direct path. Since the weakest link is typically the 
>wireless link, this  situation applies to all scenarios where only one air 
>interface is available (this is the typical case rather than the exception).
>·       The mobile may know about the correspondent’s Mobile-IPv6 support from 
>prior sessions or through means external to the standard. 
>
>·       The mobile applies the CGA-based procedure of RFC 4866, which makes the 

>HA’s security support for R/O unnecessary. This applies to all cases where 
>stateless addressing  is permitted. 
>
> 
>To increase the flexibility and robustness of route-optimized Mobile IPv6, we 
>propose to make the HA an *optional* rather than a *mandatory* feature, i.e. to 

>permit operation  without HA. This proposal requires some additional extensions 

>to the present standard.
> 
>HIGH-LEVEL OUTLINE
>The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 4866) 
>to guarantee sufficient signaling security. With the absence of a HA, mobility 
>support in R/O  can be provided in the following manner:
>·       The mobile starts the traffic session from any of its currently 
>supported IP addresses. The selected IP address automatically takes the function 
>
>of the HoA for this  session. This has the advantage that conventional transport 
>
>is used as long as the mobile does not move, i.e. mobility headers and 
>CoA-vs-HoA mapping is not needed. The HoA must have been generated via CGA in 
>compliance with RFC 4866. 
>
>·       The mobile must conduct a “home-test” from this HoA in compliance with 
>RFC 4866. It may conduct the home-test prior to session establishment, e.g. to 
>find out if  the correspondent supports the standard. 
>
>·       All binding update handshakes are conducted on the direct path according 
>
>to RFC 4866.
>·       Since sessions are always started from a currently supported IP address, 
>
>temporally overlapping sessions may use different HoAs. A multi-homed mobile may 
>
>also decide  to start sessions from different simultaneously supported IP 
>addresses. There is no principle problem here.
>·       Opposed to RFC 4866, the mobile need not perform the CoA registration 
>with the HA.
>·       The mobile must be able to deregister the HoA at the correspondent in 
>case the HoA is not supported anymore. This ensures that the correspondent does 

>not send packets  to the HoA. After deregistration of the HoA, the HoA is still 

>used by higher protocol layers of ongoing sessions. It must still be included in 
>
>the mobility headers for these sessions.
>·       When the mobile has HA support and the HA becomes temporarily 
>unavailable, the mobile simply continues R/O without HA as outlined in the prior 
>
>points.
>·       The mobile can publish its IP address in any location service. This 
>allows other hosts to initiate sessions with the mobile. These sessions enjoy 
>route-optimized  mobility support only if the published IP address was generated 
>
>via CGA in compliance with RFC 4866.
> 
>OPEN ISSUES
>These extensions have to be made compliant with RFC 5648 (multiple CoA 
>registration), RFC 3963 (NEMO) and others. More discussions are necessary.
> 
>