Internet DRAFT - draft-sun-softwire-lw4over6-radius
draft-sun-softwire-lw4over6-radius
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]
