[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 3169

NASREQ Working Group                                          M. Beadles
INTERNET-DRAFT                                          SmartPipes, Inc.
Category: Informational                                        D. Mitton
7 June 2000                                              Nortel Networks


        Criteria for Evaluating Network Access Server Protocols
                   draft-ietf-nasreq-criteria-05.txt


1.  Status of this Memo


This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups.  Note that other groups may also distribute working doc-
uments as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

The  distribution  of  this draft is unlimited.  It is filed as <draft-
ietf-nasreq-criteria-05.txt> and expires December 2000. Please send com-
ments to the authors.


2.  Copyright Statement


Copyright (C) The Internet Society 2000.  All Rights Reserved.


3.  Abstract


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 Management pro-
tocols.  Primary attention is given to setting requirements for AAA



Beadles, Mitton               Informational                     [Page 1]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


protocols, since that space is currently the least well defined.


4.  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].


5.  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 Manage-
ment 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 require-
ments, may be found in [NAS-MODEL].


6.  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] carried over a
telephony protocol.  Second are broadband pseudo-telephony access proto-
cols, 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.







Beadles, Mitton               Informational                     [Page 2]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


7.  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 pro-
tocol 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 pro-
tocol requirements imposed by virtue of the device being a NAS.

8.  AAA Protocol Requirements



8.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 authentica-
tion/authorization are not necessarily the same as those for account-
ing/auditing.  An AAA protocol suite MAY use the same transport and pro-
tocol for both functions, but this is not strictly required.


8.1.1.  Transport requirements



8.1.1.1.  Transport independence


The AAA protocol MUST be transport independent, and MUST be capable of
using both TCP and UDP as a transport.  Additionally, the AAA protocol
SHOULD be designed to easily support any new transport protocols devel-
oped by the Internet standards community.


8.1.1.2.  Scalability


Very large scale NAS's that serve up to thousands of simultaneous ses-
sions 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.



Beadles, Mitton               Informational                     [Page 3]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


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 accomodate reasonable current and future
bandwidth usage, and computational processes with high overhead that
must be performed frequently.


8.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 pro-
tocol to deliver a message or messages within a known and controllable
time period, so it can engage retransmission or server fail-over pro-
cesses.  The reliability and robustness of authentication requests MUST
be predicable 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.


8.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 impor-
tance; for example, dial roaming is now a nearly ubiquitous service.
Therefore, the AAA protocol MUST support AAA 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



Beadles, Mitton               Informational                     [Page 4]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


support proxy, and in addition SHOULD support other multi-domain rela-
tionships such as brokering and referral.

The AAA protocol MUST also meet the protocol requirements specified in
[ROAMING-REQUIREMENTS].


8.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 pro-
tocol 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).


8.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].


8.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 sup-
port this complete set of attributes, then an extension to that protocol
MUST be defined which supports this set.








Beadles, Mitton               Informational                     [Page 5]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


8.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 develop-
ment, 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.


8.1.3.  Security Requirements



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


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


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



Beadles, Mitton               Informational                     [Page 6]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


revocation of keys.


8.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 dif-
ferent administrative domains. Therefore, the AAA protocol 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.


8.2.  Authentication and User Security Requirements



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


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


8.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]


8.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:




Beadles, Mitton               Informational                     [Page 7]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


     -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


8.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 proto-
col MUST provide some support for addition of new authentication creden-
tial types.


8.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:


8.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 authenticatee and the authenticator for the following authentication
protocols:

     -PPP Password Authentication Protocol [PPP]

     -PPP Challenge Handshake Authentication Protocol [CHAP]

     -PPP Extensible Authentication Protocol [EAP]


8.2.2.2.  User Identification


The following are common types of credentials used for user identifica-
tion.  The AAA protocol MUST be able to carry the following types of
identity credentials:



Beadles, Mitton               Informational                     [Page 8]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


     -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 autho-
rization by identification or assertion only.


