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

上传人:b****5 文档编号:16892168 上传时间:2022-11-26 格式:DOCX 页数:20 大小:29.10KB
下载 相关 举报
通过RADIUS的L2TP强制遂道的实现RFC2809Word文档格式.docx_第1页
第1页 / 共20页
通过RADIUS的L2TP强制遂道的实现RFC2809Word文档格式.docx_第2页
第2页 / 共20页
通过RADIUS的L2TP强制遂道的实现RFC2809Word文档格式.docx_第3页
第3页 / 共20页
通过RADIUS的L2TP强制遂道的实现RFC2809Word文档格式.docx_第4页
第4页 / 共20页
通过RADIUS的L2TP强制遂道的实现RFC2809Word文档格式.docx_第5页
第5页 / 共20页
点击查看更多>>
下载资源
资源描述

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

《通过RADIUS的L2TP强制遂道的实现RFC2809Word文档格式.docx》由会员分享,可在线阅读,更多相关《通过RADIUS的L2TP强制遂道的实现RFC2809Word文档格式.docx(20页珍藏版)》请在冰豆网上搜索。

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

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要

本文档讨论在使用L2TP协议的拨号网络中,出现在提供强制隧道时的实现问题。

可以通过RADIUS和隧道协议综合来完成(强制隧道的)提供。

关于其他隧道协议的实现问题留到单独的文档(讨论)。

目录

1.术语3

2.约定语3

3.引言3

3.1.基于RADIUS的强制隧道的优点4

4.两种认证选择4

4.1.单一认证4

4.1.1.NAS认证4

4.1.2.有RADIUS应答转发的NAS认证5

4.1.2.1.隧道服务器认证5

4.1.2.2.基于电话号码认证6

4.1.2.3.用户名8

4.2.双重认证10

5.终止序列12

6.使用不同的RADIUS服务器13

6.1.不同的用户ID13

6.2.多链路PPP问题14

7.用户ID问题14

8.参考资料14

9.安全考虑15

10.致谢15

11.主席地址15

12.作者地址16

13.知识产权声明16

14.完全版权声明17

1.术语

自发隧道

自发隧道中,隧道是由用户来创建,典型的是通过一个隧道客户端的应用。

强制隧道

强制隧道中,隧道的建立没有用户的任何作用而且也不允许用户作任何选择。

隧道网络服务器

是一个用来终止一条隧道的服务器。

在L2TP术语中,即为所知的L2TP网络服务器(LNS)。

网络接入服务器

网络接入服务器(NAS)是客户端为了接入网络而连接的设备。

在L2TP术语中,一个执行强制隧道的NAS相当于作为L2TP接入集中器(LAC)。

RADIUS认证服务器

这是一个通过在(附录)[1]中所描述的协议来提供认证/授权的服务器。

RADIUS代理

为了向RADIUS路由提供认证请求,可以使用一个RADIUS代理。

对于NAS,RADIUS代理看上去是作为一个RADIUS服务器,而对于RADIUS服务器,代理看上去是作为一个RADIUS客户端。

当使用基于领域的隧道时,可以用来定位隧道终点。

2.约定语

本文档中,关键字“可以(MAY)”、“必须(MUST)”、“不允许(MUSTNOT)”、“可选(optional)”、“推荐(recommended)”、“应该(SHOULD)”和“不应该(SHOULDNOT)”按照参考文献[4]中的描述解释。

3.引言

隧道协议的大多应用包括拨号网络接入。

有些,例如通过Internet提供到公司intranet(企业内部互联网)的可靠接入,具有主动隧道的特征:

隧道是为某一特定目的在用户请求下建立。

其他的应用包括强制隧道:

隧道在没有来自于用户的任何作用而且不允许用户作任何选择的情况下建立。

可以利用强制隧道实现的应用实例是Internet软件升级服务器、软件注册服务器和银行系统服务。

所有这些没有强制隧道的服务,都将可能利用专用网络或者至少是专用网络接入服务器(NAS)来提供,因为他们具有需要限制用户接入到特定主机的特性。

给定普遍支持强制隧道的实体,仍然可以通过任何因特网服务提供商(ISP)访问这些类型的服务。

现今认证拨号网络用户的最流行的方式是通过RADIUS协议。

RADIUS的作用是允许在一个中心位置维持拨号用户的授权和认证数据,而不是在每个NAS上。

它对于使用RADIUS来集中管理强制隧道很有意义,因为RADIUS被广泛的配置和设计来传送这种类型的信息。

需要新的RADIUS属性来传送从RADIUS服务器到NAS的隧道信息。

那些属性在文献[3]中定义。

3.1.基于RADIUS的强制隧道的优点

当前对隧道请求的路由的建议包括静态隧道,其中所有用户被自动隧道接入到一个给定的终点,和基于领域的隧道,其中隧道终点从用户ID中的领域部分来决定。

