Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6
draft-ietf-netlmm-lma-discovery-08

Network-based Localized Mobility                             J. Korhonen
Management (NetLMM)                               Nokia Siemens Networks
Internet-Draft                                            V. Devarapalli
Intended status: Informational                           Vasona Networks
Expires: April 25, 2011                                 October 22, 2010

                  LMA Discovery for Proxy Mobile IPv6
                 draft-ietf-netlmm-lma-discovery-08.txt

Abstract

   Large Proxy Mobile IPv6 deployments would benefit from a
   functionality, where a Mobile Access Gateway could dynamically
   discover a Local Mobility Anchor for a Mobile Node attaching to a
   Proxy Mobile IPv6 domain.  The purpose of the dynamic discovery
   functionality is to reduce the amount of static configuration in the
   Mobile Access Gateway.  This document describes several possible
   dynamic Local Mobility Anchor discovery solutions.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 25, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Korhonen & Devarapalli   Expires April 25, 2011                 [Page 1]
Internet-Draft                LMA Discovery                 October 2010

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  AAA-based Discovery Solutions . . . . . . . . . . . . . . . . . 3
     2.1.  Receiving LMA Address during the Network Access
           Authentication  . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Receiving LMA FQDN during the Network Access
           Authentication  . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Discovery Solutions based on Data from Lower Layers . . . . . . 5
     3.1.  Constructing the LMA FQDN from a Mobile Node Identity . . . 5
     3.2.  Receiving LMA FQDN or IP Address from Lower Layers  . . . . 5
     3.3.  Constructing the LMA FQDN from a Service Name . . . . . . . 6
   4.  Handover Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Korhonen & Devarapalli   Expires April 25, 2011                 [Page 2]
Internet-Draft                LMA Discovery                 October 2010

1.  Introduction

   A Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would benefit from
   a functionality, where a Mobile Access Gateway (MAG) can dynamically
   discover a Local Mobility Anchor (LMA) for a Mobile Node (MN)
   attaching to a PMIPv6 domain.  The purpose of the dynamic discovery
   functionality is to reduce the amount of static configuration in the
   MAG.  Other drivers for the dynamic discovery of a LMA include LMA
   load balancing solutions and selecting a LMA based on desired
   services (i.e. allowing service-specific routing of traffic)
   [RFC5149].  This document describes several possible dynamic LMA
   discovery approaches and makes a recommendation of the preferred one.

   The following list briefly introduces solution approaches that will
   be discussed in this document.  The approaches discussed do not
   include all possible discovery mechanisms, but are limited to those
   considered to fit most simply into the PMIPv6 environment.

   o  LMA Address is retrieved from the Authentication, Authorization
      and Accounting (AAA) infrastructure during the network access
      authentication procedure when the MN attaches to the MAG.

   o  LMA Fully Qualified Domain Name (FQDN) is retrieved from the AAA
      infrastructure during the network access authentication, followed
      by a Domain Name System (DNS) lookup.

   o  LMA FQDN is derived from the MN identity received from the lower
      layers during the network attachment, followed by a DNS lookup.

   o  LMA FQDN or IP address is received from the lower layers during
      the network attachment.  The reception of an FQDN from the lower
      layers is followed by a DNS lookup.

   o  LMA FQDN is derived from the service selection indication received
      from lower layers during the network attachment, followed by a DNS
      lookup.

   When a MN performs a handover from one MAG to another, the new MAG
   must use the same LMA that the old MAG was using.  This is required
   for session continuity.  The LMA discovery mechanism in the new MAG
   should be able to return the information of the same LMA that was
   being used by the old MAG.  This document also discusses solutions
   for LMA discovery during a handover.

2.  AAA-based Discovery Solutions

   This section presents a LMA discovery solution that requires a MAG to