8.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 authenti-
cating credentials at a minimum:

     -A secret or password.

     -A response to a challenge presented by the NAS to the user

     -A one-time password

     -An X.509 digital certificate [X.509]

     -A Kerberos v5 ticket [KERBEROS]


8.2.3.  Authentication Protocol Security Requirements



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








Beadles, Mitton               Informational                     [Page 9]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


8.3.  Authorization, Policy, and Resource management



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


8.3.1.1.  Dynamic Authorization


The AAA protocol MUST support dynamic re-authorization at any time dur-
ing 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.


8.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 time-
outs and explicit interim status and disconnect messages.    There
should not be any dependencies on the Accounting message stream, as per
current practices.


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 autho-
rization features to change and revoke authorization status.







Beadles, Mitton               Informational                    [Page 10]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


8.3.2.  Authorization Attribute Requirements



8.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 fol-
lowing parameters:

     -Time/day restrictions.  The AAA protocol MUST be able to provide
     an unambiguous time stamp, NAS time zone indication, and date indi-
     cation 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 determi-
     nation through an out-of-band mechanism.


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

     -Protocol Filter application:  The AAA protocol MUST provide a
     means of applying IP protocol filters to user sessions.  Two dif-
     ferent methods MUST be supported.




Beadles, Mitton               Informational                    [Page 11]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


     First, the AAA protocol MUST provide a means of selecting a proto-
     col 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 infor-
     mation by address range, TCP/UDP port number, and IP protocol num-
     ber 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.


8.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 collect-
ing resource state information, and controlling resource allocation for
the following types of network resources.

     -Network bandwidth usage per session, including multilink sessions.

     -Access port usage, including concurrent usage and usage pools.

     -Connect time.




Beadles, Mitton               Informational                    [Page 12]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


     -IP Addresses and pools.

     -Compulsory tunnel limits.


8.3.3.  Authorization Protocol Security Requirements



8.3.3.1.  Security of Compulsory Tunnel Credentials


When an AAA protocol passes credentials that will be used to authenti-
cate compulsory tunnels, the AAA protocol MUST provide a means of secur-
ing the credentials from end-to-end of the AAA conversation.  The AAA
protocol MUST also provide protection against replay attacks in this
situation.


8.4.  Accounting and Auditing Requirements



8.4.1.  Accounting Protocol Requirements



8.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 func-
tions 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).


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




Beadles, Mitton               Informational                    [Page 13]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


8.4.1.3.  Batch Accounting


The AAA protocol SHOULD also support delivery of stored accounting and
auditing information in batches (non-real time).


8.4.1.4.  Accounting Time Stamps


There may be delays associated with the delivery of accounting informa-
tion.  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.


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


8.4.1.6.  On-Demand Accounting


NAS operators need to maintain an accurate view onto the status of ses-
sions served by a NAS, even through failure of an AAA server.  There-
fore, the AAA protocol MUST support a means of requesting current ses-
sion state and accounting from the NAS on demand.




Beadles, Mitton               Informational                    [Page 14]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


8.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 ses-
     sion.

     -The duration of the session.

     -The cumulative number of bytes sent by the user during the ses-
     sion.

     -The cumulative number of bytes received by the user during the
     session.

     -The cumulative number of packets sent by the user during the ses-
     sion.

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


8.4.3.  Accounting Protocol Security Requirements



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


8.4.3.2.  Auditibility


Network operators use accounting data for network planning, resource
management, and other business-critical functions that require confi-
dence in the correctness of this data. The AAA protocol SHOULD provide a



Beadles, Mitton               Informational                    [Page 15]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


mechanism to ensure that the source of accounting data cannot easily
repudiate this data after transmission.


9.  Device Management Protocols


This document does not specify any requirements for device management
protocols.


10.  Acknowledgments

Many of the requirements in this document first took form in Glen Zorn's
"Yet Another Authentication Protocol (YAAP)" document, for which grate-
ful acknowledgment is made.


11.  Security considerations


See above for security requirements for the NAS AAA protocol.



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 administra-
tive domains.  Network operators are advised take this into considera-
tion when deploying NAS's and AAA Servers.


