One document matched: draft-korhonen-netlmm-lma-discovery-00.txt

Network-based Localized Mobility                             J. Korhonen
Management (NetLMM)                                          TeliaSonera
Internet-Draft                                            V. Devarapalli
Intended status: Informational                                  WiChorus
Expires: April 13, 2009                                 October 10, 2008


                  LMA Discovery for Proxy Mobile IPv6
               draft-korhonen-netlmm-lma-discovery-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 13, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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 specification describes a number of
   possible dynamic Local Mobility Anchor discovery solutions.



Korhonen & Devarapalli   Expires April 13, 2009                 [Page 1]

Internet-Draft                LMA Discovery                 October 2008


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.  Lower Layers based Discovery Solutions  . . . . . . . . . . . . 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.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

































Korhonen & Devarapalli   Expires April 13, 2009                 [Page 2]

Internet-Draft                LMA Discovery                 October 2008


1.  Introduction

   Large Proxy Mobile IPv6 (PMIPv6) [1] deployments would benefit from a
   functionality, where a Mobile Access Gateway (MAG) could 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.  This specification describes a number of possible dynamic LMA
   discovery solutions.

   There are a number of different ways for dynamically discovering the
   LMA at the MAG.  The following list briefly introduces solutions that
   will be discussed in this specification:

   o  LMA Address from AAA during the network access authentication
      procedure when the MN attaches to the MAG.

   o  LMA FQDN from AAA during the network access authentication,
      followed by a DNS lookup.

   o  LMA FQDN 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 received from the lower layers during the
      network attachment followed by an optional DNS lookup.

   o  LMA FQDN 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 used by the new
   MAG should be able to return the information about 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
   be connected to an AAA infrastructure.  The AAA infrastructure is
   also assumed to be aware of and support PMIPv6 functionality.  A MN
   attaching to a PMIPv6 domain is typically required to authenticate to
   the network access and to be authorized for the mobility services
   before the MN is allowed to send or receive any IP packets or even
   complete its IP level configuration.




Korhonen & Devarapalli   Expires April 13, 2009                 [Page 3]

Internet-Draft                LMA Discovery                 October 2008


   The AAA-based LMA discovery solution hooks into the network access
   authentication and authorization procedure.  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 at the same time the MN is authenticated for the network
   access and authorized for the mobility services using the AAA
   infrastructure.  The PMIPv6 parameters bootstrapping involves the
   Policy Profile download over the AAA infrastructure to the MAG.  The
   procedure for the Policy Profile download resembles largely the
   client Mobile IPv6 Integrated Scenario bootstrapping [2].

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(es) from the AAA server over the AAA infrastructure.  The LMA
   IP address information would be part of the AAA message(s) that ends
   the successful authentication and authorization AAA exchange.

   Once the MAG receives the LMA IP address(es), it sends Proxy Binding
   Update (PBU) message for the newly authenticated and authorized MN.
   The MAG trusts 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 the MN already has a mobility session set
   up with.

