Network-based Localized Mobility J. Korhonen Management (NetLMM) Nokia Siemens Networks Internet-Draft V. Devarapalli Intended status: Informational WiChorus Expires: March 6, 2010 September 2, 2009 LMA Discovery for Proxy Mobile IPv6 draft-ietf-netlmm-lma-discovery-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 March 6, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Large Proxy Mobile IPv6 deployments would benefit from a functionality, where a Mobile Access Gateway could dynamically Korhonen & Devarapalli Expires March 6, 2010 [Page 1] Internet-Draft LMA Discovery September 2009 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. 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 . . . . 6 3.3. Constructing the LMA FQDN from a Service Name . . . . . . 6 4. Domain Name System Considerations . . . . . . . . . . . . . . 6 5. Handover Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Korhonen & Devarapalli Expires March 6, 2010 [Page 2] Internet-Draft LMA Discovery September 2009 1. Introduction Large Proxy Mobile IPv6 (PMIPv6) [RFC5213] 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. Other drivers for the dynamic discovery of a LMA include LMA load balancing solutions and selecting LMA based on desired services (i.e. allowing service-specific routing of traffic). This document 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 Domain Name System (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 Korhonen & Devarapalli Expires March 6, 2010 [Page 3] Internet-Draft LMA Discovery September 2009 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 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 [RFC5447]. 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 Korhonen & Devarapalli Expires March 6, 2010 [Page 4] Internet-Draft LMA Discovery September 2009 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 update once it receives the 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 [RFC4306] IPsec tunnel [RFC4303]. 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) [3GPP.23.003] 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. Korhonen & Devarapalli Expires March 6, 2010 [Page 5] Internet-Draft LMA Discovery September 2009 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 a LMA FQDN or an IP address information from lower layers, for example, as a part of the normal lower layer signaling when the MN attaches to the network. One existing example of such lower layer functionality 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 to the MN, meaning the MN has no knowledge it being anything LMA related. 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. 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 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. 4. Domain Name System Considerations A number of LMA discovery solutions described in Section 2 and Section 3 eventually depend on the DNS. This section discusses impacts of the DNS response caching and issues related to the Dynamic DNS [RFC2136] updates. The caching (positive or negative) properties of the DNS [RFC2308] and the fact that updates to the DNS take time to propagate globally, need to be considered when applying DNS-based solutions to the PMIPv6 domain. First, the caching of DNS responses effectively delay the propagation of up to date FQDN to IP address mappings (after both Korhonen & Devarapalli Expires March 6, 2010 [Page 6] Internet-Draft LMA Discovery September 2009 addition and deletion). Hosts in the PMIPv6 domain keep using the stale cached DNS response (positive or negative) until they give up or the caching times out. The delay can be in order of hours in the worst case. On the other hand, DNS administrators can lower the resource record caching time (the Time To Live (TTL) value). Obviously, too low TTL values increase the number of DNS queries considerably. Second, the secondary DNS servers do not get immediately updated when the masters do. These updates are also periodic, usually in order of several hours, and may cause considerable delay on global propagation of the updated naming information. Third, some DNS resolvers ignore low TTLs, replacing them with a higher default value. This could lead to outdated LMA information being around for longer than desired. The above considerations are valid when, for example, the PMIPv6 domain LMA availability or load information is dynamically updated into the DNS. There are incentives for doing so, however, the concerns described above need to be understood clearly in that case. 5. 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 [I-D.ietf-mipshop-pfmipv6]. 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 parameters). Another alternative could that MAG uses, 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. Korhonen & Devarapalli Expires March 6, 2010 [Page 7] Internet-Draft LMA Discovery September 2009 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 [I-D.ietf-dime-pmip6]. 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 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 RFC 5026 [RFC5026]. 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 [RFC5213] specifies the use of IKEv2 [RFC4306] 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 specification has no actions for IANA. 8. Acknowledgements The authors would like to thank Julien Laganier, Christian Vogt, Ryuji Wakikawa, Frank Xia, Behcet Sarikaya and Xiangsong Cui for their comments, extensive discussions and suggestions on this document. Korhonen & Devarapalli Expires March 6, 2010 [Page 8] Internet-Draft LMA Discovery September 2009 9. Informative References [3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 8.2.0, September 2008. [3GPP.24.008] 3GPP, "Mobile radio interface Layer 3 specification", 3GPP TS 24.008 8.6.0, June 2009. [I-D.ietf-dime-pmip6] 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", draft-ietf-dime-pmip6-03 (work in progress), August 2009. [I-D.ietf-mipshop-pfmipv6] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", draft-ietf-mipshop-pfmipv6-08 (work in progress), July 2009. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [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. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Korhonen & Devarapalli Expires March 6, 2010 [Page 9] Internet-Draft LMA Discovery September 2009 Network Access Server to Diameter Server Interaction", RFC 5447, February 2009. Authors' Addresses Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FIN-02600 Espoo Finland Email: jouni.nospam@gmail.com Vijay Devarapalli WiChorus 3950 North First Street San Jose, CA 95134 USA Email: vijay@wichorus.com Korhonen & Devarapalli Expires March 6, 2010 [Page 10]