属性技能 - 搜狗百科
声明：搜狗百科免费提供信息查询和信息编辑，坚决打击恶意篡改、冒充官方收费代编等违规行为。
过渡技术—Radius扩展属性
城域网IPv6过渡技术—Radius扩展属性 摘要：在IPv6城域网改造过程中，AAA服务器除了保持与BRAS通过IPv4 Radius报文交互，但是需要扩展支持IPv6的扩展。与IPv6相关的Radius属性分为标准属性、过渡技术属性和设备厂商扩展属性。 作者：来源：51CTO | 日 11:44:39 关键字：IPv6 技术 城域网 RADIUS ZDNET网络频道 12月18日 综合消息：在IPv6城域网改造过程中，AAA服务器除了保持与BRAS通过IPv4 Radius报文交互，但是需要扩展支持IPv6的扩展。与IPv6相关的Radius属性分为标准属性、过渡技术属性和设备厂商扩展属性。 第一类属性：IPv6地址上报属性(标准属性) 标准规范RFC3162和RFC4818规定了Radius的IPv6属性。
在ND接入或者使用DHCPv6 IA-NA方式为Host或者网关分配地址时使用标准属性Framed-Interface-Id和Framed-IPv6-Prefix上报用户地址信息 如果使用DHCPv6 IA-NA方式给用户分配128位地址则在Framed-IPv6-Prefix中上报 在对于PD接入的情况下分配前缀时，使用标准属性Delegated-IPv6-Prefix上报前缀信息 第二类属性：针对过渡技术的属性 每个过渡技术在实现的过程中需要配置相关属性，这些属性很多都是AAA通过Radius下发到BRAS，然后在通过DHCP等方式下发到CPE的。 DS-lite：RFC6519定义了DS-Lite-Tunnel-Name的属性，属性ID为144. 6RD:RFC6930定义了5中Radius扩展属性。
还有NAT64、MAP、4rd的扩展属性在IETF工作组中进行研究和讨论。 第三类属性：设备商扩展属性 由于标准规范的IPv6 Radius的属性不能满足业务运营，允许设备商按照RFC2138规范，使用属性Vender-Specific(26)进行扩展。 以上三类Radius属性可以完整的支持IPv6的业务开展，并不断完善
扩展阅读：
词条标签：
合作编辑者：
搜狗百科词条内容由用户共同创建和维护，不代表搜狗百科立场。如果您需要医学、法律、投资理财等专业领域的建议，我们强烈建议您独自对内容的可信性进行评估，并咨询相关专业人士。
点击编辑词条，进入编辑页面君，已阅读到文档的结尾了呢~~
本文描述在网络访问服务器和记账服务器之间传递记账信息协议。
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
Radius计费
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口RADIUS协议的扩展应用研究
摘& 要 介绍了RADIUS协议的基本概念和原理，结合实际需求，指出了RADIUS协议在应用中的不足与缺陷，提出了实现扩展应用的设计方案和具体实现方法，以符合宽带环境下认证和计费的实际应用需求。 &&& 关键词 RADIUS；802.1x；AAA；扩展&0& 前言&&& RADIUS协议（Remote Access Dail-In User Service，远程认证拨号用户服务协议）由于其支持多种认证法方式、易于扩展、相对安全、易于实现等特点，已成为很流行的AAA协议。很多厂商推出了各种有关RADIUS的产品，例如RADIUS服务器，支持RADIUS的接入路由器、交换机等，目前RADIUS已经成为环境中一个事实上的AAA（Authentication 认证，Authorization授权，Accounting 计费）标准。但由于RADIUS协议本身没有解决好对用户上下行带宽的控制、用户上网时限的限制等问题，限制了其推广与广泛应用。本文利用RADIUS协议的可扩展性，通过扩展RADIUS协议的应用，在实现认证计费的同时可以对用户的认证进行有效控制。1& RADIUS协议简介&&& RADIUS主要提供三个基本功能：Authentication（认证）、Authorization（授权）、Accounting（计费），即AAA功能。该协议采用C/S结构，以UDP作为传输协议，具有强大的认证能力，是管理远程用户验证和授权的常用方法。RADIUS的客户端一般是NAS（Network Access Server，网络接入服务器）。同时RADIUS是一种可扩展的协议，它进行的全部工作都是基于Attribute-Length-Value的向量进行的。1.1& RADIUS数据包格式&&& RADIUS协议是TCP/IP的应用层协议，在传输层它的报文封装在UDP报文中，进而封装进IP包。Radius数据包格式如图1所示，各个域是自左向右传送的。Code&&IdentifierLengthAuthenticatorAttributes图1 Radius数据包格式&&& （1）Code：标识Radius包的类型；&&& （2）Identifier：匹配请求和响应的标识符；&&& （3）Length：表明Code、Identifier、Length、Authenticator和Attributes的总长度；&&& （4）Authenticator：该字段用来识别RADIUS服务器和隐藏口令算法中的答复。&&& （5）Attributes：属性可能包含多个实例，在这种情况下同种类型的各个属性的排列应当保持一定的顺序。但是，不同类型的各个属性的排列顺序是任意的。1.2& Attribute数据格式&&& Attribute的数据格式有两种，一种是标准属性的数据格式图2所示；另一种是类型值为26的Vendor-Specific属性的数据格式图3所示，此属性允许厂商扩展不适合作通用用途的私有属性。TypeLengthValue1图 2 标准属性数据格式TypeLengthVendor-idValue2图 3 Vendor-Specific数据格式&&& （1）Type：指示了Attribute的类型；&&& （2）Length：指明Attribute（包括Type,Length,Vendor-Id和Value域）的长度，如果某个Attribute是在Access-Request中收到的，但长度是无效的，这时应发一个Access-Reject。如果某个Attribute是从Access-Accept, Access-Reject或者Access-Challenge中收到的，并具有无效的长度，这个包必须被视为Access-Reject或者丢弃；&&& （3）Value1有4种类型：String、Ipa-ddress、Integer、Time从00:00:00GMT,Jan-uary 1,1970到当前的总秒数）；&&& （4）Vendor-Id：是以网络字节顺序排列的私人代码（一般为常量）；&&& （5）Value2与Value1类型相同。此域应按如下顺序编码vendor type/vendor length/ verdor value，其中verdor value域取决于厂商对这个属性的定义。2& RADIUS在应用中存在的问题&&& 基于802.1x技术的RADIUS服务器的应用在一定程度上提高了网络性能，实现了大型局域网内外部的安全认证管理，但随着RADIUS的产品的广泛应用，协议本身存在的不足和局限渐渐暴露出来，给整个网络带来安全隐患。其不足与局限主要体现在以下几个方面：图4应用网络拓朴图&&& （1）如果网络中某一用户受到非法攻击，此用户可能占用过多的网络带宽，从而导致整个网络流量异常，更严重者可能阻塞整个网络带宽，导致网络瘫痪。如图4所示，假如PC1机子中毒了，那么他的上行和下行流量可能会出现异常，这就影响PC2使用网络，更有甚者会影响PC3，PC4使用网络。&&& （2）在RADIUS协议里面没有对上网时限进行控制的属性，如果PC1申请了一账号，那么这个账号将永久有效，而且用户通过认证后，可以不受时间限制的使用网络。在一些特定环境中，这就不实用了。比如在校园网内，无法对那些通宵上网的学生进行控制，也无法对那些即将毕业的用户设置有效期。&&& （3）利用802.1x的基于二层的认证方式，本方案采用DHCP服务器分配IP地址，只有当用户PC1认证通过后，才能够分配到IP网络地址，这样提高了网络的安全性，但用户在认证时就不能绑定IP，同时PC2、PC3、PC4都可能使用PC1的账号上网，这就又给这个网络安全带来了隐患。3& RADIUS协议在实际应用中的扩展应用&&&& 如上所述，RADIUS协议在实际应用中存在的问题较多，要更好地实现RADIUS服务器对用户的控制管理就必须对其功能进行扩展，下面是具体的解决方法。3.1& 限制用户上下行带宽&&& 有效的限制用户使用网络带宽有时候是网络管理者追求网络可控的一个目标。大部分用户使用互联网都是下载的多，上传的少。因此我们可以设置用户的上行和下行带宽来更好的控制认证用户访问网络。在RADIUS标准里面并没有控制上行和下行带宽的属性，为了实现此功能，可以利用RADIUS协议的可扩展性扩展需要的私有属性。具体的限制用户上下行带宽可以这样实现：&&& 扩展Uplink-Bandwidth属性用以限制用户的上行带宽，同时扩展Downlink-Bandwidth属性用以分配用户的下行带宽。这两个属性存储了用户被允许的上行和下行带宽的描述，这些属性的值应设置为整形，长度不超过四个字节，单位一般可以设为kbps或者bps。对于预先没有配置上下行带宽的用户在上网过程中，系统探测到此用户流量出现异常，可以先强制其下线，然后在RADIUS server的用户属性中配置用户的上行和下行带宽。当用户再次发起认证并通过后，配置的带宽数据将被携带在Access-Accept报文里返回给NAS，由NAS认证系统设置认证端口的上行及下行的访问带宽，用户下线后，再由NAS认证系统取消该设置。3.2& 用户上网时限的控制&&& 在局域网里面，实现对用户上网时限的控制是管理员对网络进行控制主要手段之一。有时我们会将RADIUS中的Auth-Type属性设置为Reject以拒绝某一用户认证，但这并没有实现对用户上网时限的控制。对用户上网时限的控制，包括两层含义：第一，在不被允许的时间段里，拒绝用户认证上网；第二，在用户上网过程中，时限到了可以强制用户下线。在RADIUS标准里并没有一个上网时限的属性，但是提供了一个Session-Timeout的属性，可以利用这个属性来实现对用户账号有效期以及用户上网的时间段的控制。具体实现如下。3.2.1 账号有效期的控制&&&& 在人员流动性比较大的局域网里，为了便于我们管理局域网络，可以将用户的账号设置成具有有效时间限制的，管理人员可以定期清理过期账号，从而保证了整个局域网的安全。可以在Radius服务中扩展一个Expiration属性，这个属性存储了用户密码超时时间的描述，它可以是这样的：06 Jun 年6月6号前密码都未超时的）。在用户认证时，只要把当前的系统日期与用户账户中的Expiration日期信息比较，判断该日期是否超出密码过期的日期，如果没有超出了用户密码过期的日期，便允许认证通过，否则返回认证失败的信息。3.2.2 使用网络时间段的限制&&&& 为了提高用户利用网络的效率以及使我们便于管理局域网络，我们对用户上网时间段进行限制。为了满足上述要求，扩展一个logintime属性，logintime属性的时间格式为被 "|"或","隔离开来的串。天可能为Mo、Tu、We、Th、 Fr、 Sa、Su. 分别代表星期一至星期日，其中wk表示工作日，也就是周一到周五（Wk for Mo-Fr）。"Any" or "Al" 表示每一天。时间格式为hhmm-hhmm 的格式。例如：Wk,Sa,Su 允许一个用户在工作日的晚上23:05到早上8:55,周六全天，周日晚23:05到下午16:55。在用户认证时，只要将系统时间和用户设定的logintime的值做一下比较，如果系统时间超出规定时间的限制，那么认证失败，并提示相关信息；反之如果在规定时间之内，那么时间跨段末端的值将会被携带在Access-Accept报文里返回给NAS，NAS进行相应的设置，这样用户在上网过程中，到了规定的时间就会被NAS强制下线。3.3& VLAN的绑定&&& 由于 802.1x采用基于二层的认证方式，在请求认证时是不需要IP的，因此在较为复杂的局域网应用中，为了便于维护和方便用户的使用，通常会采用DHCP动态分配IP地址的方式来为上网的用户分配IP。动态分配显然比自动分配更加灵活，尤其是当实际IP地址不足的时候。采用此类地址分配方式，就导致用户认证时无法绑定IP。为了解决上述问题，我们采取扩展其它的绑定的元素来保证用户认证的安全可靠。&&& 可以通过扩展一个VLAN-IP-Address属性，将用户账号与连接用户的NAS端口所属VLAN的IP地址绑定，唯一的确定用户身份。如图4，首先将整个网络中的用户划分为两个VLAN，PC1和PC2属于VLAN1，PC3和PC4属于VLAN2，其中PC1用户在RADIUS服务器绑定了自己的VLAN信息，而PC2未绑定。当PC1，PC2向RADIUS提交用户信息时，服务器只将PC1用户提交的VLAN的信息与系统中PC1用户绑定的VLAN值进行比较，如果两者一样，则允许认证通过，否则便返回认证失败信息。而当用户PC3盗用PC1的账号时，则会因为其提供的VLAN2信息与VLAN1不符，将阻止他认证通过。这在一定程度将网络中的非法用户隔离在网络之外，有效的对用户进行接入控制，保证只有认证通过的合法用户使用网络，提高了网络的安全性，方便了网络的管理。4& RADIUS服务器的安装配置&&& 本系统运行于linux平台下，采用的Radius服务器是在FreeRadius-1.0.5基础上做了一些改进的，即在认证和计费失败的情况下，该系统能够对802.1x客户端配合通告处理原因和处理结果。其部分配置文件做如下改动，其余配置为系统默认。4.1& client.conf&&& 每增加一个NAS都要在client.conf文件里面添加一下，否则用户认证时，将出现找不到NAS的错误。在设置client.conf时，要确保NAS和Radius的共享密码的一致性。如下是为client 192.168.21.30进行的配置：&&& client 192.168.21.30 { &&&&&&&& # NAS的IP地址&&& secret&&&&&&&&&& = testing123&& &&& # NAS和radius服务器的共享密码&&& shortname&& = localhost&&& &&& # shortname 是IP地址的一个别名 &&& # 下面几个选项是可选的，为了以后查# 询NAS的需要设置的& &&& # nastype&&&& = other & &&&& &&& # locahost不一定就是NAS&&& # login&&&&&& = !root&&& # password&&& = someadminpas}4.2& USERS&&& FreeRadius server从外部获得用户认证信息，而这些用户认证信息可以存放在USERS文件或者SQL、LDAP数据库中。其中USERS文件比较直截了当，其他形式的用户信息都是该文件内容的镜像。如下是USERS文件里用户名为Jane的配置属性。jane Auth-Type := Local, User-Password == "testing", VLAN- IP-Address ==172.21.13.23&&&&&&&& & &&&& Uplink-Bandwidth = 1500,Downlink-Bandwidth = 3000&&& 如上配置表示如果Jane提交的信息与第一行相同，则认证通过，且用户的上行下行带宽属性值将被携带在Access-Accept报文里返回给NAS，NAS进行相关配置。5& 结论&&& 本结合实际应用的需求，指出了RADIUS协议在实际应用中的不足与缺陷，通过扩展RADIUS属性字段的应用，能够很好地解决限制用户上下行带宽和上网时限控制等问题，以上措施的应用便于对网络进行管理，同时增强了网络的安全性，提高了网络的使用效率。 [1] RFC2865.Remote Authentication Dial In User Service(RADIUS)[S].[2] RFC2869 RADIUS Extensions[S].[3] 黄永锋,王滨,许晓东.RADIUS在802.1x中的应用[J].工程与设计,2006,(5).[4] 陆谊,张红.RADIUS协议扩展应用新研究[J].金卡工程，2005-08.
· · · · · · · · · ·
· · · · · · · · · ·BAS收到用户的请求后，向iSCP发出Access-Request(code=1)的认证
请求报文；
iSCP向BAS发出相应的Access-Accept(code=2)或
Access-Reject(code=3)响应报文；
BAS根据iSCP发回的属性对用户进行配置；
同时BAS向iSCP发出Accounting-Request(code=4/start)的计费开始
请求报文；
iSCP发回相应的计费响应报文；
用户上网过程中，BAS定时向iSCP发出
Accounting-Request(Interim-Update)实时计费请求；
iSCP发回相应的计费响应报文；
用户提出下线请求；
BAS收到用户的请求后，向iSCP发出Accounting-Request(stop)计费
结束请求报文；
iSCP发回相应的计费响应报文；
BAS收到iSCP的计费结束响应报文后，断开用户连接，此时用户下线。 可以看出，在整个的交互过程中，iSCP被动响应BAS发出的各种请求，iSCP本身无法控制用户的连接。用户上下线过程比较简单，但是运营商无法为用户提供任何个性化的服务，对于新的业务功能特性需求也将显得束手无力。
采用Radius+1.0并增加Portal-Server时用户上网过程
随着用户水平的提高和数量的增加，不同的用户对于上网的需求是各不相同的。这就要求运营商针对不同的用户提供不同的服务解决方案，以吸引更多的用户。因此在标准Radius用户上网流程中增加了Portal-Server，在Portal-Server上增加各种个性化的服务内容，同时需要扩展标准Radius相应属性到Radius+1.0。采用这种上网方式时，用户需要登录到相应的Portal页面，通过Portal页面提交用户名和口令，接着是Portal-Server和BAS之间通过Portal协议进行交互，将用户名和口令送到BAS，然后再由BAS触发与iSCP之间的Radius认证计费过程。
用户的上网过程如下：
首先用户通过DHCP获取IP地址，然后 (强制)登录到Portal页面(免费)；
用户通过Portal页面输入相应的用户名和口令；
Portal-Server完成与BAS的交互过程，将用户名和口令提交给BAS；
BAS根据Portal传送的用户名和口令与iSCP之间进行Radius认证计
费(同标准Radius步骤)；
BAS与Portal-Server之间进行交互，由BAS向Portal-Server发送上线
成功确认信息；
Portal-Server通过弹出上线页面通知用户验证通过；
用户通过Portal-Server弹出的页面进行注销请求；
Portal-Server收到此消息后与BAS进行交互，通知BAS对该用户进行
下线处理；
BAS对相应的用户进行下线处理(同标准Radius步骤)；
BAS与Portal-Server之间进行交互，由BAS向Portal-Server发送下线
成功确认信息；
Portal-Server通知用户下线成功。
与标准Radius用户上网过程相比，可以看出此类用户上网过程中需要和Portal-Server进行多次的交互。这样，运营商可以在此过程中可以通过Portal-Server提供各种个性化的业务以吸引更多的用户，如个性化业务管理、本地特色内容业务、内容过滤、看广告免费上网等等。
采用Radius+1.1并增加Portal-Server时用户上网过程
从上述的两类上网过程可以看出，iSCP总是被动响应BAS发出的各种请求，从而iSCP无法控制管理用户的上网过程；另一方面，如果用户在上网过程中出现某种突发的需求，如快速下载或传送很大的文件，那么就需要更大的带宽，这时用户就希望将带宽扩大，以缩短上网所用的时间，其它的时候不需
要很大的带宽时，希望将带宽缩小，以节省费用。面对自身的管理需求和用户的需求，上述的两类上网过程显然是无法满足的，而Radius+1.1的出现就是为了解决上述的问题。这种方式比采用标准Radius或Radius+1.0时多了一种报文：Session-Control(code=20)，该报文根据子属性command的值又分为四种类型：command=1/2/3/4分别对应的报文类型为Trigger-Request/Terminate/SetPolicy/result。用户通过Portal页面提交用户名和口令后，Portal-Server采用PSCP协议和iSCP进行交互，将用户名和口令首先提交给iSCP，iSCP则通过发送Session-Control(Trigger-Request)触发BAS开始Radius认证计费过程；当用户需要改变业务属性时，由iSCP发送Session-Control(SetPolicy)触发BAS修改对应的用户属性；当用户下线时，则由iSCP发送Session-Control(Terminate)触发BAS断开用户的连接；而BAS则相应的发送Session-Control(result)进行响应(Session-Control(Terminate)没有对应的响应报文)。下面就是采用Radius+1.1并增加Portal-Server时用户上网过程：
首先用户通过DHCP获取IP地址，然后 (强制)登录到Portal页面(免费)；
用户通过Portal页面输入相应的用户名和口令；
Portal-Server通过PSCP协议(另一种Portal协议)将用户名和口令直接
传送给iSCP；
iSCP将用户名和IP地址封装成Code=20的
Session-Control(Trigger-request)报文发送给BAS，触发BAS开始进行Radius认证计费过程。其中Session-Control是Radius+1.1新增报文；
BAS根据IP地址，找到相应的用户连接，进行Radius认证计费过程(同
标准Radius步骤)；
BAS向iSCP发送Session-Control(Trigger-request)的响应报文
Session-Control(result)；
iSCP接收到Session-Control(result)后，向Portal发送成功信息；
Portal-Server通过弹出上线页面通知用户验证通过；
用户通过Portal-Server提供的个性化页面，提出动态改变业务属性的需
Portal-Server通过PSCP协议将用户的需求发送给iSCP；
iSCP将用户连接号和新的业务属性封装成Session-Control(SetPolicy)
报文，发送给BAS；
BAS找到对应的用户连接，和iSCP完成相应的计费，并用新的业务属
性修改配置用户；
BAS向iSCP发送Session-Control(result)，确认完成业务属性的修改；
iSCP接收到Session-Control(result)后，向Portal发送修改业务属性成
Portal-Server通过弹出相应页面通知用户成功修改业务属性；
用户通过Portal-Server弹出的页面进行注销请求；
Portal-Server通过PSCP向iSCP发送用户注销请求；
iSCP将用户的连接号封装在Session-Control(Terminate)报文中，发送
BAS根据用户的连接号，完成相应的计费过程，并断开此用户的连接；
iSCP收到BAS发送的确认信息后，向Portal-Server通知用户下线；
Portal-Server通知用户下线成功。
可以看出，此种上网流程的确解决了刚才提出的两个问题，不仅支持iSCP主动下发控制报文，同时用户可以根据自身需求动态改变业务属性，从而使得运营商能够真正实现可运营、可管理性。
本文的内容结构
本文主要是针对上述的用户上网流程中涉及的Radius+协议和Portal协议而进行详细叙述的。首先是Radius+协议，在简单比较标准Radius与Radius+异同点的基础上，重点介绍Radius+1.1的协议内容；其次是Portal协议，主要介绍Portal V2.0的协议内容；再次，着重介绍了iTELLIN与BAS对接时各种业务流程；接下来，主要以ISN8850与iTELLIN对接时的debug调试信息，