2.2.  Receiving LMA FQDN during the Network Access Authentication

   This solution is identical to the procedure described in Section 2.1.
   The difference is that the MAG receives a Fully Qualified Domain Name
   (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 to a PMIPv6 domain resolving to one
   or more LMAs in the said domain.  Alternatively the LMA FQDN might
   resolve 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,
   return the LMA IP address during the subsequent attachments to other
   MAGs in the PMIPv6 domain.  In order 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 update once it receives the



Korhonen & Devarapalli   Expires April 13, 2009                 [Page 4]

Internet-Draft                LMA Discovery                 October 2008


   initial PBU from the MAG for the new mobility session.


3.  Lower Layers based Discovery Solutions

   The following section discusses solutions, where the MAG receives
   information from lower layers below the IP layer when the MN attaches
   to the MAG.  Based on this information, the MAG is then able to
   determine which LMA to contact.  These solution could essentially
   allow large PMIPv6 deployments without the AAA infrastructure.  The
   lower layers discussed here are not explicitly defined but could
   include different radio access technologies and tunneling solutions
   such as IKEv2 [3] IPsec tunnel [4].

3.1.  Constructing the LMA FQDN from a mobile node Identity

   Depending on the actual network access technology, the MAG may be
   able to receive a MN identity (or actually the subscription identity
   but from now on we assume that the MN identity equals to the
   subscription identity, which is a rather broad simplification) as a
   result of the network access attachment procedure.  The MN may signal
   its identity as part of the attachment signaling or alternatively the
   MAG receives the MN identity from a remote policy store.

   Once the MAG has acquired the MN identity, 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 elements that can be extracted and at
   minimum used to determine the entity hosting and operating the LMA
   for the MN.  Thus the MN identity in this solution cannot be a "flat"
   identity without any structure and "clear text" parts containing the
   hosting entity information.  Examples of such identities are the
   International Mobile Subscriber Identity (IMSI) or Globally Unique
   Temporary User Equipment Identity (GUTI) [5] that both contain
   information of the operator owning the given subscription.

   The solution discussed in this section has issues if MN's identity
   does not embed enough information.  In a case the MN identity does
   not embed any LMA hosting entity information, the MAG might use a
   local database to map MN identities to corresponding LMAs.  However,
   this solution is unlikely to scale outside a limited PMIPv6 domain.

3.2.  Receiving LMA FQDN or IP Address from Lower Layers

   The solution described in this section is similar to the solution
   discussed in Section 3.1.  Instead of deriving the LMA FQDN from the
   MN identity, the MAG receives explicit LMA FQDN or IP address



Korhonen & Devarapalli   Expires April 13, 2009                 [Page 5]

Internet-Draft                LMA Discovery                 October 2008


   information from lower layers.  This usually means the MN is the
   originator of the LMA information and explicitly participates to the
   mobility management signaling (even if that only means providing LMA
   discovery assisting information).

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 identification information it wants
   to access.  If the MN originated service name or external network
   information also embeds the information of the entity hosting the
   service or the external network, then the MAG can construct a generic
   LMA FQDN (based on some pre-configured formatting rules) providing an
   access to the service or the external network.  Once the MAG has the
   FQDN it can proceed to resolve the LMA IP address(es) using the DNS.
   Example of such service or external network name is the Access Point
   Name (APN) [5] that contain information of the operator providing the
   access to the given service or the external network.


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 [6].  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.  Obviously, relying on DNS
   during handovers is not a working solution if the PMIPv6 domain has
   more than one LMA.  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.

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

   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





Korhonen & Devarapalli   Expires April 13, 2009                 [Page 6]

Internet-Draft                LMA Discovery                 October 2008


5.  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 RFC 5026 [8].  However, the risks described in RFC
   5026 are mitigated to a large extent in this document, since the MAG
   and the LMA belong 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.
   RFC 5213 [1] specifies the use of IKEv2 [3] 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.


6.  IANA Considerations

   This specification has no actions for IANA.


7.  Informative References

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

   [2]  Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K.
        Chowdhury, "Diameter Mobile IPv6: Support for Network Access
        Server to Diameter Server  Interaction",
        draft-ietf-dime-mip6-integrated-10 (work in progress),
        September 2008.

   [3]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
        December 2005.

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

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

   [6]  Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia,



Korhonen & Devarapalli   Expires April 13, 2009                 [Page 7]

Internet-Draft                LMA Discovery                 October 2008


        "Fast Handovers for PMIPv6", draft-yokota-mipshop-pfmipv6-03
        (work in progress), July 2008.

   [7]  Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K., and U.
        Meyer, "Diameter Proxy Mobile IPv6: Support For Mobile Access
        Gateway and Local  Mobility Anchor to Diameter Server
        Interaction", draft-korhonen-dime-pmip6-04 (work in progress),
        September 2008.

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


Authors' Addresses

   Jouni Korhonen
   TeliaSonera Corporation
   P.O.Box 970
   FIN-00051 Sonera
   Finland

   Email: jouni.korhonen@teliasonera.com


   Vijay Devarapalli
   WiChorus
   3950 North First Street
   San Jose, CA 95134
   USA

   Email: vijay@wichorus.com




















Korhonen & Devarapalli   Expires April 13, 2009                 [Page 8]

Internet-Draft                LMA Discovery                 October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Korhonen & Devarapalli   Expires April 13, 2009                 [Page 9]