通过RADIUS的L2TP强制遂道的实现RFC2809Word文档格式.docx

1、Copyright （C） The Internet Society （2000）. All Rights Reserved.摘要本文档讨论在使用L2TP协议的拨号网络中，出现在提供强制隧道时的实现问题。可以通过RADIUS和隧道协议综合来完成（强制隧道的）提供。关于其他隧道协议的实现问题留到单独的文档（讨论）。目录1术语 32约定语 33引言 33.1基于RADIUS的强制隧道的优点 44两种认证选择 44.1单一认证 44.1.1NAS认证 44.1.2有RADIUS应答转发的NAS认证 54.1.2.1隧道服务器认证 54.1.2.2基于电话号码认证 64.1.2.3. 用户名 84.2

2、. 双重认证 105. 终止序列 126. 使用不同的RADIUS服务器 136.1. 不同的用户ID 136.2. 多链路PPP问题 147. 用户ID问题 148. 参考资料 149. 安全考虑 1510. 致谢 1511. 主席地址 1512. 作者地址 1613. 知识产权声明 1614. 完全版权声明 171术语自发隧道 自发隧道中，隧道是由用户来创建，典型的是通过一个隧道客户端的应用。 强制隧道 强制隧道中，隧道的建立没有用户的任何作用而且也不允许用户作任何选择。 隧道网络服务器是一个用来终止一条隧道的服务器。在L2TP术语中，即为所知的L2TP网络服务器（LNS）。 网络接入服务

3、器网络接入服务器（NAS）是客户端为了接入网络而连接的设备。在L2TP术语中，一个执行强制隧道的NAS相当于作为L2TP接入集中器（LAC）。 RADIUS认证服务器 这是一个通过在（附录）1中所描述的协议来提供认证/授权的服务器。 RADIUS代理 为了向RADIUS路由提供认证请求，可以使用一个RADIUS代理。对于NAS，RADIUS代理看上去是作为一个RADIUS服务器，而对于RADIUS服务器，代理看上去是作为一个RADIUS客户端。当使用基于领域的隧道时，可以用来定位隧道终点。2约定语 本文档中，关键字“可以（MAY）”、“必须（MUST）”、“不允许（MUST NOT）”、“可选

4、（optional）”、“推荐（recommended）”、“应该（SHOULD）”和“不应该（SHOULD NOT）”按照参考文献4中的描述解释。3引言 隧道协议的大多应用包括拨号网络接入。有些，例如通过Internet提供到公司intranet（企业内部互联网）的可靠接入，具有主动隧道的特征：隧道是为某一特定目的在用户请求下建立。其他的应用包括强制隧道：隧道在没有来自于用户的任何作用而且不允许用户作任何选择的情况下建立。可以利用强制隧道实现的应用实例是Internet软件升级服务器、软件注册服务器和银行系统服务。所有这些没有强制隧道的服务，都将可能利用专用网络或者至少是专用网络接入服务器（

5、NAS）来提供，因为他们具有需要限制用户接入到特定主机的特性。给定普遍支持强制隧道的实体，仍然可以通过任何因特网服务提供商（ISP）访问这些类型的服务。现今认证拨号网络用户的最流行的方式是通过RADIUS协议。RADIUS的作用是允许在一个中心位置维持拨号用户的授权和认证数据，而不是在每个NAS上。它对于使用RADIUS来集中管理强制隧道很有意义，因为RADIUS被广泛的配置和设计来传送这种类型的信息。需要新的RADIUS属性来传送从RADIUS服务器到NAS的隧道信息。那些属性在文献3中定义。3.1基于RADIUS的强制隧道的优点 当前对隧道请求的路由的建议包括静态隧道，其中所有用户被自动隧

6、道接入到一个给定的终点，和基于领域的隧道，其中隧道终点从用户ID中的领域部分来决定。基于用户的隧道因为由RADIUS和隧道协议综合提供，具有这两种方法的重要优点。 为静态隧道这一目的需要专用一个NAS设备。ISP方面，这是不受欢迎的，因为它需要他们专用一个NAS来为一个特定客户提供隧道服务，而不是让他们应用在这个域中配置的已有的NAS。结果用静态隧道来开展全球服务可能是非常昂贵的。 基于领域的隧道假设在一个特定领域内的所有用户希望被以相同的方式对待。这限制了帐号管理中的适应性。例如，BIGCO可能希望给Janet提供一个帐号，允许他访问Internet和intranet两种服务，Janet的i

