Network Working Group G. Zorn
Internet-Draft Network Zen
Intended status: Standards Track Q. Wu
Expires: November 17, 2012 Huawei
M. Liebsch
NEC
J. Korhonen
NSN
May 16, 2012
Diameter Support for Proxy Mobile IPv6 Localized Routingdraft-ietf-dime-pmip6-lr-13
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 November 17, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zorn, et al. Expires November 17, 2012 [Page 1]

Internet-Draft PMIP6 Localized Routing Support May 20121. 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] 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 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 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 November 17, 2012 [Page 3]

Internet-Draft PMIP6 Localized Routing Support May 2012
Routing Service Authorization. This reference architecture assumes
that
o MN1 and MN2 belong to the same LMA or different LMAs. If MN1 and
MN2 belong to the same LMA, LMA1 and LMA2 to which MN1 and MN2 are
anchored in Figure 1 should be the same LMA. If MN1 and MN2
belong to different LMAs, LMA1 and LMA2 in Figure 1 are in the
same provider domain (as described in [RFC6279]).
o The MAG and LMA support Diameter client functionality.
+---------+
LMA2? | AAA & |
+------>| Policy |
| | Profile |
Diameter +---------+
|
|
|
|
LMA2? +--V-+ +----+
+------->|LMA1| |LMA2|
| +----+ +----+
| | |
| // \\
PMIP // \\
| // \\
| | |
| +----+ MAG2? +----+
+---->|MAG1|<-------- |MAG2|
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 1: Localized Routing Service Authorization Reference
Architecture
The interaction of the MAG and LMA with the AAA server according to
the extension specified in this document considers the following
feature:
a. The interaction of LMA1 with the AAA server is used to authorize
the localized routing service and, if necessary, fetch the IP
address of LMA2
Zorn, et al. Expires November 17, 2012 [Page 4]

Internet-Draft PMIP6 Localized Routing Support May 20124. 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. MIP6-Agent-Info AVP
The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in
[RFC5447] and extended in [RFC5779]. This AVP with the M bit cleared
is used to carry LMA addressing in the AA-Answer (AAA) message
[I-D.ietf-dime-rfc4005bis].
4.2. 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.3. 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.4. 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.5. 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.
Note that localized routing related signaling is required prior to
Zorn, et al. Expires November 17, 2012 [Page 5]

Internet-Draft PMIP6 Localized Routing Support May 2012
localized routing. 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], 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 (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 must first locate the entity that maintains the
data required to setup the path (i.e., the LMA corresponding to MN2
and MN1) by looking up the Binding Update List and then 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], Section4.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 and 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.,
Zorn, et al. Expires November 17, 2012 [Page 6]

Internet-Draft PMIP6 Localized Routing Support May 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-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.5) set indicating
direct routing of IP packets between MNs anchored to different MAGs
is supported. LMA1 then knows the localized routing is allowed and
verifies the IP address of LMA corresponding to MN2 using the data
returned in the MIP6-Agent-Info AVP. In success case, LMA1 responds
to MAG1 in accordance with [I-D.ietf-netext-pmip-lr].
Note: The signaling flow between LMA1 and AAA server shown in
Figure 3 also applies to A22 described in RFC6279. With returned
LMA2 corresponding to MN2, LMA1 knows that MN2 belongs to a different
LMA (i.e., LMA2) (i.e.,A22 described in [RFC6279]), 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. This 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.
Zorn, et al. Expires November 17, 2012 [Page 8]

Internet-Draft PMIP6 Localized Routing Support May 2012
+---+ +----+ +----+ +---+ +----+ +---+
|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
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-Agent-Info
AVP [RFC5779] containing 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 and the IP
address and/or Fully Qualified Domain Name (FQDN) of LMA
corresponding to MN2 (i.e.,LMA2) . LMA1 then knows the localized
routing is allowed and verifies the IP address of LMA corresponding
to MN2 using the data returned in the MIP6-Agent-Info AVP. In
success case, LMA1 responds to MAG1 for localized routing in
accordance with [I-D.ietf-netext-pmip-lr].
Zorn, et al. Expires November 17, 2012 [Page 9]

Internet-Draft PMIP6 Localized Routing Support May 2012
+---+ +---+ +----+ +----+ +---+
|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.
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.5).
8. Contributors
Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early
Zorn, et al. Expires November 17, 2012 [Page 10]