Network Working Group F. Xia Internet-Draft B. Sarikaya Expires: January 2, 2008 Huawei USA July 2007 RADIUS Proxy Mobile IPv6 draft-xia-netlmm-radius-00 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 January 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Xia & Sarikaya Expires January 2, 2008 [Page 1] Internet-Draft RADIUS-PMIP6 July 2007 Abstract Proxy Mobile IPv6 is network based mobility management protocol which allows IP session continuity for a mobile node without its involvement in mobility management. A mobile access gateway (MAG) is authorized to send Mobile IPv6 signaling messages on behalf of mobile nodes. The MAG requires a local mobility anchor address(LMAA), mobile node's identifier (MN-Identifier),and IPsec security association (SA) with it's LMA before it sends signaling messages. Interworking with existing authentication, authorization and accounting (AAA) infrastructure, MAG acquires the LMAA (directly or indirectly) and MN-Identifier. LMA also uses AAA infrastructure to authenticate MAG and build SA between MAG when EAP is used with IKEv2. This document defines new RADIUS attributes and reasonably reuses existing attributes to serve the purpose. This information exchange takes place as part of the initial network access authentication procedure. Address configuration modes and others can also be obtained from AAA infrastructure to emulate MN's home link on access links. Xia & Sarikaya Expires January 2, 2008 [Page 2] Internet-Draft RADIUS-PMIP6 July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. MIP6 Bootstrapping Overview . . . . . . . . . . . . . . . 5 3.2. PMIP6 Bootstrapping Procedure . . . . . . . . . . . . . . 6 3.2.1. Security Association Setup . . . . . . . . . . . . . . 6 3.2.2. Service Negotiation . . . . . . . . . . . . . . . . . 6 3.2.3. Dynamic LMA . . . . . . . . . . . . . . . . . . . . . 7 3.2.4. DNS Update . . . . . . . . . . . . . . . . . . . . . . 8 3.2.5. Home Link Emulation . . . . . . . . . . . . . . . . . 9 4. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . 9 4.1. PMIPv6 MN-HoA configuration mode . . . . . . . . . . . . . 9 4.2. Use of existing RADIUS Attributes . . . . . . . . . . . . 10 4.2.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . 10 4.2.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . 11 4.2.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . 11 4.2.4. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . 11 4.2.5. Service-Type . . . . . . . . . . . . . . . . . . . . . 11 4.2.6. Framed-Protocol . . . . . . . . . . . . . . . . . . . 11 4.2.7. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . 11 5. Diameter Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative references . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Xia & Sarikaya Expires January 2, 2008 [Page 3] Internet-Draft RADIUS-PMIP6 July 2007 1. Introduction It is possible to support mobility for IPv6 nodes by extending Mobile IPv6 [RFC3775] signaling and reusing the home agent via a proxy mobility agent in the network. [I-D.ietf-netlmm-proxymip6] describes the approach to supporting mobility without requiring the mobile node to be involved in mobility management signaling. The proxy mobility agent in the network performs the signaling and does the mobility management on behalf of the mobile node. From AAA perspective, the operation of Proxy Mobile IPv6 includes the following parts: Access Authentication. When MN attaches to an access link connected to the MAG, the MN presents its identity, MN-Identifier, as part of the access authentication procedure. Upon a successful access authentication, MAG acting as an RADIUS client obtains the MN's profile from AAA servers through RADIUS protocol. The profile probably contains the following information: LMAA, FQDN of LMA, address configuration mode, MN-HoA, Home link Prefix and it's length , IPv4 LMAA when transport network is IPv4, IPv4 MN-HoA when MN is IPv4 enabled, and so on. Security Association Establishment. After a successful access authentication and authorization, the MAG MUST send a Proxy Binding Update(PBU) message to the MN's LMA. The signaling messages, Proxy Binding Update and Proxy Binding Acknowledgement are protected using IPsec. In PMIP6 scenario, a pair of security associations between LMA and MAG are shared by multiple MNs. Before sending Proxy Binding Update message, MAG checks if there is a SA ready between the MAG and the LMA. MAG initiates SA establishment procedure if there is no existing SA. IKEv2 is used to setup security associations between the MAG and the LMA. The MAG and the LMA can use any of the authentication mechanisms (shared secret/certificate/EAP), as described in [RFC4877], for mutual authentication. When EAP is used, the three parties of the authentication are MAG as a supplicant, LMA as an authenticator, and RADIUS server as an authentication server. If the authentication succeeds, the RADIUS server sends a RADIUS Access- Accept packet containing the EAP-Success and the AAA-Key derived from the EAP authentication method. The AAA-Key is used for further SA establishment between MAG and LMA. MN home address configuration . An important function of PMIPv6 is emulation of the mobile node's home link on the access link. Home address configuration is an important characteristics of links. The MN can be operating in an IPv4-only mode, IPv6-only mode or in dual IPv4/IPv6 mode. MN can obtain IPv6 address through DHCPv6. In this case, MAG can relay DHCP message between MN and DHCP server, or act as a DHCP proxy. In the latter, MAG can obtain IP Xia & Sarikaya Expires January 2, 2008 [Page 4] Internet-Draft RADIUS-PMIP6 July 2007 address from AAA server, or from LMA through PBU/PBA exchange. MN can also use the prefix in RA advertised by MAG to statelessly configure an IPv6 address. The prefix can be obtained from AAA server or LMA. Once MN-HoA address configuration is finished, MAG sends Access-Request for triggering a MN's DNS update by the RADIUS. 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 [RFC2119]. The terminology in this document is based on the definitions in [I-D.ietf-netlmm-proxymip6], in addition to the ones specified in this section. Simple IP Service. Access to the Internet without any mobility protocol. 3. Solution Overview 3.1. MIP6 Bootstrapping Overview [RFC4640] is problem statement for bootstrapping Mobile IPv6. In MIP6 scenario, a MN needs at least the following information: a home address, a home agent address, and a security association with home agent to register. The process of obtaining this information is called bootstrapping. [RFC4640] discusses issues involved with how MN can be bootstrapped and various potential deployment scenarios for MN's bootstrapping. Two deployments scenarios are defined in [RFC4640]: split scenario and integrated one. The essential difference between the two scenarios is that in split scenario, the mobility service and the network access service are authorized by different entities while in integrated scenario, the two services are authorized by the same entities. [I-D.ietf-mip6-bootstrapping-split] details bootstrapping solution in split scenario, while [I-D.ietf-mip6-bootstrapping-integrated-dhc] describes the solution for integrated one. Furthermore, [I-D.ietf-mip6-hiopt] defines new DHCP options used for dynamic home information discovery in integrated scenario. To facilitate the solutions, the AAA functionality for the integrated Xia & Sarikaya Expires January 2, 2008 [Page 5] Internet-Draft RADIUS-PMIP6 July 2007 and the split scenario needs to be defined. [I-D.ietf-mip6-radius] defines new RADIUS attributes to facilitate Mobile IPv6 bootstrapping in both integrated and split scenarios. [I-D.ietf-dime-mip6-integrated] describes Diameter interface between a network access server and home AAA server in integrated scenario. [I-D.ietf-dime-mip6-split] specifies Diameter interface between a home agent and an AAA server in split scenario. 3.2. PMIP6 Bootstrapping Procedure Proxy Mobile IPv6 offloads mobility management to networks. As a proxy, MAG at least needs the following information: a home agent address, a home address or MN-Identifier, a security association with LMA to register the MN with LMA. The process of obtaining this information will be called PMIPv6 bootstrapping in this document. Both split and integrated scenarios in Section 3.1 are applicable to Proxy Mobile IPv6. However, the integrated scenario seems more suitable to PMIPv6 because the access authentication is a part of the bootstrapping. Because of this, we will not present all the details of PMIPv6 bootstrapping but instead we will only highlight special considerations that apply. 3.2.1. Security Association Setup IKEv2 is used to setup security associations between the MAG and the LMA to protect the Proxy Binding Update and Proxy Binding Acknowledgment messages. These security associations can be shared by multiple MNs. The MAG and LMA can use any of the authentication mechanisms (shared secret/certificate/EAP) described in [RFC4877] for mutual authentication. When EAP is used, LMA acting as an authenticator gets AAA-key from RADIUS server through RADIUS Access- Accept message. The AAA-Key is used for further SA establishment between MAG and LMA. 3.2.2. Service Negotiation Based on the quality of the networks, accounting policy, application distribution and so on, the user can choose one of the following services: Simple IP access, PMIPv6 with or without IPv4 support, Hybrid access (such as, for dual stack, IPv4 is used for local access while IPv6 is supported as PMIPv6), and so on. There are two alternatives for service choice: static configuration and dynamic negotiation. In the former, MN's services are statically configured in it's profile stored in AAA server. In the latter, MN dynamically negotiates services with AAA server, as elaborated in [I-D.xia-netlmm-service-negotiation]. Based on the result of service negotiation or a static profile, the AAA server configures the Xia & Sarikaya Expires January 2, 2008 [Page 6] Internet-Draft RADIUS-PMIP6 July 2007 service through RADIUS Framed-Protocol attribute described in Section 4.2.6. Different service needs different forwarding and accounting policy. The MAG is the policy enforcement point (PEP). 3.2.3. Dynamic LMA [I-D.ietf-mip6-hiopt] defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home agent FQDN and home subnet. Similarly, MAG can act as DHCP client to dynamically request LMAA, or LMA FQDN. MN MAG AAA DHCP-S or DHCP-R | | | | | Access Authentication | | |<----------->|<----------------->| | | | | | | | Access-Accept | | | |<------------------| | | | | | | | | | | | DHCP solicit | | | |----------------------------------->| | | | | | | DHCP advertise | | | |<-----------------------------------| | | | | | | DHCP request | | | |----------------------------------->| | | | | | | DHCP reply | | |<---------------------------------- | | | | | Figure 1: Dynamic LMA Using DHCP As illustrated in Figure 1, LMAA or LMA's FQDN can be included in RADIUS Access-Accept message. LMAA MUST be used if it is present. LMA's FQDN can be used to retrieve LMAA from either DHCP server or DNS server if LMAA is not present in RADIUS Access-Accept message. If there isn't any LMA's information in Access-Accept, MAG can dynamically find a LMA from it's local DHCP server. Xia & Sarikaya Expires January 2, 2008 [Page 7] Internet-Draft RADIUS-PMIP6 July 2007 3.2.4. DNS Update In order that the MN is reachable through its dynamically assigned Home Address, the DNS needs to be updated with the new Home Address. Since the DNS update must be performed securely in order to prevent attacks or modifications from malicious nodes, the node performing this update must share a security association with the DNS server. In this case the MAG may not share a security association with the DNS server and the DNS entry update can be performed by the AAA server. In order to accomplish this, the MAG sends to the AAA server the FQDN-HoA pair using the RADIUS protocol LMA MAG AAA DNS server | | | | | 1 PBU | | | |<------------| | | | | | | | 2 PBA | | | |------------>| | | | | | | | Address Configuration | | | | | | | | 3 Access-Request | | | |------------------>| | | | | 4 DNS Update | | | |<-------------->| | | | | | | 5 Access-Accept | | | |<------------------| | | | | | Figure 2: DNS Update through AAA Figure 2 illustrates a typical MN-HoA DNS Update procedure 1. After successful access authentication and authorization, the MAG MUST send a Proxy Binding Update message to the LMA. The Proxy Binding Update message MUST have the Home Network Prefix option. MAG can learn the prefix from AAA server or from other means, and include the prefix in the Home Network Prefix option for requesting it from the local mobility anchor. If the specified value is 0::/0, then the LMA will allocate a prefix to the mobile node. 2. Successful PBA includes confirmed prefix which is advertised in Router Advertisement message by MAG to MN for stateless address auto-configuration. Xia & Sarikaya Expires January 2, 2008 [Page 8] Internet-Draft RADIUS-PMIP6 July 2007 3. Once address configuration finishes, the MAG sends Access-Request with MIP6-DNS-MO Attribute defined in [I-D.ietf-mip6-radius]. 4. The AAA server performs the DNS update based on [RFC2136]. 5. MIP6-DNS-MO attribute SHOULD be included in Access-Accept to confirm DNS update. 3.2.5. Home Link Emulation In PMIP6, MAG is also responsible for emulating the MN's home link on the access link. The characteristics of links are prefix, address configuration mode, MTU, link layer address of the default address and so on. To keep the consistency of link characteristics, MN's prefix is allocated from LMA or AAA server. MN's address configuration mode SHOULD be conveyed in Access-Accept in PMIP6-HL- Feature attribute defined in Section 4.1 . The other parameters have limited impact on MN's behavior, so we offer no further discussion. 4. RADIUS Attributes We define a new attribute and then describe the existing attributes in [I-D.ietf-mip6-radius] that are reused in PMIPv6. 4.1. PMIPv6 MN-HoA configuration mode The new defined attribute is included in Access-Accept message for MAG to emulate MN's home link. Xia & Sarikaya Expires January 2, 2008 [Page 9] Internet-Draft RADIUS-PMIP6 July 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | DHCP server address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: to be defined by IANA. Length: The length of the attribute. M bit: 1-bit "Managed address configuration" flag. When set, MN uses stateful protocol (that is, DHCP) for address auto-configuration, and DHCP server's address is included in the attribute. When M bit is not set, MN uses stateless address configuration. Reserved: Reserved for future use. DHCP server address: When M bit is set, the field holds DHCP server's address. 4.2. Use of existing RADIUS Attributes [I-D.ietf-mip6-radius] defines the following new RADIUS attributes for MIPv6 bootstrapping. In this document, these attributes are properly reused in PMIPv6 scenario. 4.2.1. MIP6-HA Attribute The RADIUS server may dynamically assign a LMA to the MN based on LMA location and current load. Xia & Sarikaya Expires January 2, 2008 [Page 10] Internet-Draft RADIUS-PMIP6 July 2007 4.2.2. MIP6-HA-FQDN Attribute The RADIUS server may assign an FQDN of the LMA to the MN. MAG can perform DNS query or DHCP request with the FQDN to derive the LMA address. 4.2.3. MIP6-HL-Prefix Attribute The RADIUS server may assign a Home Link that is in close proximity to the MAG. The MN can use the prefix to formulate MN-HoA. 4.2.4. MIP6-DNS-MO Attribute By using this payload the MAG as a RADIUS client instructs the RADIUS server to perform a dynamic DNS update. The following attributes defined in [RFC2865] are extended. 4.2.5. Service-Type Service-Type (6) SHALL set its value to "Framed" (2). 4.2.6. Framed-Protocol It MAY be used in both Access-Request and Access-Accept packets. The values of the attribute are extended as following: IPv4 (7), IPv6 (8), IPv6/IPv4 dual stack (9), PMIPv6 IPv4 support (10), PMIPv6 IPv6 support (11). 4.2.7. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key To transport the MSK from the RADIUS server to LMA, RADIUS SHALL utilize the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [RFC2548] . 5. Diameter Considerations When used in Diameter, the attributes defined in this specification can be used as Diameter AVPs from the Code space 1-255 (RADIUS attribute compatibility space). No additional Diameter Code values need be therefore allocated. 6. Security Considerations The MAG and the LMA to the RADIUS server transactions must be adequately secured. Otherwise there is a possibility that fraudulent Xia & Sarikaya Expires January 2, 2008 [Page 11] Internet-Draft RADIUS-PMIP6 July 2007 values are received from a rogue RADIUS server. The new attributes defined in this document do not introduce additional security considerations. 7. IANA consideration The type of attribute PMIPv6 MN-HoA configuration mode MUST be assigned by IANA. The value of the attribute Framed-Protocol MUST also be assigned by IANA. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 9.2. Informative references [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-01 (work in progress), June 2007. Xia & Sarikaya Expires January 2, 2008 [Page 12] Internet-Draft RADIUS-PMIP6 July 2007 [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-00 (work in progress), April 2007. [I-D.ietf-mip6-bootstrapping-split] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-05 (work in progress), May 2007. [I-D.ietf-mip6-bootstrapping-integrated-dhc] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-04 (work in progress), June 2007. [I-D.ietf-dime-mip6-split] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support", draft-ietf-dime-mip6-split-02 (work in progress), May 2007. [I-D.ietf-dime-mip6-integrated] Korhonen, J., "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", draft-ietf-dime-mip6-integrated-04 (work in progress), May 2007. [I-D.ietf-mip6-hiopt] Jang, H., "DHCP Option for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-05 (work in progress), June 2007. [I-D.ietf-mip6-radius] Chowdhury, K., "RADIUS Mobile IPv6 Support", draft-ietf-mip6-radius-02 (work in progress), March 2007. [I-D.xia-netlmm-service-negotiation] Xia, F. and B. Sarikaya, "PMIPv6 service negotiation based on EAP", draft-xia-netlmm-service-negotiation-00 (work in progress), May 2007. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. Xia & Sarikaya Expires January 2, 2008 [Page 13] Internet-Draft RADIUS-PMIP6 July 2007 Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Xia & Sarikaya Expires January 2, 2008 [Page 14] Internet-Draft RADIUS-PMIP6 July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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). Xia & Sarikaya Expires January 2, 2008 [Page 15]