rfc3169.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

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