7、ntranet接入由位于工程部的一个隧道服务器提供。然而BIGCO可能希望给Fred提供一个只能接入到intranet的帐号，Fred的intranet接入由位于销售部的一个隧道服务器提供。这种情形不能使用基于领域的隧道，但可以通过被在文献3中定义的属性激活的基于用户的隧道来提供。4两种认证选择基于RADIUS的强制隧道能支持两种认证，即，单一认证，用户在NAS和隧道服务器被认证，或双重认证，用户在NAS和隧道服务器两处都被认证。当支持单一认证时，可能有多种模式，其中包括基于电话号码认证。当使用双重认证时，也有许多模式可用，包括双重CHAP认证；CHAP/EAP认证；CHAP/PAP（toke

8、n）认证；和EAP/EAP认证，对两个认证使用相同的EAP类型。EAP在资料5中描述。下面对这两种选择作更详细的介绍。4.1单一认证 单一认证可供选择的方法包括： NAS认证 有RADIUS应答转发的NAS认证 隧道服务器认证 4.1.1NAS认证 用这种方法，认证和授权（包括隧道信息）在NAS上只发生一次。这个方法的优点是它禁止XX的的NAS用户接入网络，以及允许在NAS上记帐。缺点是它需要隧道服务器信任NAS，因为没有在隧道服务器上没有用户认证。由于缺少用户认证，不能在隧道服务器上进行需要严格保证准确用户结算的记帐。 单独NAS认证最典型的是与LCP转发和隧道认证一起使用，后面的二者都在L

9、2TP中被支持，在资料2中描述。这样，隧道服务器可以设置为接受所有发生在已认证隧道中的呼叫，不需要PPP认证。然而这个方法不支持漫游，因为隧道服务器典型的设置为只接受从限定的NAS来的隧道。典型的初始序列看上去是这样：客户端和NAS：呼叫连接PPP LCP协商PPP认证NAS到RADIUS服务器：RADIUS Access-requestRADIUS服务器到NAS：RADIUS Access-Accept/Access-RejectNAS到隧道服务器：L2TP Incoming-Call-Request w/LCP forwarding（转发）隧道服务器到NAS：L2TP Incoming-C

10、all-ReplyL2TP Incoming-Call-Connected客户端和隧道服务器：NCP协商该过程以一个到NAS的进入呼叫开始，接下来是客户端和NAS之间的PPP LCP协商。为了认证客户端，NAS会发送一个RADIUS Access-Request给RADIUS服务器并收到一个包含隧道属性的RADIUS Access-Accept或是一个Access-Reject。在指定了一条L2TP隧道的情况下，如果之前不存在，NAS将提出一个控制连接，并且NAS和隧道服务器将建立呼叫。至此，数据将开始流过这条隧道。NAS将典型的使用LCP转发，虽然对隧道服务器来说，重新协商LCP也是可能的。

11、如果LCP允许重协商，NAS不应发送一个LCP CONFACK完成LCP协商。代替发送LCP CONFACK，NAS将变成发送一个LCP Configure-Request包，在资料6中描述。然后客户端可能重协商LCP，并且从这点向前，所有从客户端发起的PPP包将被封装并发送到隧道服务器。 由于地址分配将发生在隧道服务器上，客户端和NAS不许开始NCP协商。变为NCP协商将发生在客户端和隧道服务器之间。4.1.2有RADIUS应答转发的NAS认证这一方法中，认证和授权在NAS发生一次并且RADIUS应答转发给隧道服务器。该方法不接受未授权NAS用户的网络接入；并允许在隧道的两端进行记帐。然而，

12、它也需要两端都与RADIUS服务器共享相同的密钥，因为那是隧道服务器能够检查RADIUS的Access-Reply的唯一方法。这个方法中，隧道服务器将与所有的NAS和相关RADIUS服务器共享密钥，并且隧道服务器没有在这里提供LCP重协商。同样，隧道服务器需要知道如何去处理和验证RADIUS的Access-Accept消息。虽然如果应答直接来自于一个RADIUS服务器，这个方案是可用的，但如果包括一个RADIUS代理，它将变得难以管理，因为应答要用客户端和代理共享的密钥进行认证，而不是RADIUS服务器。结果，这个方案是不切实际的。4.1.2.1隧道服务器认证 这个方案中，认证和授权在隧道服务

