rfc2809.txt

radius服务器

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






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


   The process begins with an incoming call to the NAS. If configured
   for telephone-number based authentication, the NAS sends a RADIUS
   Access-Request containing the Calling-Station-Id and the Called-
   Station-Id attributes. The RADIUS server will then respond with a
   RADIUS Access-Accept or Access-Reject.

   The NAS MUST NOT begin PPP authentication before bringing up the
   tunnel.  If timing permits, the NAS MAY bring up the tunnel prior to
   beginning LCP negotiation with the peer. If this is done, then LCP
   will not need to be renegotiated between the peer and tunnel server,
   nor will LCP forwarding need to be employed.

   If the initial telephone-number based authentication is unsuccessful,
   the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS
   MUST send an LCP-Terminate and disconnect the user.

   In the case where tunnel attributes are included in the RADIUS
   Access-Accept, and an L2TP tunnel is indicated, the NAS will now
   bring up a control connection if none existed before. This is
   accomplished by sending an L2TP Start-Control-Connection-Request
   message to the tunnel server.  The tunnel server will then reply with
   an L2TP Start-Control-Connection-Reply.  If this message indicates an
   error, or if the control connection is terminated at any future time,
   then the NAS MUST send an LCP-Terminate and disconnect the user.

   The NAS will then send an L2TP Incoming-Call-Request message to the
   tunnel server. Among other things, this message will contain the Call
   Serial Number, which along with the NAS-IP-Address and Tunnel-
   Server-Endpoint is used to uniquely identify the call. The tunnel
   server will reply with an L2TP Incoming-Call-Reply message. If this
   message indicates an error, then the NAS MUST send an LCP-Terminate
   and disconnect the user. If no error is indicated, the NAS then
   replies with an L2TP Incoming-Call-Connected message.

   At this point, data can begin to flow through the tunnel. If LCP
   negotiation had been begun between the NAS and the client, then LCP
   forwarding may be employed, or the client and tunnel server will now
   renegotiate LCP and begin PPP authentication. Otherwise, the client
   and tunnel server will negotiate LCP for the first time, and then
   move on to PPP authentication.

   If a renegotiation is required, at the time that the renegotiation
   begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP
   negotiation, and the client and NAS MUST NOT have begun NCP
   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



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


   the tunnel server.  When LCP re-negotiation has been concluded, the
   NCP phase will begin, and the tunnel server will assign an address to
   the client.

   If L2TP is being used as the tunnel protocol, and LCP renegotiation
   is required, the NAS MAY in its initial setup notification include a
   copy of the LCP CONFACKs sent in each direction which completed LCP
   negotiation. The tunnel server MAY then use this information to avoid
   an additional LCP negotiation. With L2TP, the initial setup
   notification can also include the authentication information required
   to allow the tunnel server to authenticate the user and decide to
   accept or decline the connection. However, in telephone-number based
   authentication, PPP authentication MUST NOT occur prior to the NAS
   bringing up the tunnel.  As a result, L2TP authentication forwarding
   MUST NOT be employed.

   In performing the PPP authentication, the tunnel server can access
   its own user database, or alternatively can send a RADIUS Access-
   Request.  The latter approach is useful in cases where authentication
   forwarding is enabled, such as with roaming or shared use networks.
   In this case, the RADIUS and tunnel servers are under the same
   administration and are typically located close together, possibly on
   the same LAN.  Therefore having the tunnel server act as a RADIUS
   client provides for unified user administration. Note that the tunnel
   server's RADIUS Access-Request is typically sent directly to the
   local RADIUS server rather than being forwarded via a proxy.

   The interactions involved in initiation of a compulsory tunnel with
   telephone-number based authentication are summarized below. In order
   to simplify the diagram that follows, we have left out the client.
   However, it is understood that the client participates via PPP
   negotiation, authentication and subsequent data interchange with the
   Tunnel Server.


















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


                                  INITIATION SEQUENCE

   NAS                            Tunnel Server       RADIUS Server
   ---                            -------------       -------------
   Call connected
   Send RADIUS
    Access-Request
    with Called-Station-Id,
    and/or Calling-Station-Id
   LCP starts
                                                      IF authentication
                                                      succeeds
                                                       Send ACK
                                                      ELSE Send NAK
   IF NAK DISCONNECT
   ELSE
    IF no control
     connection exists
     Send
     Start-Control-Connection-Request
     to Tunnel Server
                                Send
                                Start-Control-Connection-Reply
                                to NAS
    ENDIF

   Send
   Incoming-Call-Request
   message to Tunnel Server
                                Send Incoming-Call-Reply
                                to NAS
   Send
   Incoming-Call-Connected
   message to Tunnel Server

   Send data through the tunnel
                                Re-negotiate LCP,
                                authenticate user,
                                bring up IPCP,
                                start accounting











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


