文档介绍：RFC2866 - RADIUS记账(1)
RFC2866 - RADIUS Accounting
摘要
本文描述在网络访问服务器和记账服务器之间传递记账信息协议。
注意
本文描述RADIUS记账协议。早期的RADIUS记账报文使用UDP1646端口,这和“sa-msg-port”服务冲突。RADIUS记账协议的正式端口是1813。
1. 概述
管理大量用户的分散的串行线路和modem池为管理支持创建了大量需求。因为modem池定义和外界联系的方式,必须仔细关注安全,授权和记账问题。通过管理一个用户数据库,允许用户认证(确认用户名和密码),同时配置为用户传递数据的服务类型,是一种最佳的实现方式。
RADIUS协议用来进行认证和授权。本文扩展了RADIUS协议,将记账报文通过NAS传递到RADIUS记账服务器。
本文废弃了RFC 2139。
RADIUS记账的特点如下:
l C/S模式
网络访问服务器(NAS)作为客户端与RADIUS记账服务器进行交互。客户端需要将记账报文发向指定的记账服务器。
RADIUS记账服务器的职责是接收记账请求,并且向客户端应答报文表示记账成功。
RADIUS记账服务器可以作为代理将请求转发到其他记账服务器。
l 网络安全
客户端和RADIUS记账服务器之间的事务使用一个从来不在网络中传递的共享密钥进行认证。
l 可扩展协议
所有的事务都由(属性,长度,值)三部分组成。实现时添加新的属性不会影响已有属性。
. 需求描述
以下关键字在RFC 2119中描述。"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MENDED", "MAY", and "OPTIONAL"。
这些关键字不区分大小写。
. 术语
文档中有以下术语:
l 服务
NAS为拨号用户提供服务,。
l 事务
NAS为拨号用户提供的服务构成一个事务,事务的开始是第一次提供服务的时候,事务的结束是服务结束的时候。如果NAS支持同一用户多个事务,那么用户可以串行或并行的持有多个事务,t-Session-Id可以分别进行开始和结束记账记录。
l 静默丢弃
具体的实现不继续执行,直接丢弃报文。实现时应该对这种情况记录日志,日志中包括静默丢弃的报文内容,同时应该统计发生这种时间的次数。
2. 操作
如果客户端使用RADIUS记账服务,开始记账时会生成一个记账开始报文,报文中描述了服务的类型以及用户正在享受这种服务,这个报文被发送到RADIUS记账服务器,然后记账服务器返回一个报文通知客户端已经收到记账开始报文。服务结束时客户端会生成一个记账结束报文,报文中描述了服务类型以及可选的统计信息,例如消耗时间、上行和下行字节数或者上行和下行的报文数,客户端将这个报文发送到记账服务器,记账服务器收到报文后返回应答报文,通知客户端已经收到记账结束报文。
Accounting-Request(记账请求)报文,不论是开始记账还是记账结束,都通过网络发送到记账服务器。建议当客户端没有收到记账请求报文应答时持续尝试。如果一段时间内没有应答,重传几次请求。当主服务器已经关闭或不可到达时,客户端可以将请求转发到其他服务器。当主服务器几次请求失败或使用轮叫调度的算法将报文发送到另一台服务器。重传回退算法是一个正在研究的课题,在本文中不进行描述。
RADIUS记账服务器为了满足客户端的请求,可以将请求转发到其他服务器中,这时,它作为客户端出现。
如果记账服务器不能正常记录记账报文,不能向客户端发送记账应答(Accounting-Response)报文。
. 代理
请参考RADUIS RFC中有关RADIUS代理的描述。RADIUS记账服务代理的运行方式一样,以下是一些例子:
1. NAS将记账请求(accounting-request)报文发送到***。
2. ***记录日志(如果需要),将自己的Proxy-State属性放置到其他Proxy-State属性之后,然后更新请求认证码,最后将请求转发到远程服务器。
3. 远程服务器收到报文后记录日志(如果需要),从请求报文中将所有Proxy-State
属性按照原来的顺序无修改的拷贝到应答报文中,然后将记账应答(accounting-response)报文发送到***。
4. 如果***在第2步添加了Proxy-State属性,就删除最后一个Proxy-State属性,然后更新应答认证码,再将记账应答(accounting-response)报文转发到NAS。
转发服务器不能修改已有的Proxy-State