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]