Diameter Maintenance and M. Liebsch Extensions (DIME) P. Loureiro Internet-Draft NEC Intended status: Standards Track J. Korhonen Expires: April 29, 2010 Nokia Siemens Network October 26, 2009 Local Mobility Anchor Resolution for PMIPv6 draft-liebsch-dime-pmip6-lmaresolve-01.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 April 29, 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. Liebsch, et al. Expires April 29, 2010 [Page 1] Internet-Draft LMA Resolution for PMIPv6 October 2009 Abstract The IETF is specifying Diameter extensions to support mobility service authorization and home network prefix allocation for Proxy Mobile IPv6. The protocol operates between a Local Mobility Anchor and a AAA server. Furthermore, the associated specification extends the existing protocol for network access service to support dynamic assignment and discovery of a Local Mobility Anchor during the authentication procedure. The AAA server maintains mobile nodes' profile in a policy store, which includes information about the assigned Local Mobility Anchor as well as the home network prefix. This document proposes a further extension to allow Local Mobility Anchors benefit from the AAA server's policy store and resolve an unknown mobile node's IP address into a routable address of its assigned Local Mobility Anchor. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Problem Statement and Reference Architecture . . . . . . . . . 5 4. Information Query extension to Diameter for LMA Resolution . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Liebsch, et al. Expires April 29, 2010 [Page 2] Internet-Draft LMA Resolution for PMIPv6 October 2009 1. Introduction The IETF specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as solution for network-based localized mobility management. While in host mobility solutions, such as Mobile IPv6 [RFC3775], the mobile node (MN) takes care about updating its routing state on a mobility anchor, in PMIPv6 a Mobility Access Gateway (MAG) recognizes an attachment of an MN and takes over the role of registering the MN at a selected Local Mobility Anchor (LMA). The base PMIPv6 protocol as per [RFC5213] specifies protocol operation between a MAG and an LMA for registration, de-registration and handover. The LMA is under control of assigning a unique IP address prefix (Home Network Prefix, HNP) to a registering MN and performs prefix-based forwarding of downlink data packets according to the MN's binding cache entry (BCE). The MAG, which performed the registration of the MN by means of sending a Proxy Binding Update (PBU) to the responsible LMA, is referred to as proxy care-of-address for the MN and the LMA forwards downlink data packets to the MN's MAG through an IP tunnel. The MAG forwards the packets to the MN by means of link mechanisms. [RFC5213] considers selection of a responsible LMA as well as sources for the assignment of an HNP to a registering MN at the LMA out of scope. [I-D.ietf-dime-pmip6] specifies extensions to the Network Access Server (NAS), which is collocated with a MAG in the access network, to retrieve an MN's policy profile and LMA information from a AAA server during access authentication. Furthermore, generic extensions to the Diameter protocol are specified for mobility service authorization and prefix delegation, which apply to the interface between an LMA and the AAA server. As MNs get assigned a unique prefix during the PMIPv6 registration and associated IP addresses may be from a virtual address space and remain anchored at the LMA, there is no efficient means to resolve an MN's virtual IP address into the routable address of the MN's LMA. This may be needed to support different use cases in a PMIPv6 domain, which utilizes multiple LMAs for load sharing or other purposes. Two exemplary use cases are referred to in Section 3. This document proposes a mechanism which further extends the generic Diameter protocol extension as per [I-D.ietf-dime-pmip6] to support the resolution of an MN's virtual IP address into the associated LMA's routable IP address. Liebsch, et al. Expires April 29, 2010 [Page 3] Internet-Draft LMA Resolution for PMIPv6 October 2009 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Liebsch, et al. Expires April 29, 2010 [Page 4] Internet-Draft LMA Resolution for PMIPv6 October 2009 3. Problem Statement and Reference Architecture Addressing of MNs in PMIPv6 [RFC5213] is based on the assignment of individual Home Network Prefixes to an MN during its registration with an LMA. An LMA may use a local prefix pool, DHCP or other means to retrieve a valid and unique HNP for an MN. In large PMIPv6 domains, multiple LMAs will serve MNs to ensure load distribution. In case of local communication within the PMIPv6 domain or even beyond a single PMIPv6 domain, a particular LMA has only forwarding information for destination MNs, which are registered with this particular LMA. For unknown destination prefixes, the LMA may forward data to a default gateway. In some scenarios it may be useful or even necessary for one LMA to discover the LMA of the destination MN. Hence, an LMA needs to resolve the destination MN's virtual IP address into the routable IP address of the destination MN's LMA. Figure 1 depicts this problem for the communication between MN1 and MN2, which are registered with LMA1 and LMA2 respectively. The reference architecture of this document assumes a NAS being collocated with the MAG on an access router, which performs Diameter protocol operation with a AAA server for access authentication and LMA discovery according to [I-D.ietf-dime-pmip6] (B1,B2 interface of Figure 1). Furthermore, the architecture assumes a Diameter client on each LMA for mobility service authorization and HNP delegation according to [I-D.ietf-dime-pmip6] (A1,A2 interface of Figure 1). Liebsch, et al. Expires April 29, 2010 [Page 5] Internet-Draft LMA Resolution for PMIPv6 October 2009 +---------+ +-------------->| AAA & |<--------------+ | +---->| Policy |<----+ | | | | Profile | | | | Diameter +---------+ Diameter | | A1 A2 | | | | | Diameter v v Diameter B1 +----+ LMA2? +----+ B2 | |LMA1| ------> |LMA2| | | +----+ +----+ | | | | | | // \\ | | // \\ | | // \\ | | | | | | +----+ +----+ | +---->|MAG1| |MAG2|<----+ +----+ +----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ Figure 1: Reference architecture Exemplary use cases for the resolution of an MN's (virtual) IP address into the anchor's node are as follows: o Local Routing: Two MNs, MN1 and MN2, which are attached to the same PMIPv6 domain but are registered with different LMAs, LMA1 and LMA2, communicate with each other. MN1 sends data to MN2 through its LMA1. Dependent on the nature of MN2's IP address prefix, LMA1 needs to resolve MN2's virtual IP address into a routable IP address, such as LMA2's address. LMA1 can use LMA2's IP address as forwarding information. o Route Optimization Signaling: The IETF's NetExt WG is specifying extensions to PMIPv6 for Route Optimization (Localized Routing) [I-D.ietf-netext-pmip6-lr-ps]. Associated scenarios include the communication between two MNs, MN1 and MN2, which are attached to the same PMIPv6 domain but are registered with different LMAs, LMA1 and LMA2. Protocol solutions for route optimization may require signaling between the two LMAs within the same PMIPv6 domain to set up a direct forwarding path between the two MNs' MAGs. As a result, data packets between the two MNs can be forwarded locally without traversing any LMA. In such case, LMA1 Liebsch, et al. Expires April 29, 2010 [Page 6] Internet-Draft LMA Resolution for PMIPv6 October 2009 may need to resolve MN2's virtual IP address into LMA2's routable IP address. LMA1 can now send signaling messages to LMA2. [RFC5213] assumes that the LMA is responsible for assigning an HNP to the MN during the PMIPv6 registration, but means to determine a unique HNP are out of scope of the specification. [I-D.ietf-dime-pmip6] specifies extensions to network access service to retrieve information about a responsible LMA for an MN during the MN's authentication procedure. Furthermore, generic protocol extensions to the Diameter protocol are specified to operate between an LMA, which implements a Diameter client, and the AAA server. These extensions are used to authorize mobility service for an MN after an LMA received a Proxy Binding Update (PBU) from the MN's MAG and to retrieve a valid and unique HNP for the MN from the AAA server. Figure 2 depicts the registration procedure of MN1 with LMA1 and of MN2 with LMA2 according to [I-D.ietf-dime-pmip6]. MN1 attaches to MAG1, whereas MN2 attaches to MAG2. As a result of mobility service authorization, MN1 gets assigned HNP1, whereas MN2 gets assigned HNP2. Liebsch, et al. Expires April 29, 2010 [Page 7] Internet-Draft LMA Resolution for PMIPv6 October 2009 +---+ +---+ +----+ +----+ +----+ +---+ +----+ |MN1| |MN2| |MAG1| |MAG2| |LMA1| |AAA| |LMA2| +---+ +---+ +----+ +----+ +----+ +---+ +----+ | | | | | | | | | | | | | | |- attach- -| | | | | | | |-----AA-Request[MN1]---------------->| | | | |<----AA-Answer[LMA1]-----------------| | | | |----PBU[MN1]--->| | | | | | | |----AA-Req[MN1]---->| | | | | | | [Authorization] | | | | | |<--AA-Answer[HNP1]--| | | | |<---PBA[HNP1]---| | | | | | | | | | | |- -attach - | | | | | | | |----------AA-Request[MN2]--->| | | | | |<---------AA-Answer[LMA2]----| | | | | |-------------PBU[MN2]----------------------->| | | | | | |<-AA-Req[MN2]--| | | | | | | [Authoriz.] | | | | | |-AA-Ans[HNP2]->| | | | |<------------PBA[HNP2]-----------------------| | | | | | | | | | | | | | | | | | | | | | Figure 2: MN Authentication, LMA discovery, service authorization and Prefix delegation in a multi-LMA scenario Liebsch, et al. Expires April 29, 2010 [Page 8] Internet-Draft LMA Resolution for PMIPv6 October 2009 4. Information Query extension to Diameter for LMA Resolution According to [I-D.ietf-dime-pmip6], the AAA server is a suitable entity to maintain MNs' profile information and to store further dynamically assigned information during an MN's mobility session. Such information includes the assigned LMA and the HNP, which has been assigned to the MN during access authorization. This makes the AAA server a suitable information database for trusted Diameter clients to request some information from the policy store. This document proposes an extension to the Diameter protocol interface as per [I-D.ietf-dime-pmip6] to support resolving an MN's HNP into its LMA's IP address by means of a new message type INFO_QUERY. Any Diameter client, which is associated with the AAA server, may send an INFO_QUERY to the AAA server, having the unknown MN's HNP or complete IP address included. The AAA server performs a lookup in its policy store and a longest prefix match to resolve the HNP into the associated LMA's IP address. Subsequently, the AAA server replies to the requesting Diameter client with an INFO_RESPONSE (INFO_RESP), including the requested binding between the unknown MN's HNP and its assigned LMA's IP address. Now, the requesting LMA can contact the unknown LMA directly for signaling reasons or take the resolved IP address as forwarding information for data packets. Figure 3 illustrates exemplarily the resolution of the IP address/HNP of MN2, which is registered with LMA2, into the IP address of LMA2 with the help of the proposed LMA Resolution extension to Diameter. MN1 sends a data packet to MN2, which traverses MN1's LMA1. In case LMA1 needs to know a routable IP address of MN2's mobility anchor, LMA1 performs LMA Resolution with the AAA server to resolve MN2's IP address/HNP (IP MN2) into LMA2's IP address (IP LMA2). Liebsch, et al. Expires April 29, 2010 [Page 9] Internet-Draft LMA Resolution for PMIPv6 October 2009 +---+ +----+ +----+ +---+ +----+ |MN1| |MAG1| |LMA1| |AAA| |LMA2| +---+ +----+ +----+ +---+ +----+ | data | data | | | |- - - - ->|-==========->| | | | | |--INFO_QUERY[IP MN2]->| | | | | | | | | |<--INFO_RESP[IP LMA2]-| | | | | | | | | |-----data/signaling----------------->| | | | | | | | | | | Figure 3: LMA resolution at a AAA server In large domains, multiple AAA servers may distribute load. To assign a unique HNP to registering MNs, AAA servers may use administratively assigned prefix pools. In such case, it may happen that an LMA tries to resolve an unknown MN's IP/HNP into the associated LMA's IP address, but the requested AAA server does not have an entry for the unknown MN as well. Here, the concept of the Diameter redirect agent [RFC3588] may help to support LMA resolution beyond the scope of a single AAA server. Such an architecture is illustrated in Figure 4. Liebsch, et al. Expires April 29, 2010 [Page 10] Internet-Draft LMA Resolution for PMIPv6 October 2009 +------------------------------------+ ( AAA ) ( +--------+ Backend ) ( |Redirect| ) ( | Agent | ) ( +--------+ ) ( ^ ) ( | ) ( | ) ( v ) ( +---------+ +---------+ ) +---->| AAA1 & | | AAA2 & |<---+ | ( | Policy |<-------->| Policy | ) | | ( | Profile | | Profile | ) | | ( +---------+ +---------+ ) | | ( ^ ^ ) | | +----- | ------------------- |-------+ | | A1 A2 | | | | | | | | | Diameter v v Diameter B1 +----+ LMA2 ? +----+ B2 | |LMA1| ------> |LMA2| | | +----+ +----+ | | | | | | // \\ | | // \\ | | // \\ | | | | | | +----+ +----+ | +---->|MAG1| |MAG2|<----+ +----+ +----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ Figure 4: Use of a Diameter redirect agent to support LMA resolution in networks with multiple AAA servers Referring to an architecture with multiple AAA servers according to Figure 4, AAA1 may not be able to resolve the HNP of MN2 into the IP address of LMA2, as AAA2 holds this information in its policy store. In such case, AAA1 contacts a Diameter redirect agent [RFC3588] to request the AAA server being responsible for the assignment from the address space where MN2's HNP belongs to. The redirect agent informs Liebsch, et al. Expires April 29, 2010 [Page 11] Internet-Draft LMA Resolution for PMIPv6 October 2009 AAA1 about AAA2's address in a Redirection Notification message, which allows AAA1 to forward the INFO_QUERY to AAA2. AAA2 resolves MN2's HNP into the IP address of LMA2 and sends the results back in an INFO_RESPONSE message to LMA2 via AAA1. Details about the use of redirection agents in this context are for further study. Liebsch, et al. Expires April 29, 2010 [Page 12] Internet-Draft LMA Resolution for PMIPv6 October 2009 5. Security Considerations As LMA resolution according to this draft is performed between a Diameter client on an LMA and the AAA server using the Diameter protocol, an existing security association between the LMA and the AAA server can be assumed to protect the new signaling messages. One important difference to the existing protocol operation between a Diameter client and the Diameter server according to [I-D.ietf-dime-pmip6] is that the requesting LMA cannot include a Diameter Session-ID or the MNID of the MN, whose HNP should be resolved into an anchor address (MN2), in the INFO_QUERY message. The AAA server must rather use the HNP or the IP address of MN2 as key to perform a lookup in its policy store. Since the requesting Diameter client on the LMA and the AAA server share a trust relationship and associated signaling can be protected, there should be no security threat with such operation. Liebsch, et al. Expires April 29, 2010 [Page 13] Internet-Draft LMA Resolution for PMIPv6 October 2009 6. Acknowledgments Many thanks to Rafael Richter for his valuable input on AAA-based anchor resolution. May thanks to Glen Zorn, Dan Romascanu, Hannes Tschofenig and Qin Wu for their valuable comments on the initial version of this draft. Liebsch, et al. Expires April 29, 2010 [Page 14] Internet-Draft LMA Resolution for PMIPv6 October 2009 7. References 7.1. Normative References [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-04 (work in progress), September 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 7.2. Informative References [I-D.ietf-netext-pmip6-lr-ps] Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized Routing Problem Statement", draft-ietf-netext-pmip6-lr-ps-00 (work in progress), September 2009. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Liebsch, et al. Expires April 29, 2010 [Page 15] Internet-Draft LMA Resolution for PMIPv6 October 2009 Authors' Addresses Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: liebsch@nw.neclab.eu Paulo Loureiro NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342177 Email: loureiro@nw.neclab.eu Jouni Korhonen Nokia Siemens Network Linnoitustie 6 Espoo FI-02600 Finland Email: jouni.nospam@gmail.com Liebsch, et al. Expires April 29, 2010 [Page 16]