rfc2809.txt

很多RFC的中文文档

   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:
   单一NAS认证最典型的应用是结合LCP转发和隧道认证，这两种在L2TP中都支持，
   在〔2〕中有描述。因此，隧道服务器可以被设置为接受任何发生在认证通过的
   隧道中的的呼叫，而并不需要进行PPP 认证。但是，这种方式并不能兼容漫游，
   因为隧道服务器只能典型的被设置为接受来自有限数量的NAS设备的隧道。一个
   典型的初始化序列如下：
   

   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
   用户客户端 和 NAS：呼叫连接
   用户客户端 和 NAS：PPP LCP 协商
   NAS 到 RADIUS服务器：RADIUS 认证请求
   RADIUS服务器 到 NAS：RADIUS 认证接受/认证拒绝
   NAS 到 隧道服务器：L2TP Incoming-Call-Request w/LCP forwarding
   隧道服务器 到 NAS：L2TP Incoming-Call-Reply
   NAS 到 隧道服务器：L2TP Incoming-Call-Connected
   用户客户端 和 隧道服务器：NCP 协商







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.
   此过程开始于到NAS的接入呼叫和用户客户端和NAS间的PPP LCP协商。为了认证
   用户端，NAS将发送RADIUS认证请求到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 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.
   在L2TP隧道被指明的情况下，如果此隧道不存在，NAS将在此时建立一条控制
   连接，NAS和隧道服务器将建立起这次呼叫。到此时，数据将开始在隧道上传送。
   虽然隧道服务器重新进行LCP协商也是可能的，但典型的NAS将使用LCP转发。
   如果LCP重新协商被允许，NAS不能（SHOULD NOT）发送LCP CONFACK，相反NAS
   将发送一个LCP 配置请求（Configure-Request）包，在〔6〕中有描述。用户
   客户端可能（MAY）进行LCP重新协商，从此时起，所有的从用户客户端发出的
   PPP包将被封装发送到隧道服务器。

   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.
   因为地址分配将发生在隧道服务器那端，用户客户端和NAS不应该（MUST NOT）
   启动NCP协商。相反，NCP协商将在用户客户端和隧道服务器间发生。

4.1.2.  NAS authentication with RADIUS reply forwarding
        RADIUS回应转发的NAS认证

   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.
   在这种方式下，认证和授权将在NAS发生一次，RADIUS回应被转发到隧道服务器。
   这种方式不允许未授权的用户访问网络；不需要NAS和隧道服务器间的相互信任；
   允许计费同时在两端进行。但是，它需要两端共享相同的和RADIUS 服务器间
   的共享密钥，因为这是隧道服务器能检查RADIUS认证回应的唯一方法。

   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.
   在此方式下，隧道服务器将同所有的NAS设备共享和RADIUS服务器通信的共享密钥，
   而且隧道服务器将不能提供LCP重新协商。另外，隧道服务器将需要知道如何去
   处理和验证认证接受消息。

   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.
   如果回应直接来自一个RADIUS服务器的话这种方案是可行的。但如果RADIUS代理
   被涉及，那将变得不可管理，因为此回应将被使用客户端和代理间的共享密钥进
   行验证，而不是RADIUS服务器的密钥。导致的结果是此方案是不实际的。







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:
   在这个方案中，认证和授权在隧道服务器端发生一次。这需要NAS判定需要被隧道定向的
   用户（通过RADIUS或NAS 配置）。如果RADIUS被使用，此判定可使用下面的一种方法：

   Telephone-number based authentication
   UserID
   基于电话号码的认证
   用户ID（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.
   使用主叫号码（Calling-Station-Id）和被叫号码（Called-Station-Id）RADIUS
   属性，授权和随后的隧道属性可以基于以发起呼叫的电话号或被叫的号码。这允许
   RADIUS服务器能够基于用户的呼叫电话号码来授权用户，或者根据主叫号码或被叫
   号码来提供隧道属性。相似的，在L2TP中，隧道服务器可能（MAY）选择拒绝或接受
   包含在NAS 发送的L2TP Incoming-Call-Request 包中的被拨叫号码和主拨叫号码。
   计费也可基于主叫号码和被叫号码进行。

   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.
   在〔1〕中定义的RADIUS需要在认证请求中包含一条用户名（User-Name）属性和CHAP密码
   （CHAP-Password）或用户密码（User-Password）之一，而且必须为非空。为了满足这样
   的要求，主叫号码或被叫号码可能（MAY）被置放在用户名属性，并且虚假值可能（MAY）
   被用在用户密码（User-Password）或CHAP密码属性中。

   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
   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
   用户客户端 和 NAS：呼叫连接
   NAS 到 RADIUS服务器：RADIUS认证请求
   RADIUS服务器 到 NAS：RADIUS认证接受/认证拒绝
   NAS 到 隧道服务器：L2TP  Incoming-Call-Request
   隧道服务器 到 NAS：L2TP  Incoming-Call-Reply
   NAS 到 隧道服务器：L2TP  Incoming-Call-Connected
   用户客户端 和 隧道服务器：PPP LCP 协商
   用户客户端 和 隧道服务器：PPP认证
   隧道服务器 到 RADIUS服务器：RADIUS认证请求（可选）
   RADIUS服务器 到 隧道服务器：RADIUS认证接受/认证拒绝
   用户客户端 和 隧道服务器：NCP 协商






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.
   此流程从到NAS的接入呼叫开始。如果被配置为基于电话号码的认证，NAS发送
   包含主叫号码和被叫号码的认证请求，然后RADIUS服务器间回应认证接受或认
   证拒绝。   

   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.
   NAS不应该（MUST NOT）在建立隧道前开始PPP认证。如果相互配合的时间允许，
   NAS可以（MAY）在和对端开始LCP协商之前建立隧道。如果这些完成，然后LCP
   将不需要在对端和隧道服务器间被重新协商，LCP转发也不必进行。

   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.
   如果基于电话号码的初始化认证不成功，RADIUS服务器将回应一个RADIUS认证拒绝。
   在这种情况下，NAS必须（MUST）发送一个LCP终结（LCP-Terminate）并切断用户。

   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.
   在隧道属性被包括在RADIUS认证接受回应中，并且一个L2TP隧道被指明的情况下，
   如果以前没有连接存在的话，NAS将在此时建立一条控制连接。这是通过发送一个
   L2TP Start-Control-Connection-Request消息到隧道服务器来完成。如果这个
   消息指示出错，或者这控制连接在不久后就要被终结，NAS必须（MUST）发送
   一个LCP终结（LCP-Terminate）并切断用户。

   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.
   接着NAS将发送一个L2TP Incoming-Call-Request消息到隧道服务器。在其他事件中，
   这个消息将包含呼叫序列号，它和NAS地址属性（NAS-IP-Address）和隧道服
   务器终结点属性（Tunnel-Server-Endpoint）一起被用来唯一的确定一次呼叫。
   隧道服务器将回应一个L2TP Incoming-Call-Reply 消息。如果这个消息指示出错，
   NAS必须（MUST）发送一个LCP终结（LCP-Terminate）并切断用户。如果没有错误被
   指明，NAS将回应一个L2TP Incoming-Call-Connected消息。

   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.
   到了此时，数据可以开始通过隧道传输。如果NAS和用户客户端之间已经开始LCP协商，
   LCP转发将会被使用，或者用户客户端和隧道服务器间将会在此时进行LCP重新协商，
   并开始进行PPP认证。否则，用户客户端和隧道服务器将进行第一次LCP协商，然后
   继续进行到PPP认证。