Korhonen & Devarapalli   Expires April 25, 2011                 [Page 3]
Internet-Draft                LMA Discovery                 October 2010

   be connected to an AAA infrastructure for instance as described in
   [RFC5779].  The AAA infrastructure is also assumed to be aware of
   PMIPv6.  A MN attaching to a PMIPv6 domain is typically required to
   provide authentication for network access and to be authorized for
   mobility services before the MN is allowed to send or receive any IP
   packets or even complete its IP level configuration.

   The AAA-based LMA discovery solution hooks into the network access
   authentication and authorization process.  The MAG has also the role
   of a Network Access Server (NAS) at this step.  While the MN is
   attaching to the network, the PMIPv6 related parameters are
   bootstrapped in parallel with authentication for the network access
   and authorization for the mobility services.  The PMIPv6 parameters
   bootstrapping involves the Policy Profile download over the AAA
   infrastructure to the MAG (see Appendix A of [RFC5213]).

2.1.  Receiving LMA Address during the Network Access Authentication

   After the MN has successfully authenticated for the network access
   and authorized for the mobility service, the MAG receives the LMA IP
   address from the AAA server over the AAA infrastructure.  The LMA IP
   address information would be part of the AAA message that ends the
   successful authentication and authorization AAA exchange.

   Once the MAG receives the LMA IP address, it sends Proxy Binding
   Update (PBU) message for the newly authenticated and authorized MN.
   The MAG expects that the LMA returned by the AAA server is able to
   provide mobility session continuity for the MN, i.e. after a handover
   the LMA would be the same one the MN already has a mobility session
   set up with.

2.2.  Receiving LMA FQDN during the Network Access Authentication

   This solution is similar to the procedure described in Section 2.1.
   The difference is that the MAG receives an FQDN of the LMA instead of
   the IP address(es).  The MAG has to query the DNS infrastructure in
   order to resolve the FQDN to the LMA IP address(es).

   The LMA FQDN might be a generic name for a PMIPv6 domain that
   resolves to one or more LMAs in the PMIPv6 domain.  Alternatively the
   LMA FQDN might be resolved to exactly one LMA within the PMIPv6
   domain.  The latter approach would obviously be useful if a new
   target MAG after a handover should resolve the LMA FQDN to the LMA IP
   address where the MN mobility session is already located.

   The procedures described in this section and in Section 2.1 may also
   be used together.  For example, the AAA server might return a generic
   LMA FQDN during the MN initial attach and once the LMA gets selected,

Korhonen & Devarapalli   Expires April 25, 2011                 [Page 4]
Internet-Draft                LMA Discovery                 October 2010

   return the LMA IP address during the subsequent attachments to other
   MAGs in the PMIPv6 domain.  In order for this to work, the resolved
   and selected LMA IP address must be updated to the remote Policy
   Store.  For example, the LMA could perform the Policy Store update
   using the AAA infrastructure once it receives the initial PBU from
   the MAG for the new mobility session.

3.  Discovery Solutions based on Data from Lower Layers

   The following section discusses solutions, where a MAG acquires
   information from layers below the IP layer.  Based on this
   information, the MAG is able to determine which LMA to contact when
   the MN attaches to the MAG.  The lower layers discussed here are not
   explicitly defined but include different radio access technologies
   and tunneling solutions such as an IKEv2 [RFC5996] IPsec tunnel
   [RFC4303].

3.1.  Constructing the LMA FQDN from a Mobile Node Identity

   A MAG acquires a MN identity from lower layers.  The MAG can use the
   information embedded in the identity to construct a generic LMA FQDN
   (based on some pre-configured formatting rules) and then proceed to
   resolve the LMA IP address(es) using the DNS.  Obviously, the MN
   identity must embed information that can be used to uniquely identify
   the entity hosting and operating the LMA for the MN.  Examples of
   such MN identities are the International Mobile Subscriber Identity
   (IMSI) and Globally Unique Temporary User Equipment Identity (GUTI)
   [3GPP.23.003].  These MN identities contain information that can
   uniquely identify the operator where the subscription belongs to.