4.1.2.3.  User-Name

   Since authentication will occur only at the tunnel-server, tunnel
   initiation must occur prior to user authentication at the NAS. As a
   result, this scheme typically uses either the domain portion of the
   userID or attribute-specific processing on the RADIUS server.  Since
   the user identity is never verified by the NAS, either the tunnel
   server owner must be willing to be billed for all incoming calls, or
   other information such as the Calling-Station-Id must be used to
   verify the user's identity for accounting purposes.

   In attribute-specific processing RADIUS may be employed and an
   attribute is used to signal tunnel initiation.  For example, tunnel
   attributes can be sent back if the User-Password attribute contains a
   dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID
   beginning with a special character ('*') could be used to indicate
   the need to initiate a tunnel.  When attribute-specific processing is
   used, the tunnel server may need to renegotiate LCP.

   Another solution involves using the domain portion of the userID; all
   users in domain X would be tunneled to address Y. This proposal
   supports compulsory tunneling, but does not provide for user-based
   tunneling.

   In order for the NAS to start accounting on the connection, it would
   need to use the identity claimed by the user in authenticating to the
   tunnel server, since it did not verify the identity via RADIUS.
   However, in order for that to be of any use in accounting, the tunnel
   endpoint needs to have an account relationship with the NAS owner.
   Thus even if a user has an account with the NAS owner, they cannot
   use this account for tunneling unless the tunnel endpoint also has a
   business relationship with the NAS owner. Thus this approach is
   incompatible with roaming.

   A typical initiation sequence involving use of the domain portion of
   the userID looks like this:

   Client and NAS: Call Connected
   Client and NAS: PPP LCP negotiation
   Client and NAS: Authentication
   NAS to Tunnel Server: L2TP Incoming-Call-Request
   Tunnel Server to NAS: L2TP Incoming-Call-Reply
   NAS to Tunnel Server: L2TP  Incoming-Call-Connected
   Client and Tunnel Server: PPP LCP re-negotiation
   Client and Tunnel Server: PPP authentication
   Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
   RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
   Client and Tunnel Server: NCP negotiation



Aboba & Zorn                 Informational                     [Page 10]

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 NAS. The authentication process
   will then begin and based on the domain portion of the userID, 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 MAY begin to flow through the tunnel.  The client and tunnel
   server MAY now renegotiate LCP and will complete PPP authentication.

   At the time that the renegotiation begins, the NAS SHOULD NOT have
   sent an LCP CONFACK completing LCP negotiation, and the client and
   NAS MUST NOT have begun NCP 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.  In single authentication
   compulsory tunneling, L2TP authentication forwarding MUST NOT be
   employed.  When LCP re-negotiation has been concluded, the NCP phase
   will begin, and the tunnel server will assign an address to the
   client.

   In performing the PPP authentication, the tunnel server can access
   its own user database, or it MAY send a RADIUS Access-Request. After
   the tunnel has been brought up, the NAS and tunnel server can start
   accounting.



























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


   The interactions are summarized below.

                                  INITIATION SEQUENCE

   NAS                            Tunnel Server       RADIUS Server
   ---                            -------------       -------------
   Call accepted
   LCP starts
   Authentication
    phase starts
   IF no control
    connection exists
    Send
    Start-Control-Connection-Request
    to Tunnel Server
   ENDIF
                                IF no control
                                 connection exists
                                 Send
                                 Start-Control-Connection-Reply
                                 to NAS
                                ENDIF

   Send