rfc2809.txt

很多RFC的中文文档

   data MAY begin to flow through the tunnel.  The client and tunnel
   server MAY now renegotiate LCP and will complete PPP authentication.
   此过程开始于到NAS的呼叫和用户客户端和NAS间的PPP LCP协商。然后认证过程
   将开始并基于用户ID（userID）的域部分，此时如果还没有建立控制连接，NAS
   将建立，接着NAS和隧道服务器将建立此次呼叫。到此时，数据可以（MAY）通过
   隧道传递。现在用户客户端和隧道服务器间可能（MAY）重新协商LCP并完成PPP
   认证。

   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.
   在重新协商开始的时候，NAS不能（SHOULD NOT）已经发送了LCP CONFACK来完成
   LCP协商，并且用户客户端和NAS间不应该（MUST NOT）已经开始NCP协商。与发送
   一个LCP CNFACK相反，NAS将发送一个LCP配置请求（LCP Configure-Request）包，
   在〔6〕中描述。然后用户客户端可以（MAY）重新协商LCP，自此以后，所有的源于
   用户客户端PPP包将被封装并发送到隧道服务器。在单一认证的强制隧道连接中，
   L2TP认证转发不应该（MUST NOT）被使用。当LCP重新协商已经被终结，NCP协商
   阶段将开始，隧道服务器将给用户客户端分配地址。

   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.
   在进行PPP认证的时，隧道服务器可以访问自己的用户数据库，或者可以发送RADIUS
   认证请求。在隧道被建立后，NAS和隧道服务器可以开始计费。



























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
   呼叫接受
   LCP 协商开始
   认证阶段开始
   如果 没有控制连接存在
        发送Start-Control-Connection-Request
        到隧道服务器
   结束
                                IF no control
                                 connection exists
                                 Send
                                 Start-Control-Connection-Reply
                                 to NAS
                                ENDIF
                                如果 没有控制连接存在
                                发送 Start-Control-Connection-Reply
                                到NAS
                                结束

   Send
   Incoming-Call-Request
   message to Tunnel Server
   发送 Incoming-Call-Request
   消息到隧道服务器
                                Send Incoming-Call-Reply
                                to NAS
                                发送 Incoming-Call-Reply
                                到 NAS
   Send
   Incoming-Call-Connected
   message to Tunnel Server
   发送 Incoming-Call-Connected
   消息到隧道服务器

   Send data through the tunnel
   通过隧道传送数据
                                Re-negotiate LCP,
                                authenticate user,
                                bring up IPCP,
                                start accounting
                                重新协商LCP
                                认证用户
                                建立 IPCP
                                开始计费

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.
   在此方案中，认证在NAS端和隧道服务器端都发送。这需要拨号用户客户端使用
   辅助的LCP重新协商来处理双重认证。为了允许NAS和隧道服务器能在相同的
   数据库认证，需要RADIUS客户端和隧道服务器相兼容，并有可能在NAS端使用
   RADIUS代理。





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.
   双重认证的优点包括：对在两端认证和计费的支持；通过在隧道网络服务器的RADIUS实现，
   使用单一的用户ID/用户密码对；不需要基于电话号码的认证或在RADIUS服务器的
   属性说明处理。

   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.
   双重认证允许NAS和隧道服务器两端的计费记录的确保，使审计对帐成为可能。
   并且隧道终结点不需要和NAS所有者有账号上的关系，使此方式兼容了漫游。

   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].
   双重认证的一个缺点是除非LCP转发被使用，LCP将需要重新协商；一些用户客户
   端完全不支持，另外一些仅仅支持双重认证集合的一个子集。可行的集合包括
   PAP/PAP（token），PAP/CHAP，PAP/EAP，CHAP/PAP（token），CHAP/CHAP，
   CHAP/EAP，EAP/CHAP，和EAP/EAP。EAP在〔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
   用户客户端和NAS：PPP LCP协商
   用户客户端和NAS：PPP认证
   NAS 到 RADIUS服务器：RADIUS 认证请求
   RADIUS服务器 到 NAS：RADIUS认证接受/拒绝
   NAS 到 隧道服务器：L2TP Incoming-Call-Request
   隧道服务器 到 NAS：L2TP Incoming-Call-Reply
   NAS 到 隧道服务器：L2TP  Incoming-Call-Connected
   用户客户端和隧道服务器：PPP LCP 重新协商（optional）
   用户客户端和隧道服务器：PPP 认证
   隧道服务器 到 RADIUS服务器：RADIUS 认证请求
   RADIUS服务器 到 隧道服务器：RADIUS认证接受/拒绝
   用户客户端和隧道服务器：NCP协商

   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.
   此过程开始于到NAS的呼叫。然后用户客户端和NAS开始LCP协商。接着PPP认证
   阶段开始，并且NAS发送RADIUS认证请求消息到RADIUS服务器。如果认证成功，
   认证服务器回应包含隧道属性的认证接受。

   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.
   在L2TP隧道被指明的情况下，如果控制连接不存在，NAS将在现在建立。到此时，
   数据可以（MAY）开始通过隧道传送。用户客户端和隧道服务器可以（MAY）现在
   重新协商LCP并进而进入下一轮的认证。在这重新协商开始的时候，NAS不能
   （SHOULD NOT）已经发送了一个LCP CONFACK 来结束LCP协商，并且NAS不应该
   （MUST NOT）已经开始NCP协商。于发送一个LCPCONFACK相反，NAS将发送一个
   LCP 配置请求（LCP Configure-Request）包，在〔6〕描述。然后用户客户端
   可以〔MAY〕重新协商LCP，从此时起，所有的源于用户客户端的PPP包将被封装
   并发送到隧道服务器。当LCP重新协商终结，NCP协商阶段将开始，隧道服务器
   将给用户客户端分配地址。
   

   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.
   如果L2TP被用作为隧道协议，NAS可以在初始化建立通知中包含一份发向各方向的
   LCP CONFACK拷贝，此LCP CONFACK是用来完成LCP协商的。然后隧道服务器可以
   （MAY）使用这些信息来避免LCP重新协商。对于L2TP，初始化建立通知还能包含
   必要的认证信息，这些信息允许隧道服务器来认证用户并觉得是接受或拒绝连接。
   但是，这中便利会导致回应攻击的弱点，并在NAS和隧道服务器使用不同的RADIUS
   服务器的情况下导致问题。其结果，当通过RADIUS基于用户的隧道连接被应用的
   话，L2TP认证转发不能（SHOULD NOT）被使用。

   In performing the PPP authentication, the tunnel server can access