rfc2809.txt

RFC 的详细文档！

   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

4.2.  Dual authentication

   In this scheme, authentication occurs both at the NAS and the tunnel
   server. This requires the dial-up client to handle dual
   authentication, with attendant LCP re-negotiations. In order to allow
   the NAS and tunnel network server to authenticate against the same
   database, this requires RADIUS client capability on the tunnel
   network server, and possibly a RADIUS proxy on the NAS end.





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


   Advantages of dual authentication include support for authentication
   and accounting at both ends of the tunnel; use of a single
   userID/password pair via implementation of RADIUS on the tunnel
   network server; no requirement for telephone-number based
   authentication, or attribute-specific processing on the RADIUS
   server.

   Dual authentication allows for accounting records to be generated on
   both the NAS and tunnel server ends, making auditing possible. Also
   the tunnel endpoint does not need to have an account relationship
   with the NAS owner, making this approach compatible with roaming.

   A disadvantage of dual authentication is that unless LCP forwarding
   is used, LCP will need to be renegotiated; some clients do not
   support it at all, and others only support only a subset of the dual
   authentication combinations. Feasible combinations include
   PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP,
   CHAP/EAP, EAP/CHAP, and EAP/EAP.  EAP is described in [5].

   In the case of a dual authentication, a typical initiation sequence
   looks like this:

   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
   Tunnel Server to NAS: L2TP Incoming-Call-Reply
   NAS to Tunnel Server: L2TP  Incoming-Call-Connected
   Client and Tunnel Server: PPP LCP re-negotiation (optional)
   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

   The process begins with an incoming call to the NAS. The client and
   NAS then begin LCP negotiation. Subsequently the PPP authentication
   phase starts, and the NAS sends a RADIUS Access-Request message to
   the RADIUS server. If the authentication is successful, the RADIUS
   server responds with a RADIUS Access-Accept containing tunnel
   attributes.

   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 MAY begin
   to flow through the tunnel. The client and tunnel server MAY now
   renegotiate LCP and go through another round of PPP authentication.
   At the time that this renegotiation begins, the NAS SHOULD NOT have



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


   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.  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, 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, this facility creates a vulnerability to replay attacks, and
   can create problems in the case where the NAS and tunnel server
   authenticate against different RADIUS servers. As a result, where
   user-based tunneling via RADIUS is implemented, L2TP authentication
   forwarding SHOULD NOT be employed.

   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.

   The interactions involved in initiation of a compulsory tunnel with
   dual authentication are summarized below.






















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


                                  INITIATION SEQUENCE

   NAS                            Tunnel Server       RADIUS Server
   ---                            -------------       -------------
   Call accepted
   LCP starts
   PPP authentication
    phase starts
   Send RADIUS
    Access-Request
    with userID and
    authentication data
                                                      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
   ENDIF








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


5.  Termination sequence

   The tear down of a compulsory tunnel involves an interaction between
   the client, NAS and Tunnel Server. This interaction is virtually
   identical regardless of whether telephone-number based
   authentication, single authentication, or dual authentication is
   being used.  In any of the cases, the following events occur:

        Tunnel Server to NAS: L2TP Call-Clear-Request (optional)
        NAS to Tunnel Server: L2TP Call-Disconnect-Notify

   Tunnel termination can occur due to a client request (PPP
   termination), a tunnel server request (Call-Clear-Request), or a line
   problem (call disconnect).

   In the case of a client-requested termination, the tunnel server MUST
   terminate the PPP session. The tunnel server MUST subsequently send a
   Call-Clear-Request to the NAS. The NAS MUST then send a Call-
   Disconnect-Notify message to the tunnel server, and will disconnect
   the call.

   The NAS MUST also respond with a Call-Disconnect-Notify message and
   disconnection if it receives a Call-Clear-Request from the tunnel
   server without a client-requested termination.

   In the case of a line problem or user hangup, the NAS MUST send a
   Call-Disconnect-Notify to the tunnel server. Both sides will then
   tear down the call.

   The interactions involved in termination of a compulsory tunnel are
   summarized below. In order to simplify the diagram that follows, we
   have left out the client. However, it is understood that the client
   MAY participate via PPP termination and disconnection.


















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


                                  TERMINATION SEQUENCE

   NAS                            Tunnel Server         RADIUS Server
   ---                            -------------         -------------
   IF user disconnected
    send
    Call-Disconnect-Notify
    message to tunnel server
                                  Tear down the call
                                  stop accounting
   ELSE IF client requests
    termination
                                  send
                                  Call-Clear-Request
                                  to the NAS
    Send
    Call-Disconnect-Notify
    message to tunnel server
    Disconnect the user
                                  Tear down the call
                                  stop accounting
   ENDIF

6.  Use of distinct RADIUS servers

   In the case that the NAS and the tunnel server are using distinct
   RADIUS servers, some interesting cases can arise in the provisioning
   of compulsory tunnels.

6.1.  Distinct userIDs

   If distinct RADIUS servers are being used, it is likely that distinct
   userID/password pairs will be required to complete the RADIUS and
   tunnel authentications. One pair will be used in the initial PPP
   authentication with the NAS, and the second pair will be used for
   authentication at the tunnel server.

   This has implications if the NAS attempts to forward authentication
   information to the tunnel server in the initial setup notification.
   Since the userID/password pair used for tunnel authentication is
   different from that used to authenticate against the NAS, forwarding
   authentication information in this manner will cause the tunnel
   authentication to fail. As a result, where user-based tunneling via
   RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be
   employed.






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


   In order to provide maximum ease of use in the case where the
   userID/password pairs are identical, tunnel clients typically attempt
   authentication with the same userID/password pair as was used in the
   initial PPP negotiation. Only after this fails do they prompt the
   user for the second pair. Rather than putting up an error message
   indicating an authentication failure, it is preferable to present a
   dialog requesting the tunnel userID/password combination.

   A similar issue arises when extended authentication methods are being
   used, as is enabled by EAP, described in [5]. In particular, when
   one-time passwords or cryptographic calculators are being used,