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]