| Network Working Group | G. Zorn |
| Internet-Draft | Network Zen |
| Intended status: Standards Track | Q. Wu |
| Expires: October 26, 2012 | Huawei |
| M. Liebsch | |
| NEC | |
| J. Korhonen | |
| NSN | |
| April 26, 2012 |
Diameter Support for Proxy Mobile IPv6 Localized Routing
draft-ietf-dime-pmip6-lr-11
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.
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 October 26, 2012.
Copyright (c) 2012 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. 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.
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] describes a solution for PMIPv6 localized routing based on the scenarios defined in [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 identify the LMA that is managing the Correspondent Node's traffic and then obtain the address of the Correspondent Node's MAG from that LMA. In Proxy Mobile IPv6, the LMA to be assigned to the CN may be maintained as a configured entry in the Correspondent Node's policy profile located on an Authentication, Authorization and Accounting (AAA) server. However, there is no relevant work discussing how AAA-based mechanisms can be used by the Mobile Node's MAG or LMA to discover the address of the Correspondent Node's LMA during the setup of localized routing; in addition, authorization from AAA for enabling localized routing is unspecified.
This document describes Diameter [I-D.ietf-dime-rfc3588bis] support for the authorization and discovery of PMIPv6 mobility entities during localized routing.
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].
+---------+
LMA2? | AAA & |
+------>| Policy |
| | Profile |
Diameter +---------+
|
|
|
|
LMA2? +--V-+ +----+
+------->|LMA1| |LMA2|
| +----+ +----+
| | |
| // \\
PMIP // \\
| // \\
| | |
| +----+ MAG2? +----+
+---->|MAG1|<-------- |MAG2|
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
This document addresses how to 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 Routing Service Authorization. This reference architecture assumes that
Note that if MN1 and MN2 are connected to different MAGs but belong to different LMAs, the interaction between LMA1 and the AAA server should be exactly the same as the case where MNs belong to MAGs under the same LMA.
This section describes Attribute Value Pairs (AVPs) defined by this specification or re-used from existing specifications in a PMIPv6-specific way.
The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in [RFC5447] and extended in [RFC5779]. This AVP is used to carry LMA addressing in the AA-Answer (AAA) message [I-D.ietf-dime-rfc4005bis].
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] from the LMA to the home AAA server (HAAA).
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 from the LMA to the HAAA.
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)
Localized Routing Service Authorization can happen during the network access authentication procedure [RFC5779], i.e., 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. In this example scenario, MN1 and MN2 are anchored to the same LMA. In this case, in order to setup a localized routing path with MAG2, MAG1 must first locate the entity that maintains the data required to setup the path (i.e., the LMA corresponding to MN2 or LMA2) by sending a Request message to LMA1. The request message is the Localized Routing Initialization (LRI) message in Figure 2 and belongs to the Initial phase of the localized routing. The Diameter client in LMA1 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 INTER_MAG_ROUTING_SUPPORTED bit (Section 4.4) set and 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 MN2.
The Diameter server authorizes localized routing service by checking if MN2 is allowed to use localized routing. If so, the Diameter server responds with an AAA message encapsulating an instance of the MIP6-Agent-Info AVP [RFC5779] containing the IP address and/or Fully Qualified Domain Name (FQDN) of LMA corresponding to MN2 (i.e., LMA2) and an instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.4) set indicating direct routing of IP packets between MNs anchored to different MAGs is supported. LMA1 then determines the IP address of LMA corresponding to MN2 using the data returned in the MIP6-Agent-Info AVP and responds to MAG1 with the address of LMA corresponding to MN2 in the Localized Routing Acknowledge message (LRA in Figure 2). If MAG1 knows that MN1 and MN2 belong to the same LMA, it requests the address of MAG2 from the same LMA as MN1 and uses that address to setup the localized routing path between itself and MAG2 via a Proxy Binding Update (PBU)/Proxy Binding Acknowledgement (PBA) message exchange [RFC5213]. If 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), MAG1 SHOULD request the address of MAG2 from LMA2; the subsequent localized routing path setup is similar to the case where the MNs share LMAs.
Note: This case is mentioned in RFC 6279 but not covered by [I-D.ietf-netext-pmip-lr]; it is used here as an illustration of the capabilities provided by the AAA infrastructure, possibly for future use.
+---+ +----+ +----+ +---+ +----+ +---+ |MN1| |MAG1| |LMA1| |AAA| |MAG2| |MN2| +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+-+ | | | | Anchored | | Anchored o------------------+--------o o------------------o | | | Data[MN1->MN2] | | | | |------->| LRI(MN2)| | | | | |-------->| | | | | | |AAR(MFV, MN2) | | | | |--------->| | | | | |AAA(MFV, LMA) | | | LRA([LMA ]) |<---------| | | | |<--------| | | | | | | | |
Figure 3 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 anchored to the same LMA. 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 Diameter server. The message contains an instance of the MIP6-Feature-Vector AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit set and 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 MN2. The Diameter server authorizes the localized routing service by checking if MN2 is allowed to use localized routing. If so, the Diameter server responds with an AA-Answer message encapsulating an instance of the MIP6-Agent-Info AVP [RFC5779] containing the IP address and/or Fully Qualified Domain Name (FQDN) of LMA corresponding to MN2 (i.e.,LMA2) and an instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.4) set indicating direct routing of IP packets between MNs anchored to different MAGs is supported. LMA1 then determines the IP address of LMA corresponding to MN2 using the data returned in the MIP6-Agent-Info AVP and responds to MAG1 with the address of LMA corresponding to MN2. If LMA1 knows that MN1 and MN2 share the same LMA, then the LMA may look up the address of MAG2 directly based on the IP address of MN2 and send a request message (LRI in Figure 3) to MAG1 for localized routing with the IP address of MAG2 included. The MAG1 confirms the success of localized routing if a localized routing path can be setup. If LMA1 knows that MN2 belongs to a different LMA (e.g., LMA2), LMA1 SHOULD initiate an exchange with LMA2 to trigger the corresponding LMA to setup binding entries on the corresponding MAG for localized routing and configure MAG1 and MAG2 to use the same encapsulation mechanism as that being used for the PMIP tunnel between the MAG and LMA without special configuration or dynamic tunneling negotiation between MAGs.
Note: The latter case is mentioned in RFC 6279 but not addressed by [I-D.ietf-netext-pmip-lr] and used here as an illustration of the capabilities provided by the AAA infrastructure.
+---+ +----+ +----+ +---+ +----+ +---+ |MN1| |MAG1| |LMA1| |AAA| |MAG2| |MN2| +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+-+ | | | Anchored | | | Anchored o-------------------+--------o o--------+-------o Data[MN2->MN1] | | | | |<----- | | | | | |AAR(MFV,MN2 | | | | |--------->| | | | LRI |AAA(MFV,LMA | | | (MN2,[LMA2])|<---------| | | | |<------| | | | | LRA(Succ) | | | | | |------>| | | |
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.
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.
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).
Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early versions of this document.
The authors would like to thank Carlos Jesús Bernardos Cano, Dan Romascanu, Elwyn Davies, Ralph Droms, Stephen Farrel, Robert Sparks and Abhay Roy for their valuable comments and suggestions on this document.
| [RFC6279] | Liebsch, M., Jeong, S. and Q. Wu, "Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement", RFC 6279, June 2011. |
| [I-D.ietf-netext-pmip-lr] | Krishnan, S., Koodli, R., Loureiro, P., Wu, Q. and A. Dutta, "Localized Routing for Proxy Mobile IPv6", Internet-Draft draft-ietf-netext-pmip-lr-08, January 2012. |