3.2.  Receiving LMA FQDN or IP Address from Lower Layers

   The solution described here is similar to the solution discussed in
   Section 3.1.  A MAG receives a LMA FQDN or an IP address from lower
   layers, for example, as a part of the normal lower layer signaling
   when the MN attaches to the network.  IKEv2 could be existing example
   of such lower layer signaling where IPsec is the "lower layer" for
   the MN [3GPP.24.302].  IKEv2 has an IKEv2 IDr payload, which is used
   by the IKEv2 initiator (i.e. the MN in this case) to specify which of
   the responder's identities (i.e. the LMA in this case) it wants to
   talk to.  And here the responder identity could be an FQDN or an IP
   address of the LMA (as the IKEv2 identification payload can be an IP
   address or an FQDN).  Another existing example is the Access Point
   Name Information Element (APN IE) in 3GPP radio's network access
   signaling capable of carrying a FQDN [3GPP.24.008].  However, in
   general this means the MN is also the originator of the LMA
   information.  The LMA information content as such can be transparent

Korhonen & Devarapalli   Expires April 25, 2011                 [Page 5]
Internet-Draft                LMA Discovery                 October 2010

   to the MN, meaning the MN does not associate the information with any
   LMA function.

3.3.  Constructing the LMA FQDN from a Service Name

   Some network access technologies (including tunneling solutions)
   allow the MN to signal the service name that identifies a particular
   service or the external network it wants to access [3GPP.24.302]
   [RFC5996].  If the MN originated service name also embeds the
   information of the entity hosting the service or the hosting
   information can be derived from other information available at the
   same time (e.g., see Section 3.1), then the MAG can construct a
   generic LMA FQDN (e.g., based on some pre-defined formatting rules)
   providing an access to the service or the external network.  The pre-
   defined formatting rules [3GPP.23.003] are usually agreed on among
   operators that belong to the same inter-operator roaming consortium
   or by network infrastructure vendors defining an open networking
   system architecture.

   Once the MAG has the FQDN it can proceed to resolve the LMA IP
   address(es) using the DNS.  An example of such service or external
   network name is the Access Point Name (APN) [3GPP.23.003] that
   contain information of the operator providing the access to the given
   service or the external network.  For example, an FQDN for an "ims"
   APN could be "ims.apn.epc.mnc015.mcc234.3gppnetwork.org".

4.  Handover Considerations

   Whenever a MN moves and attaches to a new MAG in a PMIPv6 domain, all
   the MAGs that the MN attaches to, should use the same LMA.  If there
   is only one LMA per PMIPv6 domain, then there is no issue.  If there
   is a context transfer mechanism available between the MAGs, then the
   new MAG knows the LMA information from the old MAG.  Such a mechanism
   is described in [RFC5949].  If the MN related context is not
   transferred between the MAGs, then a mechanism to deliver the current
   LMA information to the new MAG is required.

   Relying on DNS during handovers is not generally a working solution
   if the PMIPv6 domain has more than one LMA, unless the DNS
   consistently assigns a specific LMA for each given MN.  In most cases
   described in Section 3, where the MAG derives the LMA FQDN, there is
   no prior knowledge whether the LMA FQDN resolves to one or more LMA
   IP address(es) in the PMIPv6 domain.  However, depending on the
   deployment and deployment related regulation (such as inter-operator
   roaming consortium agreements) the situation might not be this
   desperate.  For example, a MAG might be able to synthesize a LMA
   specific FQDN (e.g. out of MN identity or some other service specific

Korhonen & Devarapalli   Expires April 25, 2011                 [Page 6]
Internet-Draft                LMA Discovery                 October 2010

   parameters).  Alternatively, the MAG could use (for example), a MN
   identity as an input to an algorithm that deterministically assigns
   the same LMA out of a pool of LMAs (assuming the MAG has e.g. learned
   a group of LMA FQDNs via SRV [RFC2782] query).  These approaches
   would guarantee that DNS returns always the same LMA Address to the
   MAG.

   Once the MN completes its initial attachment to a PMIPv6 domain, the
   information about the LMA that is selected to serve the MN is stored
   in the Policy Store (or the AAA server).  The LMA information is
   conveyed to the policy store by the LMA after the initial attachment
   is completed [RFC5779].  Typically AAA infrastructure is used for
   exchanging information between the LMA and the Policy Store.

   When the MN moves and attaches to another MAG in the PMIPv6 domain,
   then the AAA servers delivers the existing LMA information to the new
   MAG as part of the authentication and authorization procedure as
   described in Section 2.1

