rfc2882.txt

很多RFC的中文文档

	多个Reply-Message。一个Echo属性应该通过菜单的响应来控制响应行为。用State属性
	来明了Challenge序列也是一种标准行为。
	
	另一种实现是用两个厂商定义的属性（VSA-Menu-Item, VSA-Menu-Selector）来传递
	这些信息。这种实现是厂商特有的。
	
5.4	虚拟用户

	一种客户端将RADIUS服务器的能力优势，将它用做一台远端的数据库服务器。通过用一些
	周知的、特定的用户名和密码，NAS可以从服务器获取一些特定的信息：静态IP路由、静态
	IPX路由、或者是如期等。
	
	这叫做虚拟用户，因为它们是使用一个构造的用户名，获取非认证的其它信息。
	
	另一种客户端也使用虚拟客户技术来解决未知的Filter-ID的值。将一个Access-Request
	报文－－－－将Filter-ID设为用户名，用周知的密码，设置Service-Type为VSE-Authorization-Only
	－－－发送到RADIUS服务器。响应报文中Service-Type值必需相同，否则会被丢弃。
	响应报文中必需包含IP-Filter属性（该属性是一个VSA属性），该属性定义了过滤法。
	
	必需注意的如果没有将一个特定的或者是可操作的有效的Service-Type绑定到虚拟用户的profile,
	则虚拟用户的profile会有安全问题。客户端必需测试这个返回值，以防止普通的拨号用户
	通过这个profile接入。
	
6.	资源管理
	
	为了提供服务，认证会话可能还需要分配其它的动态资源。最典型的就是IP地址。这种
	分配可以在一个独立于RADIUS服务器的层次上被延迟，直到有需要或者类似的需求为止。
	可能使用其它的一些消息去分配或者释放这些资源。RADIUS服务器可以代理将这个需求
	转发给其它的服务器。
	
	示例：一些服务器能分配本地的地址给NAS或者是使用外部的地址服务器。另外一些服务
	器有本地的地址池，通过选择分配一个地址，填入Framed-IP-Address属性。

6.1	被管理的资源

	被管理的资源包括：IP地址，并行登陆，拨号端口分配策略，隧道限定和均衡负载
	（load distribution）。
	
	有几种不同的实现技术：
	
	    - Explicit request/free resource requests
	    - Monitor usage with deamons watching the state
	    - Explicit messages to a state deamon
	    - Monitor Accounting messages for state changes
	    
6.2	资源管理消息
	
	用于资源管理的消息：

	    - IP Address Allocate
	    - IP Address Release
	
	    - Resource Request
	    - Resource Response
	    - Resource Free Request
	    - Resource Free Response
	    - Resource Reclaim Request
	    - NAS Reboot Request/Response
	    
	这些消息用于为NAS从一个集中的服务器分配/释放资源。这些方案允许业务提供者
	（service provider）能有比那些自动的LAN业务（它们是没有输入策略或者管理的）
	有着更好的管理。
	
6.3	并行登陆（Concurrent Login）

	遵照RADIUS协议的服务器是没有状态的。这就是说，服务器不知道每个会话的状态。
	但是，对于很多服务提供商来说，它们有必要跟踪一个用户打开了多少个会话，这样
	可以禁止一些非法接入。
	
	
	在RADIUS环境中有几种不同的技术可以实现限制接入数。一些厂商已经开发出一些
	工具，这些工具能利用SNMP协议或者是其它的方法检查会话的状态。
	
	而另一些厂商则是通过分离接入或者是记账请求中的状态信息来监视RADIUS的接入和
	记账消息。这些监视没有直接查询NAS可靠，但是它较少的依赖于特定的厂商。倘若它
	发送所有的流到同一个服务器，那它能与任何RADIUS NAS工作。
	
	目前使用的几种方法：
	
	    - SNMP commands
	    - Telnet monitor deamon
	    - Accounting monitor
	
6.4	授权修改
	
	如果需要实现动态修改一个在线的会话，例如修改过滤器（filter）或者是超时切断，
	那么厂商至少还需要一个类似于RADIUS的服务器，该服务器接收网络上的应用程序
	发出的消息，匹配会话，然后执行相应的动作。
	
	从服务器发给NAS的消息：
	    - Change Filter Request
	    - Change Filter Ack / Nak
	    - Disconnect Request
	    - Disconnect Response

	过滤器通过限制用户发送报文的系统和协议来限制用户的接入。通过在一个授权服务器
	上完成一些注册，业务提供者可以移去这些限制，或者是掐断一个用户。
	