基于用户的隧道因为由RADIUS和隧道协议综合提供,具有这两种方法的重要优点。

为静态隧道这一目的需要专用一个NAS设备。

ISP方面,这是不受欢迎的,因为它需要他们专用一个NAS来为一个特定客户提供隧道服务,而不是让他们应用在这个域中配置的已有的NAS。

结果用静态隧道来开展全球服务可能是非常昂贵的。

基于领域的隧道假设在一个特定领域内的所有用户希望被以相同的方式对待。

这限制了帐号管理中的适应性。

例如,BIGCO可能希望给Janet提供一个帐号,允许他访问Internet和intranet两种服务,Janet的intranet接入由位于工程部的一个隧道服务器提供。

然而BIGCO可能希望给Fred提供一个只能接入到intranet的帐号,Fred的intranet接入由位于销售部的一个隧道服务器提供。

这种情形不能使用基于领域的隧道,但可以通过被在文献[3]中定义的属性激活的基于用户的隧道来提供。

4.两种认证选择

基于RADIUS的强制隧道能支持两种认证,即,单一认证,用户在NAS和隧道服务器被认证,或双重认证,用户在NAS和隧道服务器两处都被认证。

当支持单一认证时,可能有多种模式,其中包括基于电话号码认证。

当使用双重认证时,也有许多模式可用,包括双重CHAP认证;

CHAP/EAP认证;

CHAP/PAP(token)认证;

和EAP/EAP认证,对两个认证使用相同的EAP类型。

EAP在资料[5]中描述。

下面对这两种选择作更详细的介绍。

4.1.单一认证

单一认证可供选择的方法包括:

NAS认证

有RADIUS应答转发的NAS认证

隧道服务器认证

4.1.1.NAS认证

用这种方法,认证和授权(包括隧道信息)在NAS上只发生一次。

这个方法的优点是它禁止XX的的NAS用户接入网络,以及允许在NAS上记帐。

缺点是它需要隧道服务器信任NAS,因为没有在隧道服务器上没有用户认证。

由于缺少用户认证,不能在隧道服务器上进行需要严格保证准确用户结算的记帐。

单独NAS认证最典型的是与LCP转发和隧道认证一起使用,后面的二者都在L2TP中被支持,在资料[2]中描述。

这样,隧道服务器可以设置为接受所有发生在已认证隧道中的呼叫,不需要PPP认证。

然而这个方法不支持漫游,因为隧道服务器典型的设置为只接受从限定的NAS来的隧道。

典型的初始序列看上去是这样:

客户端和NAS:

呼叫连接

PPPLCP协商

PPP认证

NAS到RADIUS服务器:

RADIUSAccess-request

RADIUS服务器到NAS:

RADIUSAccess-Accept/Access-Reject

NAS到隧道服务器:

L2TPIncoming-Call-Requestw/LCPforwarding(转发)

隧道服务器到NAS:

L2TPIncoming-Call-Reply

L2TPIncoming-Call-Connected

客户端和隧道服务器:

NCP协商

该过程以一个到NAS的进入呼叫开始,接下来是客户端和NAS之间的PPPLCP协商。

为了认证客户端,NAS会发送一个RADIUSAccess-Request给RADIUS服务器并收到一个包含隧道属性的RADIUSAccess-Accept或是一个Access-Reject。

在指定了一条L2TP隧道的情况下,如果之前不存在,NAS将提出一个控制连接,并且NAS和隧道服务器将建立呼叫。

至此,数据将开始流过这条隧道。

NAS将典型的使用LCP转发,虽然对隧道服务器来说,重新协商LCP也是可能的。

如果LCP允许重协商,NAS不应发送一个LCPCONFACK完成LCP协商。

代替发送LCPCONFACK,NAS将变成发送一个LCPConfigure-Request包,在资料[6]中描述。

然后客户端可能重协商LCP,并且从这点向前,所有从客户端发起的PPP包将被封装并发送到隧道服务器。

由于地址分配将发生在隧道服务器上,客户端和NAS不许开始NCP协商。

变为NCP协商将发生在客户端和隧道服务器之间。

4.1.2.有RADIUS应答转发的NAS认证

这一方法中,认证和授权在NAS发生一次并且RADIUS应答转发给隧道服务器。

该方法不接受未授权NAS用户的网络接入;

并允许在隧道的两端进行记帐。

然而,它也需要两端都与RADIUS服务器共享相同的密钥,因为那是隧道服务器能够检查RADIUS的Access-Reply的唯一方法。

这个方法中,隧道服务器将与所有的NAS和相关RADIUS服务器共享密钥,并且隧道服务器没有在这里提供LCP重协商。

同样,隧道服务器需要知道如何去处理和验证RADIUS的Access-Accept消息。

