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

["Hampel, K Georg (K Georg)" <[e-mail]>]

Hi Alex,

I think there are principle concerns about host-based mobility solutions without proper security (see RFC 4225 for instance). HA-free RO without security would fall into that space. Obviously, it would be of advantage to keep HA-free RO as general as possible, i.e. without relying on a *specific* security solution.

Regarding mobile routers + optimal paths: Shouldn't this be covered by route-optimized NEMO?

Georg



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Alexandru Petrescu
Sent: Tuesday, January 25, 2011 12:55 PM
To: [e-mail]
Subject: Re: [MEXT] Support of route optimization in *absence* of HA

Thanks for listing these 3 documents.

For what it's worth...

I think it would be good to decouple the security effort from the
HA-less part of the effort.

I would thus go further with the proposal to operate on a more general
level.  Do you have anything against a basic RO HA-less which is
security-less as well?

If against, then it would make sense to talk _Secure_ HA-less RO RR.

If for, then it would make sense to cite
http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00
and MNPP draft along the 3 documents you cited.

I think a basic RO HA-less which is independent of the security
mechanism could become a place for adding more security later.  For
example: add a widely deployed certificate-based https security which
secures a link layer (and not CGA, not Mobile IP RR tests).

I think that if one tries to further develop existing Mobile IP security
mechanisms (CGA, IKE, RR tests) then the goal should be
stated in the title, call the effort a security effort, and not simply
RO, nor simply RR.

For example: return routability tests (called RR in Mobile IP only)
exists in other protocols as well (TCP) yet they're not as highly secure
as in Mobile IPv6 (nonces, keys).  In this sense, in Mobile IP, RR is
actually a security effort.

RO of Mobile IP does not exist without RR, hence RO is also a security
effort.

However, it is possible to achieve optimal paths ("route optimization"),
without using security.  For example, most paths in the Internet are
highly optimal in terms of path length, yet very few of them are
established securely.

I think Mobile IP needs means to offer optimal paths CN-MH (move HA out
of the path). However, the effort of offering these paths is not
necessarily a security effort.

Alex

Le 25/01/2011 16:44, Hampel, K Georg (K Georg) a écrit :
> All,
>
> Based on feedback and further thoughts, I propose to permit HA-free
> operation on a more general level, i.e. for ALL R/O-solutions that
> permit return-routability procedure WITHOUT participation of the HA.
> Among those are currently:
>
> - RFC 4866: Enhanced R/O for MIPv6
>
> - RFC 4449: Securing MIPv6 R/O using static shared key
>
> - draft-ebalard-mext-ipsec-ro-01: Mobile IPv6 IPsec Route
> Optimization (IRO)
>
> Note that HA-free R/O was already anticipated by RFC 4651 (A
> Taxonomy and Analysis of Enhancements to Mobile IPv6 Route
> Optimization). I think it would add substantial value to MIPv6. RFC
> 4651 says:
>
>
>
> 2.4. Robustness Enhancements
>
>
>
> Route Optimization could conceptually enable continued
> communications
>
> during periods of temporary home-agent unavailability.    The
> protocol
>
> defined in RFC 3775 does not achieve this independence, however, as
>
> the home agent plays an active role in the return-routability
>
> procedure.    Appropriate enhancements could increase the
> independence
>
> from the home agent and thus enable robust Route Optimization even
> in
>
> the absence of the home agent.
>
> Regards,
>
> - Georg
>
> ------------------------------------------------------------------------
>
>
>
*From:*Laganier, Julien [mailto:[e-mail]] *Sent:*
> Saturday, January 22, 2011 1:47 AM *To:* Hampel, K Georg (K Georg);
> [e-mail] *Cc:* Klein, Thierry E (Thierry) *Subject:* RE:
> Support of route optimization in *absence* of HA
>
> 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
>
> BellLaboratories
>
> 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.
>
>
>
> _______________________________________________ MEXT mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext