Softwire Working Group J. Wu Internet-Draft Q. Sun Intended status: Standards Track Z. Liu Expires: August 18, 2014 Tsinghua University February 14, 2014 Radius Extension for Lightweight 4over6 draft-sun-softwire-lw4over6-radius-00 Abstract IPv4-over-IPv6 tunneling transition mechanisms provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co- existing period. The Dynamic Host Configuration Protocol for IPv6(DHCPv6) options has been extended and defined to configure tunnel initiator (TI) in lightweight 4over6. However, in many networks, the configuration information are stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. Thus AAA server as a database can be extended to establish and store the whole information of tunnels and help the tunnel concentrator (TC) recover in failure. This document defines the mechanism and the Remote Authentication Dial In User Service (RADIUS) attributes that carry TI configuration information from AAA server to BNG and the tunnel configuration information from AAA server to TC. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 18, 2014. Wu, et al. Expires August 18, 2014 [Page 1] Internet-Draft Radius Extension February 2014 Copyright Notice Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Configuration process with RADIUS . . . . . . . . . . . . . . 3 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Table of attributes . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Contributors List . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Recently IPv6 is under deployment and providers are considering how to transit to IPv6 smoothly. Many tunnelling based transition mechanisms have been proposed for running IPv4 over IPv6-only infrastructure, such as Lightweight 4over6 [I-D.ietf-softwire-lw4over6] . They provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. In Lightweight 4over6, tunnel configuration information need to be allocated and managed correctly. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is used as auto-configuring protocol. And tunnel configuration information are managed by AAA (Authentication, Authorization, and Accounting) servers. The tunnel initiator(TI) gets tunnel configurations and its own network parameter from the DHCPv6 options in DHCPv6 messages. Current AAA servers communicate using the Remote Authentication Dial In User Service (RADIUS) [RFC2865] protocol. In Wu, et al. Expires August 18, 2014 [Page 2] Internet-Draft Radius Extension February 2014 an access network, the Broadband Network Gateways (BNGs) act as the access gateway of TI. The BNGs are assumed to embed a DHCPv6 server function that allows them to locally handle any DHCPv6 requests initiated by TI. Since TI configuration information is stored in AAA servers and in Lightweight 4over6 the tunnel mapping table is only related to the information of TI and TC, AAA server knows the overall information of the tunnels. Therefore, AAA server, instead of the TC, can allocate tunnel configuration information and establish the tunnel mapping table, which helps relieve the TC. AAA server provides the function of authentication and works as a database storing the information of TI and TC, especially the tunnel mapping table. AAA server has the ability to update the tunnel mapping table in TC and reconfigure the TC when it comes to service again.For the new function of AAA server, new RADIUS attributes are needed to propagate the information from AAA servers to BNGs and TC. 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]. 3. Configuration process with RADIUS TI and TC provide the tunnel service for users to connect to the Internet. BNGs are gateway of TI, and AAA server authenticates TI and TC which is also work as the manager of tunnel. Figure 1 illustrates how the RADIUS protocol and DHCPv6 cooperate to provide TI and TC with tunnel configuration information. TI is the lwB4 in Lightweight 4over6, and TC is the lwAFTR in Lightweight 4over6. Wu, et al. Expires August 18, 2014 [Page 3] Internet-Draft Radius Extension February 2014 TI BNG AAA Server TC | | | | | --DHCPv6 Request--> | | | | | --Access-Request--> | | | | (softwire attriubte)| | | | |--configuration--> | | | | <------ACK------- | | | <--Access-Accept--- | | | | (softwire attriubte)| | | <--DHCPv6 Reply---- | | | DHCPv6 Radius Figure 1: Lightweight 4over6 configuration process with RADIUS and DHCPv6 BNGs act as a RADIUS client and as a DHCPv6 server. Before the tunnel establishes, TI MAY initiate a DHCPv6 Solicit message that includes an Option Request option[RFC3315] with tunnel options defined in [I-D.ietf-softwire-map-dhcp]. When BNG receives the SOLICIT, it SHOULD initiates radius Access-Request message, in which the User-Name attribute SHOULD be filled by the TI MAC address, to the RADIUS server and the User-password attribute SHOULD be filled by the shared password that has been preconfigured on the DHCPv6 server, requesting authentication as defined in [RFC2865] with lw4over6-Configuration Attribute, defined in the next Section. If the authentication request is approved by the AAA server, it SHOULD distribute the tunnel configuration for TI. Since AAA server knows the IP addresses, Port of TI and the IP address of TC, it will establish tunnel mapping table which SHOULD be used to convert message by TC in Lightweight 4over6. AAA server SHOULD first send the configuration with new tunnel mapping table to TC defined in [I-D.zhou-dime-4over6-provisioning] TC SHOULD update its tunnel mapping table with the configuration and replies an ACK message. Then, an Access-Accept message MUST be replied to BNG with the lw4over6-Configuration Attribute. After receiving the Access-Accept message with lw4over6-Configuration Attribute, BNG SHOULD respond TI an DHCPv6 message with tunnel configuration. After receiving the initial Access-Accept, the BNG SHOULD store the received configuration parameters from the lw4over6-Configuration Attribute locally. When TI sends a DHCPv6 Request message to renew the assigned IPv6 lease, the BNG does not have to initiate a new Access-Request towards the AAA server and repeat the process mentioned earlier. The BNG could retrieve the previously stored configuration parameters and use them in its reply. Wu, et al. Expires August 18, 2014 [Page 4] Internet-Draft Radius Extension February 2014 If the BNG does not receive the Configuration Attribute in the Access-Accept or if the BNG receives an Access-Reject, the tunnel cannot be established. TC need to update its tunnel mapping table from AAA server and AAA server also need to store the information of TC, so the identity of TC SHOULD be checked in consideration of security. Figure 2 describes another situation, in which TC authenticate itself to AAA server and recover rapidly with the help of AAA server. AAA Server TC | | | <-----Access-Request----- | | (softwire attriubte) | | -----Access-Accept-----> | | (softwire attriubte) | | <----------ACK----------- | Radius Figure 2: TC's authentication and recovery TC SHOULD authenticate itself to AAA server before working. In the process, AAA server will store TC's information including TC's address, and send the existing tunnel mapping table. As TC is recognized, AAA server will update new tunnel mapping table to TC afterwards. In another situation, when TC fails in fault, the standby TC can recover its tunnel mapping table during the authentication. When TC first connect to the network, TC SHOULD initiates radius Access-Request message, in which the User-Name attribute SHOULD be filled by the TC MAC address, to the RADIUS server and the User-password attribute SHOULD be filled by the shared password that has been preconfigured, requesting authentication as defined in[RFC2865]. If the authentication request is approved by the AAA server, AAA server SHOULD store the information of TC, and reply an Access-Accept message with lw4over6-Configuration Attribute which contains the tunnel mapping table. After receiving the Access- Accept message , TC can update its tunnel mapping table and recover its function immediately. At last TC SHOULD reply an ACK message to AAA server. 4. Attributes This section defines the Lw4over6-Configuration Attribute that is used in both above-mentioned scenarios. The attribute design follows [RFC6158]. Wu, et al. Expires August 18, 2014 [Page 5] Internet-Draft Radius Extension February 2014 The Lw4over6-Configuration attribute contains TI's information including IPv6 address, IPv4 address and the port-set.The BNG SHALL store the information and reply TI according to it. When the Access- Request message is triggered by a DHCP Rebind message, and BNG received the new Lw4over6-Configuration Attribute in the Access- Accept message ,the BNG MUST store the new TI's configuration and force TI to reconfigure itself using the new tunnel information received in the Access-Accept message. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Set Index | Port Set Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 2 Port Set Index: Port Set Index identifies a set of ports assigned to TI. Port Set Mask: Port Set Mask indicates the position of the bits used to build the mask. IPv4 address: The translated IPv4 address for TI. IPv6 address: The IPv6 address for TI. Figure 3: Lw4over6-Configuration Attribute 5. Table of attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Wu, et al. Expires August 18, 2014 [Page 6] Internet-Draft Radius Extension February 2014 Request Accept Reject Challenge Accounting # Attribute Request 0-1 0-1 0 0 0-1 TBD1 lw4o6-Configuration 0-1 0-1 0 0 0-1 1 User-Name 0-1 0 0 0 0 2 User-Password 0-1 0-1 0 0 0-1 6 Service-Type 0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet. Figure 4: Lightweight 4over6 Attribute Table 6. Security Considerations TI,TC and BNG are within a provider network,which can be considered as a closed network and a lower security threat environment. But, A malicious user may use MAC address proofing to get unauthorized tunnel configuration information or set up a spurious TI.It requires extra method to protect the message exchange between TI and BNG. In the another hand, RADIUS message exchange between BNG and the AAA server or between TC and AAA server using RADIUS protocol. And the security consideration of the RADIUS protocol are discussed in [RFC2865] and [RFC2869]. 7. IANA Considerations This document has no IANA actions. 8. Contributors List Many thanks to Yong Cui and Cong Liu, for their great contributions to the draft. 9. References 9.1. Normative References [I-D.ietf-radext-radius-extensions] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", draft-ietf-radext- radius-extensions-13 (work in progress), February 2013. Wu, et al. Expires August 18, 2014 [Page 7] Internet-Draft Radius Extension February 2014 [I-D.ietf-softwire-lw4over6] Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS- Lite Architecture", draft-ietf-softwire-lw4over6-06 (work in progress), February 2014. [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. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, 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. [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011. 9.2. Informative References [I-D.ietf-softwire-map-dhcp] Mrugalski, T., Troan, O., Dec, W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients", draft-ietf-softwire-map-dhcp-06 (work in progress), November 2013. [I-D.zhou-dime-4over6-provisioning] Zhou, C., Taylor, T., Qiong, Q., and M. Boucadair, "Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions", draft- zhou-dime-4over6-provisioning-02 (work in progress), October 2013. Authors' Addresses Wu, et al. Expires August 18, 2014 [Page 8] Internet-Draft Radius Extension February 2014 Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: jianping@cernet.edu.cn Qi Sun Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: sunqi@csnet1.cs.tsinghua.edu.cn ZiLong Liu Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: liuzilong8266@126.com Wu, et al. Expires August 18, 2014 [Page 9]