虽然如果应答直接来自于一个RADIUS服务器,这个方案是可用的,但如果包括一个RADIUS代理,它将变得难以管理,因为应答要用客户端和代理共享的密钥进行认证,而不是RADIUS服务器。

结果,这个方案是不切实际的。

4.1.2.1.隧道服务器认证

这个方案中,认证和授权在隧道服务器发生一次。

这要求NAS决定用户需要(怎样)建立隧道(通过RADIUS或是NAS配置)。

如果使用了RADIUS,可使用下面方法之一来做决定:

基于电话号码认证

用户ID

4.1.2.2.基于电话号码认证

使用Calling-Station-Id和Called-station-IdRADIUS属性,授权和并发隧道属性能够以发起呼叫的电话号码或被呼叫号码为依据。

这允许RADIUS服务器基于呼叫电话号码来授权用户或是基于Calling-Station-Id或Called-Station-Id来提供隧道属性。

同样的,在L2TP中隧道服务器可以基于包含在NAS发送的L2TPIncoming-Call-Request包中的被拨号码和拨叫号码来选择拒绝或接受这个呼叫。

也可以基于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属性。

在基于电话号码认证的情况下,一个典型的开始顺序像这样:

客户端和NS:

NAS到RADIUS服务器:

RADIUS服务器到NAS:

NAS到隧道服务器:

L2TPIncoming-Call-Request

隧道服务器到NAS:

客户端和隧道服务器:

隧道服务器到RADIUS服务器:

RADIUSAccess-request(可选)

RADIUS服务器到隧道服务器:

该过程以一个到NAS的进入呼叫开始。

如果配置为基于电话号码认证,NAS发送一个包含Calling-Station-Id和Called-Station-Id属性的RADIUSAccess-Request。

然后RADIUS服务器将以一个RADIUSAccess-Accept或Access-Reject响应。

在隧道建立起来之前,不允许NAS开始PPP认证。

如果时限允许,NAS可以先于同对等实体开始LCP协商建立起隧道。

如果这个完成,那么将不需要在对等实体和隧道服务器之间进行LCP重协商,也不需使用LCP转发。

如果基于电话号码的认证初始不成功,RADIUS服务器发送一个RADIUSAccess-Reject。

这种情况下,NAS必须发送一个LCP-Terminate并断开用户连接。

在隧道属性包含在RADIUSAccess-Accept中,并且一条L2TP隧道被指出的情况下,NAS此刻将建立起一条控制连接,如果先前不存在。

这通过向隧道服务器发送一个L2TPStart-Control-Connection-Request消息来实现。

然后隧道服务器将用一个L2TPStart-Control-Connection-Reply应答。

如果该消息指出一条错误(信息),或者该控制连接在将来任意时刻被终止,那么NAS必须发送一个LCP-Terminate并断开用户连接。

之后,NAS将发送一个L2TPIncoming-Call-Request消息给隧道服务器。

其他情况中,该消息将包含呼叫序列号,该号与NAS-IP-Address和Tunnel-Server-Endpoint一起用来唯一地确定这个呼叫。

隧道服务器将用一个L2TPIncoming-Call-Reply消息应答。

如果该消息指出一条错误,那么NAS必须发送一条LCP-Terminate并断开用户连接。

如果没有指出错误,那么NAS就用一条L2TPIncoming-Call-Connected消息应答。

至此,数据可以开始通过隧道流通。

如果NAS和客户端之间的LCP协商已经开始,然后就可以使用LCP转发,或者客户端和隧道服务器将现在重协商LCP并开始PPP认证。

否则,客户端和隧道服务器将第一次协商LCP并且之后转移到PPP认证阶段。

如果需要重协商,在重协商开始的时候,NAS不应该已经发送LCPCONFACK结束掉LCP协商,而且不允许客户端和NAS已经开始NCP协商。

胜于发送一条LCPCONFACK,NAS将代之于发送一个LCPConfigure-Request包,在资料[6]中描述。

之后客户端可以重协商LCP,并且从这一点之后,所有从客户端发出的PPP包将被封装并发送到隧道服务器。

当LCP重协商已经结束,NCP阶段就将开始,并且隧道服务器将给客户端分配一个地址。

如果L2TP正在被用作隧道协议,且LCP重协商是必需的,NAS可以在它的初始设置通知(initialsetupnotification)中包括一份在每一方向发送来结束LCP协商的LCPCONFACK的拷贝。

之后隧道服务器可以用这条信息来避开一个附加的LCP协商。

用L2TP,初始设置通知也可以包括认证信息,请求允许隧道服务器来认证用户以及决定接受或拒绝连接。

然而,基于电话号码的认证中,PPP认证禁止在NAS建立隧道之前出现。

其结果是禁止设置L2TP认证转发。