13、器发生一次。这要求NAS决定用户需要（怎样）建立隧道（通过RADIUS或是NAS配置）。如果使用了RADIUS，可使用下面方法之一来做决定： 基于电话号码认证 用户ID4.1.2.2基于电话号码认证 使用Calling-Station-Id和Called-station-Id RADIUS属性，授权和并发隧道属性能够以发起呼叫的电话号码或被呼叫号码为依据。这允许RADIUS服务器基于呼叫电话号码来授权用户或是基于Calling-Station-Id或Called-Station-Id来提供隧道属性。同样的，在L2TP中隧道服务器可以基于包含在NAS发送的L2TP Incoming-Call-R

14、equest包中的被拨号码和拨叫号码来选择拒绝或接受这个呼叫。也可以基于Calling-Station-Id和Called-Station-Id来进行记帐。 在资料1中定义的RADIUS要求一个Access-Request包包含一个User-Name属性，也（包含）一个必须为非空的CHAP-Password或User-Password属性。为满足这一要求，Called-Station-Id或Calling-Station-Id可以在User-Name属性中提供，而且一个伪值可以用于User-Password或CHAP-Password属性。 在基于电话号码认证的情况下，一个典型的开始顺序像这样

15、： 客户端和NS： NAS到RADIUS服务器： RADIUS服务器到NAS： NAS到隧道服务器：L2TP Incoming-Call-Request 隧道服务器到NAS： 客户端和隧道服务器： 隧道服务器到RADIUS服务器：RADIUS Access-request（可选） RADIUS服务器到隧道服务器： 该过程以一个到NAS的进入呼叫开始。如果配置为基于电话号码认证，NAS发送一个包含Calling-Station-Id和Called-Station-Id属性的RADIUS Access-Request。然后RADIUS服务器将以一个RADIUS Access-Accept或Acce

16、ss-Reject响应。 在隧道建立起来之前，不允许NAS开始PPP认证。如果时限允许，NAS可以先于同对等实体开始LCP协商建立起隧道。如果这个完成，那么将不需要在对等实体和隧道服务器之间进行LCP重协商，也不需使用LCP转发。 如果基于电话号码的认证初始不成功，RADIUS服务器发送一个RADIUS Access-Reject。这种情况下，NAS必须发送一个LCP-Terminate并断开用户连接。在隧道属性包含在RADIUS Access-Accept 中，并且一条L2TP隧道被指出的情况下，NAS此刻将建立起一条控制连接，如果先前不存在。这通过向隧道服务器发送一个L2TP Start-

17、Control-Connection-Request消息来实现。然后隧道服务器将用一个L2TP Start-Control-Connection-Reply应答。如果该消息指出一条错误（信息），或者该控制连接在将来任意时刻被终止，那么NAS必须发送一个LCP-Terminate并断开用户连接。之后，NAS将发送一个L2TP Incoming-Call-Request消息给隧道服务器。其他情况中，该消息将包含呼叫序列号，该号与NAS-IP-Address和Tunnel-Server-Endpoint一起用来唯一地确定这个呼叫。隧道服务器将用一个L2TP Incoming-Call-Reply消息

18、应答。如果该消息指出一条错误，那么NAS必须发送一条LCP-Terminate并断开用户连接。如果没有指出错误，那么NAS就用一条L2TP Incoming-Call-Connected消息应答。至此，数据可以开始通过隧道流通。如果NAS和客户端之间的LCP协商已经开始，然后就可以使用LCP转发，或者客户端和隧道服务器将现在重协商LCP并开始PPP认证。否则，客户端和隧道服务器将第一次协商LCP并且之后转移到PPP认证阶段。如果需要重协商，在重协商开始的时候，NAS不应该已经发送LCP CONFACK结束掉LCP协商，而且不允许客户端和NAS已经开始NCP协商。胜于发送一条LCP CONFAC

19、K，NAS将代之于发送一个LCP Configure-Request包，在资料6中描述。之后客户端可以重协商LCP，并且从这一点之后，所有从客户端发出的PPP包将被封装并发送到隧道服务器。当LCP重协商已经结束， NCP阶段就将开始，并且隧道服务器将给客户端分配一个地址。如果L2TP正在被用作隧道协议，且LCP重协商是必需的，NAS可以在它的初始设置通知（initial setup notification）中包括一份在每一方向发送来结束LCP协商的LCP CONFACK的拷贝。之后隧道服务器可以用这条信息来避开一个附加的LCP协商。用L2TP，初始设置通知也可以包括认证信息，请求允许隧道服务