7.	策略服务
	
	一些厂商通过把RADIUS作为控制协议，实现了策略服务器。	两个明显的策略管理者作为
	一个RADIUS代理过滤器，使用RADIUS消息，拒绝那些超出了当前策略限制的接入。
	
	一种实现实现就象一个RADIUS代理服务器，但是通过一个策略进程管理下一步的决定。最
	典型的就是当一个呼叫到达时，NAS在发出认证消息前发出一个其它的消息（例如想在最新
	的草案中的Service-Type = CallCheck )。该消息只在用户名域包含呼叫号的信息。服
	务器收到这个Access-Request消息后，通过它所知道的网络状态和预备的策略处理该报文。
	
	接收这个呼叫后，一个Access-Accept报文被返回给系统，同时还包含一些动态的策略信息
	以及特定的虚拟POP缺省参数（Virtual POP specific default parameters）。当一
	个真正的ppp认证消息到达后，代理将该报文转发给RADIUS服务器。这个过程可以看做是
	一个认证预处理过程。它也可以处理没有这种预处理的接入请求，而用用户名域获得它想要
	获得的用于策略评估的信息。
	
	其它的实现也有类似的操作。不同的是他不是用预认证消息，而是在Access-Request中使用
	VSA。
	
8.	记账扩展

	通常记账只记录会话的开始和结束，这个感觉挺烦的。当相关操作发生时，为了给出一个更好的
	描述而额外上报一些其它的信息是很容易的事。
	
8.1	审核/行为（Auditing/Activity）
	
	    - Call or Modem Starts, Stops
	    - Tunnel Starts, Stops
	    - Tunnel Link Starts & Stops
	    - Admin changes
	
	如果一个状态服务器监视上面这些事件，那它可以被用于收集一个用户/会话的网络使用信息。
	与向后跟踪IP地址流相比，一个特定用户进入网络的信息与网络业务管理更相关。通过一定
	范围内的NAS收集的关于使用端口的有效信息能使得业务提供者能很快的发现有问题的区域
	或者是用户。
	
	同样，对于业务提供者来说，关于用户呼叫的成功、失败、质量的信息同样很重要。
	
	扩展RADIUS记账很容易，但奇怪的是很多实现都没有关于这个方面的内容。
	
9.	结论

	实际中，RADIUS服务器的软件实现变得相当复杂。他们经常作为一个中间人将认证或授权
	信息转到其它的授权处或者是某个中心。为了实现这种解决方案，通常将不同的RADIUS
	协议组合在一起使用。
	
	一些解决方案能被一些潜在的更好的业务替代。
	
	对实现者来说，这意味者RADIUS与RFC的描述变得更不相关了。很多增加的特性需要
	匹配客户端和服务器关于消息的处理。如果没有标准，我们在该领域不能协同工作，
	则更多的精力花费在相互作用上。
	
	无论如何，该文档不是一个完全的调查。它只是我写这篇文档时所知道的一些典型
	应用摘要。感谢那些提供关于一些实践和细节的材料的用户和厂商。如果你有什么参
	考材料能提供的话，我也感激不尽。
	
10.	安全考虑

	略
	
11.	实现文档
	
	下面的材料可以从各自的所有者获得。很多列表在制造厂商的站点上就能找到。
	
11.1	客户端
	
	   - 3Com(USR) Total Control Hub
	   - Ericsson(ACC) Tigris
	           draft-ilgun-radius-accvsa-01.txt, Dec 1998
	   - Lucent(Ascend) MAX TNT
	   - Lucent(Livingston) Portmaster
	   - Nortel(Aptis) CVX 1800
	   - Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller
	   - Intel(Shiva)

11.2	服务器

	   - Ericsson(ACC) Virtual Port Server Manager
	   - Funk Steel-Belted RADIUS
	   - Intel(Shiva) Access Manager
	   - Lucent(Ascend) Access Control
	   - Lucent(Ascend) NavisAccess
	   - Lucent(Ascend) Modified Livingston 1.16
	   - Lucent(Livingston) V2.01
	   - Lucent(Livingston) ABM
	   - Lucent Port Authority
	   - MERIT AAA Servers
	   - Nortel(Bay Networks) BaySecure Access Control
	   - Nortel Preside Radius
	   - Nortel CVX Policy Manager

12	参考材料

	   [1]  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
	        Authentication Dial In User Service (RADIUS)", RFC 2138, April
	        1997.
	
	   [2]  Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
	
	   [3]  Rigney, C., Willens, S., Ruebens, A. and W. Simpson, "Remote
	        Authentication Dial In User Service (RADIUS)", RFC 2865, June
	        2000.
	
	   [4]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
	
	   [5]  Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
	        2869, June 2000.
	
	   [6]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
	        I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
	        2868, June 2000.
	
	   [7]  Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
	        Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
	
	   [8]  Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory
	        Tunneling via RADIUS", RFC 2809, April 2000.
	
	   [9]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
	        2548, March 1999.
	
	   [10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson
	        Datacom Access", Work in Progress.
	
13.  Author's Address

   David Mitton
   Nortel Networks
   880 Technology Park Drive
   Billerica, MA 01821

   Phone: [phone]
   EMail: [e-mail]

14.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked 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 ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.