Diameter Maintenance and M. Liebsch Extensions (DIME) P. Loureiro Internet-Draft NEC Intended status: Standards Track J. Korhonen Expires: September 5, 2009 Nokia Siemens Network March 4, 2009 Local Mobility Anchor Resolution for PMIPv6 draft-liebsch-dime-pmip6-lmaresolve-00.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 September 5, 2009. 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 (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. Liebsch, et al. Expires September 5, 2009 [Page 1] Internet-Draft LMA Resolution for PMIPv6 March 2009 Abstract The IETF is specifying a new Diameter Application 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 an extension to the Diameter PMIPv6 Application 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. LMA Resolution Extension to the Diameter PMIPv6 Application . 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 September 5, 2009 [Page 2] Internet-Draft LMA Resolution for PMIPv6 March 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, a new Diameter application is specified for mobility service authorization and prefix delegation and applies 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 extends the PMIPv6 Diameter application 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 September 5, 2009 [Page 3] Internet-Draft LMA Resolution for PMIPv6 March 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 September 5, 2009 [Page 4] Internet-Draft LMA Resolution for PMIPv6 March 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 September 5, 2009 [Page 5] Internet-Draft LMA Resolution for PMIPv6 March 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 is planning a new working group to specify extensions to PMIPv6 for Route Optimization [I-D.liebsch-netext-pmip6-ro-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 September 5, 2009 [Page 6] Internet-Draft LMA Resolution for PMIPv6 March 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, a new Diameter PMIPv6 Application is specified to operate between an LMA, which implements a Diameter client, and the AAA server. The Diameter PMIPv6 Application is 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 September 5, 2009 [Page 7] Internet-Draft LMA Resolution for PMIPv6 March 2009 +---+ +---+ +----+ +----+ +----+ +---+ +----+ |MN1| |MN2| |MAG1| |MAG2| |LMA1| |AAA| |LMA2| +---+ +---+ +----+ +----+ +----+ +---+ +----+ | | | | | | | | | | | | | | |- attach- -| | | | | | | |-----AA-Request[MN1]---------------->| | | | |<----AA-Answer[LMA1]-----------------| | | | |----PBU[MN1]--->| | | | | | | |--LHA-Req[MN1]----->| | | | | | |<-LHA-Answer[HNP1]--| | | | |<---PBA[HNP1]---| | | | | | | | | | | |- -attach - | | | | | | | |----------AA-Request[MN2]--->| | | | | |<---------AA-Answer[LMA2]----| | | | | |-------------PBU[MN2]----------------------->| | | | | | |<-LHA-Req[MN2]-| | | | | | |-LHA-Ans[HNP2]>| | | | |<------------PBA[HNP2]-----------------------| | | | | | | | | | | | | | | | | | | | | | Figure 2: MN Authentication, LMA discovery, service authorization and Prefix delegation in a multi-LMA scenario Liebsch, et al. Expires September 5, 2009 [Page 8] Internet-Draft LMA Resolution for PMIPv6 March 2009 4. LMA Resolution Extension to the Diameter PMIPv6 Application 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 PMIPv6 Application as specified in [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 INFORMATION_REQUEST (InfoReq). Any Diameter client, which is associated with the AAA server to operate according to the Diameter PMIPv6 Application, may send an INFORMATION_REQUEST 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 INFORMATION_RESPONSE (InfoResp), 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 the Diameter PMIPv6 Application. 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 September 5, 2009 [Page 9] Internet-Draft LMA Resolution for PMIPv6 March 2009 +---+ +----+ +----+ +---+ +----+ |MN1| |MAG1| |LMA1| |AAA| |LMA2| +---+ +----+ +----+ +---+ +----+ | data | data | | | |- - - - ->|-==========->| | | | | |---InfoReq[IP MN2]--->| | | | | | | | | |<--InfoResp[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 September 5, 2009 [Page 10] Internet-Draft LMA Resolution for PMIPv6 March 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 September 5, 2009 [Page 11] Internet-Draft LMA Resolution for PMIPv6 March 2009 AAA1 about AAA2's address in a Redirection Notification message, which allows AAA1 to forward the INFORMATION_REQUEST to AAA2. AAA2 resolves MN2's HNP into the IP address of LMA2 and sends the results back in an INFORMATION_REPLY message to LMA2 via AAA1. Details about the use of redirection agents in this context are for further study. Liebsch, et al. Expires September 5, 2009 [Page 12] Internet-Draft LMA Resolution for PMIPv6 March 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 PMIPv6 Application according to [I-D.ietf-dime-pmip6], an existing security association between the LMA and the AAA server can be assumed to protect the new signaling message. One important difference to the existing operation of the Diameter PMIPv6 Application 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 INFORMATION_REQUEST 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 September 5, 2009 [Page 13] Internet-Draft LMA Resolution for PMIPv6 March 2009 6. Acknowledgments Many thanks to Rafael Richter for his valuable input on AAA-based anchor resolution. Liebsch, et al. Expires September 5, 2009 [Page 14] Internet-Draft LMA Resolution for PMIPv6 March 2009 7. References 7.1. Normative References [I-D.ietf-dime-pmip6] 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-ietf-dime-pmip6-00 (work in progress), January 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.liebsch-netext-pmip6-ro-ps] Liebsch, M., "PMIPv6 Localized Routing Problem Statement", draft-liebsch-netext-pmip6-ro-ps-00 (work in progress), February 2009. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Liebsch, et al. Expires September 5, 2009 [Page 15] Internet-Draft LMA Resolution for PMIPv6 March 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 September 5, 2009 [Page 16]