rfc2809.txt

RFC 的详细文档！

Network Working Group                                          B. Aboba
Request for Comments: 2809                                    Microsoft
Category: Informational                                         G. Zorn
                                                                  Cisco
                                                             April 2000


         Implementation of L2TP Compulsory Tunneling via RADIUS

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document discusses implementation issues arising in the
   provisioning of compulsory tunneling in dial-up networks using the
   L2TP protocol.  This provisioning can be accomplished via the
   integration of RADIUS and tunneling protocols. Implementation issues
   encountered with other tunneling protocols are left to separate
   documents.

1. Terminology

   Voluntary Tunneling
              In voluntary tunneling, a tunnel is created by the user,
              typically via use of a tunneling client.

   Compulsory Tunneling
              In compulsory tunneling, a tunnel is created without any
              action from the user and without allowing the user any
              choice.

   Tunnel Network Server
              This is a server which terminates a tunnel. In L2TP
              terminology, this is known as the L2TP Network Server
              (LNS).








Aboba & Zorn                 Informational                      [Page 1]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   Network Access Server
              The Network Access Server (NAS) is the device that clients
              contact in order to get access to the network. In L2TP
              terminology, a NAS performing compulsory tunneling is
              referred to as the L2TP Access Concentrator (LAC).

   RADIUS authentication server
              This is a server which provides for
              authentication/authorization via the protocol described in
              [1].

   RADIUS proxy
              In order to provide for the routing of RADIUS
              authentication requests, a RADIUS proxy can be employed.
              To the NAS, the RADIUS proxy appears to act as a RADIUS
              server, and to the RADIUS server, the proxy appears to act
              as a RADIUS client.  Can be used to locate the tunnel
              endpoint when realm-based tunneling is used.

2.  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [4].

3.  Introduction

   Many applications of tunneling protocols involve dial-up network
   access.  Some, such as the provisioning of secure access to corporate
   intranets via the Internet, are characterized by voluntary tunneling:
   the tunnel is created at the request of the user for a specific
   purpose. Other applications involve compulsory tunneling: the tunnel
   is created without any action from the user and without allowing the
   user any choice.

   Examples of applications that might be implemented using compulsory
   tunnels are Internet software upgrade servers, software registration
   servers and banking services.  These are all services which, without
   compulsory tunneling, would probably be provided using dedicated
   networks or at least dedicated network access servers (NAS), since
   they are characterized by the need to limit user access to specific
   hosts.

   Given the existence of widespread support for compulsory tunneling,
   however, these types of services could be accessed via any Internet
   service provider (ISP).  The most popular means of authorizing dial-
   up network users today is through the RADIUS protocol. The use of
   RADIUS allows the dial-up users' authorization and authentication



Aboba & Zorn                 Informational                      [Page 2]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   data to be maintained in a central location, rather than on each NAS.
   It makes sense to use RADIUS to centrally administer compulsory
   tunneling, since RADIUS is widely deployed and was designed to carry
   this type of information.  New RADIUS attributes are needed to carry
   the tunneling information from the RADIUS server to the NAS. Those
   attributes are defined in [3].

3.1.  Advantages of RADIUS-based compulsory tunneling

   Current proposals for routing of tunnel requests include static
   tunneling, where all users are automatically tunneled to a given
   endpoint, and realm-based tunneling, where the tunnel endpoint is
   determined from the realm portion of the userID. User-based tunneling
   as provided by integration of RADIUS and tunnel protocols offers
   significant advantages over both of these approaches.

   Static tunneling requires dedication of a NAS device to the purpose.
   In the case of an ISP, this is undesirable because it requires them
   to dedicate a NAS to tunneling service for a given customer, rather
   than allowing them to use existing NASes deployed in the field. As a
   result static tunneling is likely to be costly for deployment of a
   global service.

   Realm-based tunneling assumes that all users within a given realm
   wish to be treated the same way. This limits flexibility in account
   management.  For example, BIGCO may desire to provide Janet with an
   account that allows access to both the Internet and the intranet,
   with Janet's intranet access provided by a tunnel server located in
   the engineering department. However BIGCO may desire to provide Fred
   with an account that provides only access to the intranet, with
   Fred's intranet access provided by a tunnel network server located in
   the sales department. Such a situation cannot be accommodated with
   realm-based tunneling, but can be accommodated via user-based
   tunneling as enabled by the attributes defined in [3].

4.  Authentication alternatives

   RADIUS-based compulsory tunneling can support both single
   authentication, where the user is authenticated at the NAS or tunnel
   server, or dual authentication, where the user is authenticated at
   both the NAS and the tunnel server. When single authentication is
   supported, a variety of modes are possible, including telephone-
   number based authentication.  When dual-authentication is used, a
   number of modes are available, including dual CHAP authentications;







Aboba & Zorn                 Informational                      [Page 3]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   CHAP/EAP authentication; CHAP/PAP(token) authentication; and EAP/EAP
   authentication, using the same EAP type for both authentications. EAP
   is described in [5].

   The alternatives are described in more detail below.

4.1.  Single authentication

   Single authentication alternatives include:

   NAS authentication
   NAS authentication with RADIUS reply forwarding
   Tunnel server authentication