5.  Recommendations

   This document discussed several solution approaches for a dynamic LMA
   discovery.  All discussed solution approaches actually require
   additional functionality or infrastructure support that the base
   PMIPv6 [RFC5213] does not require.

   Solutions in Section 3 all depend on lower layers being able to
   provide information that a MAG can then use to query DNS and discover
   a suitable LMA.  The capabilities of the lower layers and the
   interactions with them are generally out of scope of IETF, and
   specific to a certain system and architecture.

   Solutions in Section 2 depend on the existence of an AAA
   infrastructure, which is able to provide a MAG either a LMA IP
   address or a LMA FQDN.  While there can be system and architecture
   specific details regarding the AAA interactions and the use of DNS,
   the dynamic LMA discovery can be implemented in an access and
   technology agnostic manner, and work in the same way across
   heterogeneous environments.  Therefore, using AAA based LMA discovery
   solutions are recommended by this document.  Furthermore, following
   the guidance in Section 4.1 of [RFC1958] the use of FQDNs should be
   preferred over IP addresses in the context of AAA based LMA discovery
   solutions.

Korhonen & Devarapalli   Expires April 25, 2011                 [Page 7]
Internet-Draft                LMA Discovery                 October 2010

6.  Security Considerations

   The use of DNS for obtaining the IP address of a mobility agent
   carries certain security risks.  These are explained in detail in
   Section 9.1 of [RFC5026].  However, the risks described in [RFC5026]
   are mitigated to a large extent in this document, since the MAG and
   the LMA belong to the same PMIPv6 domain.  The DNS server that the
   MAG queries is also part of the same PMIPv6 domain.  Even if the MAG
   obtains the IP address of a bogus LMA from a bogus DNS server,
   further harm is prevented since the MAG and the LMA should
   authenticate each other before exchanging PMIPv6 signaling messages.
   [RFC5213] specifies the use of IKEv2 between the MAG and the LMA to
   authenticate each other and setup IPsec security associations for
   protecting the PMIPv6 signaling messages.

   The AAA infrastructure may be used to transport the LMA discovery
   related information between the MAG and the AAA server via one or
   more AAA brokers and/or AAA proxies.  In this case the MAG to the AAA
   server communication relies on the security properties of the
   intermediate AAA brokers and AAA proxies.

7.  IANA Considerations

   This document has no actions for IANA.

8.  Acknowledgements

   The authors would like to thank Julien Laganier, Christian Vogt,
   Ryuji Wakikawa, Frank Xia, Behcet Sarikaya, Charlie Perkins, Qin Wu,
   Jari Arkko and Xiangsong Cui for their comments, extensive
   discussions and suggestions on this document.

9.  References

9.1.  Normative References

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

9.2.  Informative References

   [3GPP.23.003]
              3GPP, "Numbering, addressing and identification", 3GPP
              TS 23.003 8.2.0, September 2008.

Korhonen & Devarapalli   Expires April 25, 2011                 [Page 8]
Internet-Draft                LMA Discovery                 October 2010

   [3GPP.24.008]
              3GPP, "Mobile radio interface Layer 3 specification", 3GPP
              TS 24.008 8.6.0, June 2009.

   [3GPP.24.302]
              3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via
              non-3GPP access networks", 3GPP TS 24.302 10.0.0,
              June 2010.

   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5026]  Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
              Bootstrapping in Split Scenario", RFC 5026, October 2007.

   [RFC5149]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
              Selection for Mobile IPv6", RFC 5149, February 2008.

   [RFC5779]  Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
              and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
              Gateway and Local Mobility Anchor Interaction with
              Diameter Server", RFC 5779, February 2010.

   [RFC5949]  Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
              Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
              September 2010.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

Korhonen & Devarapalli   Expires April 25, 2011                 [Page 9]
Internet-Draft                LMA Discovery                 October 2010

Authors' Addresses

   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   FIN-02600 Espoo
   Finland

   Email: jouni.nospam@gmail.com

   Vijay Devarapalli
   Vasona Networks

   Email: dvijay@gmail.com

Korhonen & Devarapalli   Expires April 25, 2011                [Page 10]