PPP认证执行过程中,隧道服务器能够访问它自己的用户数据库,或是作为选择,能够发送一个RADIUSAccess-Request请求。

后面的方法在允许认证转发,比如有漫游或者共享使用网络的情况下很有用。

在这种情况下,RADIUS和隧道服务器在统一的管理之下而且典型的被紧密放置在一起,可能在同一个LAN上。

因此让隧道服务器担当RADIUS客户端提供了统一的用户管理。

注意隧道服务器的RADIUSAccess-Request典型地直接发送到本地RADIUS服务器而不是通过一个代理来转发。

下面概述这种包含在基于电话号码认证的强制隧道的初始化中的交互。

为了简化下面的图表,我们省去了客户端。

但是,应知道客户端通过PPP协商参与同隧道服务器的认证和并发数据交换。

初始化顺序

NASTunnelServerRADIUSServer

-----------------------------

Callconnected

SendRADIUS

Access-Request

withCalled-Station-Id,

and/orCalling-Station-Id

LCPstarts

IFauthentication

succeeds

SendACK

ELSESendNAK

IFNAKDISCONNECT

ELSE

IFnocontrol

connectionexists

Send

Start-Control-Connection-Request

toTunnelServer

Start-Control-Connection-Reply

toNAS

ENDIF

Incoming-Call-Request

messagetoTunnelServer

SendIncoming-Call-Reply

Incoming-Call-Connected

Senddatathroughthetunnel

Re-negotiateLCP,

authenticateuser,

bringupIPCP,

startaccounting

4.1.2.3.用户名

因为认证只发生在隧道服务器,在NAS的隧道初始化必须先于用户认证发生。

结果,这一方案代表性地或者使用用户ID的域名部分,或者利用RADIUS服务器上的attribute-specific处理。

因为用户身份从未被NAS验证,或者隧道服务器所有者必须乐于负担所有的入呼叫,或者为记帐目的,必须用诸如Calling-Station-Id的其他信息验证用户身份。

在attribute-specific处理中,可能使用RADIUS并且用一个属性发信号通知隧道初始化。

例如,隧道属性可能被送回,如果User-Password属性包含一个伪值(比如“tunnel”或“L2TP”)。

可选的,以一个特殊字符(‘*’)开始的用户ID可用来指出发起一条隧道的要求。

当使用了attribute-specific处理,隧道服务器可能需要重协商LCP。

另外的解决方案包括使用用户ID的域名部分;

在域X中的所有用户将通过隧道连到地址Y。

这个建议支持强制建立隧道,但不提供基于用户建立隧道。

为了让NAS对连接开始记帐,将需要利用在到隧道服务器的认证过程中用户所声称的身份,因为它没有通过RADIUS来验证身份。

但是,为使之在记帐中有用,隧道终点需要有一个与NAS属主相关联的帐号。

这样即使用户拥有一个具有NAS属主的帐号,他们也不能利用这个帐号建立隧道,除非隧道终点还与NAS属主有一种商业关联。

这样该方法与漫游是相矛盾的。

一个典型的包括利用用户ID域名部分的初始化顺序是这样的:

客户端和NAS:

认证

PPPLCP重协商

RADIUSAccess-request(可选)

此过程以一个到NAS的入呼叫开始,紧接着是客户端和NAS之间的PPPLCP协商。

然后认证过程开始,且是基于用户ID的域名部分,如果先前没有,这时NAS将建立一条控制连接,并且NAS和隧道服务器将建立呼叫。

至此,数据可以开始通过隧道传输。

客户端和隧道服务器现在可以进行LCP重协商并将完成PPP认证。

在重协商开始时,NAS不应该已经发送LCPCONFACK完成LCP协商,而且客户端和NAS不允许已开始NCP协商。

胜于发送LCPCONFACK,该NAS将改为发送一个LCPConfigure-Request包,详见资料[6]。

然后客户端可以重协商LCP,并且从此刻开始,所有从客户端发起的PPP包将被封装并发送到隧道服务器。

在单一认证的强制隧道中,不允许设置L2TP认证转发。

当LCP重协商结束时,NCP阶段就会开始,而且隧道服务器将给客户端分配一个地址。

在PPP认证执行过程中,隧道服务器能够访问它自己的用户数据库,或者是它可以发送一个RADIUSAccess-Request。

隧道建立起来之后,NAS和隧道服务器能够开始记帐。

此交互概括如下。

初始序列

Callaccepted

LCPstarts

Authentication

phasestarts

4.2.双重认证

此方案中,在NAS和隧道服务器两端都进行认证。

这需要拨号客户端处理双重认证,伴随LCP重协商。

为了让NAS和隧道服务器依据相同的数据库进行认证,要求隧道网络服务器上有RADIUS客户

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 小学教育 > 数学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1