Network Working Group G. Zorn Internet-Draft Network Zen Intended status: Standards Track Q. Wu Expires: January 14, 2013 Huawei M. Liebsch NEC J. Korhonen NSN July 13, 2012 Diameter Support for Proxy Mobile IPv6 Localized Routing draft-ietf-dime-pmip6-lr-14 Abstract In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, the usage of localized routing may be authorized for both MAGs. This document specifies how to accomplish this using the Diameter protocol. 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 January 14, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Zorn, et al. Expires January 14, 2013 [Page 1] Internet-Draft PMIP6 Localized Routing Support July 2012 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 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 5 4.1. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 5 4.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 5 4.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 5 4.4. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 5 5. Example Signaling Flows for Localized Routing Service Authorization . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zorn, et al. Expires January 14, 2013 [Page 2] Internet-Draft PMIP6 Localized Routing Support July 2012 1. Introduction Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobility Access Gateway to optimize media delivery by locally routing packets from a Mobile Node to a Correspondent Node that is locally attached to an access link connected to the same Mobile Access Gateway, avoiding tunneling them to the Mobile Node's Local Mobility Anchor. This is referred to as "local routing" in RFC 5213. However, this mechanism is not applicable to the typical scenarios in which the MN and CN are connected to different MAGs and are registered to the same LMA or different LMAs. [RFC6279] defines the problem statement for PMIPv6 localized routing. [I-D.ietf-netext-pmip-lr] specifies the PMIPv6 localized routing protocol based on the scenarios A11, A12, and A21 [RFC6279]. In these scenarios the information needed to set up a localized routing path (e.g., the addresses of the Mobile Access Gateways to which the MN and CN are respectively attached) is distributed between their respective Local Mobility Anchors. This may complicate the setup and maintenance of localized routing. Therefore, in order to establish a localized routing path between the two Mobile Access Gateways, the Mobile Node's MAG must obtain the address of the Correspondent Node's MAG from the LMA that is managing the Correspondent Node's traffic. In Diameter Proxy Mobile IPv6 [RFC5779], the AAA interactions between an Authentication, Authorization and Accounting (AAA) server and the LMA can be used to authorize the received Proxy Binding Update from the MAG. However, there is no relevant work discussing how AAA-based mechanisms can be used to provide authorization to the Mobile Node's MAG or LMA for enabling localized routing. This document describes Diameter [I-D.ietf-dime-rfc3588bis] support for the authorization of PMIPv6 mobility entities in case of A11,A12,A21 during localized routing. 2. 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 RFC 2119 [RFC2119]. 3. Solution Overview This document addresses how to provide authorization to the Mobile Node's MAG or LMA for enabling localized routing and resolve the destination MN's MAG by means of interaction between the LMA and the AAA server. Figure 1 shows the reference architecture for Localized Zorn, et al. Expires January 14, 2013 [Page 3] Internet-Draft PMIP6 Localized Routing Support July 2012 Routing Service Authorization. This reference architecture assumes that o If MN and CN belong to different LMAs, MN and CN should share the same MAG(e.g., MN1 and CN2 in Figure 1 are attached to the same MAG1 and belong to LMA1 and LMA2 respectively ). Note that LMA1 and LMA2 in Figure 1 are in the same provider domain (as described in [RFC6279]). o If MN and CN are attached to the different MAGs, MN and CN should belong to the same LMA (e.g., MN1 and CN3 in theFigure 1 are attached to the MAG1 and MAG3 respectively but belong to LMA1 ). o MN and CN may belong to the same LMA and are attached to the same MAG,e.g.,MN1 and CN1 in the Figure 1 are both attached to the MAG1 and belong to LMA1. o The MAG and LMA support Diameter client functionality. +---------+ +---------------------->| AAA & | | +------>| Policy | | | | Profile | | Diameter +---------+ | | | CN's MAG?+--V-+ +----+ | +------->|LMA1| |LMA2| | | +---++ +----+ | | | | | Diameter | | +-------+--------- | | | | | | | | | \\ | | // // \\ | PMIP // // \\ | | // // \\ | | | | | | +---->+---------------+ +----+ | | MAG1 | |MAG3| +-------->+---------------+ +----+ : : : : +---+ +---+ +---+ +---+ |MN1| |CN1| |CN2| |CN3| +---+ +---+ +---+ +---+ Figure 1: Localized Routing Service Authorization Reference Architecture Zorn, et al. Expires January 14, 2013 [Page 4] Internet-Draft PMIP6 Localized Routing Support July 2012 The interaction of the MAG and LMA with the AAA server according to the extension specified in this document is used to authorize the localized routing service. 4. Attribute Value Pair Definitions This section describes Attribute Value Pairs (AVPs) defined by this specification or re-used from existing specifications in a PMIPv6- specific way. 4.1. User-Name AVP The User-Name AVP (AVP Code 1) is defined in [I-D.ietf-dime-rfc3588bis]. This AVP is used to carry the MN- Identifier (Mobile Node identifier) [RFC5213] in the AA-Request (AAR) message [I-D.ietf-dime-rfc4005bis]. 4.2. PMIP6-IPv4-Home-Address AVP The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in [RFC5779]. This AVP is used to carry the IPv4-MN-HoA (Mobile Node's IPv4 home address)[RFC5844] in the AA-Request (AAR) message [I-D.ietf-dime-rfc4005bis]. 4.3. MIP6-Home-Link-Prefix AVP The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779]. This AVP is used to carry the MN-HNP (Mobile Node's home network prefix) in the AAR. 4.4. MIP6-Feature-Vector AVP The MIP6-Feature-Vector AVP is defined in [RFC5447]. This document allocates a new capability flag bit according to the IANA rules in RFC 5447. INTER_MAG_ROUTING_SUPPORTED (TBD) Direct routing of IP packets between MNs anchored to different MAGs without involving any LMA is supported. This bit is used with MN-Identifier. When a MAG or LMA sets this bit in the MIP6- Feature-Vector and MN-Identifier corresponding to the Mobile Node is carried with this bit, it indicates to the HAAA that the Mobile Node associated with this LMA is allowed to use localized routing. When a MAG or LMA sets this bit in the MIP6-Feature-Vector and MN- Identifiers corresponding to the Mobile Node and Correspondent Node are both carried with this bit, it indicates to the HAAA that Zorn, et al. Expires January 14, 2013 [Page 5] Internet-Draft PMIP6 Localized Routing Support July 2012 localized routing of IP packets between Mobile Node and Correspondent Node anchored to different MAGs is supported. If this bit is cleared in the returned MIP6- Feature-Vector AVP, the HAAA does not authorize direct routing of packets between MNs anchored to the different MAG. The MAG and LMA MUST support this policy feature on a per-MN and per-subscription basis. 5. Example Signaling Flows for Localized Routing Service Authorization Localized Routing Service Authorization can happen during the network access authentication procedure [RFC5779] before localized routing is initialized. In this case, the preauthorized pairs of LMA/prefix sets can be downloaded to Proxy Mobile IPv6 entities during the RFC 5779 procedure. Localized routing can be initiated once the destination of a received packet matches one or more of the prefixes received during the RFC 5779 procedure. Figure 2 shows an example scenario in which MAG1 acts as a Diameter client, processing the data packet from MN1 to MN2 and requesting authorization of localized routing (i.e.,MAG-Initiated LR authorization). In this example scenario, MN1 and MN2 are attached to the same MAG and anchored to the different LMAs (i.e.,A12 described in [RFC6279]). In this case, MAG1 knows that MN2 belongs to a different LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of LMA1 and LMA2). In order to setup a localized routing path with MAG2, MAG1 acts as Diameter client and sends an AAR message to the Diameter server. The message contains an instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779],Section 5.5 ) set,two instances of the User-Name AVP ([I-D.ietf-dime-rfc3588bis], Section 8.14)containing MN1-Identifier and MN2-Identifier. In addition, the message may contain either an instance of the MIP6-Home-Link-Prefix AVP ([RFC5779], Section 5.3) or an instance of the PMIP6-IPv4- Home- Address AVP ([RFC5779], Section 5.2) containing the IP address/ HNP of MN1. The Diameter server authorizes localized routing service by checking if MN1 and MN2 are allowed to use localized routing. If so, the Diameter server responds with an AAA message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779],Section 5.5) set indicating direct routing of IP packets between MNs anchored to the same MAG is supported. MAG1 then knows the localized routing between MN1 and MN2 is allowed. Then MAG1 sends the Request messages respectively to LMA1 and LMA2. The request message is the Localized Routing Initialization (LRI) message Zorn, et al. Expires January 14, 2013 [Page 6] Internet-Draft PMIP6 Localized Routing Support July 2012 in Figure 2 and belongs to the Initial phase of the localized routing. LMA1 and LMA2 responds to MAG1 using the Localized Routing Acknowledge message (LRA inFigure 2 ) in accordance with [I-D.ietf-netext-pmip-lr]. In case of LRA_WAIT_TIME expiration [I-D.ietf-netext-pmip-lr],MAG1 should ask for authorization of localized routing again according to the procedure described above before LRI is retransmitted up to a maximum of LRI_RETRIES. +---+ +---+ +----+ +----+ +---+ +----+ |MN2| |MN1| |MAG1| |LMA1| |AAA| |LMA2| +-|-+ +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ | | Anchored | | | o---------------------------------------------o | | Anchored | | | | o------------------o | | | Data[MN1->MN2] | | | | |------->| | | | | | | AAR(MFV, MN1,MN2) | | | | |------------------->| | | | | AAA(MFV, LMA) | | | | |<-------------------| | | | | LRI | | | | | |-------->| | | | | | | LRI | | | | |--------------------------->| | | | LRA | | | | | |<--------| | | | | | | LRA | | | | |<---------------------------| Figure 2: MAG-initiated Localized Routing Authorization in A12 Figure 3 shows the second example scenario, in which LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and requesting the authorization of localized routing. In this scenario, MN1 and MN2 are attached to the different MAG and anchored to the same LMA (i.e., A21 described in [RFC6279] ), LMA knows that MN1 and MN2 belong to the same LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of LMA corresponding to MN1 and LMA corresponding to MN2). In contrast with the signaling flow shown in Figure 2, it is LMA1 instead of MAG1 which initiates the setup of the localized routing path. The Diameter client in LMA1 sends an AA-Request message to the Zorn, et al. Expires January 14, 2013 [Page 7] Internet-Draft PMIP6 Localized Routing Support July 2012 Diameter server. The message contains an instance of the MIP6- Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set indicating direct routing of IP packets between MNs anchored to different MAGs is supported and two instances of the User-Name AVP ([I-D.ietf-dime-rfc3588bis], Section 8.14)containing MN1-Identifier and MN2-Identifier. The Diameter server authorizes the localized routing service by checking if MN1 and MN2 are allowed to use localized routing. If so, the Diameter server responds with an AA- Answer message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set indicating direct routing of IP packets between MNs anchored to different MAGs is supported. LMA1 then knows the localized routing is allowed. In success case, LMA1 responds to MAG1 in accordance with [I-D.ietf-netext-pmip-lr]. In case of LRA_WAIT_TIME expiration [I-D.ietf-netext-pmip-lr],LMA1 should ask for authorization of localized routing again according to the procedure described above before LRI is retransmitted up to a maximum of LRI_RETRIES. +---+ +----+ +----+ +---+ +----+ +---+ |MN1| |MAG1| |LMA1| |AAA| |MAG2| |MN2| +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+-+ | | | Anchored | | | Anchored o-------------------+--------o o--------+-------o Data[MN2->MN1] | | | | |<----- | | | | | |AAR(MFV,MN1,MN2) | | | | |--------->| | | | | |AAA(MFV,LMA) | | | | LRI |<---------| | | | |<------| LRI | | | | LRA |------------------>| | | |------>| LRA | | | | |<------------------| | Figure 3: LMA-initiated Localized Routing Authorization in A21 Figure 4 shows another example scenario, in which LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and requesting the authorization of localized routing. In this scenario, MN1 and MN2 are attached to the same MAG and anchored to the same LMA (i.e., A11 described in [RFC6279]), LMA knows that MN1 and MN2 belong to the same LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the Zorn, et al. Expires January 14, 2013 [Page 8] Internet-Draft PMIP6 Localized Routing Support July 2012 addresses of LMA corresponding to MN1 and LMA corresponding to MN2). The Diameter client in LMA1 sends an AA-Request message to the Diameter server. The message contains an instance of the MIP6- Feature-Vector AVP ([RFC5447], Section 4.2.5) with the LOCAL_MAG_ROUTING_SUPPORTED bit set and two instances of the User- Name AVP ([I-D.ietf-dime-rfc3588bis], Section 8.14)containing MN1- Identifier and MN2-Identifier. The Diameter server authorizes the localized routing service by checking if MN1 and MN2 are allowed to use localized routing. If so, the Diameter server responds with an AA- Answer message encapsulating an instance of the MIP6-Feature- Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779],Section 5.5) set indicating direct routing of IP packets between MNs anchored to the same MAG is supported. LMA1 then knows the localized routing is allowed and responds to MAG1 for localized routing in accordance with [I-D.ietf-netext-pmip-lr]. In case of LRA_WAIT_TIME expiration [I-D.ietf-netext-pmip-lr], LMA1 should ask for authorization of localized routing again according to the procedure described above before LRI is retransmitted up to a maximum of LRI_RETRIES. +---+ +---+ +----+ +----+ +---+ |MN2| |MN1| |MAG1| |LMA1| |AAA| +-+-+ +-+-+ +-+--+ +-+--+ +-|-+ | | Anchored | | o-----------------------o | | | Anchored | | | o--------+-------o Data[MN2->MN1] | | | |<----- | | | | |AAR(MFV,MN1,MN2) | | | |--------->| | | | |AAA(MFV,LMA) | | | LRI |<---------| | | |<------| | | | | LRA | | | | |------>| | Figure 4: LMA-initiated Localized Routing Authorization in A11 6. Security Considerations The security considerations for the Diameter NASREQ [I-D.ietf-dime-rfc4005bis] and Diameter Proxy Mobile IPv6 [RFC5779] applications are also applicable to this document. Zorn, et al. Expires January 14, 2013 [Page 9] Internet-Draft PMIP6 Localized Routing Support July 2012 The service authorization solicited by the MAG or the LMA relies upon the existing trust relationship between the MAG/LMA and the AAA server. An authorised MAG could in principle track the movement of any participating CNs at the level of the MAG to which they are anchored. If such a MAG were compromised, or under the control of a bad-actor, then such tracking could represent a privacy breach for the set of tracked CNs. In such a case, the traffic pattern from the compromised MAG might be notable so monitoring for e.g. excessive queries from MAGs might be worthwhile. 7. IANA Considerations This specification defines a new value in the Mobility Capability registry [RFC5447] for use with the MIP6-Feature-Vector AVP: INTER_MAG_ROUTING_SUPPORTED (see Section 4.4). 8. Contributors Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early versions of this document. 9. Acknowledgements The authors would like to thank Carlos Jesus Bernardos Cano, Dan Romascanu, Elwyn Davies, Basavaraj Patil, Ralph Droms, Stephen Farrel, Robert Sparks, Benoit Claise and Abhay Roy for their valuable comments and suggestions on this document. 10. References 10.1. Normative References [I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34 (work in progress), June 2012. [I-D.ietf-dime-rfc4005bis] Zorn, G., "Diameter Network Access Server Application", draft-ietf-dime-rfc4005bis-09 (work in progress), May 2012. Zorn, et al. Expires January 14, 2013 [Page 10] Internet-Draft PMIP6 Localized Routing Support July 2012 [I-D.ietf-netext-pmip-lr] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, "Localized Routing for Proxy Mobile IPv6", draft-ietf-netext-pmip-lr-10 (work in progress), May 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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 Network Access Server to Diameter Server Interaction", RFC 5447, February 2009. [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. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. 10.2. Informative References [RFC6279] Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement", RFC 6279, June 2011. Authors' Addresses Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 87-040-4617 Email: glenzorn@gmail.com Zorn, et al. Expires January 14, 2013 [Page 11] Internet-Draft PMIP6 Localized Routing Support July 2012 Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 21001 China Phone: +86-25-84565892 Email: sunseawq@huawei.com Marco Liebsch NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg, 69115 Germany Email: liebsch@nw.neclab.eu Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 Espoo FI-02600, Finland Email: jouni.nospam@gmail.com Zorn, et al. Expires January 14, 2013 [Page 12]