rfc2868.txt

很多RFC的中文文档

		   |      Type     |    Length     |      Tag      |   String ...
		   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		   
	Type
		91
	
	Length
		>=3
		
	Tag
		该域长度是一个字节，用于组织属于同一隧道的一组属性，如果该域的值大于0x00，
		且小于或者等于0x1F，则被解释成指示该属性所属的隧道。如果该域的值大于0x1F，
		则被解释成String域的第一个字节。

	String
		该域是必需的。它包含了隧道终结者用于认证的认证名。建议该认证名的格式用UTF-8。
		
4.  属性列表
	下面的列表表示了上面的属性能被包含在那些属性中，以及在该报文中能出现的次数。
		Request Accept Reject Challenge Acct-Request #  Attribute
		0+      0+     0      0         0-1          64 Tunnel-Type
		0+      0+     0      0         0-1          65 Tunnel-Medium-Type
		0+      0+     0      0         0-1          66 Tunnel-Client-Endpoint
		0+      0+     0      0         0-1          67 Tunnel-Server-Endpoint
		0       0+     0      0         0            69 Tunnel-Password
		0+      0+     0      0         0-1          81 Tunnel-Private-Group-ID
		0       0+     0      0         0-1          82 Tunnel-Assignment-ID
		0+      0+     0      0         0            83 Tunnel-Preference
		0+      0+     0      0         0-1          90 Tunnel-Client-Auth-ID
		0+      0+     0      0         0-1          91 Tunnel-Server-Auth-ID
		
5.  安全因素
	Tunnel-Password属性有可能包含一些只有隧道端点才能知道的信息，但是现在用于隐藏该属性的值
	的方法会使得中间的RADIUS代理也知道其中的内容。由于这个原因，Tunne-Password属性不应该
	被包含在Access-Accept报文中，因为该报文有可能通过一个不可信任的RADIUS代理。另外，
	Tunnel-Password属性不应该被返回到一个没有认证的终端；如果对应的Access-Request报文没有
	包含一个能被证实的签名属性[15],则Access-Accept报文中就不应该包含Tunnel-Password属性。

	隧道协议提供从没有安全保护（如PPTP）到最强的安全保护（如IPSec）等不同的安全等级。但是，
	需要注意的是，在强制隧道中，任何安全措施只应用于隧道端点之间的传输。特别是终端用户不应该依
	赖隧道的安全性来保护它们自己的数据。隧道传输的加密保护不能替代点到点之间的安全。
	
6.  IANA考虑事项
	该文档定义了一系列有IANA维护的魔术数（magic number）。这一节解释了IANA分配这些数字的标准。
	下面的每个子节解释了关于在本文档其它地方定义的名字空间的分配原则。

6.1.  Tunnel-Type 属性值
	Tunnel-Type属性的的取值1-12已经在5.1节定义。剩下的值有IANA根据IETF的意见分配[16]。

6.2.  Tunnel-Medium-Type属性值
	Tunnel-Medium-Type属性的取值1-15已经在5.2定义。剩下的值有IANA根据IETF的意见分配[16]。
	
7.  参考

   [1]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
        G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
        July 1999.
        
   [2]  Valencia, A., Littlewood, M. and T. Kolar, T., "Cisco Layer Two
        Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.

   [3]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
        B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661,
        August 1999.

   [4]  Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
        2107, February 1997.

   [5]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [6]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
        1996.

   [7]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
        October 1996.

   [8]  Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
        1827, August 1995.

   [9]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
        Encapsulation (GRE)", RFC 1701, October 1994.

   [10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

   [11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for
        Tunnel Protocol Support", RFC 2867, June 2000.

   [12] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
        Authentication Dial in User Service (RADIUS)", RFC 2865, June
        2000.

   [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [14] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.

   [15] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
        2869, June 2000.

   [16] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [17] Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

8.  Acknowledgements

   Thanks to Dave Mitton for pointing out a nasty circular dependency in
   the original Tunnel-Password attribute definition and (in no
   particular order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia,
   Bill Westfield, Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson,
   Aydin Edguer, and Bernard Aboba for useful input and review.

9.  Chair's Address

   The RADIUS Working Group can be contacted via the current chair:

   Carl Rigney
   Livingston Enterprises
   4464 Willow Road
   Pleasanton, California  94588

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

10.  Authors' Addresses

   Questions about this memo can also be directed to:

   Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, Washington 98004
   USA

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


   Dory Leifer
   Ascend Communications
   1678 Broadway
   Ann Arbor, MI 48105

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

   John Shriver
   Intel Corporation
   28 Crosby Drive
   Bedford, MA  01730

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


   Allan Rubens
   Ascend Communications
   1678 Broadway
   Ann Arbor, MI 48105

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


   Matt Holdrege
   ipVerse
   223 Ximeno Ave.
   Long Beach, CA 90803

   EMail: [e-mail]


   Ignacio Goyret
   Lucent Technologies
   One Ascend Plaza
   1701 Harbor Bay Parkway
   Alameda, CA 94502

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

11.  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.