20、器来认证用户以及决定接受或拒绝连接。然而，基于电话号码的认证中，PPP认证禁止在NAS建立隧道之前出现。其结果是禁止设置L2TP认证转发。PPP认证执行过程中，隧道服务器能够访问它自己的用户数据库，或是作为选择，能够发送一个RADIUS Access-Request请求。后面的方法在允许认证转发，比如有漫游或者共享使用网络的情况下很有用。在这种情况下，RADIUS和隧道服务器在统一的管理之下而且典型的被紧密放置在一起，可能在同一个LAN上。因此让隧道服务器担当RADIUS客户端提供了统一的用户管理。注意隧道服务器的RADIUS Access-Request典型地直接发送到本地RADIUS服务器

21、而不是通过一个代理来转发。下面概述这种包含在基于电话号码认证的强制隧道的初始化中的交互。为了简化下面的图表，我们省去了客户端。但是，应知道客户端通过PPP协商参与同隧道服务器的认证和并发数据交换。初始化顺序 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 NA

22、K DISCONNECT ELSE IF no control connection exists Send Start-Control-Connection-Request to Tunnel Server Start-Control-Connection-Reply to NAS ENDIF Incoming-Call-Request message to Tunnel Server Send Incoming-Call-Reply Incoming-Call-Connected Send data through the tunnel Re-negotiate LCP, authenti

23、cate user, bring up IPCP, start accounting4.1.2.3. 用户名因为认证只发生在隧道服务器，在NAS的隧道初始化必须先于用户认证发生。结果，这一方案代表性地或者使用用户ID的域名部分，或者利用RADIUS服务器上的attribute-specific处理。因为用户身份从未被NAS验证，或者隧道服务器所有者必须乐于负担所有的入呼叫，或者为记帐目的，必须用诸如Calling-Station-Id的其他信息验证用户身份。在attribute-specific处理中，可能使用RADIUS并且用一个属性发信号通知隧道初始化。例如，隧道属性可能被送回，如果Use

24、r-Password属性包含一个伪值（比如“tunnel”或“L2TP”）。可选的，以一个特殊字符（*）开始的用户ID可用来指出发起一条隧道的要求。当使用了attribute-specific处理，隧道服务器可能需要重协商LCP。另外的解决方案包括使用用户ID的域名部分；在域X中的所有用户将通过隧道连到地址Y。这个建议支持强制建立隧道，但不提供基于用户建立隧道。为了让NAS对连接开始记帐，将需要利用在到隧道服务器的认证过程中用户所声称的身份，因为它没有通过RADIUS来验证身份。但是，为使之在记帐中有用，隧道终点需要有一个与NAS属主相关联的帐号。这样即使用户拥有一个具有NAS属主的帐号，他们

25、也不能利用这个帐号建立隧道，除非隧道终点还与NAS属主有一种商业关联。这样该方法与漫游是相矛盾的。一个典型的包括利用用户ID域名部分的初始化顺序是这样的： 客户端和NAS：认证PPP LCP重协商RADIUS Access-request （可选）此过程以一个到NAS的入呼叫开始，紧接着是客户端和NAS之间的PPP LCP协商。然后认证过程开始，且是基于用户ID的域名部分，如果先前没有，这时NAS将建立一条控制连接，并且NAS和隧道服务器将建立呼叫。至此，数据可以开始通过隧道传输。客户端和隧道服务器现在可以进行LCP重协商并将完成PPP认证。在重协商开始时，NAS不应该已经发送LCP CONF

26、ACK完成LCP协商，而且客户端和NAS不允许已开始NCP协商。胜于发送LCP CONFACK，该NAS将改为发送一个LCP Configure-Request包，详见资料6。然后客户端可以重协商LCP，并且从此刻开始，所有从客户端发起的PPP包将被封装并发送到隧道服务器。在单一认证的强制隧道中，不允许设置L2TP认证转发。当LCP重协商结束时，NCP阶段就会开始，而且隧道服务器将给客户端分配一个地址。在PPP认证执行过程中，隧道服务器能够访问它自己的用户数据库，或者是它可以发送一个RADIUS Access-Request。隧道建立起来之后，NAS和隧道服务器能够开始记帐。 此交互概括如下。 初始序列 Call accepted LCP starts Authentication phase starts4.2. 双重认证此方案中，在NAS和隧道服务器两端都进行认证。这需要拨号客户端处理双重认证，伴随LCP重协商。为了让NAS和隧道服务器依据相同的数据库进行认证，要求隧道网络服务器上有RADIUS客户