doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3169.txt b/doc/rfc/rfc3169.txt
new file mode 100644
index 0000000..2b93297
--- /dev/null
+++ b/doc/rfc/rfc3169.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                         M. Beadles
+Request for Comments: 3169                              SmartPipes, Inc.
+Category: Informational                                        D. Mitton
+                                                         Nortel Networks
+                                                          September 2001
+
+
+        Criteria for Evaluating Network Access Server Protocols
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document defines requirements for protocols used by Network
+   Access Servers (NAS).
+
+1.  Requirements language
+
+   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
+   described in [KEYWORDS].
+
+2.  Introduction
+
+   This document defines requirements for protocols used by Network
+   Access Servers (NAS).  Protocols used by NAS's may be divided into
+   four spaces:  Access protocols, Network protocols, AAA protocols, and
+   Device Management protocols.  The primary focus of this document is
+   on AAA protocols.
+
+   The reference model of a NAS used by this document, and the analysis
+   of the functions of a NAS which led to the development of these
+   requirements, may be found in [NAS-MODEL].
+
+3.  Access Protocol Requirements
+
+   There are three basic types of access protocols used by NAS's.  First
+   are the traditional telephony-based access protocols, which interface
+   to the NAS via a modem or terminal adapter or similar device.  These
+   protocols typically support asynchronous or synchronous PPP [PPP]
+
+
+
+Beadles & Mitton             Informational                      [Page 1]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+   carried over a telephony protocol.  Second are broadband pseudo-
+   telephony access protocols, which are carried over xDSL or cable
+   modems, for example.  These protocols typically support an
+   encapsulation method such as PPP over Ethernet [PPPOE].  Finally are
+   the virtual access protocols used by NAS's that terminate tunnels.
+   One example of this type of protocol is L2TP [L2TP].
+
+   It is a central assumption of the NAS model used here that a NAS
+   accepts multiple point-to-point links via one of the above access
+   protocols.  Therefore, at a minimum, any NAS access protocol MUST be
+   able to carry PPP.  The exception to this requirement is for NAS's
+   that support legacy text login methods such as telnet [TELNET],
+   rlogin, or LAT.  Only these access protocols are exempt from the
+   requirement to support PPP.
+
+4.  Network Protocol Requirements
+
+   The network protocols supported by a NAS depend entirely on the kind
+   of network to which a NAS is providing access.  This document does
+   not impose any additional requirements on network protocols beyond
+   the protocol specifications themselves.  For example, if a NAS that
+   serves a routed network includes internet routing functionality, then
+   that NAS must adhere to [ROUTING-REQUIREMENTS], but there are no
+   additional protocol requirements imposed by virtue of the device
+   being a NAS.
+
+5.  AAA Protocol Requirements
+
+5.1.  General protocol characteristics
+
+   There are certain general characteristics that any AAA protocol used
+   by NAS's must meet.  Note that the transport requirements for
+   authentication/authorization are not necessarily the same as those
+   for accounting/auditing.  An AAA protocol suite MAY use the same
+   transport and protocol for both functions, but this is not strictly
+   required.
+
+5.1.1.  Transport requirements
+
+5.1.1.1.  Transport independence
+
+   The design of the AAA protocol MUST be transport independent.
+   Existing infrastructures use UDP-based protocols [RADIUS], gateways
+   to new protocols must be practical to encourage migration.  The
+   design MUST comply with congestion control recommendations in RFC
+   2914 [CONGEST].
+
+
+
+
+
+Beadles & Mitton             Informational                      [Page 2]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+5.1.1.2.  Scalability
+
+   Very large scale NAS's that serve up to thousands of simultaneous
+   sessions are now being deployed.  And a single server system may
+   service a large number of ports.  This means that, in the extreme,
+   there may be an almost constant exchange of many small packets
+   between the NASes and the AAA server.  An AAA protocol transport
+   SHOULD support being optimized for a long-term exchange of small
+   packets in a stream between a pair of hosts.
+
+   The protocol MUST be designed to support a large number of ports,
+   clients, and concurrent sessions.  Examples of poor design would
+   include message identifiers which values are so small that queues and
+   reception windows wrap under load, unique session identifier ranges
+   that are so small that they wrap within the lifetime of potential
+   long sessions, counter values that cannot accommodate reasonable
+   current and future bandwidth usage, and computational processes with
+   high overhead that must be performed frequently.
+
+5.1.1.3.  Support for Multiple AAA Servers and Failure Recovery
+
+   In order to operationally support large loads, load balancing and
+   fail-over to multiple AAA servers will be required.  The AAA protocol
+   MUST provide for NAS's to balance individual AAA requests between two
+   or more AAA servers.  The load balancing mechanism SHOULD be built in
+   to the AAA protocol itself.
+
+   The AAA protocol MUST be able to detect a failure of the transport
+   protocol to deliver a message or messages within a known and
+   controllable time period, so it can engage retransmission or server
+   fail-over processes.  The reliability and robustness of
+   authentication requests MUST be predictable and configurable.
+
+   The AAA protocol design MUST NOT introduce a single point of failure
+   during the AAA process.  The AAA protocol MUST allow any sessions
+   between a NAS and a given AAA server to fail-over to a secondary
+   server without loss of state information.  This fail-over mechanism
+   SHOULD be built in to the AAA protocol itself.
+
+5.1.1.4.  Support for Multiple Administrative Domains
+
+   NAS's operated by one authority provide network access services for
+   clients operated by another authority, to network destinations
+   operated by yet another authority.  This type of arrangement is of
+   growing importance; for example, dial roaming is now a nearly
+   ubiquitous service.  Therefore, the AAA protocol MUST support AAA
+
+
+
+
+
+Beadles & Mitton             Informational                      [Page 3]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+   services that travel between multiple domains of authority.  The AAA
+   protocol MUST NOT use a model that assumes a single domain of
+   authority.
+
+   The AAA protocol MUST NOT dictate particular business models for the
+   relationship between the administrative domains.  The AAA protocol
+   MUST support proxy, and in addition SHOULD support other multi-domain
+   relationships such as brokering and referral.
+
+   The AAA protocol MUST also meet the protocol requirements specified
+   in [ROAMING-REQUIREMENTS].
+
+5.1.2.  Attribute-Value Protocol Model
+
+   Years of operational experience with AAA protocols and NAS's has
+   proven that the Attribute-Value protocol model is an optimal
+   representation of AAA data.  The protocol SHOULD use an Attribute-
+   Value representation for AAA data.  This document will assume such a
+   model.  Even if the AAA protocol does not use this as an on-the-wire
+   data representation, Attribute-Value can serve as abstraction for
+   discussing AAA information.
+
+   Experience has also shown that attribute space tends to run out
+   quickly.  In order to provide room for expansion in the attribute
+   space, the AAA protocol MUST support a minimum of 64K Attributes (16
+   bits), each with a minimum length of 64K (16 bits).
+
+5.1.2.1.  Attribute Data Types
+
+   The AAA protocol MUST support simple attribute data types, including
+   integer, enumeration, text string, IP address, and date/time.  The
+   AAA protocol MUST also provide some support for complex structured
+   data types.  Wherever IP addresses are carried within the AAA
+   protocol, the protocol MUST support both IPv4 and IPv6 [IPV6]
+   addresses.  Wherever text information is carried within the AAA
+   protocol, the protocol MUST comply with the IETF Policy on Character
+   Sets and Languages [RFC 2277].
+
+5.1.2.2.  Minimum Set of Attributes
+
+   At a minimum, the AAA protocol MUST support, or be easily extended to
+   support, the set of attributes supported by RADIUS [RADIUS] and
+   RADIUS Accounting [RADIUS-ACCOUNTING].  If the base AAA protocol does
+   not support this complete set of attributes, then an extension to
+   that protocol MUST be defined which supports this set.
+
+
+
+
+
+
+Beadles & Mitton             Informational                      [Page 4]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+5.1.2.3.  Attribute Extensibility
+
+   NAS and AAA development is always progressing.  In order to prevent
+   the AAA protocol from being a limiting factor in NAS and AAA Server
+   development, the AAA protocol MUST provide a built-in extensibility
+   mechanism, which MUST include a means for adding new standard
+   attribute extensions.  This MUST include a method for registering or
+   requesting extensions through IANA, so that long-term working group
+   involvement is not required to create new attribute types.  Ideally,
+   the AAA protocol SHOULD separate specification of the transport from
+   specification of the attributes.
+
+   The AAA protocol MUST include a means for individual vendors to add
+   value through vendor-specific attributes and SHOULD include support
+   for vendor-specific data types.
+
+5.1.3.  Security Requirements
+
+5.1.3.1.  Mutual Authentication
+
+   It is poor security practice for a NAS to communicate with an AAA
+   server that is not trusted, and vice versa.  The AAA protocol MUST
+   provide mutual authentication between AAA server and NAS.
+
+5.1.3.2.  Shared Secrets
+
+   At a minimum, the AAA protocol SHOULD support use of a secret shared
+   pairwise between each NAS and AAA server to mutually verify identity.
+   This is intended for small-scale deployments.  The protocol MAY
+   provide stronger mutual security techniques.
+
+5.1.3.3.  Public Key Security
+
+   AAA server/NAS identity verification based solely on shared secrets
+   can be difficult to deploy properly at large scale, and it can be
+   tempting for NAS operators to use a single shared secret (that rarely
+   changes) across all NAS's.  This can lead to an easy compromise of
+   the secret.  Therefore, the AAA protocol MUST also support mutual
+   verification of identity using a public-key infrastructure that
+   supports expiration and revocation of keys.
+
+5.1.3.4.  Encryption of Attributes
+
+   Some attributes are more operationally sensitive than others.  Also,
+   in a multi-domain scenario, attributes may be inserted by servers
+   from different administrative domains.  Therefore, the AAA protocol
+
+
+
+
+
+Beadles & Mitton             Informational                      [Page 5]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+   MUST support selective encryption of attributes on an attribute-by-
+   attribute basis, even within the same message.  This requirement
+   applies equally to Authentication, Authorization, and Accounting
+   data.
+
+5.2.  Authentication and User Security Requirements
+
+5.2.1.  Authentication protocol requirements
+
+   End users who are requesting network access through a NAS will
+   present various types of credentials.  It is the purpose of the AAA
+   protocol to transport these credentials between the NAS and the AAA
+   server.
+
+5.2.1.1.  Bi-directional Authentication
+
+   The AAA protocol MUST support transport of credentials from the AAA
+   server to the NAS, between the User and the NAS, and between the NAS
+   and the AAA server.
+
+5.2.1.2.  Periodic Re-Authentication
+
+   The AAA protocol MUST support re-authentication at any time during
+   the course of a session, initiated from either the NAS or the AAA
+   server.  This is a requirement of CHAP [CHAP].
+
+5.2.1.3.  Multi-phase Authentication
+
+   The AAA protocol MUST be able to support multi-phase authentication
+   methods, including but not limited to support for:
+
+      -  Text prompting from the NAS to the user
+
+      -  A series of binary challenges and responses of arbitrary length
+
+      -  An authentication failure reason to be transmitted from the NAS
+         to the user
+
+      -  Callback to a pre-determined phone number
+
+5.2.1.4.  Extensible Authentication Types
+
+   Security protocol development is going on constantly as new threats
+   are identified and better cracking methods are developed.  Today's
+   secure authentication methods may be proven insecure tomorrow.  The
+   AAA protocol MUST provide some support for addition of new
+   authentication credential types.
+
+
+
+
+Beadles & Mitton             Informational                      [Page 6]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+5.2.2.  Authentication Attribute Requirements
+
+   In addition to the minimum attribute set, the AAA protocol must
+   support and define attributes that provide the following functions:
+
+5.2.2.1.  PPP Authentication protocols
+
+   Many authentication protocols are defined within the framework of
+   PPP.  The AAA protocol MUST be able to act as an intermediary
+   protocol between the authenticate and the authenticator for the
+   following authentication protocols:
+
+      -  PPP Password Authentication Protocol [PPP]
+
+      -  PPP Challenge Handshake Authentication Protocol [CHAP]
+
+      -  PPP Extensible Authentication Protocol [EAP]
+
+5.2.2.2.  User Identification
+
+   The following are common types of credentials used for user
+   identification.  The AAA protocol MUST be able to carry the following
+   types of identity credentials:
+
+      -  A user name in the form of a Network Access Identifier [NAI].
+
+      -  An Extensible Authentication Protocol [EAP] Identity Request
+         Type packet.
+
+      -  Telephony dialing information such as Dialed Number
+         Identification Service (DNIS) and Caller ID.
+
+   If a particular type of authentication credential is not needed for a
+   particular user session, the AAA protocol MUST NOT require that dummy
+   credentials be filled in.  That is, the AAA protocol MUST support
+   authorization by identification or assertion only.
+
+5.2.2.3.  Authentication Credentials
+
+   The following are common types of credentials used for
+   authentication.  The AAA protocol MUST be able to carry the following
+   types of authenticating credentials at a minimum:
+
+      -  A secret or password.
+
+      -  A response to a challenge presented by the NAS to the user
+
+      -  A one-time password
+
+
+
+Beadles & Mitton             Informational                      [Page 7]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+      -  An X.509 digital certificate [X.509]
+
+      -  A Kerberos v5 ticket [KERBEROS]
+
+5.2.3.  Authentication Protocol Security Requirements
+
+5.2.3.1.  End-to-End Hiding of Credentials
+
+   Where passwords are used as authentication credentials, the AAA
+   protocol MUST provide a secure means of hiding the password from
+   intermediates in the AAA conversation.  Where challenge/response
+   mechanisms are used, the AAA protocol MUST also prevent against
+   replay attacks.
+
+5.3.  Authorization, Policy, and Resource management
+
+5.3.1.  Authorization Protocol Requirements
+
+   In all cases, the protocol MUST specify that authorization data sent
+   from the NAS to the AAA server is to be regarded as information or
+   "hints", and not directives.  The AAA protocol MUST be designed so
+   that the AAA server makes all final authorization decisions and does
+   not depend on a certain state being expected by the NAS.
+
+5.3.1.1.  Dynamic Authorization
+
+   The AAA protocol MUST support dynamic re-authorization at any time
+   during a user session.  This re-authorization may be initiated in
+   either direction.  This dynamic re-authorization capability MUST
+   include the capability to request a NAS to disconnect a user on
+   demand.
+
+5.3.1.2.  Resource Management
+
+   Resource Management MUST be supported on demand by the NAS or AAA
+   Server at any time during the course of a user session.  This would
+   be the ability for the NAS to allocate and deallocate shared
+   resources from a AAA server servicing multiple NASes.  These
+   resources may include, but are not limited to; IP addresses,
+   concurrent usage limits, port usage limits, and tunnel limits.  This
+   capability should have error detection and synchronization features
+   that will recover state after network and system failures.  This may
+   be accomplished by session information timeouts and explicit interim
+   status and disconnect messages.  There should not be any dependencies
+   on the Accounting message stream, as per current practices.
+
+
+
+
+
+
+Beadles & Mitton             Informational                      [Page 8]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+   This feature is primarily intended for NAS-local network resources.
+   In a proxy or multi-domain environment, resource information should
+   only be retained by the server doing the allocation, and perhaps it's
+   backups.  Authorization resources in remote domains should use the
+   dynamic authorization features to change and revoke authorization
+   status.
+
+5.3.2.  Authorization Attribute Requirements
+
+5.3.2.1.  Authorization Attribute Requirements - Access Restrictions
+
+   The AAA protocol serves as a primary means of gathering data used for
+   making Policy decisions for network access.  Therefore, the AAA
+   protocol MUST allow network operators to make policy decisions based
+   on the following parameters:
+
+      -  Time/day restrictions.  The AAA protocol MUST be able to
+         provide an unambiguous time stamp, NAS time zone indication,
+         and date indication to the AAA server in the Authorization
+         information.
+
+      -  Location restrictions:  The AAA protocol MUST be able to
+         provide an unambiguous location code that reflects the
+         geographic location of the NAS.  Note that this is not the same
+         type of thing as either the dialing or dialed station.
+
+      -  Dialing restrictions:  The AAA protocol MUST be able to provide
+         accurate dialed and dialing station indications.
+
+      -  Concurrent login limitations:  The AAA protocol MUST allow an
+         AAA Server to limit concurrent logins by a particular user or
+         group of users.  This mechanism does not need to be explicitly
+         built into the AAA protocol, but the AAA protocol must provide
+         sufficient authorization  information for an AAA server to make
+         that determination through an out-of-band mechanism.
+
+5.3.2.2.  Authorization Attribute Requirements - Authorization Profiles
+
+   The AAA protocol is used to enforce policy at the NAS.  Essentially,
+   on granting of access, a particular access profile is applied to the
+   user's session.  The AAA protocol MUST at a minimum provide a means
+   of applying profiles containing the following types of information:
+
+      -  IP Address assignment: The AAA protocol MUST provide a means of
+         assigning an IPv4 or IPv6 address to an incoming user.
+
+
+
+
+
+
+Beadles & Mitton             Informational                      [Page 9]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+      -  Protocol Filter application:  The AAA protocol MUST provide a
+         means of applying IP protocol filters to user sessions.  Two
+         different methods MUST be supported.
+
+         First, the AAA protocol MUST provide a means of selecting a
+         protocol filter by reference to an identifier, with the details
+         of the filter action being specified out of band.  The AAA
+         protocol SHOULD define this out-of-band reference mechanism.
+
+         Second, the AAA protocol MUST provide a means of passing a
+         protocol filter by value.  This means explicit passing of
+         pass/block information by address range, TCP/UDP port number,
+         and IP protocol number at a minimum.
+
+      -  Compulsory Tunneling:  The AAA protocol MUST provide a means of
+         directing a NAS to build a tunnel or tunnels to a specified
+         end- point.  It MUST support creation of multiple simultaneous
+         tunnels in a specified order.  The protocol MUST allow, at a
+         minimum, specification of the tunnel endpoints, tunneling
+         protocol type, underlying tunnel media type, and tunnel
+         authentication credentials (if required by the tunnel type).
+         The AAA protocol MUST support at least the creation of tunnels
+         using the L2TP [L2TP], ESP [ESP], and AH [AH] protocols.  The
+         protocol MUST provide means of adding new tunnel types as they
+         are standardized.
+
+      -  Routing:  The AAA protocol MUST provide a means of assigning a
+         particular static route to an incoming user session.
+
+      -  Expirations/timeouts:  The AAA protocol MUST provide a means of
+         communication session expiration information to a NAS.  Types
+         of expirations that MUST be supported are:  total session time,
+         idle time, total bytes transmitted, and total bytes received.
+
+      -  Quality of Service:  The AAA protocol MUST provide a means for
+         supplying Quality of Service parameters to the NAS for
+         individual user sessions.
+
+5.3.2.3.  Resource Management Requirements
+
+   The AAA protocol is a means for network operators to perform
+   management of network resources.  The AAA protocol MUST provide a
+   means of collecting resource state information, and controlling
+   resource allocation for the following types of network resources.
+
+      -  Network bandwidth usage per session, including multilink
+         sessions.
+
+
+
+
+Beadles & Mitton             Informational                     [Page 10]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+      -  Access port usage, including concurrent usage and usage pools.
+
+      -  Connect time.
+
+      -  IP Addresses and pools.
+
+      -  Compulsory tunnel limits.
+
+5.3.3.  Authorization Protocol Security Requirements
+
+5.3.3.1.  Security of Compulsory Tunnel Credentials
+
+   When an AAA protocol passes credentials that will be used to
+   authenticate compulsory tunnels, the AAA protocol MUST provide a
+   means of securing the credentials from end-to-end of the AAA
+   conversation.  The AAA protocol MUST also provide protection against
+   replay attacks in this situation.
+
+5.4.  Accounting and Auditing Requirements
+
+5.4.1.  Accounting Protocol Requirements
+
+5.4.1.1.  Guaranteed Delivery
+
+   The accounting and auditing functions of the AAA protocol are used
+   for network planning, resource management, policy decisions, and
+   other functions that require accurate knowledge of the state of the
+   NAS.  NAS operators need to be able to engineer their network usage
+   measurement systems to a predictable level of accuracy.  Therefore,
+   an AAA protocol MUST provide a means of guaranteed delivery of
+   accounting information between the NAS and the AAA Server(s).
+
+5.4.1.2.  Real Time Accounting
+
+   NAS operators often require a real time view onto the status of
+   sessions served by a NAS.  Therefore, the AAA protocol MUST support
+   real-time delivery of accounting and auditing information.  In this
+   context, real time is defined as accounting information delivery
+   beginning within one second of the triggering event.
+
+5.4.1.3.  Batch Accounting
+
+   The AAA protocol SHOULD also support delivery of stored accounting
+   and auditing information in batches (non-real time).
+
+
+
+
+
+
+
+Beadles & Mitton             Informational                     [Page 11]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+5.4.1.4.  Accounting Time Stamps
+
+   There may be delays associated with the delivery of accounting
+   information.  The NAS operator will desire to know the time an event
+   actually occurred, rather than simply the time when notification of
+   the event was received.  Therefore, the AAA protocol MUST carry an
+   unambiguous time stamp associated with each accounting event.  This
+   time stamp MUST be unambiguous with regard to time zone.  Note that
+   this assumes that the NAS has access to a reliable time source.
+
+5.4.1.5.  Accounting Events
+
+   At a minimum, the AAA protocol MUST support delivery of accounting
+   information triggered by the following events:
+
+      -  Start of a user session
+
+      -  End of a user session
+
+      -  Expiration of a predetermined repeating time interval during a
+         user session.  The AAA protocol MUST provide a means for the
+         AAA server to request that a NAS use a certain interval
+         accounting time.
+
+      -  Dynamic re-authorization during a user session (e.g., new
+         resources being delivered to the user)
+
+      -  Dynamic re-authentication during a user session
+
+5.4.1.6.  On-Demand Accounting
+
+   NAS operators need to maintain an accurate view onto the status of
+   sessions served by a NAS, even through failure of an AAA server.
+   Therefore, the AAA protocol MUST support a means of requesting
+   current session state and accounting from the NAS on demand.
+
+5.4.2.  Accounting Attribute Requirements
+
+   At a minimum, the AAA protocol MUST support delivery of the following
+   types of accounting/auditing data:
+
+      -  All parameters used to authenticate a session.
+
+      -  Details of the authorization profile that was applied to the
+         session.
+
+      -  The duration of the session.
+
+
+
+
+Beadles & Mitton             Informational                     [Page 12]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+      -  The cumulative number of bytes sent by the user during the
+         session.
+
+      -  The cumulative number of bytes received by the user during the
+         session.
+
+      -  The cumulative number of packets sent by the user during the
+         session.
+
+      -  The cumulative number of packets received by the user during
+         the session.
+
+      -  Details of the access protocol used during the session (port
+         type, connect speeds, etc.)
+
+5.4.3.  Accounting Protocol Security Requirements
+
+5.4.3.1.  Integrity and Confidentiality
+
+   Note that accounting and auditing data are operationally sensitive
+   information.  The AAA protocol MUST provide a means to assure end-
+   to-end integrity of this data.  The AAA protocol SHOULD provide a
+   means of assuring the end-to-end confidentiality of this data.
+
+5.4.3.2.  Auditibility
+
+   Network operators use accounting data for network planning, resource
+   management, and other business-critical functions that require
+   confidence in the correctness of this data.  The AAA protocol SHOULD
+   provide a mechanism to ensure that the source of accounting data
+   cannot easily repudiate this data after transmission.
+
+6.  Device Management Protocols
+
+   This document does not specify any requirements for device management
+   protocols.
+
+7.  Acknowledgments
+
+   Many of the requirements in this document first took form in Glen
+   Zorn's, "Yet Another Authentication Protocol (YAAP)" document, for
+   which grateful acknowledgment is made.
+
+8.  Security Considerations
+
+   See above for security requirements for the NAS AAA protocol.
+
+
+
+
+
+Beadles & Mitton             Informational                     [Page 13]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+   Where an AAA architecture spans multiple domains of authority, AAA
+   information may need to cross trust boundaries.  In this situation, a
+   NAS might operate as a shared device that services multiple
+   administrative domains.  Network operators are advised take this into
+   consideration when deploying NAS's and AAA Servers.
+
+9.  IANA Considerations
+
+   This document does not directly specify any IANA considerations.
+   However, the following recommendations are made:
+
+   Future development and extension of an AAA protocol will be made much
+   easier if new attributes and values can be requested or registered
+   directly through IANA, rather than through an IETF Standardization
+   process.
+
+   The AAA protocol might use enumerated values for some attributes,
+   which enumerate already-defined IANA types (such as protocol number).
+   In these cases, the AAA protocol SHOULD use the IANA assigned numbers
+   as the enumerated values.
+
+10.  References
+
+   [AH]                    Kent, S. and R. Atkinson, "IP Authentication
+                           Header (AH)", RFC 2402, November 1998.
+
+   [CHAP]                  Simpson, J.,  "PPP Challenge Handshake
+                           Authentication Protocol (CHAP)", RFC 1994,
+                           August 1996.
+
+   [CONGEST]               Floyd, S., "Congestion Control Principles",
+                           RFC 2914, Sept. 2000.
+
+   [EAP]                   Blunk, L. and J. Vollbrecht, "PPP Extensible
+                           Authentication Protocol (EAP)", RFC 2284,
+                           March 1998.
+
+   [ESP]                   Kent, S. and R. Atkinson, "IP Encapsulating
+                           Security Payload (ESP)", RFC 2406, November
+                           1998.
+
+   [KEYWORDS]              Bradner, S., "Key words for use in RFCs to
+                           Indicate Requirement Levels", BCP 14, RFC
+                           2119, March 1997.
+
+   [KERBEROS]              Kohl, J. and C. Neuman, "The Kerberos Network
+                           Authentication Service (V5)", RFC 1510,
+                           September 1993.
+
+
+
+Beadles & Mitton             Informational                     [Page 14]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+   [IPV6]                  Deering, S. and R. Hinden, "Internet
+                           Protocol, Version 6 (IPv6) Specification",
+                           RFC 2460, December 1998.
+
+   [L2TP]                  Townsley, W., Valencia, A., Rubens, A., Pall,
+                           G., Zorn, G. and B. Plater, "Layer Two
+                           Tunneling Protocol (L2TP)", RFC 2661, August
+                           1999.
+
+   [NAI]                   Aboba, B. and M. Beadles, "The Network Access
+                           Identifier", RFC 2486, January 1999.
+
+   [NAS-MODEL]             Mitton, D. and M. Beadles, "Network Access
+                           Server Requirements Next Generation
+                           (NASREQNG) NAS Model", RFC 2881, July 2000.
+
+   [NAS-EXT]               Mitton, D., "Network Access Servers
+                           Requirements: Extended RADIUS Practices", RFC
+                           2882, July 2000.
+
+   [PPP]                   Simpson, W., "The Point-to-Point Protocol
+                           (PPP)", STD 51, RFC 1661, July 1994.
+
+   [PPPOE]                 Mamakos, L., Lidl, K., Evarts, J., Carrel,
+                           D., Simone, D. and R. Wheeler, "A Method for
+                           Transmitting PPP Over Ethernet (PPPoE)", RFC
+                           2516, February 1999.
+
+   [ROUTING-REQUIREMENTS]  Baker, F., "Requirements for IP Version 4
+                           Routers", RFC 1812, June 1995.
+
+   [TELNET]                Postel, J. and J. Reynolds, "Telnet Protocol
+                           Specification", STD 8, RFC 854, May 1983.
+
+   [RFC 2277]              Alvestrand, H., "IETF Policy on Character
+                           Sets and Languages", BCP 18, RFC 2277,
+                           January 1998.
+
+   [X.509]                 ITU-T Recommendation X.509 (1997 E):
+                           Information Technology - Open Systems
+                           Interconnection - The Directory:
+                           Authentication Framework, June 1997.
+
+   [RADIUS]                Rigney, C., Rubens. A., Simpson, W. and S.
+                           Willens, "Remote Authentication Dial In User
+                           Service (RADIUS)", RFC 2138, April 1997.
+
+
+
+
+
+Beadles & Mitton             Informational                     [Page 15]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+   [RADIUS-ACCOUNTING]     Rigney, C., "RADIUS Accounting", RFC 2139,
+                           April 1997.
+
+   [ROAMING-REQUIREMENTS]  Aboba, B. and G. Zorn, "Criteria for
+                           Evaluating Roaming Protocols", RFC 2477,
+                           January 1999.
+
+11.  Authors' Addresses
+
+   Mark Anthony Beadles
+   SmartPipes, Inc.
+   565 Metro Place South Suite 300
+   Dublin, OH 43017
+
+   Phone: 614-923-6200
+
+
+   David Mitton
+   Nortel Networks
+   880 Technology Park Drive
+   Billerica, MA 01821
+
+   Phone: 978-288-4570
+   EMail: dmitton@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Beadles & Mitton             Informational                     [Page 16]
+
+RFC 3169         Criteria for Evaluating NAS Protocols    September 2001
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Beadles & Mitton             Informational                     [Page 17]
+