NETLMM WG J. Korhonen
Internet-Draft TeliaSonera
Intended status: Standards Track A. Muhanna
Expires: August 21, 2008 Nortel Networks
February 18, 2008
Policy Profile and AAA Interfaces Requirements for PMIPv6
draft-korhonen-netlmm-pp-aaa-reqs-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This specification defines the Policy Profile and AAA interfaces
requirements for the Proxy Mobile IPv6. The Policy Profile
information needed by the Proxy Mobile IPv6 may be statically
provisioned in the mobile access gateway and in the local mobility
anchor. Alternatively, the Policy Profile information or a subset of
its parameters can be dynamically downloaded to the mobile access
gateway from the AAA server during the mobile node access
Korhonen & Muhanna Expires August 21, 2008 [Page 1]
Internet-Draft Policy Profile and AAA Requirements February 2008
authentication and authorization when the mobile node roams into a
Proxy Mobile IPv6 domain. The local mobility anchor may download the
user policy profile parameters during the Proxy Mobile IPv6
registration process. This document describes the requirements for
the Proxy Mobile IPv6 Policy Profile and the corresponding AAA
interfaces.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Policy Profile . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Policy Profile and Storage Requirements . . . . . . . . . 7
5. Mobility Service Setup . . . . . . . . . . . . . . . . . . . . 8
5.1. Generic Service Setup Requirements . . . . . . . . . . . . 8
5.2. Initial Dynamic LMA Discovery Requirements . . . . . . . . 9
5.3. LMA Discovery After a Handover Requirements . . . . . . . 9
5.4. MAG to LMA Security Association Setup Requirements . . . . 10
5.5. Generic LMA to AAA Requirements . . . . . . . . . . . . . 10
5.6. Generic MAG to AAA Requirements . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Korhonen & Muhanna Expires August 21, 2008 [Page 2]
Internet-Draft Policy Profile and AAA Requirements February 2008
1. Introduction
In the Proxy Mobile IPv6 (PMIPv6) protocol [1] and PMIPv6 IPv4
support [2], a Mobile Access Gateway (MAG) performs a proxy
registration with a Local Mobility Anchor (LMA) on behalf of the
mobile node (MN). In order to perform the proxy registration, the
PMIPv6 MAG needs the address of the LMA, MN's home network prefix
(MN-HNP), possibly MN's IPv4 home address (IPv4-HoA), DHCP server
address and other PMIPv6 specific information such as allowed address
configuration modes, bearer plane security requirements, and possible
roaming related policies. All this information is defined in MN's
Policy Profile (PP) that could be downloaded from a remote Policy
Store (PS) using the AAA infrastructure or statically configured in
the MAG and/or the LMA.
Dynamic assignment and downloading of PMIPv6 Policy Profile
information is a desirable feature to ease the deployment and network
maintenance of large PMIPv6 deployments. For this purpose, the AAA
infrastructure which is used for access authentication, can be
leveraged to assign some or all of the necessary policy profile
parameters. The AAA server in the Mobility Service Authorizer's
(MSA) or in the Mobility Service Provider's (MSP) network may return
these parameters to the Network Access Server (NAS). The NAS may be
either co-located with MAGs or an integral part of a MAG.
This specification defines the requirements for the PMIPv6 Policy
Profile, the Policy Store and the AAA interfaces interactions.
2. Terminology and Abbreviations
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 [3].
General mobility terminology can be found in [4] and [1]. The
following additional or clarified terms are used in this document:
Network Access Server (NAS):
A device that provides an access service for a user to a network.
In the context of this document the NAS may be integrated into or
co-located with a MAG. The NAS contains a Diameter client
function.
Korhonen & Muhanna Expires August 21, 2008 [Page 3]
Internet-Draft Policy Profile and AAA Requirements February 2008
Home AAA (HAAA):
An authentication, authorization and accounting server located in
user's home network. A HAAA is essentially a Diameter server.
Policy Profile (PP)
A user subscription policy profile contains the essential
operational parameters that are required by the network entities
for managing the mobile node's network-based mobility service.
These policy profiles are stored in a local or a remote policy
store.
Policy Store (PS):
A node that contains the policy profile of a subscriber. The
policy store may be co-located with the Mobile Access Gateway, the
Local Mobility Anchor or the AAA server. When the Policy Store is
co-located with the HAAA server it can be queried by using an AAA
infrastructure.
3. Overview
This document addresses the authentication, authorization, accounting
and session management functionality needed by the PMIPv6 protocol.
It also defines the requirements of a diameter based MAG to HAAA and
LMA to HAAA interfaces. The intention of this document is to define
the requirements which may extend existing Mobile IPv6 specifications
such as [5] and define needed additional AVPs and functionality to
fulfill the needs of the PMIPv6 deployment.
The policy profile download from the HAAA to the MAG is part of the
network access authentication procedure when a MN roams into or
within a PMIPv6 Domain. Figure 1 shows the participating network
entities. This document, however, only concentrates on the MAG, LMA,
possible local Diameter proxies and the home Diameter server. When
aligned with [5] the MAG acts as the NAS located in ASP, the HAAA
acts as the Diameter server located in ASA/MSA/MSP and the LMA acts
as the HA in ASP/MSP.
Korhonen & Muhanna Expires August 21, 2008 [Page 4]
Internet-Draft Policy Profile and AAA Requirements February 2008
+--------+
| HAAA & | AAA +-----+
| Policy |<-------->| LMA |
| Profile| +-----+
+--------+ | <--- LMA-Address
^ |
| // \\
+--|------------- //---\\----------------+
( | IPv4/IPv6 // \\ )
( | Network // \\ )
+--|-----------//---------\\-------------+
| // \\
AAA | // <- Tunnel1 \\ <- Tunnel2
| // \\
| |- MAG-Address1 |- MAG-Address2
| +----+ +----+
+---->|MAG1| |MAG2|
+----+ +----+
| |
| |
[MN1] [MN2]
Figure 1: Proxy Mobile IPv6 Domain with MAG and LMA Interfaces with
HAAA
In a PMIPv6 access scenario a MN attaches to a PMIPv6-Domain and
starts a network access authentication procedure. The choice of
authentication mechanism is specific to the access network
deployment, but could be based on the Extensible Authentication
Protocol (EAP) [6]. During the network access authentication
procedure, the MAG acting as a NAS queries the HAAA through the AAA
infrastructure using the Diameter protocol. If the HAAA detects that
the subscriber is also authorized for the PMIPv6 service, the
subscriber policy is returned along with the successful network
access authentication answer to the MAG.
After the mobile node is successfully authenticated and the MAG
receives the policy profile parameters during the access
authentication procedure the MAG sends a PBU to the LMA. Upon
receiving the PBU the LMA may interact with the HAAA and fetches the
relevant subscriber policy, authorization and security information
related to the PMIPv6 session. This specification assumes that the
HAAA is the central node for managing all PMIPv6 subscription and
session related activities which may even include the allocation of
prefixes.
Korhonen & Muhanna Expires August 21, 2008 [Page 5]
Internet-Draft Policy Profile and AAA Requirements February 2008
Prior to sending the PBU there might be a need to dynamically setup
the MAG to LMA Security Association (SA), for example using IKEv2/
IPSec [7]. The dynamic SA setup procedure may be triggered by the MN
attaching to the MAG that does not have existing SA with the
correspondent LMA. The details of the dynamic SA setup procedure is
out of scope of this specification. However, the SA is between the
MAG and the corresponding LMA, thus it can be created using any
security mechanism that is applicable for PMIPv6 security such as
IKEv2 IPSec with an EAP-based authentication. It should be noted
that the identity used by MAG during the SA creation is the MAG's own
identity and the credentials are for authenticating the MAG toward
the LMA and the MAG authorization to send Proxy BU on behalf the
mobile nodes.
4. Policy Profile
A MN's Policy Profile contains the essential operational parameters
that are required by the network entities for managing the MN's
mobility service. In the context of this documents, we only address
the Policy Profile parameters that are essential for PMIPv6.
However, in live network deployments the Policy Profile may also be
populated with parameters that are not directly related to PMIPv6
operation but required by the operator. This document makes an
assumption that these Policy Profiles are stored in a remote Policy
Store that could be co-located with the MN's home AAA server and
accessed through an AAA interface. The same AAA interface is also
used for authenticating the MN when it attaches to the MAG and the
PMIPv6 Domain. The Policy Profile has both static and dynamically
updated parameters. The dynamic parameters may change per PMIPv6
session basis or during the session to reflect the current status of
the mobile node's PMIPv6 session.
The MAG and the LMA obtain essential parameters of the MN's Policy
Profile to their local copies of the Policy Store using the AAA
interface. The MAG and the LMA use the same AAA interfaces also to
update the dynamic Policy Profile parameters in the remote Policy
Store. The Policy Profile may also be handed over to a serving MAG
as part of a context transfer procedure during a handover. However,
the context transfer is out of scope of this document. The local
copy of the MN's Policy Profile may be slightly different in the MAG
compared to one in the LMA.
The following Policy Profile parameters are located in the MAG.
These parameters may be statically configured or dynamically
allocated using the MAG-AAA interface. Dynamically assigned
parameter values always override the statically configured ones:
Korhonen & Muhanna Expires August 21, 2008 [Page 6]
Internet-Draft Policy Profile and AAA Requirements February 2008
o The MN's identifier (MN-ID). This parameter may be obtained from
the remote Policy Store, learned during mobile node access
authentication, or generated locally in the MAG. If inter-
operator deployments are supported then the MD-ID parameter must
be accompanied with MN's home realm parameter.
o The IPv6 address of the Local Mobility Anchor (LMAA). This
parameter may be configured dynamically using methods described in
section . If inter-operator deployments are supported then the
LMAA parameter must be accompanied with corresponding realm
o The IPv4 address of the Local Mobility Anchor (LMAA). This
parameter may be configured dynamically using methods described in
section . If inter-operator deployments are supported then the
LMAA parameter must be accompanied with corresponding realm.
o The MN's IPv6 home network prefix (MN-HNP). The MN-HNP may be
downloaded during the MN access authentication from the remote
Policy Store. If the MN-HNP is not provided during the access
authentication time, it will be dynamically assigned to the MN
during the proxy binding procedure.
o Supported address configuration procedures (Stateful, Stateless or
both) on the access links in the PMIPv6 domain. This parameter
also defines whether IPv4 home address can be configured to the
MN.
o The MN's IPv4 home address (IPv4-HoA). The IPv4-HoA may be
downloaded during the MN access authentication from the remote
Policy Store. If the IPv4-HoA is not provided during the access
authentication time, it will be dynamically assigned to the MN
during the proxy binding procedure.
o The MN's interface identifier. The identifier may be MN's link
layer interface identifier or generated locally based by the MAG.
This identifies must be unique in all those PMIPv6 Domains the MN
can attach to.
o The local routing option flag. When this configuration option is
set true, two MNs attached to the same MAG may directly
communicate with each other without routing traffic via the LMA.
4.1. Policy Profile and Storage Requirements
As stated earlier there are local and remote copies of the Policy
Profile. The default local profile is usually coupled with the local
administrative policies that must be taken into account during the
Korhonen & Muhanna Expires August 21, 2008 [Page 7]
Internet-Draft Policy Profile and AAA Requirements February 2008
Policy Profile retrieval from the remote Policy Store.
R1.1: There must be a mechanism for a capability negotiation between
the MAG and the remote Policy Store. For example, the MAG must be
able to inform the remote Policy Store whether a local routing in
a MAG is supported by the local administrative policy.
5. Mobility Service Setup
Setting up the mobility service refers to a procedure that takes
place when a MN attaches to a MAG and to a PMIPv6 Domain. Prior the
attachment, the MAG may or may not have a security association set up
with the LMA located in the MN's home realm.
The discovery of the LMA corresponding to the MN's home realm is an
essential part of the mobility service setup. The discovery may be
dynamic or static depending on the MAG configuration. In the context
of this document the dynamic discovery of the LMA is inherently tied
to procedures that take place during the MN access authentication.
5.1. Generic Service Setup Requirements
The mobility service setup procedures must comply with the following
deployment related requirements:
R2.1: The MN should provide at least its permanent id and home realm
during the access authentication. In the case the MN is not able
to provide adequate home realm information, then the MN must
provide the MAG with another identifier that the MAG can use
either to generate or discover MN's home realm. The home realm is
used by the MAG/NAS and the AAA infrastructure to route AAA
requests from the MAG/NAS to the MN's home AAA server.
R2.2: It must be possible to separate the MAG's proxy mobile agent
functionality and the NAS functionality. Thus allowing
deployments, where a single NAS provides AAA services for a pool
of MAGs.
R2.3: It must be possible for the LMA to return a temporary MN
identity to the MAG during the access authentication. This
identity must be unique within the PMIPv6 domain and should hide
MN's true identity even from the MAG. The LMA provided temporary
MN identity must remain unchanged during the lifetime of the
mobility service session. The MAG must use this identity, if
available, in all subsequent AAA messages to identify the MN.
Korhonen & Muhanna Expires August 21, 2008 [Page 8]
Internet-Draft Policy Profile and AAA Requirements February 2008
5.2. Initial Dynamic LMA Discovery Requirements
This section describes the requirements for the initial LMA address
discovery process. The discovery process takes place when the MN
attaches to the PMIPv6 Domain and starts the mobility service for the
first time.
R3.1: Configuration of the LMA address must be possible per realm
basis. The configuration may be static or dynamic to the MAG.
R3.2: The LMA address must be provided either as an IP address or as
a FQDN. The FQDN may be generated by the MAG based on the MN's
home realm or other identifier provided by the MN, or retrieved
from the AAA server.
R3.3: It must be possible to return multiple LMA addresses and FQDNs
simultaneously using the AAA interface between the MAG and the
Policy Store. Furthermore, grouping of LMA address and FQDN pairs
must be possible.
The MAG queries the DNS system in order to resolve the FQDN to the
LMA IP address. SRV, AAAA or A resource records may be queried
depending on the deployment.
The AAA interface between the MAG and the Policy Store may return
both LMA IP address and the LMA FQDN at the same time. In this case
the MAG may skip the LMA address DNS resolving step. It is possible,
depending on the deployment, that the FQDN is also used to piggy-back
service level information (e.g. LMAs with dedicated roles).
5.3. LMA Discovery After a Handover Requirements
This section describes the requirements for the LMA address discovery
process after a handover to a new MAG when the MN has an existing
mobility session. The discovery process takes place when the MN
attaches to a new MAG either under the same or different PMIPv6
Domain.
R4.1: During the MN access authentication procedure the remote
Policy Store must be able to discover that the MN has an existing
mobility service session and return the IP address or the FQDN of
the LMA where the MN's mobility service session is anchored.
R4.2: During the MN access authentication procedure the remote
Policy Store must return MN's temporary identity to the MAG, if
the MAG does not have other mechanisms of learning it. The remote
Policy Store should also return other MN's Policy Profile
information to the MAG. This information may include e.g., MN-HNP
Korhonen & Muhanna Expires August 21, 2008 [Page 9]
Internet-Draft Policy Profile and AAA Requirements February 2008
and IPv4-HoA.
If the remote Policy Store (i.e. the home AAA server) is able to find
an existing mobility service session for the authenticating MN, then
the existing LMA IP address should be returned to the MAG/NAS. If a
FQDN is returned instead, then the MAG/NAS may not have a way to
distinguish between a MN handover and a MN initial attachment. If
only a FQDN gets returned to the MAG/NAS for the existing mobility
service session then the operator must ensure that the FQDN gets
resolved to exactly one LMA where the MN's mobility service session
is anchored.
5.4. MAG to LMA Security Association Setup Requirements
The SA between the MAG and each LMA may be 1) statically configured
or 2) a MAG initiated using some dynamic security association and key
exchange protocol. An example of a security association and key
exchange protocol is IKEv2 [7]. Credentials and identities used to
authenticate and authorize the MAG towards the LMA must be decoupled
from those used to authenticate and authorize the MN. The dynamic
creation of the MAG to LMA security association setup may be
triggered by a MN roaming in and attaching to the PMIPv6 domain.
R5.1: Depending on the deployment, it must be possible to decouple
the MAG to LMA Security Association Setup from the MN
authentication and authorization.
The MAG to LMA Security Association may be removed or disabled when
there is not any active mobility service session towards the LMA.
5.5. Generic LMA to AAA Requirements
The LMA to AAA interface has five possible functions: 1) the MAG to
LMA security association setup related AAA signaling that was
discussed in Section 5.4, 2) authorization of the incoming PBU, 3)
mobility service session management, 4) dynamic updating of MN's
Policy profile in the remote Policy Store, and 5) accounting.
R6.1: Depending on the deployment, the LMA should be able to
delegate the MN-HNP and IPv4-HoA management to the AAA server.
R6.2: AAA server must be able to initiate a mobility service session
termination towards the LMA.
Korhonen & Muhanna Expires August 21, 2008 [Page 10]
Internet-Draft Policy Profile and AAA Requirements February 2008
R6.3: Based on the deployment and trust relationship between the MAG
and the LMA, the LMA MAY be able to validate the mobile node
PMIPv6 service authorization upon receiving a PMIPv6 PBU from the
specified MAG.
R6.4: The LMA must be able to send accounting data to the AAA
server.
The dynamic updating of MN's Policy Profile in the remote Policy
Store is implicitly part of the above requirements.
5.6. Generic MAG to AAA Requirements
The MAG to AAA interface has several additional functions in addition
to the authentication and authorization of the MN, and subsequent
setting up the mobility service session. These additional functions
include e.g., accounting and the mobility service session management.
R7.1: AAA server must be able to initiate a mobility service session
termination towards the MAG.
R7.2: The MAG must be able to send accounting data to the AAA
server.
6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
TBD
8. Acknowledgements
TBD
9. References
9.1. Normative References
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10
(work in progress), February 2008.
Korhonen & Muhanna Expires August 21, 2008 [Page 11]
Internet-Draft Policy Profile and AAA Requirements February 2008
[2] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile
IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in
progress), November 2007.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[4] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[5] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K.
Chowdhury, "Diameter Mobile IPv6: Support for Network Access
Server to Diameter Server Interaction",
draft-ietf-dime-mip6-integrated-08 (work in progress),
February 2008.
[6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
Authors' Addresses
Jouni Korhonen
TeliaSonera
Teollisuuskatu 13
Sonera FIN-00051
Finland
Email: jouni.korhonen@teliasonera.com
Ahmad Muhanna
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Email: amuhanna@nortel.com
Korhonen & Muhanna Expires August 21, 2008 [Page 12]
Internet-Draft Policy Profile and AAA Requirements February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Korhonen & Muhanna Expires August 21, 2008 [Page 13]