RFC 2866 RADIUS AccountingWord下载.docx
- 文档编号:21813934
- 上传时间:2023-02-01
- 格式:DOCX
- 页数:38
- 大小:28.54KB
RFC 2866 RADIUS AccountingWord下载.docx
《RFC 2866 RADIUS AccountingWord下载.docx》由会员分享,可在线阅读,更多相关《RFC 2866 RADIUS AccountingWord下载.docx(38页珍藏版)》请在冰豆网上搜索。
4
2.1
Proxy(代理)...................................
3.
报文格式........................................
5
4.
报文类型........................................
7
4.1
Accounting-Request(计费请求)..................
8
4.2
Accounting-Response(计费回应).................
9
5.
Attributes(属性)................................
10
5.1
Acct-Status-Type..............................
12
5.2
Acct-Delay-Time...............................
13
5.3
Acct-Input-Octets.............................
14
5.4
Acct-Output-Octets............................
15
5.5
Acct-Session-Id...............................
5.6
Acct-Authentic................................
16
5.7
Acct-Session-Time.............................
17
5.8
Acct-Input-Packets............................
18
5.9
Acct-Output-Packets...........................
5.10
Acct-Terminate-Cause..........................
19
5.11
Acct-Multi-Session-Id.........................
21
5.12
Acct-Link-Count...............................
22
5.13
属性列表.......................................
23
6.
IANA事项........................................
25
7.
安全事项.........................................
8.
更改记录.........................................
9.
参考文献.........................................
26
10.
致谢.............................................
11.
AAA工作组主席地址.................................
12.
作者地址.........................................
27
13.
版权声明.........................................
28
1.
简介
要经营为众多的用户提供的串口线路和modem池,这会带来巨大的管理支持方面的需求。
由于modem池是通向外部的链路,因此它对安全、认证、计费都提出了很高的要求。
可以通过维护一个用户数据库来实现该需求,该数据库包含了认证(验证用户的名字和密码)以及为用户提供的服务类型的详细的配置信息
(如SLIP,PPP,telnet,rlogin等)。
RADIUS(远程用户拨号认证系统)文档[2]详细说明了RADIUS协议中认证和授权的相关内容。
本文扩展了RADIUS协议的应用,使其覆盖了从NAS(NetworkAccessServer)给RADIUS服务器传递计费信息的应用。
本文废弃了RFC2139[1]。
它与RFC2139之间的差别可以在附录“更改记录”中找到。
RADIUS计费协议的主要特性:
客户/服务器模式
网络接入服务器(NAS)是RADIUS计费服务器的客户端。
客户端负责将用户的计费信息传递给指定的RADIUS计费服务器。
RADIUS计费服务器负责接收计费请求,并给客户端返回一个回应信息,表示成功接收到了计费请求。
RADIUS计费服务器也可以作为其他类型的计费服务器的代理。
网络安全
客户端与RADIUS计费服务器之间的交互是通过共享密钥来进行相互认证的,共享密钥不会通过网络传送。
协议扩充性
所有的报文交互都是由多个不同长度的属性-长度-值三元组(Attribute-Length-Value3-tuples)构成的。
新的属性值的加入不会影响到原有协议的实现。
1.1.
描述文档的约定
本文中的关键词"
MUST"
"
MUSTNOT"
REQUIRED"
SHALL"
SHALLNOT"
"
SHOULD"
SHOULDNOT"
RECOMMENDED"
MAY"
以及"
OPTIONAL"
的参见RFC2119[3]中的描述。
这些关键词意义与其是否大写无关。
1.2.
术语
本文使用了以下的术语:
服务
NAS为拨入用户提供的某种服务,如:
PPP或者Telnet。
会话
NAS为拨入用户提供的每一个服务都会建立一个会话。
第一次开始提服务做为会话的开始,服务终止做为会话的结束。
如果NAS支持的话,一个用户可以有多个并行或者串行的会话。
对于每一个会话,都会产生一个独立的计费开始和计费结束记录,它们以不同的Acct-Session-ID属性值区分。
静默丢弃
应用程序不对包进行任何处理就直接丢弃。
应用程序应该(SHOULD)有提供记录错误的能力,其中包括被静默丢弃的包的内容,而且应用程序应该(SHOULD)在一个统计计数器中记录下该事件。
2.
操作
当一个客户端被配置成采用RADIUS计费协议时,在开始提供服务的时候它会生成一个计费开始报文,报文描述了服务类型以及被服务的用户的信息,该报文被发送到RADIUS计费服务器。
计费服务器会返回应答,表示计费报文已经收到。
服务终止时,客户端会产生一个计费结束报文,该报文描述了服务类型以及一些可选的统计数据,譬如,服务总时长、输入和输出的字节数或者输入和输出报文数。
该报文被发送到RADIUS计费服务器,计费服务器会返回应答,表示计费报文已经收到。
计费请求(不管是计费开始报文还是计费结束报文)通过网络发送给RADIUS计费服务器。
本文推荐客户端应该反复发送计费请求,直到收到回应消息为止。
如果在一段时间内没有收到回应消息,计费请求就会被重发几次。
如果主服务器宕机或者是无法到达,客户端也可以向备用服务器转发计费请求消息,可以在对主服务器重试失败一定的次数之后客户端将计费消息转发到备用服务器上,也可以采用循环方式将计费消息转发到备用服务器上。
重试和放弃算法是
目前正在研究的一个课题,在本文中就不再赘述了。
RADIUS计费服务器可以(MAY)向其他的服务器发送计费请求,这时该RADIUS服务器是一个客户端。
如果RADIUS计费服务器不能成功的记录计费报文,服务器一定不能(MUSTNOT)给客户端发送计费回应报文。
2.1.
代理
参阅“RADIUS”RFC[2]中关于代理RADIUS的描述,代理RADIUS计费服务器的工作方式与代理RADIUS服务器是相同的,如下例所示:
NAS向转发服务器发送计费请求。
转发服务器将计费请求记录下来(如果必要的话),在所有其它的Proxy-State属性之后添加自己的Proxy-State属性(如果必要的话),并且更新请求Authenticator(认证字),然后将计费请求转发给远程服务器。
远程服务器将计费请求记录下(如果必要的话),将所有的Proxy-State属性按顺序原封不动的从请求数据报文复制到回应报文中,然后将计费回应报文发送给转发服务器。
转发服务器剥离最后一个Proxy-State属性(如果在第2步添加了的话),更新回应Authenticator(认证字),然后将计费回应报文发送给NAS。
转发服务器一定不能(MUSTnot)更改当前报文中已经存在的Proxy-State或者Class属性。
转发服务器可以(MAY)以通过(passthrough)方式实现转发功能,这样,转发服务器只要收到重发报文就将该报文转发;
或者转发服务器可以(MAY)自身实现重发功能,例如:
在转发服务器和远程服务器之间的网络链路与NAS和转发服务器之间的链路相比有很大不同的情况下。
当代理服务器实现重发功能的时候,要特别的注意确保重发算法是健壮的和可扩展的。
3.
报文格式
准确地讲,RADIUS计费报文被封装在UDP报文的数据域[4],它的UDP目的端口号是1813(十进制数)。
当产生一个回应的时候,源端口和目的端口互换。
本文定义了RADIUS计费协议。
早期的RADIUS计费协议使用UDP端口1646,由于它和著名的"
服务相冲突。
官方为RADIUS计费协议重新分配的端口号是1813。
RADIUS报文格式如下所示。
各个域的数据是从左向右传输的。
0
1
2
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
Identifier
Length
|
Authenticator
Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code(代码)
Code域占位一个字节,它用来标识RADIUS报文类型。
当收到的报文Code域非法时,该报文将会被静默丢弃。
RADIUS计费报文Code域(十进制)分配如下:
4
计费请求
5
计费回应
Identifier(标识符)
Identifier域占位一个字节,用于匹配请求和回应报文。
如果在一个很短的时间内接收到相同的源IP地址、源UDP端口号和相同的Identifier域的请求报文,RADIUS服务器就可以认为是重复的请求报文。
Length(长度)
Length域占位两个字节。
它包含了报文中的Code域,Identifier域,Length域,Authenticator域和属性域的总长度。
在长度域限定的范围之外的字节必须(MUST)作为填充字节,在接收时不予处理。
如果包的实际长度小于长度域中给出的值,该包必须(MUST)被静默丢弃。
报文的最小长度是20,最大长度是4095。
Authenticator(认证字)
Authenticator域占位16个字节。
最重要的字节先传输。
该域的值用来鉴别客户端和RADIUS计费服务器之间的消息。
RequestAuthenticator(请求认证字)
在计费请求报文中,认证字的值是一个占位16个字节的MD5[5]校验和,称作请求认证字。
NAS和RADIUS计费服务器共享一个密钥。
计费请求报文中的认证字中包含对一个由Code+Identifier+Length+16个值为0的字节+请求属性+共享密钥(+表示将各个字符连接起来)所构成的字节流进行某种方式的MD5哈希计算得出的16个字节的hash值。
这个占位16个字节的MD5哈希值被存储到计费请求包的Authenticator域中。
注意计费请求中的请求认证字不得与RADIUS接入请求的请求认证字的生成方式相同,因为在计费请求中没有User-Password属性。
ResponseAuthenticator(回应认证字)
在计费回应报文中的Authenticator域称作回应认证字。
它包含对一个由计费回应Code+Identifier+Length+对应的计费请求包的请求认证字+回应属性(如果有的话)+共享密钥构成的字节流进行某种方式的MD5哈希计算得出的16个字节的hash值。
这个占位16个字节的MD5哈希值被存储到计费回应报文的Authenticator域中。
属性
属性可以(may)包含多个实例,在这种情况下,同种类型的各个属性应当(SHOULD)有一定的顺序。
但是,不同类型的各个属性不需要有顺序。
4.
报文类型
RADIUS报文类型是由位于报文的第一个字节的Code域决定的。
4.1.
描述
计费请求报文是由客户端(典型的情况是NAS或者代理服务器)发送到
RADIUS计费服务器的,其中包含为用户提供服务的计费的信息。
客户端发送一个Code域值为4(计费请求)的RADIUS数据报文。
一旦接收到计费请求报文,如果服务器能够成功地记录下计费报文的话,必须(MUST)回应一个计费回应报文,但如果记录计费报文失败,则不能(MUSTNOT)回应计费回应报文。
除了User-Password,CHAP-Password,Reply-Message,State属性外(MUSTNOT),其它在接入请求和接入成功回应报文中有效的属性,在计费请求报文中同样有效。
在RADIUS计费请求报文中必须(MUST)包含NAS-IP-Address或者NAS-Identifer属性。
在计费请求报文中还应当(SHOULD)包含NAS-port或者NAS-Port-Type属性,或者两者都包含,除非服务不涉及端口或者NAS不区分端口。
如果计费请求报文包含Framed-IP-Address属性,则该属性必须(MUST)是用户IP地址。
如果接入成功回应报文中包含了有具体值的Framed-IP-Address属性,告诉NAS需要给用户分配或者与用户协商一个IP地址,则计费请求报文中的Framed-IP-Address属性(如果有的话)必须是分配的或者协商的实际的IP地址。
计费请求报文格式如下所示。
各个域是自左向右传输的。
RequestAuthenticator
4代表计费请求报文
当属性域的内容发生改变或者是已经收到前一个请求的有效的回应,Identifier域必须(MUST)改变。
如果仅仅是由于重传而内容没有变化时,标识符必须(MUST)保持不变。
需要指出的是,如果计费请求报文中包含了Acct-Delay-Time属性,则当该报文重传时,Acct-Delay-Time属性值将被更新,这导致了属性域内容发生变化,这时需要一个新的Identifier域和RequestAuthenticator域。
计费请求报文的请求认证字是一个占位16个字节的MD5哈希值,该值的计算方法已在上述的“RequestAuthenticator”中描述了。
Attributes(属性)
属性域的长度是变化的,其中包含着一系列的属性。
4.2.
计费回应报文是由RADIUS计费服务器发送给客户端的,用来通知客户端计费请求报文已接收到,并且成功地记录下来了。
如果计费请求报文被成功地记录下来,RADIUS计费服务器必须(MUST)发送一个Code域值为5(计费回应)的报文。
客户端收到计费回应报文后,其Identifier域需要能够和一个等待回应的计费请求报文的Identifier域相匹配。
回应认证字域必须
(MUST)含有对等待回应的的计费请求的正确响应,而无效的数据包会被静默丢弃。
RADIUS计费回应报文不要求包含属性。
计费回应报文格式如下所示。
各个域是自左向右传输的。
Id
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- RFC 2866 RADIUS Accounting