rfc2867.RADIUS Accounting Modifications for Tunnel Protocol Support
RFC2868
14 Banyan Vines
15 E.164 with NSAP format subaddress
3.3. Tunnel-Client-Endpoint
描述
该属性包含了创建端的地址。它可以被包含在Access-Request和Access-Accept报文中，
类型，则它按照收到一个Access-Reject报文处理。
如果一个隧道终结者发送的Access-Request报文中包含了Tunnel-Type属性，则该属性应该
是表示当前正在使用的隧道协议。这中情况下，如果RADIUS服务器认为该协议没有被授权，
它会返回一个Access-Reject报。如果一个隧道终结者收到包含有一个或者是多个
3.1. Tunnel-Type
描述
该属性描述了将被使用的隧道协议（隧道创建者[tunnel initiator]）或者是已经被使用的
隧道协议（隧道终结者[tunnel terminator]）。该属性可以被包含在Access-Request,
Access-Accept 和 Accounting-Request报文中。如果该属性是被包含在隧道创建者发送
Category: Informational A. Rubens
Ascend Communications
J. Shriver
支持隧道协议的RADIUS属性
(RFC2868-RADIUS Attributes for Tunnel Protocol Support)
摘要
该文档定义了一组Radius属性，用于支持拨号网络中的强制隧道。
需要定义一些用于从RADIUS服务器传送隧道信息到隧道另一端的新的RADIUS属性。
AAA协议和RADIUS协议
AAA认证认证名称由来：AAA系统的简称：认证(Authentication)：验证用户的身份与可使用的网络服务；授权(Authorization)：依据认证结果开放网络服务给用户；计帐(Accounting)：记录用户对各种网络服务的用量，并提供给计费系统。
AAA-----身份验证 (Authentication)、授权 (Authorization)和统计(Accounting)Cisco开发的一个提供网络安全的系统。
奏见authentication。
authorization和accounting常用的AAA协议是Radius，参见RFC 2865，RFC 2866。
另外还有 HWTACACS协议（Huawei Terminal Access Controller Access Control System）协议。
HWTACACS是华为对TACACS进行了扩展的协议HWTACACS是在TACACS（RFC1492）基础上进行了功能增强的一种安全协议。
该协议与RADIUS协议类似，主要是通过“客户端－服务器”模式与HWTACACS服务器通信来实现多种用户的AAA功能。
HWTACACS与RADIUS的不同在于：l RADIUS基于UDP协议，而HWTACACS基于TCP协议。
l RADIUS的认证和授权绑定在一起，而HWTACACS的认证和授权是独立的。
l RADIUS只对用户的密码进行加密，HWTACACS可以对整个报文进行加密。
认证方案与认证模式AAA支持本地认证、不认证、RADIUS认证和HWTACACS认证四种认证模式，并允许组合使用。
组合认证模式是有先后顺序的。
例如，authentication-mode radius local表示先使用RADIUS认证，RADIUS认证没有响应再使用本地认证。
当组合认证模式使用不认证时，不认证（none）必须放在最后。
例如：authentication-mode radius local none。
RFC目录及对照表
ＲＦＣ930_Telnet 终端类型选项 ＲＦＣ932_子网地址分配方案 ＲＦＣ937_邮局协议( 版本 2) ＲＦＣ948_IP 数据包通过 IEEE 802.3 网络传输的两种方法 ＲＦＣ949_FTP 未公开的独特命令 ＲＦＣ951_引导协议(BOOTP) ＲＦＣ955_朝向一个处理过程应用的传输服务 ＲＦＣ962_TCP-4 的最初 ＲＦＣ968 “这是开动前的黑暗” ＲＦＣ974_邮件路由与域名系统 ＲＦＣ975_自治联邦 ＲＦＣ976 UUCP 邮件互换格式标准 ＲＦＣ985 Internet 网关要求 - 起草 ＲＦＣ988 主机扩展用于 IP 多点传送
中文 RFC 文档阅读 101-700
ＲＦＣ102 主机-主机 协议故障清除委员会的说明 ＲＦＣ103 中断键的执行 ＲＦＣ104 连接 191 ＲＦＣ105 通过 UCSB 进行远程登录和远程输出返回的网络说明书 ＲＦＣ106 用户/服务器 站点协议的网络主机问卷 ＲＦＣ107 主机-主机 协议故障清除委员会的说明 ＲＦＣ108 1971 年 2 月 17-19 日在 Urbana 举行的 NWG 会议的人员列表 ＲＦＣ124 在 ＲＦＣ107 中有印刷错误 ＲＦＣ132 ＲＦＣ107 的排版错误 ＲＦＣ148 ＲＦＣ123 的注释 ＲＦＣ149 最好的铺设计划 ＲＦＣ154 风格显示 ＲＦＣ156 伊利诺斯州站点的状态: 响应 ＲＦＣ116 ＲＦＣ179 连接的数字分配 ＲＦＣ185 NIC 分发手册 ＲＦＣ188 数据管理会议公告 ＲＦＣ198 站点证明-林肯实验室 360/67 ＲＦＣ204_利用报路 ＲＦＣ218 改变 IMP 状态报告设备 ＲＦＣ228 澄清 ＲＦＣ232 网络图形会议延缓 ＲＦＣ245 预定网络工作组会议 ＲＦＣ246 网络图形会议 ＲＦＣ256 IMPSYS 变更通知 ＲＦＣ276 NIC 过程 ＲＦＣ285 网络图形 ＲＦＣ324 RJE 协议会议 ＲＦＣ335 新界面 - IMP/360 ＲＦＣ348_放弃过程 ＲＦＣ404 文件迁移协议的注释 ＲＦＣ405 给 TIP 用户的第二封信 ＲＦＣ456 UCSB 的数据重置服务 ＲＦＣ457_FTP 的服务器与服务器交互 ＲＦＣ496 IMP/TIP 内存更新时间表(修订版 2) ＲＦＣ516 丢失消息的检测 ＲＦＣ591 在 NVT ASCII UCSB 和在线系统之间的实验输入映象 ＲＦＣ621 “注意圣诞节的时候要把长袜挂在烟囱下面” ＲＦＣ628 更深的数据语言的设计观念 ＲＦＣ634 最近的网络图 ＲＦＣ637 SU-DSL 网络地址的更改
RFC2866讲解
1、Accounting流程2、Accounting包格式0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Authenticator || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Attributes ...+-+-+-+-+-+-+-+-+-+-+-+-+-2.1 Code：4 Accounting-Request5 Accounting-Response2.2 Authenticator2.2.1 Request Authenticator占16个八位字节的MD5校验和；网络接入服务器（NAS）和RADIUS记帐服务器共享一个密钥。
记帐请求包中的鉴别码中包含对一个由Code＋Identifier＋Length＋16个为0的八位字节＋Request Attributes＋Shared Secret（在这里，＋表示将各个字符连接起来）所构成的八位字节流进行某种方式的MD5哈希计算得到的代码。
这个占有16个8位字节的MD5哈希值被存储到记帐请求包的鉴别码域中。
注意记帐请求中的请求鉴别码不得与RADIUS接入请求的请求鉴别码的生成方式相同。
Radius Request packect必须包括：Any attribute valid in a RADIUS Access-Request or Access-Acceptpacket is valid in a RADIUS Accounting-Request packet, except thatthe following attributes MUST NOT be present in an Accounting-Request: User-Password, CHAP-Password, Reply-Message, State.NAS-IP-Address（网络接入服务器的IP地址）或者NAS-Identifer(网络接入服务器标识符)。
RADIUS认证技术介绍
RADIUSRADIUS:Remote Authentication Dial In User Service，远程用户拨号认证系统由RFC2865，RFC2866定义，是目前应用最广泛的AAA协议。
RADIUS协议最初是由Livingston公司提出的，原先的目的是为拨号用户进行认证和计费。
后来经过多次改进，形成了一项通用的认证计费协议。
创立于1966年Merit Network, Inc.是密执安大学的一家非营利公司，其业务是运行维护该校的网络互联MichNet。
1987年，Merit在美国NSF（国家科学基金会）的招标中胜出，赢得了NSFnet（即Internet前身）的运营合同。
因为NSFnet是基于IP的网络，而MichNet却基于专有网络协议，Merit面对着如何将MichNet的专有网络协议演变为IP协议，同时也要把MichNet上的大量拨号业务以及其相关专有协议移植到IP网络上来。
1991年，Merit决定招标拨号服务器供应商，几个月后，一家叫Livingston的公司提出了建议，冠名为RADIUS，并为此获得了合同。
1992年秋天，IETF的NASREQ工作组成立,随之提交了RADIUS作为草案。
很快，RADIUS成为事实上的网络接入标准，几乎所有的网络接入服务器厂商均实现了该协议。
1997年，RADIUS RFC2039发表，随后是RFC2138，最新的RADIUS RFC2865发表于2000年6月。
RADIUS是一种C/S结构的协议，它的客户端最初就是NAS（Net Access Server）服务器，现在任何运行RADIUS客户端软件的计算机都可以成为RADIUS的客户端。
RADIUS协议认证机制灵活，可以采用PAP、 CHAP或者Unix登录认证等多种方式。
RADIUS是一种可扩展的协议，它进行的全部工作都是基于Attribute-Length-Value的向量进行的。
802.1x+RADIUS认证计费技术原理及配置
PPP帧格式
• 一个典型的PPP协议的帧格式
Flag Address Control Protocol Information
•protocol域表明协议类型为C227(PPP EAP) 时，在PPP数据链路层帧的Information域中 封装且仅封装PPP EAP数据包
EAP报文格式
Code
• IEEE 802.1x标准定义了一种基于“客户端——服务器”（ClientServer）模式实现了限制未认证用户对网络的访问。客户端要访 问网络必须先通过认证服务器的认证。在客户端通过认证之前， 只有EAPOL报文（Extensible Authentication Protocol over LAN） 可以在网络上通行。在认证成功之后，通常的数据流便可在网络 上通行。
控制方式
网络性能 组播支持 VLAN要求 客户端软件 对设备要求 安全性
数据认证统一
差 差 无 需要 集中的BAS设备 差
数据认证统一
差 好 多 不需要 集中BAS设备 差
数据认证分离
好 好 无 需要 接入层交换机 高
议程
• 认证计费原理及技术（AAA、Radius） • IEEE 802.1X协议以及应用 • 锐捷RG-SAM的安装与配置 • 锐捷安全交换机的802.1X配置
802.1X典型应用（一）
802.1X典型应用（二）
议程
• 认证计费原理及技术（AAA、Radius） • IEEE 802.1X协议以及应用 • 锐捷RG-SAM的安装与配置 • 锐捷安全交换机的802.1X配置
锐捷网络的安全认证计费产品
• Radius Server – RG-Radius、RG-SAM • NAS（Radius Client） – 锐捷全系列安全交换机、路由器、防火墙 • 接入用户 – 802.1x的认证客户端软件STAR Supplicant（分SuA普 通安装版本和SuB免安装版本）
RFC2865中文版
远程认证拨号用户服务（RADIUS）备忘录状态本文档描述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。
请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度和状态。
本备忘录可以不受限制地传播。
版权说明Copyright (C) The Internet Society (2000). All Rights Reserved. IESG说明本协议已经被广泛实现和使用，经验表明当本协议在一个大范围的系统中使用会降低性能和丢失数据。
部分原因是协议中没有提供拥塞控制的机制。
读者可以发现阅读本文对跟踪IETF组织的AAA工作组的工作进程有很大的帮助，AAA工作组可能会开发一个能够更好的解决扩展性和拥塞控制问题的成功的协议。
摘要本文描述了一个传输认证、授权和配置信息的协议。
这些信息在想要认证链路的网络接入服务器（Network Access Server）和共享的认证服务器务器之间传递。
实现说明本备忘录记录了RADIUS协议，RADIUS协议的早期版本使用的UDP端口是16 45，由于和"datametrics"服务冲突，官方为RADIUS协议分配了一个新的端口号1812。
目录1. 简介 (3)1.1 描述文档的约定 (4)1.2 术语 (5)2. 操作 (5)2.1 挑战/回应 (7)2.2 使用PAP和CHAP互操作 (8)2.3 代理 (8)2.4 为什么使用UDP (11)2.5 重发提醒 (12)2.6 被证明是有害的心跳 (13)3. 报文格式 (13)4. 报文类型 (17)4.1 接入请求报文 (17)4.2 接入成功回应报文 (18)4.3 接入拒绝回应报文 (20)4.4 接入挑战报文 (21)5. 属性 (22)5.1 User-Name (26)5.2 User-Password (27)5.3 CHAP-Password (28)5.4 NAS-IP-Address (29)5.5 NAS-Port (30)5.6 Service-Type (31)5.7 Framed-Protocol (33)5.8 Framed-IP-Address (34)5.9 Framed-IP-Netmask (34)5.10 Framed-Routing (35)5.11 Filter-Id (36)5.12 Framed-MTU (37)5.13 Framed-Compression (37)5.14 Login-IP-Host (38)5.15 Login-Service (39)5.16 Login-TCP-Port (40)5.17 (unassigned) (41)5.18 Reply-Message (41)5.19 Callback-Number (42)5.20 Callback-Id (42)5.21 (unassigned) (43)5.22 Framed-Route (43)5.23 Framed-IPX-Network (44)5.24 State (45)5.25 Class (46)5.26 Vendor-Specific (47)5.27 Session-Timeout (48)5.28 Idle-Timeout (49)5.29 Termination-Action (49)5.30 Called-Station-Id (50)5.31 Calling-Station-Id (51)5.32 NAS-Identifier (52)5.33 Proxy-State (53)5.34 Login-LAT-Service (54)5.35 Login-LAT-Node (55)5.36 Login-LAT-Group (56)5.37 Framed-AppleTalk-Link (57)5.38 Framed-AppleTalk-Network (58)5.39 Framed-AppleTalk-Zone (58)5.40 CHAP-Challenge (59)5.41 NAS-Port-Type (60)5.42 Port-Limit (61)5.43 Login-LAT-Port (62)5.44 Table of Attributes (63)6. IANA注意事项 (64)6.1 术语定义 (64)6.2 推荐的注册策略 (65)7. 举例 (66)7.1 用户Telnet到指定主机上 (66)7.2 用户使用CHAP认证方式认证 (67)7.3 用户使用挑战-回应卡 (68)8. 安全事项 (71)9. 更新记录 (71)10. 参考文献 (73)11. 致谢 (74)12. AAA工作组主席地址 (74)13. 作者地址 (75)14. 版权声明 (76)1. 简介本文档废弃了RFC 2138 [1]。
rfc2869_radius
document are to be interpreted as described in RFC 2119 [4].
An implementation is not compliant if it fails to satisfy one or more
"unconditionally compliant"; one that satisfies all the must and must
not requirements but not all the should or should not requirements
for its protocols is said to be "conditionally compliant."
2.3.5选择使用 20
3报文格式 20
4报文类型 20
5属性 20
5.1Acct-Input-Gigawords 23
5.2Acct-Output-Gigawords 23
5.3Evቤተ መጻሕፍቲ ባይዱnt-Timestamp 24
5.4ARAP-Password 25
5.5ARAP-Features 26
所有的属性由Type-Length-Value三元组组成。可以添加新的属性值而又不影响协议的实现。
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Cisco 5500 系列无线控制器产品手册说明书
产品手册Cisco 5500 系列无线控制器Cisco ®5500 系列无线控制器是一款高度可扩展的灵活平台，能够在大中型企业和园区环境中，为关键任务无线网络提供系统级服务。
5500 系列专门采用了独特设计，支持 802.11n 的性能下的最大可扩展性，通过射频的监控和保护能力提供延长的正常工作时间，并且可以同时管理 500 个接入点；它具有卓越的性能，可以提供可靠的视频流和长话级音质；它还具有增强的故障恢复功能，能在要求最严格的环境中提供一致的移动体验。
最大限度提高性能和可扩展性● 支持多达 500 个接入点和 7000 个客户端。
● 经过优化的 802.11n 性能，能够提供相当于 802.11a/g 网络九倍的性能。
● 延长的正常运行时间，每个控制器能同时配置和管理 500 个接入点 增强的移动性和服务● 范围更大的移动域，可以同时关联更多客户端。
● 速度更快的射频资源管理 (RRM) 更新，可在用户漫游时提供不间断的网络接入。
● 智能射频控制平面，可以自行配置、修复和优化。
● 高效漫游功能可提升应用性能，例如长话级音质、一致的视频流及数据备份。
许可灵活性与投资保护● 可以根据需要，逐步添加附加接入点容量许可。
OfficeExtend 解决方案● 安全、简便、经济高效的移动远程办公人员解决方案。
● 每个控制器支持多达 500 个远程接入点。
● 通过支持统一通信无线电话，节约手机费用。
全面的有线/无线安全性● 在接入点和控制器之间提供全面的 CAPWAP 加密。
● 支持检测恶意接入点和拒绝服务攻击。
● 管理帧保护功能可以检测恶意用户，并向网络管理员发出警报。
企业无线网状网● 动态无线网状网支持在室内和室外为难以布线的区域提供网络连接。
支持环保● 支持自适应功率管理，可以在非高峰时段关闭接入点无线电设备，以减少功耗。
● OfficeExtend 解决方案通过减少通勤时间和节省汽油、驾驶里程和保险成本，可降低成本和支持环保最佳实践。
Radius计费
RFC2866 - RADIUS记账(1)RFC2866 - RADIUS Accounting摘要本文描述在网络访问服务器和记账服务器之间传递记账信息协议。
注意本文描述RADIUS记账协议。
早期的RADIUS记账报文使用UDP1646端口，这和“sa-msg-port”服务冲突。
RADIUS记账协议的正式端口是1813。
1.概述管理大量用户的分散的串行线路和modem池为管理支持创建了大量需求。
因为modem池定义和外界联系的方式，必须仔细关注安全，授权和记账问题。
通过管理一个用户数据库，允许用户认证（确认用户名和密码），同时配置为用户传递数据的服务类型，是一种最佳的实现方式。
RADIUS协议用来进行认证和授权。
本文扩展了RADIUS协议，将记账报文通过NAS传递到RADIUS记账服务器。
本文废弃了RFC 2139。
RADIUS记账的特点如下：●C/S模式网络访问服务器（NAS）作为客户端与RADIUS记账服务器进行交互。
客户端需要将记账报文发向指定的记账服务器。
RADIUS记账服务器的职责是接收记账请求，并且向客户端应答报文表示记账成功。
RADIUS记账服务器可以作为代理将请求转发到其他记账服务器。
●网络安全客户端和RADIUS记账服务器之间的事务使用一个从来不在网络中传递的共享密钥进行认证。
●可扩展协议所有的事务都由（属性，长度，值）三部分组成。
实现时添加新的属性不会影响已有属性。
1.1. 需求描述以下关键字在RFC 2119中描述。
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"。
RADIUS-RFC2866(中文)
组织：中国互动出版网（/）RFC文档中文翻译计划（/compters/emook/aboutemook.htm）E-mail：ouyang@译者：刘伟娜(superwinner, starfield@)译文发布时间：2001-3-30版权：本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group C. Rigney Request for Comments: 2866 Livingston Category: Informational June 2000 Obsoletes: 2139RADIUS（远程用户拨号认证系统）记帐协议（RFC2866 ADIUS Accounting）Status of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved.摘要本文描述了在网络接入服务器和共享的记帐服务器之间传送记帐信息的协议。
实现RADIUS记帐协议的注意事项本文证明了RADIUS记帐协议。
早期开发的RADIUS记帐协议使用的是端口号为1646的UDP 端口，它和“sa-msg-port"服务互相冲突。
为RADIUS协议正式分配的端口号为1813。
目录RADIUS（远程用户拨号认证系统）记帐协议 1摘要 1实现RADIUS记帐协议的注意事项 11．简介 21.1 必要的说明 21.2 术语 22．操作 22.1 代理 33．包格式 34．包的类型 44.1 记帐请求 44.2 记帐响应 45. 属性 55.1 记帐状态类型 65.2 记帐延迟时间 65.3 输入字节数75.4 输出字节数75.5 会话Id 75.6 授权85.7 会话时间85.8 输入数据包85.9 输出包总数95.10 记帐中止事件95.11 多会话Id 105.12 记帐链路计数105.13 属性列表116. IANA（国际互联网分配的数字标准）因素127. 安全因素 128. 更改记录 129．参考文献 1210. 说明131．简介 (4)1.1 必要的说明 (4)1.2 术语 (4)2．操作 (5)2.1 代理 (5)3．包格式 (6)4．包的类型 (7)4.1 记帐请求 (7)4.2 记帐响应 (8)5. 属性 (9)5.1 记帐状态类型 (10)5.2 记帐延迟时间 (11)5.3 输入字节数 (11)5.4 输出字节数 (12)5.5 会话Id (12)5.6 授权 (13)5.7 会话时间 (13)5.8 输入数据包 (14)5.9 输出包总数 (14)5.10 记帐中止事件 (15)5.11 多会话Id (16)5.12 记帐链路计数 (16)5.13 属性列表 (17)6. IANA（国际互联网分配的数字标准）因素 (19)7. 安全因素 (19)8. 更改记录 (19)9．参考文献 (19)1．简介经营为众多的用户提供的串口线路和modem池会带来巨大的管理支持方面的需求。
中文RFC文档阅读 2501-3000
中文RFC文档阅读2501-3000ＲＦＣ2508 低速串行链路下IP/UDP/RTP数据包头的压缩ＲＦＣ2511 Internet X.509认证请求消息格式ＲＦＣ2516 在以太网上传输PPP的方法（PPPoE）ＲＦＣ2526 IPv6保留的子网任意传送地址ＲＦＣ2541 DNS 安全操作考虑ＲＦＣ2547 BGP/MPLS VPNsＲＦＣ2554 SMTP服务认证扩展ＲＦＣ2560 x.509因特网公钥基础设施在线证书状态协议——OCSPＲＦＣ2570 标准互联网络管理框架第三版介绍ＲＦＣ2577 FTP 安全考虑ＲＦＣ2581 TCP拥塞控制ＲＦＣ2582 TCP的快速恢复算法NewReno修正ＲＦＣ2585 Internet X.509 公共键底部结构操作协议: FTP和HTTPＲＦＣ2597 确定的面向PHB组ＲＦＣ2598 面向加速PHBＲＦＣ2618 RADIUS 身份验证客户端管理系统库(MIB)ＲＦＣ2629 用XML 写I-Ds 和ＲＦＣ文档ＲＦＣ2633 S/多用途网际邮件扩充协议(MIME) 版本3 信息说明书ＲＦＣ2644 更改直接广播在路由器上的缺省值ＲＦＣ2669 DOCSIS 电缆设备管理系统库(MIB) 电缆设备管理信息基础用于DOCSIS 适应性电缆调制解调器和电缆调制解调器中断系统ＲＦＣ2670 音频频率(RF)界面管理信息基础用于MCNS/DOCSIS适应性RF界面ＲＦＣ2685 虚拟专用网标志符ＲＦＣ2702 基于MPLS的流量工程要求ＲＦＣ2706 ECML v1:电子商务字段名ＲＦＣ2713 LDAP（轻型目录存取协议）目录中JAVATM对象的表征模式ＲＦＣ2714 LDAP（轻型目录存取协议）目录中的CORBA对象参考方案ＲＦＣ2731 Dublin核心元数据在HTML上的编码ＲＦＣ2732 文本IPv6地址在URL上的格式ＲＦＣ2733 RTP有效载荷格式用于普通正向错误更正ＲＦＣ2736 RTP有效载荷格式说明书作者的指导方针ＲＦＣ2754 RPS IANA的发布ＲＦＣ2756 超文本缓存协议(HTCP/0.0)ＲＦＣ2764 IP VPN的框架体系ＲＦＣ2773 使用KEA和SKIPJACK加密ＲＦＣ2774 HTTP 扩展框架ＲＦＣ2781 UTF-16,ISO 10646的一种编码ＲＦＣ2784 通用路由封装（GRE）ＲＦＣ2788 网络服务监视MIBＲＦＣ2793 用于文本交谈的RTP负载ＲＦＣ2796 BGP路由映象ＲＦＣ2809 通过RADIUS的L2TP强制通道的执行ＲＦＣ2810 Internet 延迟交谈:体系结构ＲＦＣ2811 Internet延迟交谈：通道管理ＲＦＣ2813 Internet 延迟交谈:服务器协议ＲＦＣ2817 在HTTP/1.1中升级到TLSＲＦＣ2818 TLS之上的HTTPＲＦＣ2824 呼叫过程语言框架和要求ＲＦＣ2825 复杂网络:I18N的发布,域名,和其它Internet协议ＲＦＣ2829 LDAP的身份验证方法ＲＦＣ2830 轻量级目录访问协议(v3): 传输层安全扩展ＲＦＣ2833 用于DTMF数字信号、电话音和电话信号的RTP负载格式ＲＦＣ2854 text/html 媒体类型ＲＦＣ2855 IEEE 1394的DHCPＲＦＣ2861 TCP 拥塞窗口检验ＲＦＣ2862 用于实时指针的RTP负载格式ＲＦＣ2866 RADIUS（远程用户拨号认证系统）记帐协议ＲＦＣ2867 RADIUS 账目管理修改用于通道协议支持ＲＦＣ2868 RADIUS 属性用于协议支持ＲＦＣ2869 RADIUS 扩展ＲＦＣ2871 一个IP电话路由框架ＲＦＣ2873 在Ipv4优先域中的TCP过程ＲＦＣ2874 支持IPv6地址集合和重编号的DNS 扩展ＲＦＣ2882 网络访问服务要求: 扩展范围实践ＲＦＣ2887 可靠的多点传送设计空间用于大的数据传送ＲＦＣ2889 基准方法论用于局域网交换设备ＲＦＣ2890 GRE中Key和SequenceNumber扩展ＲＦＣ2893 IPv6 主机和软件路由器转换机制ＲＦＣ2898 PKCS #5: 基于密码的密码系统说明书版本 2.0. BＲＦＣ2906 AAA 授权要求ＲＦＣ2914 拥塞控制原理ＲＦＣ2917 核心MPLS IP VPN 体系结构ＲＦＣ2918 BGP-4（边界网关协议）的路由刷新功能ＲＦＣ2920 SMTP 针对命令流水线的服务扩展ＲＦＣ2923 TCP的路径MTU发现问题ＲＦＣ2932 IPv4 多点传送路由管理系统库(MIB)ＲＦＣ2935 Internet开放贸易协议(IOTP)HTTP 补充ＲＦＣ2939 新DHCP选项和信息类型的定义步骤和IANA指导方针ＲＦＣ2945 SRP身份验证和键交换系统ＲＦＣ2946 Telnet 数据加密选项ＲＦＣ2947 Telnet加密：DES3 64位密码回馈ＲＦＣ2948 Telnet加密：DES3 64位输出回馈ＲＦＣ2949 Telnet加密:CAST-128 64比特输出回馈ＲＦＣ2950 Telnet加密:CAST-128 64比特密码回馈ＲＦＣ2951 使用KEA和SKIPJACK进行TELNET身份验证ＲＦＣ2952 Telnet加密：DES 64位密码回馈ＲＦＣ2953 Telnet加密:DES 64比特输出回馈ＲＦＣ2957 The 应用/whoispp-请求目录-类型ＲＦＣ2958 The 应用/whoispp-回答目录-类型ＲＦＣ2959 实时传输协议管理信息库ＲＦＣ2964 超文本传输协议(HTTP)状态管理的应用ＲＦＣ2971 Internet信息访问协议(IMAP4)的标识符扩展ＲＦＣ2976 SIP信息方法ＲＦＣ2983 有区别的协议和通道ＲＦＣ2984 CAST-128密码算法在CMS中的使用ＲＦＣ2987 字符集注册和语言媒体特征标签ＲＦＣ2988 计算TCP重传时间的定时器ＲＦＣ2991 多路径分发在Unicast上和多点传送下一路程段选择ＲＦＣ2992 等值多-路径算法的分析ＲＦＣ2994 MISTY1加密算法的描述。
【协议】AAARadius协议的常用报文分析
【协议】AAARadius协议的常⽤报⽂分析写在前⾯的话RADIUS：Remote Authentication Dial In User Service，远程⽤户拨号认证系统由RFC2865，RFC2866定义，是应⽤最⼴泛的AAA协议。
如下简单的分析⼀下 RADIUS 协议是怎么⼯作的。
名词解释BRAS：宽带接⼊服务器，Broadband Remote Access Server,简称 BRASNAS: ⽹络接⼊服务器，Network Access Server，简称 NASAAA: 认证 Authentication，授权 Authorization，计费 AccountingRADIUS: 远程认证拨号⽤户服务，remote authentication dial-in user service，简称RADIUS。
DM: Radius主动发起断开链接请求 Disconnect-Request，简称DMCOA: Radius主动发起修改授权属性，Change of Authorization，简称 COA报⽂说明Radius协议的报⽂协议0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Authenticator || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Attributes ...+-+-+-+-+-+-+-+-+-+-+-+-+-在报⽂中的表⽰如下所⽰：Radius 报⽂可以分为 Header 和 Attribute 两部分Radius 的头部代码定义// radius headertypedef struct RadHeader {iunsigned char code;unsigned char identifier;unsigned short length;unsigned char authcator[16];} RadHeader;Code 占⼀个字节常⽤的取值如下：1 Access-Request2 Access-Accept3 Access-Reject4 Accounting-Request5 Accounting-Response6 Accounting Status (now Interim Accounting [5])7 Password Request8 Password Ack9 Password Reject10 Accounting Message11 Access-Challenge12 Status-Server (experimental)13 Status-Client (experimental)21 Resource Free Request22 Resource Free Response23 Resource Query Request24 Resource Query Response25 Alternate Resource Reclaim Request26 NAS Reboot Request27 NAS Reboot Response29 Next Passcode30 New Pin31 Terminate Session32 Password Expired33 Event Request34 Event Response40 Disconnect Request41 Disconnect Ack42 Disconnect Nak43 Change Filters Request44 Change Filters Ack45 Change Filters Nak50 IP Address Allocate51 IP Address Release255 ReservedIdentifier是报⽂的流⽔号NAS 和 AAA 服务器通过这个流⽔号来标识认证请求和认证响应，计费请求和计费响应的配对关系。
Radius协议及实现
CHAP和PAP认证（续）
PAP认证
PAP（Password Authentication Protocol）：用 户以明文的形式把用户名和密码传递给接入服务器。 接入服务器根据用户名在接入服务器端查找数据库， 如果存在相同的用户名和密码表明验证通过，否则表 明验证未通过。
CHAP和PAP认证（续）
2
Radius三次握手认证(续)
1.
由NAS或者radius服务器产生随机码，通知客户端进行接入认证， 客户端根据id、用户密码、随机码进行MD5计算得出ChallengeResponse结果，送往NAS; Radius服务器接收到NAS发送来的Challenge-Response值之后，根 据数据包的用户名查找数据库，得到用户密码，然后从数据包中取 得id值，按照客户端同样的方法计算响应值，跟NAS发送来的响应 值进行比较，如果一致，则密码正确；同时Radius服务器根据请求 鉴别码和将要回应的数据包类容重新生成响应鉴别码，发送给NAS; NAS接收到Radius服务器发送来的响应数据包后，按照跟Radius服 务器相同的计算方法重新计算响应鉴别码值，然后跟Radius服务器 发送过来的值进行比较，如果一致，证明此数据包是客户端所需要 的响应包，通知客户端认证通过。
2.
3.
AAA介绍
AAA的定义 AAA是验证、授权和计费（Authentication, Authorization and Accounting）的简称。它是运行于 NAS上的客户端程序。它提供了一个用来对验证、授权和 计费这三种安全功能进行配置的一致的框架。AAA的配置 实际上是对网络安全的一种管理。这里的网络安全主要 是指访问控制。包括哪些用户可以访问网络服务器：具 有访问权的用户可以得到哪些服务：如何对正在使用网 络资源的用户进行计费。
AAA(认证、授权和记账)简介
AAA (认证、授权和记账)简介AAA服务器AAA是验证、授权和记账(Authentication、Authorization、Accounting )三个英文单词的简称。
其主要目的是管理哪些用户可以访问网络服务器，具有访问权的用户可以得到哪些服务，如何对正在使用网络资源的用户进行记账。
具体为：1、验证(Authentication):验证用户是否可以获得访问权限；2、授权(Authorization):授权用户可以使用哪些服务；3、记账(Accounting):记录用户使用网络资源的情况。
目前RADIUS (Remote Authentication Dial In User Service )协议是唯一的AAA 标准，在IETF 的RFC 2865和2866中定义的。
RADIUS是基于UDP的一种客户机/服务器协议。
RADIUS客户机是网络访问服务器，它通常是一个路由器、交换机或无线访问点。
RADIUS服务器通常是在UNIX或Windows 2000服务器上运行的一个监护程序。
RADIUS 协议的认证端口是1812 ,计费端口是1813。
RADIUS协议的主要特点概括的来说，RADIUS的主要特点如下：1、客户/服务模式(Client/Server)RADIUS是一种C/S结构的协议，它的客户端最初就是网络接入服务器NAS (Network Access Server)，现在运行在任何硬件上的RADIUS客户端软件都可以成为RADIUS的客户端。
客户端的任务是把用户信息(用户名，口令等)传递给指定的RADIUS服务器，并负责执行返回的响应。
RADIUS服务器负责接收用户的连接请求，对用户身份进行认证，并为客户端返回所有为用户提供服务所必须的配置信息。
一个RADIUS服务器可以为其他的RADIUS Server或其他种类认证服务器担当代理。
2、网络安全客户端和RADIUS服务器之间的交互经过了共享保密字的认证。
H3C-RADIUS配置
目录1 AAA配置1.1 AAA简介1.2 RADIUS协议简介1.2.1 客户端/服务器模式1.2.2 安全和认证机制1.2.3 RADIUS的基本消息交互流程1.2.4 RADIUS报文结构1.2.5 RADIUS扩展属性1.3 HWTACACS协议简介1.3.1 HWTACACS协议与RADIUS协议的区别1.3.2 HWTACACS的基本消息交互流程1.4 协议规范1.5 AAA配置任务简介1.6 配置AAA1.6.1 配置准备1.6.2 创建ISP域1.6.3 配置ISP域的属性1.6.4 配置ISP域的AAA认证方案1.6.5 配置ISP域的AAA授权方案1.6.6 配置ISP域的AAA计费方案1.6.7 配置本地用户的属性1.6.8 配置用户组的属性1.6.9 配置强制切断用户连接1.6.10 AAA显示与维护1.7 配置RADIUS1.7.1 创建RADIUS方案1.7.2 配置RADIUS认证/授权服务器1.7.3 配置RADIUS计费服务器及相关参数1.7.4 配置RADIUS报文的共享密钥1.7.5 配置RADIUS报文的超时重传次数最大值1.7.6 配置支持的RADIUS服务器的类型1.7.7 配置RADIUS服务器的状态1.7.8 配置发送给RADIUS服务器的数据相关属性1.7.9 配置RADIUS服务器的定时器1.7.10 配置RADIUS服务器的安全策略服务器1.7.11 使能RADIUS客户端的监听端口1.7.12 RADIUS显示和维护1.8 配置HWTACACS1.8.1 创建HWTACACS方案1.8.2 配置HWTACACS认证服务器1.8.3 配置HWTACACS授权服务器1.8.4 配置HWTACACS计费服务器1.8.5 配置HWTACACS报文的共享密钥1.8.6 配置发送给HWTACACS服务器的数据相关属性1.8.7 配置HWTACACS服务器的定时器1.8.8 HWTACACS显示和维护1.9 AAA典型配置举例1.9.1 Telnet/SSH用户通过RADIUS服务器认证、授权、计费的应用配置1.9.2 FTP/Telnet用户本地认证、授权、计费配置1.9.3 PPP用户通过HWTACACS服务器认证、授权、计费的应用配置1.10 AAA常见配置错误举例1.10.1 RADIUS认证/授权失败1.10.2 RADIUS报文传送失败1.10.3 RADIUS计费功能异常1.10.4 HWTACACS常见配置错误举例1 AAA配置1.1 AAA简介AAA是Authentication、Authorization、Accounting（认证、授权、计费）的简称，是网络安全的一种管理机制，提供了认证、授权、计费三种安全功能。
Rfc2866_Radius Accounting
Network Working Group C. Rigney Request for Comments: 2866 Livingston Category: Informational June 2000 Obsoletes: 2139RADIUS AccountingStatus of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved. AbstractThis document describes a protocol for carrying accountinginformation between a Network Access Server and a shared AccountingServer.Implementation NoteThis memo documents the RADIUS Accounting protocol. The earlydeployment of RADIUS Accounting was done using UDP port number 1646, which conflicts with the "sa-msg-port" service. The officiallyassigned port number for RADIUS Accounting is 1813.Table of Contents1. Introduction (2)1.1 Specification of Requirements (3)1.2 Terminology (3)2. Operation (4)2.1 Proxy (4)3. Packet Format (5)4. Packet Types (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 (15)Rigney Informational [Page 1]5.6 Acct-Authentic (16)5.7 Acct-Session-Time (17)5.8 Acct-Input-Packets (18)5.9 Acct-Output-Packets (18)5.10 Acct-Terminate-Cause (19)5.11 Acct-Multi-Session-Id (21)5.12 Acct-Link-Count (22)5.13 Table of Attributes (23)6. IANA Considerations (25)7. Security Considerations (25)8. Change Log (25)9. References (26)10. Acknowledgements (26)11. Chair’s Address (26)12. Author’s Address (27)13. Full Copyright Statement (28)1. IntroductionManaging dispersed serial line and modem pools for large numbers ofusers can create the need for significant administrative support.Since modem pools are by definition a link to the outside world, they require careful attention to security, authorization and accounting. This can be best achieved by managing a single "database" of users,which allows for authentication (verifying user name and password) as well as configuration information detailing the type of service todeliver to the user (for example, SLIP, PPP, telnet, rlogin).The RADIUS (Remote Authentication Dial In User Service) document [2] specifies the RADIUS protocol used for Authentication andAuthorization. This memo extends the use of the RADIUS protocol tocover delivery of accounting information from the Network AccessServer (NAS) to a RADIUS accounting server.This document obsoletes RFC 2139 [1]. A summary of the changesbetween this document and RFC 2139 is available in the "Change Log"appendix.Key features of RADIUS Accounting are:Client/Server ModelA Network Access Server (NAS) operates as a client of theRADIUS accounting server. The client is responsible forpassing user accounting information to a designated RADIUSaccounting server.Rigney Informational [Page 2]The RADIUS accounting server is responsible for receiving the accounting request and returning a response to the clientindicating that it has successfully received the request.The RADIUS accounting server can act as a proxy client toother kinds of accounting servers.Network SecurityTransactions between the client and RADIUS accounting serverare authenticated through the use of a shared secret, which is never sent over the network.Extensible ProtocolAll transactions are comprised of variable length Attribute-Length-Value 3-tuples. New attribute values can be addedwithout disturbing existing implementations of the protocol. 1.1. Specification of RequirementsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. Thesekey words mean the same thing whether capitalized or not.1.2. TerminologyThis document uses the following terms:service The NAS provides a service to the dial-in user, such as PPP or Telnet.session Each service provided by the NAS to a dial-in userconstitutes a session, with the beginning of the sessiondefined as the point where service is first provided andthe end of the session defined as the point where serviceis ended. A user may have multiple sessions in parallel or series if the NAS supports that, with each sessiongenerating a separate start and stop accounting record with its own Acct-Session-Id.silently discardThis means the implementation discards the packet withoutfurther processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.Rigney Informational [Page 3]2. OperationWhen a client is configured to use RADIUS Accounting, at the start of service delivery it will generate an Accounting Start packetdescribing the type of service being delivered and the user it isbeing delivered to, and will send that to the RADIUS Accountingserver, which will send back an acknowledgement that the packet hasbeen received. At the end of service delivery the client willgenerate an Accounting Stop packet describing the type of servicethat was delivered and optionally statistics such as elapsed time,input and output octets, or input and output packets. It will sendthat to the RADIUS Accounting server, which will send back anacknowledgement that the packet has been received.The Accounting-Request (whether for Start or Stop) is submitted tothe RADIUS accounting server via the network. It is recommended that the client continue attempting to send the Accounting-Request packet until it receives an acknowledgement, using some form of backoff. If no response is returned within a length of time, the request is re-sent a number of times. The client can also forward requests to analternate server or servers in the event that the primary server isdown or unreachable. An alternate server can be used either after a number of tries to the primary server fail, or in a round-robinfashion. Retry and fallback algorithms are the topic of currentresearch and are not specified in detail in this document.The RADIUS accounting server MAY make requests of other servers inorder to satisfy the request, in which case it acts as a client.If the RADIUS accounting server is unable to successfully record the accounting packet it MUST NOT send an Accounting-Responseacknowledgment to the client.2.1. ProxySee the "RADIUS" RFC [2] for information on Proxy RADIUS. ProxyAccounting RADIUS works the same way, as illustrated by the following example.1. The NAS sends an accounting-request to the forwarding server.2. The forwarding server logs the accounting-request (if desired), adds its Proxy-State (if desired) after any other Proxy-Stateattributes, updates the Request Authenticator, and forwards the request to the remote server.Rigney Informational [Page 4]3. The remote server logs the accounting-request (if desired),copies all Proxy-State attributes in order and unmodified from the request to the response packet, and sends the accounting-response to the forwarding server.4. The forwarding server strips the last Proxy-State (if it added one in step 2), updates the Response Authenticator and sendsthe accounting-response to the NAS.A forwarding server MUST not modify existing Proxy-State or Classattributes present in the packet.A forwarding server may either perform its forwarding function in apass through manner, where it sends retransmissions on as soon as it gets them, or it may take responsibility for retransmissions, forexample in cases where the network link between forwarding and remote server has very different characteristics than the link between NASand forwarding server.Extreme care should be used when implementing a proxy server thattakes responsibility for retransmissions so that its retransmissionpolicy is robust and scalable.3. Packet FormatExactly one RADIUS Accounting packet is encapsulated in the UDP Data field [4], where the UDP Destination Port field indicates 1813(decimal).When a reply is generated, the source and destination ports arereversed.This memo documents the RADIUS Accounting protocol. The earlydeployment of RADIUS Accounting was done using UDP port number 1646, which conflicts with the "sa-msg-port" service. The officiallyassigned port number for RADIUS Accounting is 1813.A summary of the RADIUS data format is shown below. The fields aretransmitted from left to right.Rigney Informational [Page 5]0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Authenticator || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Attributes ...+-+-+-+-+-+-+-+-+-+-+-+-+-CodeThe Code field is one octet, and identifies the type of RADIUSpacket. When a packet is received with an invalid Code field, it is silently discarded.RADIUS Accounting Codes (decimal) are assigned as follows:4 Accounting-Request5 Accounting-ResponseIdentifierThe Identifier field is one octet, and aids in matching requestsand replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port andIdentifier within a short span of time.LengthThe Length field is two octets. It indicates the length of thepacket including the Code, Identifier, Length, Authenticator andAttribute fields. Octets outside the range of the Length fieldMUST be treated as padding and ignored on reception. If thepacket is shorter than the Length field indicates, it MUST besilently discarded. The minimum length is 20 and maximum lengthis 4095.AuthenticatorThe Authenticator field is sixteen (16) octets. The mostsignificant octet is transmitted first. This value is used toauthenticate the messages between the client and RADIUS accounting server.Rigney Informational [Page 6]Request AuthenticatorIn Accounting-Request Packets, the Authenticator value is a 16octet MD5 [5] checksum, called the Request Authenticator.The NAS and RADIUS accounting server share a secret. The Request Authenticator field in Accounting-Request packets contains a one- way MD5 hash calculated over a stream of octets consisting of the Code + Identifier + Length + 16 zero octets + request attributes + shared secret (where + indicates concatenation). The 16 octet MD5 hash value is stored in the Authenticator field of theAccounting-Request packet.Note that the Request Authenticator of an Accounting-Request cannot be done the same way as the Request Authenticator of a RADIUS Access-Request, because there is no User-Password attribute in an Accounting-Request.Response AuthenticatorThe Authenticator field in an Accounting-Response packet is called the Response Authenticator, and contains a one-way MD5 hashcalculated over a stream of octets consisting of the Accounting-Response Code, Identifier, Length, the Request Authenticator field from the Accounting-Request packet being replied to, and theresponse attributes if any, followed by the shared secret. Theresulting 16 octet MD5 hash value is stored in the Authenticatorfield of the Accounting-Response packet.AttributesAttributes may have multiple instances, in such a case the orderof attributes of the same type SHOULD be preserved. The order of attributes of different types is not required to be preserved.4. Packet TypesThe RADIUS packet type is determined by the Code field in the firstoctet of the packet.Rigney Informational [Page 7]4.1. Accounting-RequestDescriptionAccounting-Request packets are sent from a client (typically aNetwork Access Server or its proxy) to a RADIUS accounting server, and convey information used to provide accounting for a serviceprovided to a user. The client transmits a RADIUS packet with the Code field set to 4 (Accounting-Request).Upon receipt of an Accounting-Request, the server MUST transmit an Accounting-Response reply if it successfully records theaccounting packet, and MUST NOT transmit any reply if it fails to record the accounting packet.Any attribute valid in a RADIUS Access-Request or Access-Acceptpacket is valid in a RADIUS Accounting-Request packet, except that the following attributes MUST NOT be present in an Accounting-Request: User-Password, CHAP-Password, Reply-Message, State.Either NAS-IP-Address or NAS-Identifier MUST be present in aRADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-Port-Type attribute or both unless the service does not involve a port or the NAS does not distinguish among its ports.If the Accounting-Request packet includes a Framed-IP-Address,that attribute MUST contain the IP address of the user. If theAccess-Accept used the special values for Framed-IP-Addresstelling the NAS to assign or negotiate an IP address for the user, the Framed-IP-Address (if any) in the Accounting-Request MUSTcontain the actual IP address assigned or negotiated.A summary of the Accounting-Request packet format is shown below.The fields are transmitted from left to right.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Request Authenticator || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Attributes ...+-+-+-+-+-+-+-+-+-+-+-+-+-Rigney Informational [Page 8]Code4 for Accounting-Request.IdentifierThe Identifier field MUST be changed whenever the content of theAttributes field changes, and whenever a valid reply has beenreceived for a previous request. For retransmissions where thecontents are identical, the Identifier MUST remain unchanged.Note that if Acct-Delay-Time is included in the attributes of anAccounting-Request then the Acct-Delay-Time value will be updatedwhen the packet is retransmitted, changing the content of theAttributes field and requiring a new Identifier and RequestAuthenticator.Request AuthenticatorThe Request Authenticator of an Accounting-Request contains a 16-octet MD5 hash value calculated according to the method described in"Request Authenticator" above.AttributesThe Attributes field is variable in length, and contains a list ofAttributes.4.2. Accounting-ResponseDescriptionAccounting-Response packets are sent by the RADIUS accountingserver to the client to acknowledge that the Accounting-Requesthas been received and recorded successfully. If the Accounting-Request was recorded successfully then the RADIUS accountingserver MUST transmit a packet with the Code field set to 5(Accounting-Response). On reception of an Accounting-Response bythe client, the Identifier field is matched with a pendingAccounting-Request. The Response Authenticator field MUST containthe correct response for the pending Accounting-Request. Invalidpackets are silently discarded.A RADIUS Accounting-Response is not required to have anyattributes in it.A summary of the Accounting-Response packet format is shown below.The fields are transmitted from left to right.Rigney Informational [Page 9]0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Response Authenticator || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Attributes ...+-+-+-+-+-+-+-+-+-+-+-+-+-Code5 for Accounting-Response.IdentifierThe Identifier field is a copy of the Identifier field of theAccounting-Request which caused this Accounting-Response.Response AuthenticatorThe Response Authenticator of an Accounting-Response contains a16-octet MD5 hash value calculated according to the methoddescribed in "Response Authenticator" above.AttributesThe Attributes field is variable in length, and contains a list of zero or more Attributes.5. AttributesRADIUS Attributes carry the specific authentication, authorizationand accounting details for the request and response.Some attributes MAY be included more than once. The effect of thisis attribute specific, and is specified in each attributedescription.The end of the list of attributes is indicated by the Length of theRADIUS packet.A summary of the attribute format is shown below. The fields aretransmitted from left to right.Rigney Informational [Page 10]0 1 20 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Value ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TypeThe Type field is one octet. Up-to-date values of the RADIUS Type field are specified in the most recent "Assigned Numbers" RFC [6]. Values 192-223 are reserved for experimental use, values 224-240are reserved for implementation-specific use, and values 241-255are reserved and should not be used. This specification concerns the following values:1-39 (refer to RADIUS document [2])40 Acct-Status-Type41 Acct-Delay-Time42 Acct-Input-Octets43 Acct-Output-Octets44 Acct-Session-Id45 Acct-Authentic46 Acct-Session-Time47 Acct-Input-Packets48 Acct-Output-Packets49 Acct-Terminate-Cause50 Acct-Multi-Session-Id51 Acct-Link-Count60+ (refer to RADIUS document [2])LengthThe Length field is one octet, and indicates the length of thisattribute including the Type, Length and Value fields. If anattribute is received in an Accounting-Request with an invalidLength, the entire request MUST be silently discarded.ValueThe Value field is zero or more octets and contains informationspecific to the attribute. The format and length of the Valuefield is determined by the Type and Length fields.Note that none of the types in RADIUS terminate with a NUL (hex00). In particular, types "text" and "string" in RADIUS do notterminate with a NUL (hex 00). The Attribute has a length fieldand does not use a terminator. Text contains UTF-8 encoded 10646 Rigney Informational [Page 11][7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls.RADIUS implementers using C are cautioned not to use strcpy() when handling strings.The format of the value field is one of five data types. Notethat type "text" is a subset of type "string."text 1-253 octets containing UTF-8 encoded 10646 [7]characters. Text of length zero (0) MUST NOT be sent;omit the entire attribute instead.string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead.address 32 bit value, most significant octet first.integer 32 bit unsigned value, most significant octet first.time 32 bit unsigned value, most significant octet first --seconds since 00:00:00 UTC, January 1, 1970. Thestandard Attributes do not use this data type but it ispresented here for possible use in future attributes.5.1. Acct-Status-TypeDescriptionThis attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop).It MAY be used by the client to mark the start of accounting (for example, upon booting) by specifying Accounting-On and to mark the end of accounting (for example, just before a scheduled reboot) by specifying Accounting-Off.A summary of the Acct-Status-Type attribute format is shown below.The fields are transmitted from left to right.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Value (cont) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Rigney Informational [Page 12]Type40 for Acct-Status-Type.Length6ValueThe Value field is four octets.1 Start2 Stop3 Interim-Update7 Accounting-On8 Accounting-Off9-14 Reserved for Tunnel Accounting15 Reserved for Failed5.2. Acct-Delay-TimeDescriptionThis attribute indicates how many seconds the client has beentrying to send this record for, and can be subtracted from thetime of arrival on the server to find the approximate time of the event generating this Accounting-Request. (Network transit timeis ignored.)Note that changing the Acct-Delay-Time causes the Identifier tochange; see the discussion under Identifier above.A summary of the Acct-Delay-Time attribute format is shown below.The fields are transmitted from left to right.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Value (cont) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Rigney Informational [Page 13]Type41 for Acct-Delay-Time.Length6ValueThe Value field is four octets.5.3. Acct-Input-OctetsDescriptionThis attribute indicates how many octets have been received fromthe port over the course of this service being provided, and canonly be present in Accounting-Request records where the Acct-Status-Type is set to Stop.A summary of the Acct-Input-Octets attribute format is shown below.The fields are transmitted from left to right.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Value (cont) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type42 for Acct-Input-Octets.Length6ValueThe Value field is four octets.Rigney Informational [Page 14]5.4. Acct-Output-OctetsDescriptionThis attribute indicates how many octets have been sent to theport in the course of delivering this service, and can only bepresent in Accounting-Request records where the Acct-Status-Typeis set to Stop.A summary of the Acct-Output-Octets attribute format is shown below. The fields are transmitted from left to right.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Value (cont) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type43 for Acct-Output-Octets.Length6ValueThe Value field is four octets.5.5. Acct-Session-IdDescriptionThis attribute is a unique Accounting ID to make it easy to match start and stop records in a log file. The start and stop records for a given session MUST have the same Acct-Session-Id. AnAccounting-Request packet MUST have an Acct-Session-Id. AnAccess-Request packet MAY have an Acct-Session-Id; if it does,then the NAS MUST use the same Acct-Session-Id in the Accounting- Request packets for that session.The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7]characters.Rigney Informational [Page 15]For example, one implementation uses a string with an 8-digitupper case hexadecimal number, the first two digits increment oneach reboot (wrapping every 256 reboots) and the next 6 digitscounting from 0 for the first person logging in after a reboot up to 2^24-1, about 16 million. Other encodings are possible.A summary of the Acct-Session-Id attribute format is shown below.The fields are transmitted from left to right.0 1 20 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Text ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type44 for Acct-Session-Id.Length>= 3StringThe String field SHOULD be a string of UTF-8 encoded 10646 [7]characters.5.6. Acct-AuthenticDescriptionThis attribute MAY be included in an Accounting-Request toindicate how the user was authenticated, whether by RADIUS, theNAS itself, or another remote authentication protocol. Users who are delivered service without being authenticated SHOULD NOTgenerate Accounting records.A summary of the Acct-Authentic attribute format is shown below. The fields are transmitted from left to right.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Value (cont) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Rigney Informational [Page 16]Type45 for Acct-Authentic.Length6ValueThe Value field is four octets.1 RADIUS2 Local3 Remote5.7. Acct-Session-TimeDescriptionThis attribute indicates how many seconds the user has receivedservice for, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop.A summary of the Acct-Session-Time attribute format is shown below.The fields are transmitted from left to right.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Value (cont) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type46 for Acct-Session-Time.Length6ValueThe Value field is four octets.Rigney Informational [Page 17]5.8. Acct-Input-PacketsDescriptionThis attribute indicates how many packets have been received from the port over the course of this service being provided to aFramed User, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop.A summary of the Acct-Input-packets attribute format is shown below. The fields are transmitted from left to right.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Value (cont) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type47 for Acct-Input-Packets.Length6ValueThe Value field is four octets.5.9. Acct-Output-PacketsDescriptionThis attribute indicates how many packets have been sent to theport in the course of delivering this service to a Framed User,and can only be present in Accounting-Request records where theAcct-Status-Type is set to Stop.A summary of the Acct-Output-Packets attribute format is shown below. The fields are transmitted from left to right.Rigney Informational [Page 18]。
RADIUS协议原理及应用
(reserved for accounting)
60
CHAP盘问
CHAP-Challenge
61
网络接入服务器端口类型 NAS-Port-Type
62
端口数限制
Port-Limit
63
登录的LAT端口
Login-LAT-Port
NAS设备RADIUS部分配置
NAS设备RADIUS部分配置，S21和S35系列交换机为例
下面从恳请者发起认证――认证成功――退出认证的整个过 程中，通过SNIFFER软件抓取到的报文对每个过程作详细分析；
RADIUS系统下用户认证过程
RADIUS系统下用户认证过程
RADIUS系统下用户认证过程
RADIUS系统下用户认证过程
RADIUS系统下用户认证过程
RADIUS系统下用户认证过程
User-Name User-Password CHAP-Password NAS-IP-Address NAS-Port Service-Type Framed-Protocol Framed-IP-Address Framed-IP-Netmask Framed-Routing Filter-Id Framed-MTU Framed-Compression Login-IP-Host Login-Service Login-TCP-Port (unassigned) Reply-Message Callback-Number Callback-Id (unassigned) Framed-Route
23
IPX网络数字配置
Framed-IPX-Network
24
状态
State
25
类别
radius协议详解
radius协议详解竭诚为您提供优质文档/双击可除radius协议详解篇一：Radius远程用户拨号认证系统详解Radius远程用户拨号认证系统Radius：Remoteauthenticationdialinuserservice，远程用户拨号认证系统由RFc2865，RFc2866定义，是目前应用最广泛的（aaa是authentication（认证）、authorization（授权）和accounting（计费）的简称）基本概念aaaauthentication、authorization、accounting验证、授权、记费pappasswordauthenticationprotocol口令验证协议chapchallenge-handshakeauthenticationprotocol盘问握手验证协议nasnetworkaccessserver网络接入服务器RadiusRemoteauthenticationdialinuserservice远程验证拨入用户服务（拨入用户的远程验证服务）tcptransmissioncontrolprotocol传输控制协议udpuserdatagramprotocol用户数据报协议aaa实现途径1.在网络接入服务器nas端：在nas端进行认证、授权和计费；2.通过协议进行远程的认证、授权和记帐。
实现aaa的协议有RadiusRadius是Remoteauthenticationdialinuserservice的简称，ma5200、isn8850和md5500上目前使用Radius完成对ppp用户的认证、授权和计费。
当用户想要通过某个网络(如电话网)与nas建立连接从而获得访问其他网络的权利时，nas可以选择在nas上进行本地认证计费，或把用户信息传递给Radius服务器，由Radius进行认证计费；Radius协议规定了nas与Radius服务器之间如何传递用户信息和记账信息；Radius服务器负责接收用户的连接请求，完成验证，并把传递服务给用户所需的配置信息返回给nas。
ROS认证系统
ROS认证系统ROS认证系统ROS认证系统用哪一个好，Radius Manager还是成都网大的NAT RadiusNAT Radius主体功能描述：1、支持标准Radius：RFC2865、RFC2866、RFC2759，可以为市场上的大多数标准Radius方式计费BRAS设备进行计费支持。
2、支持多种客户端登录加密帐号验证方式：PAP,CHAP,MSCHAPv1,MSCHAPv2.3、实现用户到期后PPPOE不停止服务，用户直接强转到到期通知页面告知用户4、试用安全的C/S架构，通知加密链路传递数据，为客户安全的经行远程管理提供了可靠支撑。
并可对管理员的远程登录IP进行抵制的限制，避免恶意的登录破解。
5、客户计费方式灵活，可以试用包月、包年、手动定义任意时间段、分时间段的流量/时长计费，也可以通过管理员定义一个任意长度的时间作为套餐进行计费。
6、同时支持多台NAS的计费请求，如果需要针对远程计费，可以将远程NAS设置为域名，同样可以进行安全的计费。
7、后台服务监测功能，管理工具运行时自动监测后台服务运行，避免后台服务死机造成的客户故障。
8、完善的充值卡功能配合WEB客户自动itng，为客户自助充值提供了便利。
9、详细的收款，充值日志明细，和用户使用费清单，为财务清查、故障分析提供了便利。
并针对充值日志即时生成报表、图形，可以更容易分析出客户充值变化。
10、灵活的分级区域控制，可以为用户设置区域，并按分级区域进行组用户管理，为管理员设置起限制查看的区域用户信息。
11、管理工具运行中定时监测即将到期客户情况，并对管理员做出提示细度的权限分配，为系统数据的安全提供保障。
NAT Radius特点：· 支持标准Radius协议，为主要优化RouterOS的认证系统；·基于windows平台，安装快捷、操作简易、方便实用；·设置快捷，1分钟完成Radius计费系统配置；·采用MySQL数据库，效率更高；·支持Hotspot、PPTP、L2TP和PPPOE等认证；·支持多重计费方式包月、包年、计时、流量计费、自定义时间计费、扩展计费、免费用户等；·支持分时计价功能；·支持log日志管理和现金管理日志；·客户登录web自助管理功能和向管理员自动提醒到期用户功能；·提供子帐号管理功能；·Radius系统管理分级和审批功能·支持RouterOS的simple queue、Interim Update、Incoming port、Call ID、Hotspot profile、ip pool、address-list等属性系统要求：·Microsotf .NET Framework 3.0以上版本·安装MYSQL数据库插件·仅支持操作系统Windows xp、Windows2003、Windows vista、Windows2008、Windows7（建议采用Windows2003或者2008）·支持Windows 32位操作系统硬件要求：·Pentium 4以上处理器·至少1G内存·160G以上硬盘（日志存储）·1个以太网口。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group G. Zorn Request for Comments: 2867 Cisco Systems, Inc. Category: Informational B. Aboba Updates: 2866 Microsoft Corporation D. Mitton Nortel Networks June 2000 RADIUS Accounting Modifications for Tunnel Protocol SupportStatus of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved.AbstractThis document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to supportthe provision of compulsory tunneling in dial-up networks.Specification of RequirementsIn this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted asdescribed in [2].1. IntroductionMany applications of tunneling protocols such as PPTP [5] and L2TP[4] involve dial-up network access. Some, such as the provision ofsecure access to corporate intranets via the Internet, arecharacterized by voluntary tunneling: the tunnel is created at therequest of the user for a specific purpose. Other applicationsinvolve compulsory tunneling: the tunnel is created without anyaction from the user and without allowing the user any choice in the matter, as a service of the Internet service provider (ISP).Typically, ISPs providing a service want to collect data regardingthat service for billing, network planning, etc. One way to collect usage data in dial-up networks is by means of RADIUS Accounting [1]. The use of RADIUS Accounting allows dial-up usage data to becollected at a central location, rather than stored on each NAS. Zorn, et al. Informational [Page 1]In order to collect usage data regarding tunneling, new RADIUSattributes are needed; this document defines these attributes. Inaddition, several new values for the Acct-Status-Type attribute areproposed. Specific recommendations for, and examples of, theapplication of this attribute for the L2TP protocol can be found inRFC 2809.2. Implementation NotesCompulsory tunneling may be part of a package of services provided by one entity to another. For example, a corporation might contractwith an ISP to provide remote intranet access to its employees viacompulsory tunneling. In this case, the integration of RADIUS andtunnel protocols allows the ISP and the corporation to synchronizetheir accounting activities so that each side receives a record ofthe user’s resource consumption. This provides the corporation with the means to audit ISP bills.In auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes are typically used to uniquely identify the call, allowing the Accounting-Request sent bythe NAS to be reconciled with the corresponding Accounting-Requestsent by the tunnel server.When implementing RADIUS accounting for L2TP/PPTP tunneling, theCall-Serial-Number SHOULD be used in the Acct-Tunnel-Connectionattribute. In L2TP, the Call-Serial-Number is a 32-bit field and in PPTP it is a 16-bit field. In PPTP the combination of IP Address and Call-Serial-Number SHOULD be unique, but this is not required. Inaddition, no method for determining the Call-Serial-Number isspecified, which leaves open the possibility of wrapping after areboot.Note that a 16-bit Call-Serial-Number is not sufficient todistinguish a given call from all other calls over an extended timeperiod. For example, if the Call-Serial-Number is assignedmonotonically, the NAS in question has 96 ports which are continually busy and the average call is of 20 minutes duration, then a 16-bitCall-Serial-Number will wrap within 65536/(96 * 3 calls/hour * 24hours/day) = 9.48 days.3. New Acct-Status-Type Values3.1. Tunnel-StartValue9Zorn, et al. Informational [Page 2]DescriptionThis value MAY be used to mark the establishment of a tunnelwith another node. If this value is used, the followingattributes SHOULD also be included in the Accounting-Requestpacket:User-Name (1)NAS-IP-Address (4)Acct-Delay-Time (41)Event-Timestamp (55)Tunnel-Type (64)Tunnel-Medium-Type (65)Tunnel-Client-Endpoint (66)Tunnel-Server-Endpoint (67)Acct-Tunnel-Connection (68)3.2. Tunnel-StopValue10DescriptionThis value MAY be used to mark the destruction of a tunnel toor from another node. If this value is used, the followingattributes SHOULD also be included in the Accounting-Requestpacket:User-Name (1)NAS-IP-Address (4)Acct-Delay-Time (41)Acct-Input-Octets (42)Acct-Output-Octets (43)Acct-Session-Id (44)Acct-Session-Time (46)Acct-Input-Packets (47)Acct-Output-Packets (48)Acct-Terminate-Cause (49)Acct-Multi-Session-Id (51)Event-Timestamp (55)Tunnel-Type (64)Tunnel-Medium-Type (65)Tunnel-Client-Endpoint (66)Tunnel-Server-Endpoint (67)Acct-Tunnel-Connection (68)Acct-Tunnel-Packets-Lost (86)Zorn, et al. Informational [Page 3]3.3. Tunnel-RejectValue11DescriptionThis value MAY be used to mark the rejection of theestablishment of a tunnel with another node. If this value is used, the following attributes SHOULD also be included in theAccounting-Request packet:User-Name (1)NAS-IP-Address (4)Acct-Delay-Time (41)Acct-Terminate-Cause (49)Event-Timestamp (55)Tunnel-Type (64)Tunnel-Medium-Type (65)Tunnel-Client-Endpoint (66)Tunnel-Server-Endpoint (67)Acct-Tunnel-Connection (68)3.4. Tunnel-Link-StartValue12DescriptionThis value MAY be used to mark the creation of a tunnel link.Only some tunnel types (e.g., L2TP) support multiple links per tunnel. This Attribute is intended to mark the creation of alink within a tunnel that carries multiple links. For example, if a mandatory tunnel were to carry M links over its lifetime, 2(M+1) RADIUS Accounting messages might be sent: one eachmarking the initiation and destruction of the tunnel itself and one each for the initiation and destruction of each link within the tunnel. If only a single link can be carried in a giventunnel (e.g., IPsec in the tunnel mode), this Attribute neednot be included in accounting packets, since the presence ofthe Tunnel-Start Attribute will imply the initiation of the(only possible) link.Zorn, et al. Informational [Page 4]If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet:User-Name (1)NAS-IP-Address (4)NAS-Port (5)Acct-Delay-Time (41)Event-Timestamp (55)Tunnel-Type (64)Tunnel-Medium-Type (65)Tunnel-Client-Endpoint (66)Tunnel-Server-Endpoint (67)Acct-Tunnel-Connection (68)3.5. Tunnel-Link-StopValue13DescriptionThis value MAY be used to mark the destruction of a tunnellink. Only some tunnel types (e.g., L2TP) support multiplelinks per tunnel. This Attribute is intended to mark thedestruction of a link within a tunnel that carries multiplelinks. For example, if a mandatory tunnel were to carry Mlinks over its lifetime, 2(M+1) RADIUS Accounting messagesmight be sent: one each marking the initiation and destruction of the tunnel itself and one each for the initiation anddestruction of each link within the tunnel. If only a singlelink can be carried in a given tunnel (e.g., IPsec in thetunnel mode), this Attribute need not be included in accounting packets, since the presence of the Tunnel-Stop Attribute willimply the termination of the (only possible) link.If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet:User-Name (1)NAS-IP-Address (4)NAS-Port (5)Acct-Delay-Time (41)Acct-Input-Octets (42)Acct-Output-Octets (43)Acct-Session-Id (44)Acct-Session-Time (46)Acct-Input-Packets (47)Zorn, et al. Informational [Page 5]Acct-Output-Packets (48)Acct-Terminate-Cause (49)Acct-Multi-Session-Id (51)Event-Timestamp (55)NAS-Port-Type (61)Tunnel-Type (64)Tunnel-Medium-Type (65)Tunnel-Client-Endpoint (66)Tunnel-Server-Endpoint (67)Acct-Tunnel-Connection (68)Acct-Tunnel-Packets-Lost (86)3.6. Tunnel-Link-RejectValue14DescriptionThis value MAY be used to mark the rejection of theestablishment of a new link in an existing tunnel. Only sometunnel types (e.g., L2TP) support multiple links per tunnel.If only a single link can be carried in a given tunnel (e.g.,IPsec in the tunnel mode), this Attribute need not be included in accounting packets, since in this case the Tunnel-RejectAttribute has the same meaning.If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet:User-Name (1)NAS-IP-Address (4)Acct-Delay-Time (41)Acct-Terminate-Cause (49)Event-Timestamp (55)Tunnel-Type (64)Tunnel-Medium-Type (65)Tunnel-Client-Endpoint (66)Tunnel-Server-Endpoint (67)Acct-Tunnel-Connection (68)Zorn, et al. Informational [Page 6]4. Attributes4.1. Acct-Tunnel-ConnectionDescriptionThis Attribute indicates the identifier assigned to the tunnel session. It SHOULD be included in Accounting-Request packetswhich contain an Acct-Status-Type attribute having the valueStart, Stop or any of the values described above. Thisattribute, along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [3], may be used to provide a means to uniquely identify a tunnel session for auditing purposes.A summary of the Acct-Tunnel-Connection Attribute format is shown below. The fields are transmitted from left to right.0 1 20 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | String ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type68 for Acct-Tunnel-ConnectionLength>= 3StringThe format of the identifier represented by the String fielddepends upon the value of the Tunnel-Type attribute [3]. Forexample, to fully identify an L2TP tunnel connection, the L2TP Tunnel ID and Call ID might be encoded in this field. Theexact encoding of this field is implementation dependent.4.2. Acct-Tunnel-Packets-LostDescriptionThis Attribute indicates the number of packets lost on a given link. It SHOULD be included in Accounting-Request packetswhich contain an Acct-Status-Type attribute having the valueTunnel-Link-Stop.Zorn, et al. Informational [Page 7]A summary of the Acct-Tunnel-Packets-Lost Attribute format isshown below. The fields are transmitted from left to right.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Lost+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lost (cont) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type86 for Acct-Tunnel-Packets-LostLength6LostThe Lost field is 4 octets in length and represents the number of packets lost on the link.5. Table of AttributesThe following table provides a guide to which attributes may be found in Accounting-Request packets. No tunnel attributes should be found in Accounting-Response packets.Request # Attribute0-1 64 Tunnel-Type0-1 65 Tunnel-Medium-Type0-1 66 Tunnel-Client-Endpoint0-1 67 Tunnel-Server-Endpoint0-1 68 Acct-Tunnel-Connection0 69 Tunnel-Password0-1 81 Tunnel-Private-Group-ID0-1 82 Tunnel-Assignment-ID0 83 Tunnel-Preference0-1 86 Acct-Tunnel-Packets-LostZorn, et al. Informational [Page 8]The following table defines the meaning of the above table entries.0 This attribute MUST NOT be present in packet.0+ Zero or more instances of this attribute MAY be present inpacket.0-1 Zero or one instance of this attribute MAY be present inpacket.6. Security ConsiderationsBy "sniffing" RADIUS Accounting packets, it might be possible for an eavesdropper to perform a passive analysis of tunnel connections.7. References[1] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. andI. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.[4] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. andB. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,August 1999.[5] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. andG. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.8. AcknowledgmentsThanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall for salient input and review.Zorn, et al. Informational [Page 9]9. Authors’ AddressesQuestions about this memo can be directed to:Glen ZornCisco Systems, Inc.500 108th Avenue N.E., Suite 500Bellevue, Washington 98004USAPhone: +1 425 438 8218FAX: +1 425 438 1848EMail: gwz@Dave MittonNortel Networks880 Technology Park DriveBillerica, MA 01821Phone: +1 978 288 4570Fax: +1 978 288 3030EMail: dmitton@Bernard AbobaMicrosoft CorporationOne Microsoft WayRedmond, Washington 98052Phone: +1 425 936 6605Fax: +1 425 936 7329EMail: aboba@Zorn, et al. Informational [Page 10]RFC 2867 RADIUS Tunnel Accounting Support June 2000 10. Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Zorn, et al. Informational [Page 11]。