Network Working Group B. Sarikaya Internet-Draft F. Xia Expires: January 7, 2009 Huawei USA July 6, 2008 Problem Statement and Requirements for Diameter/Radius Prefix Authorization Application draft-sarikaya-dimeradext-prefix-auth-ps-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 January 7, 2009. Sarikaya & Xia Expires January 7, 2009 [Page 1] Internet-Draft PS:Diameter Prefix Authorization July 2008 Abstract This document provides problem statement for AAA prefix authorization application. The document also identifies application scenarios and requirements on AAA prefix authorization application. Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4 4.1. Prefix Management in Access Routers . . . . . . . . . . . 4 4.2. Prefix Management in Local Mobility Anchors . . . . . . . 5 4.3. Prefix Management for Mobile Routers . . . . . . . . . . . 6 5. Requirements on AAA-based Prefix Authorization Application . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative references . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Sarikaya & Xia Expires January 7, 2009 [Page 2] Internet-Draft PS:Diameter Prefix Authorization July 2008 1. Introduction and Motivation Prefix assignment for an IPv6 node (host or router) is essential to IPv6 address formulation. Even though IPv6 address space is large enough, it still makes sense for operators to manage addresses in a central way, e.g. using central DHCPv6 servers or AAA servers. Authorizing the use of a prefix that a central server has by a prefix user needs communication between different network entities. Prefix usage and per-MN prefixes are widely discussed in IETF 16NG, NEMO, and NETLMM Working Groups. Corresponding solutions are also introduced. But these solutions only solve a part of the problem. In 16NG, an Access Router allocates a mobile node's prefix using Router Advertisement message defined in [RFC4861]. There is no discussion about how the Access Router acquires prefixes from external entity. NEMO deals with synchronization of Mobile Network prefixes between a Mobile Router and a Home Agent, while the method is agnostic to the way that a Home Agent gets prefixes from back end servers. In Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6], Proxy Binding Update and Proxy Binding Acknowledgement messages are used to allocate prefixes from a Local Mobile Anchor to a mobile node, but how the Local Mobile Anchor gets prefixes from external server is left out of the scope. [RFC3633] defines Prefix Delegation options and procedures to provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). In [RFC3633], the requesting router (RR) as DHCP client requests the prefixes for the prefix users from the delegating router (DR) as DHCP server. When RR and DR are not located on the same subnet RR needs to have a Relay agent as well as DHCP client in order to communicate with DHCP server in the network. Making use of AAA infrastructure for prefix management can solve the aforementioned problems in a uniform way. 2. Terminology Prefix Authorization (PA): The process by which a network access server (NAS) (as AAA client) obtains a prefix dynamically from AAA server. 3. Problem Statement AAA servers managing IP addresses is a convention. [RFC2865] defines attribute Framed-IP-Address for allocating IPv4 address for a host. Sarikaya & Xia Expires January 7, 2009 [Page 3] Internet-Draft PS:Diameter Prefix Authorization July 2008 AAA servers statically configuring IPv6 prefixes is also a convention. [RFC3162] introduces Framed-IPv6-Prefix attribute for configuring IPv6 prefixes for a host. This configuration is static because Framed-IPv6-Prefix carries a number of prefixes only. Lifetime values for each prefix can not be carried. Existing AAA (RADIUS and Diameter) mechanisms can't accomodate prefix authorization. [RFC4818] designs Delegated-IPv6-Prefix attribute. The protocol defined in [RFC4818] is in fact used for the AAA server to authorize prefix(es) to NAS for use in the user's network. However in [RFC4818], the recommended usage scenario is that the AAA server configures the delegating server acting as NAS with the prefix(es) and then DHCP Prefix Delegation [RFC3633] can be used to delegate these prefixes to the requesting router. Also Delegated- IPv6-Prefix carries a number of prefixes only. Lifetime values for each prefix can not be carried. The identities of the end users for which prefixes are authorized can not be carried. AAA server is not given any information on the end users of the prefixes. Also the NAS could be better configured at the requesting router instead of at the DHCP server. In a prefix authorization application, the NAS requests prefixes from the AAA server. In the request, the users of prefixes MUST be identified. AAA server replies with one or more prefixes. When the lifetime of the prefix(es) expires, the NAS renews its request for the prefix(es). There are many potential uses of such a prefix authorization application which are presented in the next section. The number of applications is growing due to the use of point-to-point link model in cellular networks. 4. Application Scenarios Diameter/Radius prefix authorization application has the applications that are described in this section. 4.1. Prefix Management in Access Routers [RFC4968] provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. As to IPv6 addressing, there are two models, shared link model and point-to-point link model. In the former model, an IPv6 prefix is shared by multiple MNs. While in the point-to-point link model, a prefix is only assigned to one interface of MN. Different MNs can't share a prefix Sarikaya & Xia Expires January 7, 2009 [Page 4] Internet-Draft PS:Diameter Prefix Authorization July 2008 and an interface can have multiple prefixes. [RFC5121] specifies the addressing and operation of IPv6 over the IPv6 specific part of the packet convergence sub-layer of IEEE Std 802.16e [802.16e] and point- to-point link model is recommended. Also, 3GPP/3GPP2 have earlier adopted the point-to-point link model [RFC3314]. A mobile node and an Access Router are connected via a point-to-point connection at the IPv6 layer. Hence each mobile node can be considered to be on a separate subnet. The prefixes for the mobile node are advertised through Router Advertisement messages [RFC4861]. When an MN attaches an Access Router(AR), the AR requests one or more prefixes for the MN from an external server. When the MN detaches the AR, the prefixes should be released. When an operator wants to renumber its network, prefixes with different lifetime are advertised to the MN. Diameter/Radius prefix authorization application can be the mechanism to deal with how AR acquires and manages these prefixes. 4.2. Prefix Management in Local Mobility Anchors [I-D.ietf-netlmm-proxymip6] enables mobility support to a host without requiring its participation in any mobility related signaling. Currently, only point-to-point access link is supported which assumes that the mobile node and the Mobile Access Gateway (MAG) are the only two nodes on the access link. Figure 1 shows a typical process for MN to request it's home network prefix(es). MN MAG LMA Server |------>| | | 1. RtSol | |------->| | 2. PBU (HNP=0) | | |<------>| 3. Prefix Exchange | |<-------| | 4. PBA (HNPs) |<------| | | 5. RA(HNPs) Figure 1: Prefix Authorization in Proxy Mobile IPv6 1. An MN solicits a router advertisement (RtSol) for stateless address configuration. 2. The Mobile Access Gateway (MAG) sends Proxy Binding Update (PBU) message to Local Mobility Anchor (LMA) and with Home Network Prefix (HNP) to zero. Sarikaya & Xia Expires January 7, 2009 [Page 5] Internet-Draft PS:Diameter Prefix Authorization July 2008 3. No details are provided in [I-D.ietf-netlmm-proxymip6] on how LMA manages prefixes. This is one of the motivations to design a Diameter/Radius application for prefix authorization. 4. The LMA replies PBU with Proxy Binding Acknowledgement (PBA) and sets MN's prefixes to HNP field of PBA. 5. MAG advertises prefixes to MN with Router Advertisement (RA) for stateless address configuration. 4.3. Prefix Management for Mobile Routers [I-D.ietf-nemo-prefix-delegation] specifies mechanism for a Mobile Router(MR) to synchronize its Mobile Network Prefixes with its Home Agents and obtain new ones dynamically. Figure 2 shows the process that a Mobile Router requests prefixes from a Home Agent. MR HA Server | | | |------->| | 1. BU | | | | |<------>| 2. Prefix Exchange | | | |<-------| | 3. BA | | | Figure 2: Prefix Delegation in NEMO 1. Mobile Network Prefix request option defined in [I-D.ietf-nemo-prefix-delegation] is included in the Binding Update(BU) to indicate to the Home Agent(HA) that the MR wishes to get new prefixes assigned to it for use as Mobile Networks Prefixes. 2. The HA requests prefix from an external entity. There is no further description in [I-D.ietf-nemo-prefix-delegation]. The problem can also be solved by defining a new Diameter/Radius application. 3. Mobile Network Prefix Confirm option defined in [I-D.ietf-nemo-prefix-delegation] is included in the Binding Acknowledgement to allocate prefixes to the MR. Mobile Network Prefix Confirm option carries the prefix lifetime. Prefixes can be refreshed either by MR sending a BU or by HA sending a BA. Sarikaya & Xia Expires January 7, 2009 [Page 6] Internet-Draft PS:Diameter Prefix Authorization July 2008 5. Requirements on AAA-based Prefix Authorization Application AAA-based prefix authorization (PA) application MUST run between a NAS, located on AR, LMA, MR, etc. and an AAA server. AAA-based PA application MUST support the AAA client to request prefixes from an AAA server. AAA-based PA application MUST support the client to give back the prefixes to the AAA server. If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices on the network, the certificate or the information needed to obtain a certificate SHOULD also be sent by the AAA server to NAS. In point-to-point link operation, the NAS MUST identify the interface of MN in its request. The NAS MAY provide a prefix hint, e.g. of length /48 to which the AAA server MUST reply with one or more prefixes, e.g. of length /64. In point-to-point operation, the AAA server MAY assign the prefix(es) and related parameters such as the lifetime and the certificates to MN from MN's profile. AAA-based prefix authorization application SHOULD support prefix release procedures. The NAS is responsible for renewing the prefixes when the lifetime expires. The NAS SHOULD be able to extend the lifetime of the prefixes using messages designed for this purpose. It SHOULD be possible to renumber the prefixes authorized by AAA server. The AAA server SHOULD initiate prefix renumbering process. 6. Security Considerations This document is a problem statement that does not by itself introduce any security issues. 7. IANA Considerations None. 8. Acknowledgements TBD. Sarikaya & Xia Expires January 7, 2009 [Page 7] Internet-Draft PS:Diameter Prefix Authorization July 2008 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. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 9.2. Informative references [802.16e] Institute of Electrical and Electronics Engineer, "Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE 802.16e/D12. [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008. [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 Based Networks", RFC 4968, August 2007. [I-D.ietf-nemo-prefix-delegation] Kniveton, T. and P. Thubert, "Mobile Network Prefix Delegation", draft-ietf-nemo-prefix-delegation-02 (work in progress), August 2007. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 (work in progress), Sarikaya & Xia Expires January 7, 2009 [Page 8] Internet-Draft PS:Diameter Prefix Authorization July 2008 May 2008. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. Sarikaya & Xia Expires January 7, 2009 [Page 9] Internet-Draft PS:Diameter Prefix Authorization July 2008 Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Sarikaya & Xia Expires January 7, 2009 [Page 10] Internet-Draft PS:Diameter Prefix Authorization July 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. Sarikaya & Xia Expires January 7, 2009 [Page 11]