📄 rfc2989.txt
字号:
RFC 2989 Network Access AAA Evaluation Criteria November 2000
[f] This requirement refers to the ability of the NAS to use the AAA
server to manage resource allocation state. This capability can
assist with, but it is not synonymous with, simultaneous user
login control, port usage limitations, or IP address pooling.
The design must provide for recovery from data loss due to a
variety of faults, including NAS and AAA server reboots, and
NAS/AAA server communication outages, and MUST be independent of
the accounting stream. The granularity of the recovery of state
information after an outage may be on the order of a fraction of
a minute. In order to provide for state recovery, explicit
session/resource status and update and disconnect messages will
be required.
Because of potential multi-domain issues, only systems that
allocate or use a resource should track its state.
[g] This requirement refers to the ability of the AAA server to
request the NAS to disconnect an active session for
authorization policy reasons.
Aboba, et al. Informational [Page 15]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
2.4. Accounting Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Accounting | NASREQ | ROAMOPS | MOBILE |
| Reqts. | | | IP |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Real-time accounting | M | M | M |
| a | 14 | 7 | 31 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Mandatory Compact | | M | |
| Encoding | | 7 | |
| b | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Accounting Record | | M | M |
| Extensibility | | 7 | 33 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Batch Accounting | S | | |
| c | 21 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Guaranteed Delivery | M | | M |
| d | 22 | | 31 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Accounting Time Stamps | M | | M |
| e | 23 | | 40 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Dynamic Accounting | M | | |
| f | 48 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboba, et al. Informational [Page 16]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
Clarifications
[a] This requirement may be loosely defined as reporting
synchronously with events. Typically the time window is on the
order of seconds, not milliseconds.
[b] The AAA protocol's Accounting data format MUST NOT be bloated,
imposing a large overhead for one or more accounting data
elements.
[c] This requirement refers to the ability to buffer or store
multiple accounting records, and send them together at some
later time.
[d] This is an application layer acknowledgment. This is sent when
the receiving server is willing to take responsibility for the
message data.
[e] This requirement refers to the ability to reflect the time of
occurrence of events such as log-on, logoff, authentication,
authorization and interim accounting. It also implies the
ability to provide for unambiguous time-stamps.
[f] This requirement refers to the ability to account for dynamic
authentication and authorization. To support this, there can be
multiple accounting records for a single session.
2.5. Unique Mobile IP requirements
In addition to the above requirements, Mobile IP also has the
following additional requirements:
Aboba, et al. Informational [Page 17]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Encoding of Mobile IP | | | M |
| registration messages | | | 33 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Firewall friendly | | | M |
| a | | | 35 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Allocation of local Home | | | S/M |
| agent | | | 37/41 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
Clarifications
[a] A firewall friendly protocol is one which is designed to
accommodate a firewall acting as a proxy. For example, this
would permit a Home Agent AAA server situated behind a firewall
to be reachable from the Internet for the purposes of providing
AAA services to a Mobile IP Foreign Agent.
Notes
[1] Section 4.2.1 of [2]
[2] Section 4.2.2 of [2]. Also see [8].
[3] Section 4.2.3 of [2]. Also see [14].
[4] Section 4.2.4 of [2].
[5] Section 4.2.5 of [2].
[6] Section 4.2.6 of [2].
[7] Section 4.3 of [2].
[8] Section 6 of [3]. Also see [6].
[9] Section 8.2.2.2 of [3]. Also see [14].
[10] Section 8.2.2.1 of [3]. Also see [14].
[11] Section 8.3.2.2 of [3]. Also see [7].
[12] Section 8.1.1 of [3].
[13] Section 8.1.4.4 of [3].
[14] Section 8.4.1.2 of [3].
Aboba, et al. Informational [Page 18]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
[15] Section 8.4.2 of [3].
[16] Section 8.1.3 of [3].
[17] Section 8.2.1.2 of [3].
[18] Section 8.3.1.1 of [3].
[19] Section 8.3.2.1 of [3]. Also see [7].
[20] Section 8.3.2.3 of [3]. Also see [6], [7].
[21] Section 8.4.1.3 of [3].
[22] Section 8.4.1.1 of [3].
[23] Section 8.4.1.4 of [3].
[24] Section 8.4.3.1 of [3].
[25] Section 8.4.3.2 of [3].
[26] Section 8.2.3.1 of [3].
[27] Section 8.3.3.1 of [3].
[28] Section 8.1.4.1 of [3].
[29] Refer [15]
[30] Section 3 of [5]
[31] Section 3.1 of [5]
[32] Section 4 of [5]
[33] Section 5 of [5]
[34] Section 5.1 of [5]
[35] Section 5.2 of [5]
[36] Section 5.3 of [5]
[37] Section 5.4 of [5]
[38] Section 5.5 of [5]
[39] Section 6 of [5]
[40] Section 5.1 of [4]
[41] Section 5.2.2 of [4]
[42] Section 8.2.2.2 of [3]
[43] Section 8.1.2.3 of [3]
[44] Section 8.1.2.2 of [3]
[45] Section 5.4 of [4]
[46] Section 7 of [4]
[47] Section 8 of [5]
[48] Section 8.4.1.5 of [3]
3. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, January 1999.
[3] Beadles, M. and D. Mitton, "Criteria for Evaluating Network
Access Server Protocols", Work in Progress.
[4] Hiller, T., et al., "Cdma2000 Wireless Data Requirements for
AAA", Work in Progress.
Aboba, et al. Informational [Page 19]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
[5] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements", RFC
2977, October 2000.
[6] Mitton, D., Beadles, M., "Network Access Server Requirements
Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[7] Mitton, D., "Network Access Server Requirements: Extended RADIUS
Practices", RFC 2882, July 2000.
[8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[11] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
"The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[13] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
1994.
[14] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[15] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
PPP IPCP", RFC 2290, Feb 1998
[16] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, March 2000.
[17] Perkins, C., "IP Mobility Support", RFC 2002, Oct 1996.
[18] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in
Progress.
[19] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[20] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
Aboba, et al. Informational [Page 20]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
4. Security Considerations
This document, being a requirements document, does not have any
security concerns. The security requirements on protocols to be
evaluated using this document are described in the referenced
documents.
5. IANA Considerations
This memo does not create any new number spaces for IANA
administration.
6. Acknowledgments
Thanks to the members of the Mobile IP, AAA, and NASREQ working
groups who have discussed and commented on these requirements. We
would also like to thank the members of the AAA evaluation team, Mike
St. Johns, Barney Wolf, Mark Stevens, David Nelson, Dave Mitton,
Basavaraj Patil and Stuart Barkley for their thorough review of this
document.
7. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425-936-6605
Fax: +1 425-936-7329
EMail: bernarda@microsoft.com
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025
Phone: +1 650-786-7733
EMail: pcalhoun@eng.sun.com
Aboba, et al. Informational [Page 21]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -