rfc2989.txt

中、英文RFC文档大全打包下载完全版 .


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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Pat R. Calhoun
   Network and Security Research Center, Sun Labs
   Sun Microsystems, Inc.
   15 Network Circle
   Menlo Park, CA 94025

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










Aboba, et al.                Informational                     [Page 21]