DHC Working GroupInternet Engineering Task Force (IETF) L. YehInternet-DraftRequest for Comments: 7037 Freelancer TechnologiesIntended status:Category: Standards Track M. BoucadairExpires: January 30, 2014ISSN: 2070-1721 France TelecomJuly 29,October 2013 RADIUS Option for the DHCPv6 Relay Agentdraft-ietf-dhc-dhcpv6-radius-opt-14Abstract The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. This architecture assumes that the Network AccessServer(NAS)Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client. When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server. The DHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests. Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 30, 2014.http://www.rfc-editor.org/info/rfc7037. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .. 32 2. Terminology and Language . . . . . . . . . . . . . . . . . ..3 3. Network Scenarios . . . . . . . . . . . . . . . . . . . . . .43 4. DHCPv6 RADIUSoption .Option . . . . . . . . . . . . . . . . . . . .76 4.1. RADIUSattributes permittedAttributes Permitted in DHCPv6 RADIUSoptionOption . . .87 5. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . .87 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . ..8 7. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . ..8 8. Security Considerations . . . . . . . . . . . . . . . . . . .98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .. 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . .. 109 11.1. Normative References . . . . . . . . . . . . . . . . . .. 109 11.2. Informative References . . . . . . . . . . . . . . . . .. 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 1110 1. Introduction DHCPv6 provides a mechanism that allows the server to assign or delegate both stateful and stateless configuration parameters totheclients. The stateful configuration parameters include IPv6addressaddresses [RFC3315] and IPv6prefixprefixes [RFC3633]. The stateless configuration parameters [RFC3736] include, for example, DNS [RFC3646], or aFQDNFully Qualified Domain Name (FQDN) ofAFTRan Address Family Transition Router (AFTR) [RFC6334]. In the scenarios described in this document, the DHCPv6 server is deployed in the central part of an ISP network. RADIUS [RFC2865] is widely used as the centralized authentication,authorizationauthorization, and user management mechanism for service provision in a Broadband access network. [RFC3162], [RFC4818],[RFC6519][RFC6519], and [RFC6911]specifiedspecify the attributes that support the service provision for IPv6-only and IPv6-transition access. The RADIUS server authorizes the Network Access Server (NAS) to assign an IPv6 address or prefix from the indicated pool, or to assign an IPv6 address or prefix with an explicitly indicated value, and to indicate other configuration parameters as per the RADIUS attributes for the subscribers. When the NAS acts as the distributed DHCPv6 server and RADIUS client simultaneously, it communicates with the RADIUS server after receiving a request from the DHCPv6 client. Upon receiving the Access-Accept message from the RADIUS server, the NAS then responds to the DHCPv6 client's requests per the associated authorization information indicated by the RADIUS attributes in the Access-Accept message. When NAS acts as the DHCPv6 relay agent and RADIUS client simultaneously, and the centralized DHCPv6 server is co-located with the RADIUS server, they may share the same database ofthe users; butusers. However, when the centralized DHCPv6 server is not located in the same place as the RADIUS server, a new communication mechanism is needed for the DHCPv6 relay agent to transfer the authorization information indicated by the RADIUS attributes to the DHCPv6 server. 2. Terminology and Language This document specifies a new DHCPv6 option for the DHCPv6 Relay Agent to transfer the authorization information of RADIUS attributes received in the Access-Accept message from the RADIUS server to the centralized DHCPv6 server. Definitions for terms and acronyms not specified in this document are defined in [RFC2865] and [RFC3315]. 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. Network ScenariosFigureFigures 1 andFigure2 show the typical network scenarios where the communication mechanism introduced in this document is necessary. In these scenarios, the centralized DHCPv6 server is not co-located with the RADIUS server, but bothof themare in the same administrative domain. The NAS acts as the DHCPv6 relay agent and the RADIUS client simultaneously. Figure 1 shows the sequence of DHCPv6 and RADIUS messages for the IP over Ethernet (IPoE) access model, when the access loop adopts the direct Ethernet encapsulation. Figure 2 shows the sequence of DHCPv6 and RADIUS messages for the PPP over Ethernet (PPPoE) access model. The mechanism introduced in this document is a genericmechanism,mechanism and might also be employed in other network scenarios where the DHCPv6 relay agent and the RADIUS clientlocateare located in the same device. +-------+ +-------+ +-------+ |DHCPv6 | Access Model: | NAS | |RADIUS | |Client | IPoE | | |Server | +-------+ +-------+ +-------+ RADIUS Client/DHCPv6 Relay Agent | | | |---Solicit---------------->| | | |---Access-Request---------->| | | | | |<--Access-Accept------------| | |(e.g. Delegated-IPv6-Prefix)| | | | DHCPv6 messages RADIUS messages +-------+ |DHCPv6 | |Server | +-------+ | | | | |---Relay-forward----------->| | | (OPTION_RADIUS) | | | | | |<--Relay-reply -------------| |<--Advertise---------------| | |(e.g.(e.g., IA_PD) | | | | | |---Request---------------->| | |(e.g.(e.g., IA_PD) |---Relay-forward----------->| | | (OPTION_RADIUS) | | | | | |<--Relay-reply -------------| |<--Reply-------------------| | |(e.g.(e.g., IA_PD) | | | | | DHCPv6 messages DHCPv6 messages Figure 1: NetworkscenarioScenario andmessage sequence when employingMessage Sequence When Employing DHCPv6 RADIUSoptionOption in IPoEaccessAccess +-------+ +-------+ +-------+ |DHCPv6 | Access Model: | NAS | |RADIUS | |Client | PPPoE | | |Server | +-------+ +-------+ +-------+ RADIUS Client/DHCPv6 Relay Agent | | | |--PPP LCP Config-Request-->| | | |---Access-Request---------->| | | | | |<--Access-Accept------------| |<----PPP LCP Config-ACK----|(e.g. Delegated-IPv6-Prefix)| | | | PPP messages RADIUS messages +-------+ |DHCPv6 | |Server | +-------+ | | | |---Solicit---------------->| | | |---Relay-forward----------->| | | (OPTION_RADIUS) | | | | | |<--Relay-reply -------------| |<--Advertise---------------| | |(e.g.(e.g., IA_PD) | | | | | |---Request---------------->| | |(e.g.(e.g., IA_PD) |---Relay-forward----------->| | | (OPTION_RADIUS) | | | | |<--Relay-reply -------------| |<--Reply-------------------| | |(e.g.(e.g., IA_PD) | | | | | DHCPv6 messages DHCPv6 messages Figure 2: NetworkscenarioScenario andmessage sequence when employingMessage Sequence When Employing DHCPv6 RADIUSoptionOption in PPPoEaccessAccess If the authentication or the authorization through RADIUS fails, the associated message sequences will stop. The NAS acting as the DHCPv6 relay agent will not forward the message received from the client to the DHCPv6 server. If the authentication or the authorization through RADIUS passes, the NAS MUST store the information indicated in the RADIUS attributes received in the Access-Accept message from the RADIUS server during the whole session. How the NAS managesthesethis information during the RADIUS session is out of the scope of this document. After receiving a RENEW (5) message from the DHCPv6 client, the NAS SHOULD NOT initiate a new Access-Request/Access-Accept message exchange with the RADIUS server. After receiving a REBIND (6) message from the DHCPv6 client, the NAS MUST initiate a newAccess-Request/ Access-AcceptAccess- Request/Access-Accept message exchange with the RADIUS server, unless RADIUS capability is disabled on the NAS. 4. DHCPv6 RADIUSoptionOption The OPTION_RADIUS is a DHCPv6 option used by the DHCPv6 relay agent to carry the authorization information of RADIUS attributes received in the Access-Accept message from the RADIUS server. The format of the OPTION_RADIUS option is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RADIUS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data (List of RADIUS Attributes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-codeTBD81 option-len Length of the option-data in octets option-data List of one or more RADIUS attributes The option-data of OPTION_RADIUS is a list of one or more RADIUS attributes received in the Access-Accept message from the RADIUS server. The format of RADIUS attributes is defined insectionSection 5 of [RFC2865] as well assectionsSections 2.1 and 2.2 of [RFC6929]. If multiple attributes with the same type (including the Long ExtendedtypeType defined insectionsSection 2.2 of [RFC6929]) are present, the order of attributes with the same type MUST be the same as that received from the RADIUS server. The OPTION_RADIUS can only contain the RADIUS attributes listed in theIANA Registry of 'RADIUS attributes permitted"RADIUS Attributes Permitted in DHCPv6 RADIUSoption'.Option" registry. According to the network scenarios described insectionSection 3, the OPTION_RADIUS should appear in the RELAY-FORW (12) message relaying SOLICIT (1), REQUEST(3)(3), and REBIND (6) from the DHCPv6client,client and may appear in the RELAY-FORW (12) relaying any other message from the DHCPv6 client. 4.1. RADIUSattributes permittedAttributes Permitted in DHCPv6 RADIUSoptionOption The RADIUS attributes listed in thebelowfollowing table arerecommended asthefirst batch ofinitial attributes registered in theIANA Registry of 'RADIUS attributes permitted"RADIUS Attributes Permitted in DHCPv6 RADIUSoption'.Option" registry. New RADIUS attributes can be added to this list after Expert Review [RFC5226]. Type Code Attribute Reference 26 Vendor-Specific [RFC2865] 123 Delegated-IPv6-Prefix [RFC4818] 144 DS-Lite-Tunnel-Name [RFC6519] 168 Framed-IPv6-Address [RFC6911] 169 DNS-Server-IPv6-Address [RFC6911] 171 Delegated-IPv6-Prefix-Pool [RFC6911] 172 Stateful-IPv6-Address-Pool [RFC6911] Note: The RADIUS attribute's 'Length' defined insectionSection 5 of [RFC2865] includes the length of 'Type' and 'Length' fields. 5. DHCPv6 Relay Agent Behavior If the Relay Agent is configured to send OPTION_RADIUS, and the Access-Accept message from the RADIUS server contained RADIUS attributes permitted for use in OPTION_RADIUS, the Relay Agent MUST include OPTION_RADIUS in the RELAY-FORW (12) message. The DHCPv6 relay agentincludesadds the permitted RADIUS attributes into OPTION_RADIUS one by one; if multiple attributes with the same type are present, the order of attributes with the same type MUST be the same as that received from the RADIUS server. 6. DHCPv6 Server Behavior Upon receipt of the RELAY-FORW (12) message with OPTION_RADIUS from a relay agent, the DHCPv6 server that supports OPTION_RADIUS SHOULD extract and interpret the RADIUS attributes in theOPTION_RADIUS,OPTION_RADIUS and use that informationin selectingto select configuration parameters for the requesting client. If the DHCPv6 server does not support OPTION_RADIUS, the DHCPv6 server MUST silently discard this option. 7. DHCPv6 Client Behavior OPTION_RADIUS is only exchanged between the relay agents and the servers. DHCPv6 clients are not aware of the usage of OPTION_RADIUS. DHCPv6clientclients MUST NOT sendOPTION_RADIUS,OPTION_RADIUS and MUST ignore OPTION_RADIUS if received. 8. Security Considerations Known security vulnerabilities of the DHCPv6 and RADIUSprotocolprotocols may apply toitstheir options. Security issues related with DHCPv6 are described insectionSection 23 of [RFC3315]. Security issues related with RADIUS are described insectionSection 8 of [RFC2865],sectionSection 5 of [RFC3162],sectionand Section 11 of [RFC6929]. The mechanism described in this document may introduce a new attack vector against the DHCPv6 server incasecases where the DHCPv6 relay agent is compromised. By forging the RADIUS attributes contained in the OPTION_RADIUS of the RELAY-FORW (12) messages, the attacker may influence the parameter assignment on the DHCPv6 server for the DHCPv6 clients. However, asthose network scenariosdescribed in thesectionSection 3, NAS always belongs to the same administrative domain of the DHCPv6 server in the real deployment. Network administrators should be aware that although RADIUS messages are encrypted, DHCPv6 messages are alwaysnot encrypted.unencrypted. It is possible that some RADIUS vendor-specific attributes might containthesensitive or confidential information. Network administrators are strongly advised to preventincludingsuch informationintofrom being included in DHCPv6 messages. If the use of vendor-specific attributes with confidential content is required, administrators are advised to use IPsec with encryption to protect the confidentiality of the RADIUS attributes. Relay agents and servers implementing this specification MUST support the use of IPsecESPEncapsulating Security Payload (ESP) with encryption in transportmodemode, according tosectionSection 3.1.1 of [RFC4303] andsectionSection 21.1 of [RFC3315]. 9. IANA ConsiderationsThis document requests to assign a new DHCPv6 option code forIANA has assigned OPTION_RADIUS (81) in the "DHCP Option Codes" registry, as defined insection 4, and to createSection 4. In addition, IANA has created a new registryon the same assignment page, which isentitledas 'RADIUS attributes permitted"RADIUS Attributes Permitted in DHCPv6 RADIUSoption'Option" in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry, as defined insectionSection 4.1. The new registrywill enumerateenumerates the RADIUS Attributes Types(http://www.iana.org/assignments/radius-types/radius-types.xml)(http://www.iana.org/ assignments/radius-types) that are permittedto be includedfor inclusion in the DHCPv6 RADIUS option. The allocation policy of this'RADIUS attributes permitted"RADIUS Attributes Permitted in DHCPv6 RADIUSoption'Option" registry is Expert Review per [RFC5226]. Designatedexpertexperts should carefully consider the security implications of allowing the relay agent to include new RADIUSattribute for the additionattributes to this registry. 10. Acknowledgements Thanks to Tomek Mrugalski, Bernie Volz, GauravHalwasiaHalwasia, and Roberta Maglione for their thorough review comments in themailing list ofDHC workinggroup,group mailing list. Thanks also to Ted Lemon for his continuous encouragement and technical guidance. 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. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- Stack Lite", RFC 6519, February 2012. [RFC6911] Dec, W., Sarikaya, B., Zorn, G., Miles, D., and B. Lourdelet, "RADIUS Attributes for IPv6 Access Networks", RFC 6911, April 2013. [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. 11.2. Informative References [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011. Authors' Addresses Leaf Y. Yeh Freelancer Technologies P. R. ChinaEmail:EMail: leaf.yeh.sdo@gmail.com Mohamed Boucadair France Telecom FranceEmail:EMail: mohamed.boucadair@orange.com