4.1.1.  NAS authentication

   With this approach, authentication and authorization (including
   tunneling information) occurs once, at the NAS. The advantages of
   this approach are that it disallows network access for unauthorized
   NAS users, and permits accounting to done at the NAS.  Disadvantages
   are that it requires that the tunnel server trust the NAS, since no
   user authentication occurs at the tunnel server. Due to the lack of
   user authentication, accounting cannot take place at the tunnel
   server with strong assurance that the correct party is being billed.

   NAS-only authentication is most typically employed along with LCP
   forwarding and tunnel authentication, both of which are supported in
   L2TP, described in [2].  Thus, the tunnel server can be set up to
   accept all calls occurring within authenticated tunnels, without
   requiring PPP authentication.  However, this approach is not
   compatible with roaming, since the tunnel server will typically only
   be set up to accept tunnels from a restricted set of NASes. A typical
   initiation sequence looks like this:

   Client and NAS: Call Connected
   Client and NAS: PPP LCP negotiation
   Client and NAS: PPP authentication
   NAS to RADIUS Server: RADIUS Access-request
   RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
   NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding
   Tunnel Server to NAS: L2TP Incoming-Call-Reply
   NAS to Tunnel Server: L2TP Incoming-Call-Connected
   Client and Tunnel Server: NCP negotiation








Aboba & Zorn                 Informational                      [Page 4]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   The process begins with an incoming call to the NAS, and the PPP LCP
   negotiation between the client and the NAS. In order to authenticate
   the client, the NAS will send a RADIUS Access-Request to the RADIUS
   server and will receive a RADIUS Access-Accept including tunnel
   attributes, or an Access-Reject.

   In the case where an L2TP tunnel is indicated, the NAS will now bring
   up a control connection if none existed before, and the NAS and
   tunnel server will bring up the call. At this point, data will begin
   to flow through the tunnel.  The NAS will typically employ LCP
   forwarding, although it is also possible for the tunnel server to
   renegotiate LCP.  If LCP renegotiation is to be permitted, the NAS
   SHOULD NOT send an LCP CONFACK completing LCP negotiation. Rather
   than sending an LCP CONFACK, the NAS will instead send an LCP
   Configure-Request packet, described in [6].  The Client MAY then
   renegotiate LCP, and from that point forward, all PPP packets
   originated from the client will be encapsulated and sent to the
   tunnel server.

   Since address assignment will occur at the tunnel server, the client
   and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will
   occur between the client and the tunnel server.

4.1.2.  NAS authentication with RADIUS reply forwarding

   With this approach, authentication and authorization occurs once at
   the NAS and the RADIUS reply is forwarded to the tunnel server. This
   approach disallows network access for unauthorized NAS users; does
   not require trust between the NAS and tunnel server; and allows for
   accounting to be done at both ends of the tunnel. However, it also
   requires that both ends share the same secret with the RADIUS server,
   since that is the only way that the tunnel server can check the
   RADIUS Access-Reply.

   In this approach, the tunnel server will share secrets with all the
   NASes and associated RADIUS servers, and there is no provision for
   LCP renegotiation by the tunnel server. Also, the tunnel server will
   need to know how to handle and verify RADIUS Access-Accept messages.

   While this scheme can be workable if the reply comes directly from a
   RADIUS server, it would become unmanageable if a RADIUS proxy is
   involved, since the reply would be authenticated using the secret
   shared by the client and proxy, rather than the RADIUS server. As a
   result, this scheme is impractical.







Aboba & Zorn                 Informational                      [Page 5]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


4.1.2.1. Tunnel server authentication

   In this scheme, authentication and authorization occurs once at the
   tunnel server.  This requires that the NAS determine that the user
   needs to be tunneled (through RADIUS or NAS configuration). Where
   RADIUS is used, the determination can be made using one of the
   following methods:

   Telephone-number based authentication
   UserID

4.1.2.2.  Telephone-number based authentication

   Using the Calling-Station-Id and Called-Station-Id RADIUS attributes,
   authorization and subsequent tunnel attributes can be based on the
   phone number originating the call, or the number being called. This
   allows the RADIUS server to authorize users based on the calling
   phone number or to provide tunnel attributes based on the Calling-
   Station-Id or Called-Station-Id.  Similarly, in L2TP the tunnel
   server MAY choose to reject or accept the call based on the Dialed
   Number and Dialing Number included in the L2TP Incoming-Call-Request
   packet sent by the NAS.  Accounting can also take place based on the
   Calling-Station-Id and Called-Station-Id.

   RADIUS as defined in [1] requires that an Access-Request packet
   contain a User-Name attribute as well as either a CHAP-Password or
   User-Password attribute, which must be non-empty.  To satisfy this
   requirement the Called-Station-Id or Calling-Station-Id MAY be
   furnished in the User-Name attribute and a dummy value MAY be used in
   the User-Password or CHAP-Password attribute.

   In the case of telephone-number based authentication, a typical
   initiation sequence looks like this:

   Client and NS: Call Connected
   NAS to RADIUS Server: RADIUS Access-request
   RADIUS server to NAS: RADIUS Access-Accept/Access-Reject