Network Working Group B. Sarikaya Internet-Draft F. Xia Intended status: Standards Track Huawei USA Expires: April 24, 2009 October 21, 2008 RADIUS Prefix Authorization Application draft-sarikaya-radext-prefix-authorization-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 April 24, 2009. Sarikaya & Xia Expires April 24, 2009 [Page 1] Internet-Draft RADIUS Prefix Authorization Application October 2008 Abstract This document specifies a RADIUS application for prefix authorization. Using RADIUS protocol, a client requests prefixes from a server; the client gives back the prefixes to the server; the client is responsible for renewing the prefixes when the lifetime expires. The RADIUS server can also renumber prefixes. RADIUS clients can be home agents in MIPv6 and NEMO scenario, local mobile anchors in Proxy MIPv6 scenario, or common access routers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 3.1. Prefix Request . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Prefix Release . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Prefix Renew . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Prefix Renumbering . . . . . . . . . . . . . . . . . . . . 7 4. Use of Existing RADIUS Attributes . . . . . . . . . . . . . . 8 4.1. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Message Authenticator . . . . . . . . . . . . . . . . . . 9 5. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Authorized-Prefix Attribute . . . . . . . . . . . . . . . 9 5.2. Prefix-Authorization Attribute . . . . . . . . . . . . . . 11 5.3. Authorized-UserID Attribute . . . . . . . . . . . . . . . 12 5.4. Authorized-UserID-Prefix Attribute . . . . . . . . . . . . 12 6. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 14 7. Diameter Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 8.1. Registration of New AVPs . . . . . . . . . . . . . . . . . 14 8.2. New Registry: Prefix Authorization Type . . . . . . . . . 14 8.3. Addition of Existing Values . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.2. Informative references . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Sarikaya & Xia Expires April 24, 2009 [Page 2] Internet-Draft RADIUS Prefix Authorization Application October 2008 1. Introduction 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. [RFC4968] provides different IPv6 link models that are suitable for 802.16e [802.16e] 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 latter model, a prefix is only assigned to one MN. Different MNs can't share a prefix, and an MN 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 and 3GPP2 have earlier adopted the point-to- point link model [RFC3314]. When an MN attaches an Access Router(AR), the AR requests one or more prefixes for the MN. When the MN detaches the AR, the prefixes should be released. When an operator wants to renumber its network, prefixes with different lifetimes are advertised to the MN. Using the mechanism defined in this document, AR can offload prefix management to a dedicated server. The prefix management method defined in this document is applicable to this scenario. Proxy Mobile IPv6 protocol enables mobility support to a host without requiring its participation in any mobility related signaling [RFC5213]. Point-to-point access link is supported. It assumes that the mobile node and the Mobile Access Gateway (MAG) are the only two nodes on the access link. Proxy Binding Update and Proxy Binding Acknowledgement are used by Local Mobility Anchor (LMA) to allocate the prefixes for the mobile node to MAG. How LMA gets these prefixes from external servers is out the scope of PMIPv6 protocol. The prefix management method defined here is also applicable to this scenario. [RFC3633] defines Prefix Delegation options to provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). [I-D.ietf-nemo-dhcpv6-pd] describes how DHCPv6 PD can be used by mobile routers and home agents in network mobility. Sarikaya & Xia Expires April 24, 2009 [Page 3] Internet-Draft RADIUS Prefix Authorization Application October 2008 In DHCPv6 PD, the delegating router can receive the prefixes from AAA server and Delegated-IPv6-Prefix RADIUS attribute was defined for this purpose [RFC4818]. In this case AAA server passively delegates the prefixes to the delegating router and it does not have any control over these prefixes in cases such as renumbering. This document proposes a new RADIUS application for prefix authorization using RADIUS [RFC2865] and [I-D.ietf-radext-design]. This new application enables full prefix authorization functionality to the AAA servers. 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]. Authorized User IDs and Prefixes: A collection of prefixes assigned to AAA client. Each has an associated User Identity. This concept is captured in Authorized-UserID-Prefix attribute defined in Section 5.4. An AAA client may have more than one Authorized- UserID-Prefix assigned to it; for example, one for each of access user's interface. Also each interface may be assigned more than one prefixes. User identifier: An identifier chosen by the client. Each user has an user identifier, which is chosen to be unique among all user identifiers for users belonging to that client. This concept is captured in Authorized-UserID attribute defined in Section 5.3. Aggregate Prefix: In Point-to-Point Link Model, AR should broadcast the prefixes (MNs route information) dynamically upstream, and this causes high routing protocol traffic (OSPF, etc.). To solve the problem, route aggregation should be used. For example, each AR can be assigned a /48 prefix, while an MN's /64 prefix is derived from the /48 prefix extension. The main, higher-level prefix is called the Aggregate Prefix. An AR only broadcasts the aggregate prefix upstream. Aggregate prefix is a pool of dedicated prefixes. Dedicated Prefix: A unique prefix used by MN in Point-to-Point Link Model. A dedicated prefix belongs to an aggregate prefix. Dedicated prefix information never be broadcasted by routing protocol. In this memo, AAA client requests dedicated prefix along with the corresponding aggregate prefix from AAA server. Using the corresponding aggregate prefix information, AAA client broadcasts upstream MN's route information. Sarikaya & Xia Expires April 24, 2009 [Page 4] Internet-Draft RADIUS Prefix Authorization Application October 2008 Prefix Authorization Client (PA Client): RADIUS Client which is responsible for exchange with a RADIUS Server to fulfill prefix request, release, renew and reconfiguration functions. In this document, it can be a HA for allocating prefix for mobile router, or a local mobility anchor (LMA) in Proxy Mobile IPv6 (PMIPv6) scenario for managing dedicated prefix of MN, or an access router in point-to-point link model. Prefix Authorization Server (PA Server): RADIUS Server which is responsible for exchange with a RADIUS Client to fulfill prefix request, release, renew and reconfiguration functions. In this document, it can be collocated with a RADIUS authentication server, or it can be a separated server managing prefixes. Prefix Authorization User (PA User): The end user of prefixes. In this document, it can be MN which configures it's prefixes from LMA in PMIPv6 scenario, or a mobile router, or MN which requests it's prefix in a visited network. 3. Protocol Description Figure 1 shows the architecture of the solution described in this document. PA Client PA Server +----+ +--------+ +-------------+ | | | | RADIUS EAP | +--------+ | | PA |<--->| AR or |<--------------------------->|AAA-EAP | | |User| | LMA or| (Authentication) | +--------+ | | | | HA | | | +----+ | | | | | |RADIUS Prefix Authorization| +---------+ | | |<--------------------------->| AAA-PA | | | | (Authorization) | +---------+ | +--------+ +-------------+ Figure 1: Architecture Overview The use of EAP and the existence of the RADIUS EAP application [RFC3579] has made the RADIUS community to separate the act of authentication from authorization, and in this case, prefix management is a type of authorization. This way, the peer (MN) and AAA client first run an EAP method with the AAA server using RADIUS EAP application, followed by a service authorization process for prefixes. To explicitly authorize the prefixes, in this document, we define a new RADIUS application. The application uses RADIUS Sarikaya & Xia Expires April 24, 2009 [Page 5] Internet-Draft RADIUS Prefix Authorization Application October 2008 messages defined in [RFC2865] and in [RFC5176]. 3.1. Prefix Request A PA Client sends an Access-Request message containing identity of the user to a PA server for prefix request. The client is identified using Authorized-UserID in Authorized-UserID-Prefix attribute defined in this document. Access-Request message MUST contain Authorized- UserID-Prefix attribute. The client MAY request an aggregate prefix, and then MAY subnet the prefix to the users. It is also possible that the client only requests a dedicated prefix. The PA server allocates one or more prefixes for the client using Access-Accept. Lifetime of prefixes is included in Valid Lifetime field of Authorized-UserID-Prefix in this message. The lifetime value included is the value proposed by PA Client. Access-Request MUST contain Prefix-Authorization type attribute. The value MUST be set to Request. PA Server replies with Access-Accept to PA Client. PA server MUST include Authorized-UserID-Prefix attribute in Access-Accept. The server authorizes prefixes included in Authorized-UserID-Prefix to PA Client. The prefixes can be used during Valid Lifetime period. Access-Accept MUST contain Prefix-Authorization type attribute. The value MUST be set to Request. PA Server replies with Access-Accept if the prefix request can be satisfied. In case of a prefix request that can not be fullfilled by PA Server, PA Server sends Access-Reject. Reception of an Access- Reject indicates an unsuccessful prefix request made by PA Client. Reply-Message attribute indicates the failure message. Prefix- Authorization type attribute MUST be set to Request. 3.2. Prefix Release When a PA User detaches a PA Client, the prefixes allocated to the user should be released. Access-Request is sent by a PA Client to a PA Server. The server replies with Access-Accept to confirm the reception and process of the prefix release. PA User and the prefixes to be released are identified in Access- Request and Access-Accept using Authorized-UserID-Prefix attribute. Multiple occurrences of this attribute can be included to release multiple prefixes authorized to the same user or to release prefixes authorized to more than one user. Access-Request MUST contain Prefix-Authorization type attribute. The Sarikaya & Xia Expires April 24, 2009 [Page 6] Internet-Draft RADIUS Prefix Authorization Application October 2008 value MUST be set to Release. Access-Accept MUST contain Prefix- Authorization type attribute. The value MUST be set to Release. PA Server replies with Access-Accept if the prefix release request can be satisfied. In case of a prefix release request that can not be fullfilled by PA Server, PA Server sends Access-Reject. Reception of an Access-Reject indicates an unsuccessful prefix release request made by PA Client. Reply-Message attribute indicates the failure message. Prefix-Authorization type attribute MUST be set to Release. 3.3. Prefix Renew When the lifetime of prefixes will expire, a PA client renews the prefix using Access-Request message. A PA server sends Access-Accept with the new lifetime of the prefixes. PA User and the prefixes to be renewed are identified in Access- Request and Access-Accept using Authorized-UserID-Prefix attribute. Multiple occurrences of this attribute can be included to renew multiple prefixes authorized to the same user or to renew prefixes authorized to more than one user. Access-Request MUST contain Prefix-Authorization type attribute. The value MUST be set to Renew. Access-Accept MUST contain Prefix- Authorization type attribute. The value MUST be set to Renew. PA Server replies with Access-Accept if the prefix renew request can be satisfied. In case of a prefix renew request that can not be fullfilled by PA Server, PA Server sends Access-Reject. Reception of an Access-Reject indicates an unsuccessful prefix renew request made by PA Client. Reply-Message attribute indicates the failure message. Prefix-Authorization type attribute MUST be set to Renew. 3.4. Prefix Renumbering Renumbering is an important feature of IPv6. A PA Server sends Change-of-Authorization-Request message to initiate prefix renumbering process. Once the message is received, a PA client replies with Change-of-Authorization-ACK and then starts the prefix renumber interactions to acquire new prefixes and reduce the lifetime of the old prefixes. The server sends Access-Accept with new prefixes, at the same time the old prefixes are also included in the message while the lifetime is reduced. The procedure is illustrated in Figure 2. Sarikaya & Xia Expires April 24, 2009 [Page 7] Internet-Draft RADIUS Prefix Authorization Application October 2008 +----------+ +----------+ | RADIUS | | RADIUS | | Client | | Server | +----------+ +----------+ | | | | | Change-of-Authorization-Request | |<----------------------------------| | | | Change-of-Authorization-ACK | |---------------------------------->| | | | Access-Request | |---------------------------------->| | Access-Accept | |<--------------------------------- | Figure 2: Renumbering Change-of-Authorization Request and Change-of-Authorization-ACK MUST contain Prefix-Authorization type with value set to Renumber. Access-Request MUST contain Prefix-Authorization type attribute. The value MUST be set to Renumber. Access-Accept MUST contain Prefix- Authorization type attribute. The value MUST be set to Renumber. PA Server replies with Access-Accept if the prefix renumber request can be satisfied. In case of a prefix renumber request that can not be fullfilled by PA Server, PA Server sends Access-Reject. Reception of an Access-Reject indicates an unsuccessful prefix renumber request made by PA Client. Reply-Message attribute indicates the failure message. Prefix-Authorization type attribute MUST be set to Renumber. 4. Use of Existing RADIUS Attributes This section defines existing attributes that are used in the messages of prefix authorization application. 4.1. Service-Type PA Client uses Session-Type to indicate that the session is for prefix authorization by setting the Session-Type attribute to "Authorize Only". Sarikaya & Xia Expires April 24, 2009 [Page 8] Internet-Draft RADIUS Prefix Authorization Application October 2008 4.2. NAS-Port-Type NAS-Port-Type is used by AAA server (PA-Server) to distinguish the source of the Access-Request. When the Access-Request originates from an MIP6 HA or PMIP6 LMA, NAS- Port-Type MUST be included and its value set to HA6 as in [I-D.ietf-mip6-radius]. When the Access-Request originates from an access router such as ASN-GW of WiMAX or Serving Gateway of 3GPP, NAS-Port-Type MUST be included and its value set to AR6 (IANA-TBD1). 4.3. Message Authenticator Message-Authenticator attribute defined in [RFC3579] MUST be used to protect all messages used in Prefix Authorization application. In the messages used for renumbering, Message-Authenticator attribute is calculated as described in [RFC5176]. 5. New Attributes This section defines new attributes. 5.1. Authorized-Prefix Attribute The Authorized-Prefix (Ext-Type TBD) contains prefix information. This attribute is defined as an extended attribute [I-D.ietf-radext-extended-attributes] with a Tag value of zero. Each prefix belongs to an aggregate prefix whose length is given in Agg Prefix Len. A dedicated prefix is an extension of an aggregate prefix. For example, if PA Client applies a /48 aggregate prefix, both aggregate prefix length and prefix length are /48. If PA Server allocates a /64 dedicated prefix belonging to a /48 aggregate prefix to PA Client, aggregate prefix length in the attribute SHOULD be /48 while prefix length SHOULD be /64. PA Client broadcasts aggregate prefix information upstream for traffic routing. Sarikaya & Xia Expires April 24, 2009 [Page 9] Internet-Draft RADIUS Prefix Authorization Application October 2008 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 (26) | Length | Vendor-Id (0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (0) |M| Tag (0) | Ext-Type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type | Ext-Length | Reserved |Agg prefix len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Valid Lifetime +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ + | | + Prefix + | | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Tag Tag MUST be set to zero. Ext-Type Type for Authorized-Prefix Attribute. To be assigned by IANA. Ext-Length The length, 26. M More bit MUST be set to zero. Reserved These bits are reserved. These bits MUST be set to zero by the sender and MUST BE ignored by the receiver. Agg prefix len 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent). A value of all one bits (0xffffffff) represents infinity. Sarikaya & Xia Expires April 24, 2009 [Page 10] Internet-Draft RADIUS Prefix Authorization Application October 2008 Prefix A prefix. 5.2. Prefix-Authorization Attribute Prefix-Authorization attribute contains the type of prefix authorization operation needed by PA Client. The possible values are Request, Renew and Release. Prefix-Authorization attribute is defined as an extended attribute [I-D.ietf-radext-extended-attributes] with a Tag value of zero. 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 (26) | Length | Vendor-Id (0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (0) |M| Tag (0) | Ext-Type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type | Ext-Length | Prefix Authorization Type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tag Tag MUST be set to zero. Ext-Type To be assigned by IANA. Ext-Length The length, 7. M More bit MUST be set to zero. Prefix Authorization Type 1 Request 2 Release 3 Renew 4 Renumber Sarikaya & Xia Expires April 24, 2009 [Page 11] Internet-Draft RADIUS Prefix Authorization Application October 2008 5.3. Authorized-UserID Attribute Authorized prefix user's are identified using Authorized-UserID attribute. This attribute is defined as an extended attribute [I-D.ietf-radext-extended-attributes] with a Tag value of zero. Prefix Authorization User ID is a 64 bits unsigned value. Prefix Authorization server manages prefixes based on Prefix Authorization User IDs. 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 (26) | Length | Vendor-Id (0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (0) |M| Tag (0) | Ext-Type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type | Ext-Length | Prefix Authorization User ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tag Tag MUST be set to zero. Ext-Type Prefix Authorization User ID type. To be assigned by IANA. Ext-Length The length, 11. M More bit MUST be set to zero. Prefix Authorization User ID 64 bits unsigned value 5.4. Authorized-UserID-Prefix Attribute The Authorized-UserID-Prefix (Type TBD) is an extended attribute [I-D.ietf-radext-extended-attributes]. This attribute carries prefixes for users. The user is identified using Authorized-UserID (TBD2) attribute. It should be set to a 64-bit value identifying the user of the prefix(es). For example, link layer identifier of the interface which will receive the prefixes could be used as the user Sarikaya & Xia Expires April 24, 2009 [Page 12] Internet-Draft RADIUS Prefix Authorization Application October 2008 id. The second component of Authorized-UserID-Prefix is Authorized-Prefix defined in Section 5.1 which defines the prefix for Authorized- Prefix-UserID. 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 (26) | Length (44) | Vendor-Id (0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) |M| Tag | Ext-Type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type (TBD) | Ext-Length(11)| Prefix Authorization User ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Length(25)| Reserved |Agg prefix len | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length Overall length = 7 + 11 + 25 M More bit MUST be set to zero. Tag To be assigned by IANA Ext-Type TBD for Authorized-Prefix-User-ID Ext-Length Length = 3 + 8 Other fields are as described in Sarikaya & Xia Expires April 24, 2009 [Page 13] Internet-Draft RADIUS Prefix Authorization Application October 2008 6. Table of Attributes The following tables provides a guide to which attributes may be found in RADIUS messages and in what number. The following defines the meaning of the notation used in the following tables: 0 An instance of this attribute MUST NOT be present. 1 Exactly one instance of this attribute MUST be present 0-1 Zero or one instance of this attribute MAY be present. 0+ Zero or more instance of this attriubte MAY be present The table below describes the RADIUS messages used for bootstrapping and are exchanged between the NAS and the RADIUS Server. Request Accept Reject CoA Request Type Attribute 1 1 1 1 PREFIX Prefix-Authorization AUTHORIZATION-TYPE 0+ 0+ 0+ 0+ Group Authorized-UserID-Prefix 7. Diameter Considerations All the attributes defined in this specification are extended attributes. Diameter compatibility of extended attributes is discussed in [I-D.ietf-radext-extended-attributes]. 8. IANA considerations 8.1. Registration of New AVPs This specification defines the following new RADIUS attributes which are all extended attributes [I-D.ietf-radext-extended-attributes]. Prefix-Authorization is set to PREFIX-AUTHORIZATION-TYPE Authorized-UserID is set to AUTHORIZED-USERID-TYPE Authorized-UserID-Prefix is set to AUTHORIZED-USERID-PREFIX-TYPE 8.2. New Registry: Prefix Authorization Type This specification needs new values for AUTHORIZED-PREFIX-TYPE. The value field is 4 octets. The current values are listed in Sarikaya & Xia Expires April 24, 2009 [Page 14] Internet-Draft RADIUS Prefix Authorization Application October 2008 Section 5.2. 8.3. Addition of Existing Values This specification requires a new value of AR6 to be assigned to NAS- Port-Type(61). 9. Security Considerations This document describes the extension of RADIUS for Prefix Authorization. The security considerations of the RADIUS protocol itself have been discussed in [RFC2865] and in [RFC5176]. Use of the attributes defined in this document MUST take into consideration the security issues and requirements of the RADIUS Base protocol. 10. Acknowledgements Madjid Nakhjiri provided help on RADIUS for which we are grateful. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, Sarikaya & Xia Expires April 24, 2009 [Page 15] Internet-Draft RADIUS Prefix Authorization Application October 2008 January 2008. [I-D.ietf-mip6-radius] Lior, A., Chowdhury, K., and H. Tschofenig, "RADIUS Mobile IPv6 Support", draft-ietf-mip6-radius-05 (work in progress), July 2008. [I-D.ietf-radext-extended-attributes] Li, Y., Lior, A., and G. Zorn, "Extended Remote Authentication Dial In User Service (RADIUS) Attributes", draft-ietf-radext-extended-attributes-04 (work in progress), July 2008. 11.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. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [I-D.ietf-nemo-dhcpv6-pd] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", draft-ietf-nemo-dhcpv6-pd-03 (work in progress), December 2007. [I-D.ietf-radext-design] Weber, G. and A. DeKok, "RADIUS Design Guidelines", draft-ietf-radext-design-05 (work in progress), August 2008. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Sarikaya & Xia Expires April 24, 2009 [Page 16] Internet-Draft RADIUS Prefix Authorization Application October 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 April 24, 2009 [Page 17] Internet-Draft RADIUS Prefix Authorization Application October 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 April 24, 2009 [Page 18]