12.  IANA Considerations


This document does not directly specify any IANA considerations.  How-
ever, 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 pro-
cess.

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 enu-
merated values.




Beadles, Mitton               Informational                    [Page 16]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


13.  References


[KEYWORDS] S. Bradner.  "Key words for use in RFCs to Indicate Require-
ment Levels."  RFC 2119, March 1997.

[NAS-MODEL] D. Mitton, M. Beadles.  "Network Access Server Requirements
Next Generation (NASREQNG) NAS Model." draft-ietf-nasreq-nas-
model-01.txt,  Work in progress.

[PPPOE] L. Mamakos, et al.  "A Method for Transmitting PPP Over Ethernet
(PPPoE)."  RFC 2516, February 1999.

[L2TP] W. M. Townsley, et al.  "Layer Two Tunneling Protocol  (L2TP)."
RFC 2661, August 1999.

[PPP] W.  Simpson.  "The Point-to-Point Protocol (PPP)."  RFC 1661, Day-
dreamer, July 1994.

[TELNET] J. Postel, J. Reynolds.  "Telnet Protocol Specification."  STD
8, RFC 854, May 1983.

[ROUTING-REQUIREMENTS] F.  Baker.   "Requirements for IP Version 4
Routers."  RFC 1812, June 1995.

[IPV6] S. Deering, R. Hinden.  "Internet Protocol, Version 6 (IPv6)
Specification."  RFC 2460, December 1998.

[RFC 2277] H. Alvestrand.  "IETF Policy on Character Sets and Lan-
guages."  RFC 2277, January 1998.

[CHAP] W. Simpson.  "PPP Challenge Handshake Authentication Protocol
(CHAP)."  RFC 1994, August 1996.

[EAP] L. Blunk, J. Vollbrecht.  "PPP Extensible Authentication Protocol
(EAP)."  RFC 2284, March 1998.

[NAI] B. Aboba, M. Beadles.  "The Network Access Identifier."  RFC 2486,
 January 1999.

[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology -
Open Systems Interconnection - The Directory: Authentication Framework,
June 1997.

[KERBEROS] J. Kohl, C. Neuman.  "The Kerberos Network Authentication
Service (V5)."  RFC 1510, September 1993.

[ESP] S. Kent, R. Atkinson.  "IP Encapsulating Security Payload (ESP)."



Beadles, Mitton               Informational                    [Page 17]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


RFC 2406, November 1998.

[AH] S. Kent, R. Atkinson.  "IP Authentication Header (AH)."  RFC 2402,
November 1998.

[ROAMING-REQUIREMENTS] B. Aboba, G. Zorn.   "Criteria for Evaluating
Roaming Protocols."  RFC 2477, January 1999.

[RADIUS] C. Rigney, et al.,  "Remote Authentication Dial In User Service
(RADIUS)"  RFC 2138, April 1997

[RADIUS-ACCOUNTING]  C. Rigney,     "RADIUS Accounting", RFC 2139, April
1997



14.  Author's Addresses



Mark Anthony Beadles
SmartPipes, Inc.
565 Metro Place South
Suite 300
Dublin, OH 43017

Phone: 614-327-8046
EMail: mbeadles@smartpipes.com

David Mitton
Nortel Networks
880 Technology Park Drive
Billerica, MA 01821

Phone: 978-288-4570
EMail: dmitton@nortelnetworks.com



15.  Full Copyright Statement


Copyright (C) The Internet Society (2000).  All Rights Reserved.

This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided



Beadles, Mitton               Informational                    [Page 18]

INTERNET-DRAFT         Criteria for NAS Protocols            7 June 2000


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 ref-
erences 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 ENGINEER-
ING 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 MERCHANTABIL-
ITY OR FITNESS FOR A PARTICULAR PURPOSE."


16.  Expiration Date


This document is filed as <draft-ietf-nasreq-criteria-05.txt>, and
expires December 2000.





























Beadles, Mitton               Informational                    [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/