One document matched: draft-natale-aaa-snmpv3-comp-00.txt
AAA B. Natale
Internet Draft ACE*COMM
<draft-natale-aaa-snmpv3-comp-00.txt> June 2000
Comparison of SNMPv3 Against AAA Network Access Requirements
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 documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents 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.
2. Abstract
This document presents an overview of SNMPv3 compliance with the AAA
protocol requirements for network access as stipulated in the
"Network Access AAA Evaluation Criteria" Internet Draft dated April
26, 2000 [1]. SNMPv3 protocol features and capabilities directly
support many of the AAA requirements. In addition, the more
sophisticated management model (see Section 5, below) now underlying
SNMP -- which has evolved from the original model introduced in the
late 1980s under the guidance of extensive use in the field --
enables the design, development, and deployment of more
sophisticated management applications geared to the overall body of
AAA protocol requirements (or sub-sets thereof).
3. Change history
00 revision: Initial version, published for quick review and comment
by interested parties to meet the AAA response deadline of June 1,
2000.
4. Introduction
This document presents an overview of SNMPv3 compliance with the AAA
protocol requirements for network access as stipulated in [1].
Natale Expires December 2000 1
INTERNET-DRAFT SNMPv3 for AAA June 2000
SNMPv3 protocol features and capabilities directly support many of
the AAA requirements. In addition, the contemporary management
model (see Section 5, below) now underlying SNMP -- which has
evolved from the original model introduced in the late 1980s under
the guidance of extensive use in the field -- enables the design,
development, and deployment of more sophisticated management
applications geared to the overall body of AAA protocol requirements
(or sub-sets thereof).
4.1. Requirements language
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in RFC 2119.
4.2. Terminology
This document describes the compliance status of version 3 of the
Simple Network Management Protocol ("SNMPv3") with respect to the
known AAA requirements as stated in [1] (aka [ACCT-RQTS], with
relevant elaborations in [2] (aka [ROAMOPS]), [3] (aka [NASREQ]),
[4], and [5] (aka [MOBILE IP]).
SNMPv3 is defined by the following documents:
RFC2570, "Introduction to Version 3 of the Internet-standard
Network Management Framework". [6]
RFC2571, "An Architecture for Describing SNMP Management
Frameworks". [7]
RFC2572, "Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)". [8]
RFC2573, "SNMP Applications". [9] (aka [APPS])
RFC2574, "User-based Security Model (USM) for version 3 of
the Simple Network Management Protocol (SNMPv3)".
[10] (aka [USM])
RFC2575, "View-based Access Control Model (VACM) for the
Simple Network Management Protocol (SNMP)". [11]
(aka [VACM])
RFC2576, "Coexistence between Version 1, Version 2, and
Version 3 of the Internet-standard Network
Management Framework". [12]
SNMPv3 is a protocol with which management entities communicate with
each other about management operations performed on managed objects.
Natale Expires December 2000 2
INTERNET-DRAFT SNMPv3 for AAA June 2000
The managed objects available for the set of management operations
supported between a given pair of SNMPv3 entities logically reside
in a virtual information store known as a management information
base (MIB). The logical structure of the data store and the
relevant attributes of the managed objects supported by it
are defined using an adapted subset of the OSI ASN.1 specification
language known as the Structure of Management Information (SMI).
The current version of the SMI is version 2 ("SMIv2"). This is the
version referenced by this document.
SMIv2 is defined by the following documents:
RFC2578, "Structure of Management Information Version 2
(SMIv2)". [13]
RFC2579, "Textual Conventions for SMIv2". [14]
RFC2580, "Conformance Statements for SMIv2". [15]
For the purposes of this document, "SNMPv3" is intended to subsume
"SMIv2". Furthermore, any otherwise unqualified references to
"SNMP" in this document are intended to refer to "SNMPv3" only.
That is, references to earlier versions of SNMP (i.e., SNMPv1 or
SNMPv2c), will be made explicit by saying "SNMPv1" or "SNMPv2c", as
the case may be. This is also true for the term "SMI" and its
previous version, "SMIv1".
The SNMPv3 AAA protocol submission consists of the ten RFCs
identified above in this section.
5. Compliance Summary
The compliance information provided in the following sections of
this document maps directly to the tables of requirements presented
in [1]. As a result, this compliance information represents a
summary view of both AAA requirements statements and the
corresponding SNMPv3 compliance statements. Substantial additional
detail on both sides of the equations will likely be needed to form
a precise operational understanding of the requirements and the
role that SNMPv3 plays in satisfying them. However, the goal of
this document is merely to establish the viability, validity, and
value of SNMPv3 as a constituent element of an overall Internet
standards based approach to meeting the stated AAA requirements.
That is, the technologies and operations encompassed by the AAA
triad -- authentication, authorization, and accounting -- cover a
large span of multi-dimensional "problem space". Also, some of the
stated requirements (aka, "evaluation criteria") seem to apply at a
protocol level, while others seem to apply to a service level (i.e.,
a level which uses a protocol...e.g., as an SNMP "engine" uses the
SNMPv3 protocol) and others yet to an application level (i.e., a
Natale Expires December 2000 3
INTERNET-DRAFT SNMPv3 for AAA June 2000
level which uses such services...e.g., an SNMPv3 command generator
entity). Therefore, it may be unrealistic to expect a single
protocol to define the corresponding "solution space".
This document takes the perspective that SNMPv3 can play a valuable
role in defining such a solution space for AAA, but only in
conjunction with a set (hopefully a small set) of other protocols
which will provide compliant functionality in those areas where
SNMPv3 either cannot (by virtue of its nature) or does not (by
virtue of its details) do so.
Furthermore, the role of SNMPv3 in the solution space for AAA must
be seen as consisting of the following elements:
- The SNMPv3 protocol itself.
- SNMP management entities.
- SNMP MIBs.
- A physical model of an SNMP management network.
- SNMP scalability mechanisms.
- On-going SNMP network management research and development.
The specific assessments made in the individual requirements
compliance sections later in this document incorporate an
expectation that all of the elements encompassed by the foregoing
list -- and briefly described in the sub-sections which immediately
follow this paragraph -- collaborate to define SNMPv3 compliance to
the AAA requirements. By and large, we are talking about components
and capabilities which exist today -- most of which have a long
record of validation in the field -- although we may need to put
some of the elements together in slightly different ways than we
have in the past and some new derivations from model elements
may need to be constructed from these components.
5.1. The SNMPv3 protocol itself
Over and above the core operational capabilities of previous
versions of SNMP, SNMPv3 provides for the following security
services [USM]:
- Data integrity: Assurance that data has not been altered or
destroyed in an unauthorized manner, nor have data sequences
been altered to an extent greater than can occur non-
maliciously.
- Data origin authentication: Assurance that the claimed
identity of the user on whose behalf received data was
originated is corroborated.
Natale Expires December 2000 4
INTERNET-DRAFT SNMPv3 for AAA June 2000
- Data confidentiality: Assurance that information is not made
available or disclosed to unauthorized individuals, entities,
or processes.
- Message timeliness and limited replay protection: Assurance
that a message whose generation time is outside of a specified
time window is not accepted.
...and data object security services [VACM]:
- Access control: Assurance that a specific type of access
(read, write, notify) to a particular object (instance) is
authorized or is otherwise disallowed.
5.2. SNMP management entities [APPS]
As opposed to the traditional view of SNMP management entities as
either "agents" or "managers", SNMPv3 views an SNMP management
entity as (among other things) any combination of the following
types of application-layer functionality:
- Command generators: Initiate read- and/or write-class
messages.
- Command responders: Respond to read- and/or write-class
messages.
- Notification originators: Originate notification-class
messages.
- Notification receivers: Receive notification-class messages.
- Proxy forwarders: Forward SNMP messages.
This refinement facilitates the design, development, and deployment
of both more focused (e.g., notification receivers) and more complex
(e.g., "dual-role entities", "mid-level managers") SNMP management
entities, providing a richer set of solutions to the user community.
This broader scope for application modeling serves to enlarge the
range of AAA operational requirements that SNMPv3 can viably
address. Furthermore, additional SNMP application types can be
defined as well -- we are not limited to only the five types already
defined. Thus, it is feasible to consider new SNMP application
types corresponding to specialized AAA processes, as well as
possible new SNMP PDU formats optimized for those processes.
5.3. SNMP MIBs
As opposed to the traditional view of SNMP MIBs as consisting of
primarily (to exclusively) atomic objects representing individual
Natale Expires December 2000 5
INTERNET-DRAFT SNMPv3 for AAA June 2000
discrete data items (or collection of such items into conceptual
rows and tables), a more current view of efficient and effective
composition calls for the design and inclusion of higher-level
objects that can represent aggregations of discrete data items,
virtual objects, result sets, states, actions, and so forth.
Such more powerful MIBs exhibit a symbiotic relationship with the
more sophisticated SNMP applications architectures described above
in that they are both enabled by those architectural possibilities
and, in turn, drive the development of the more capable applications
which implement such architectures.
5.4. A physical model of an SNMP management network
The origins of SNMP -- and especially the original motivation for
the "Simple" in its moniker -- can be traced directly to one of its
underlying tenets...indeed, its "fundamental axiom" [ROSE, p. 71]:
"The impact of adding network management to managed nodes
must be minimal, reflecting a lowest common denominator."
While arguably correct for its time, this axiom is no longer valid
in its literal rendition for the general case. Managed nodes (now
"managed elements", to reflect the more diverse range of things
which can and/or should be managed via SNMP) have become more
capable (CPU, memory, interface speeds, etc.). More significantly,
the potential benefits (in terms of market share, payoff, ROI, and
similar economic concepts) of adding management features to a
managed element are now seen as being worth some degree of added
cost (e.g., monetary and/or impact on other aspects of the element).
Perhaps the following may be a valid re-statement of the axiom for
current circumstances:
"The total cost (economic and operational) of adding network
management capabilities to managed elements must be appropriate,
reflecting the expected benefits (direct and/or indirect)."
By and large, this change in perspective mirrors changes in the
larger economic, technological, and sociological landscape and does
not imply any kind of flaw in the fundamental axiom for an earlier
point in time.
5.5. SNMP scalability mechanisms
The contemporary SNMP solutions framework includes multiple, non-
exclusionary approaches to scalability, including:
- An IETF standard for extensible SNMP agents ("AgentX")
- A set of IETF standard MIBs for distributed management
("DISMAN")
Natale Expires December 2000 6
INTERNET-DRAFT SNMPv3 for AAA June 2000
- Proxy applications
5.5.1. An IETF standard for extensible SNMP agents ("AgentX")
An extensible SNMP agent environment is one in which an SNMP entity
known as a "master agent" provides the external interface (for both
in-coming and out-going SNMP messages) to other SNMP entities on
behalf of a set of "sub-agents" that need not deal with SNMP
directly. The purpose of an extensible SNMP agent environment is
twofold: First, to provide the infrastructure for shared use of a
well-known SNMP port by multiple, independently developed agent
entities; and second, they make it technically easier and
economically more viable for component suppliers to provide an SNMP
management interface to those components.
Extensible SNMP agent environments have been available for a long
time from a number of suppliers and have played an important role
in the broad deployment of SNMP solutions. However, the lack of an
IETF standard protocol for agent extensibility was seen as a
probable barrier to the widest possible deployment of such
solutions. Hence, the IETF eventually standardized the "AgentX"
protocol to fill this need. The relevant documents are:
RFC2471, "Agent Extensibility (AgentX) Protocol Version 1".
[16] (aka [AGENTX])
RFC2472, "Definitions of Managed Objects for Extensible SNMP
Agents". [17] (aka [AGENTX-MIB])
Extensible SNMP agents can play important roles in the enabling of
various kinds of important AAA applications, especially (but not
only) those involved in data collection, filtering, aggregation,
analysis, packaging, and forwarding.
5.5.2. DISMAN (distribution of management functionality)
TBD.
5.5.3. SNMP Proxy
TDB.
5.6. On-going SNMP network management research and development
The IRTF NMRG has proposed a number of enhancements to SNMP to
improve its suitability for certain AAA applications, especially in
the area of accounting services. These are described and discussed
in ample detail in Section 7.3 of [ACCT-MGMT]. Collectively, we
will refer to them as "the NMRG extensions". They include:
- an SNMP-over-TCP transport mapping [NMRG-1]
Natale Expires December 2000 7
INTERNET-DRAFT SNMPv3 for AAA June 2000
- SNMP payload compression [NMRG-2]
- addition of a "get subtree" retrieval capability [NMRG-3]
Please note that these proposed changes are of an experimental
nature at this time and, for some of them, active discussion within
the SNMP community is underway. The present document takes the
perspective that -- while some or all of the NMRG extensions may be
beneficial in enhancing SNMP's role as an AAA protocol -- these
changes are not *required* to qualify SNMP as an important protocol
for use in the AAA solution set.
Finally, it must be noted that this document (as of rev -00) is an
initial draft. It has been authored by someone with far more
knowledge (albeit imperfect) of SNMP than of the range of AAA
requirements. And it has received helpful but limited prior review
by others who are more knowledgeable with respect to those
requirements. So, it is submitted in good faith as a working
document and revisions -- perhaps including significant corrections
-- are to be expected.
6. AAA/SNMPv3 Requirements/Compliance Tables
The AAA protocol evaluation criteria for network access are
summarized below in the following sub-sections, with the SNMPv3
compliance information reported for each one. Each criterion or
requirement is presented with the following virtual table header in
mind:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Sub-section title> | NASREQ | ROAMOPS | MOBILE | SNMPv3 |
| Requirements | | | IP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...where [NASREQ], [ROAMOPS], and [MOBILE IP] refer to the specific
requirements documents noted in the References section of this
document. Specific sections of the referenced documents are
indicated via the bracketed footnote number(s) which appear in the
cells and which correspond to the following list:
Footnotes:
[1] Section 4.2.1 of [ROAMOPS]
[2] Section 4.2.2 of [ROAMOPS]. Also see [8].
[3] Section 4.2.3 of [ROAMOPS]. Also see [14].
[4] Section 4.2.4 of [ROAMOPS].
[5] Section 4.2.5 of [ROAMOPS].
[6] Section 4.2.6 of [ROAMOPS].
[7] Section 4.3 of [ROAMOPS].
[8] Section 6 of [NASREQ]. Also see [6].
[9] Section 8.2.2.2 of [NASREQ]. Also see [14].
[10] Section 8.2.2.1 of [NASREQ]. Also see [14].
[11] Section 8.3.2.2 of [NASREQ]. Also see [7].
Natale Expires December 2000 8
INTERNET-DRAFT SNMPv3 for AAA June 2000
[12] Section 8.1.1 of [NASREQ].
[13] Section 8.1.4.4 of [NASREQ].
[14] Section 8.4.1.2 of [NASREQ].
[15] Section 8.4.2 of [NASREQ].
[16] Section 8.1.3 of [NASREQ].
[17] Section 8.2.1.2 of [NASREQ].
[18] Section 8.3.1.1 of [NASREQ].
[19] Section 8.3.2.1 of [NASREQ]. Also see [7].
[20] Section 8.3.2.3 of [NASREQ]. Also see [6], [7].
[21] Section 8.4.1.3 of [NASREQ].
[22] Section 8.4.1.1 of [NASREQ].
[23] Section 8.4.1.4 of [NASREQ].
[24] Section 8.4.3.1 of [NASREQ].
[25] Section 8.4.3.2 of [NASREQ].
[26] Section 8.2.3.1 of [NASREQ].
[27] Section 8.3.3.1 of [NASREQ].
[28] Section 8.1.4.1 of [NASREQ].
[29] Refer [PPP-IPCP]
[30] Section 3 of [MOBILE IP]
[31] Section 3.1 of [MOBILE IP]
[32] Section 4 of [MOBILE IP]
[33] Section 5 of [MOBILE IP]
[34] Section 5.1 of [MOBILE IP]
[35] Section 5.2 of [MOBILE IP]
[36] Section 5.3 of [MOBILE IP]
[37] Section 5.4 of [MOBILE IP]
[38] Section 5.5 of [MOBILE IP]
[39] Section 6 of [MOBILE IP]
[40] Section 3.1 of [TIA 45.6]
[41] Section 3.2.2 of [TIA 45.6]
[42] Section 8.2.2.2 of [NASREQ]
[43] Section 8.1.2.3 of [NASREQ]
[44] Section 8.1.2.2 of [NASREQ]
[45] Section 3.4 of [TIA 45.6]
[46] Section 4 of [TIA 45.6]
The minimum compliance level for each requirement, for each source
of the requirement, is shown in each cell in accordance with the
following meanings:
Key:
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
The SNMPv3 cell reports the summary status of SNMPv3 compliance
with the requirement(s) associated with each row and a reference to
the sub-section of this document where more details concerning this
assessment are given. The summary status entry denotes whether the
SNMPv3 protocol meets (T), partially meets (P), or does not meet (F)
Natale Expires December 2000 9
INTERNET-DRAFT SNMPv3 for AAA June 2000
the stated requirement(s). A small number of entries have a status
value of "?", indicating that the compliance or non-compliance of
SNMPv3 with the requirement could not be determined at this time
(mainly due to lack of understanding on the part of the author of
the "-00" version!).
It should be noted that the author of the "-00" version of this
document cannot claim expertise in many of the specific AAA
requirements listed in the following sections. Furthermore, the
vision he has of how SNMPv3 can be used to help form a compliant
AAA solution set requires sometimes creative use of all of the
SNMPv3 dimensions discussed in Section 5, above. While the
author has tried to make an honest judgment about SNMPv3
compliance with each requirement in the context of those
considerations, the results clearly suggest that more errors
were made on the side of compliance than of non-compliance.
It is anticipated (and hoped for) that subsequent review and
scrutiny by a wider audience of more expert readers will lead
to proper adjustments in the text.
6.1. General requirements
These requirements apply to all aspects of AAA and thus are
considered general requirements.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| General | NASREQ | ROAMOPS | MOBILE | SNMPv3 |
| Requirements | | | IP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scalability | M | M | M | T |
| | | | | 6.1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fail-over | M | | M | T |
| | | | | 6.1.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mutual auth | M | | M | T |
| AAA client/server | | | | 6.1.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmission level | | M | S | T |
| security | | | | 6.1.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data object | M | M | S | T |
| Confidentiality | | | | 6.1.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data object | M | M | M | P |
| Integrity | | | | 6.1.6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate | M | | S | T |
| Transport | | | | 6.1.7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliable AAA | M | | M | P |
| transport mechanism | | | | 6.1.8 |
Natale Expires December 2000 10
INTERNET-DRAFT SNMPv3 for AAA June 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Run Over IPv4 | M | M | M | T |
| | | | | 6.1.9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Run Over IPv6 | M | | S | P |
| | | | | 6.1.10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Support Proxy and | M | | M | P |
| Routing Brokers | | | | 6.1.11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auditability | S | | | F |
| | | | | 6.1.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared secret not | S | O | O/M | T |
| required | | | | 6.1.13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ability to carry | M | | S | T |
| service-specific attr.| | | | 6.1.14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.1. Scalability
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scalability | M | M | M | T |
| | 12 | 3 | 30 39 | |
|-----------------------------------------------------------------|
| [a] The AAA protocol must be capable of supporting millions of |
| users and tens of thousands of simultaneous requests. The AAA |
| architecture and protocol MUST be capable of supporting tens of |
| thousands of devices, AAA servers, proxies and brokers. |
|-----------------------------------------------------------------|
| SNMPv3 satisfies this requirement. SNMP has existence proofs of|
| supporting networks with tens of thousands of managed nodes. |
| the text in the note (a) referring to "millions of users" and |
| "tens of thousands of simultaneous requests" does not seem |
| relevant to the envisioned role(s) for SNMPv3 in AAA, which will|
| likely be tied to administrative and operating domains of |
| smaller (yet large in an absolute sense) scope. |
| |
| To be sure these numbers do mean that distributed management |
| facilities for collection, aggregation, filtering, analysis, |
| packaging, forwarding, and so forth will be critical in such an |
| environment. The DISMAN series of MIBs suggest that SNMP can be|
| deployed in ways that will scale to meet the needs of networks |
| of the sizes required for AAA. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.2. Fail-over
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fail-over | M | | M | T |
| | 12 | | 31 | |
Natale Expires December 2000 11
INTERNET-DRAFT SNMPv3 for AAA June 2000
|-----------------------------------------------------------------|
| [b] In the event of failure to communicate with a given server,|
| the protocol must provide a mechanism to change service to |
| another backup or secondary server. |
|-----------------------------------------------------------------|
| SNMP satisfies this requirement via the application-layer |
| timeout detection mechanisms normally built into SNMP engines |
| and/or higher-|order SNMP entities. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.3. Mutual authentication
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mutual auth | M | | M | T |
| AAA client/server | 16 | | 30 | |
|-----------------------------------------------------------------|
| [c] This requirement refers to the ability to support mutual |
| authentication between the AAA client and server. |
|-----------------------------------------------------------------|
| SNMPv3 security features satisfy this requirement. |
| The requirement is that a server can explicitly authenticate a |
| client, and that a client can explicitly authenticate a server. |
| SNMP does this in USM by the use of shared keys, timeliness |
| checking, message IDs sequencing, etc. New security models may |
| add new mechanisms as well. |
| Also, the use of protocols and methods other than SNMPv3 by AAA |
| clients and servers is not precluded by the envisioned use of |
| SNMPv3 for AAA. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.4. Transmission level security
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmission level | | M | S | T |
| security | | 6 | 31 39 | |
|-----------------------------------------------------------------|
| [d] The AAA protocol requires authentication, integrity |
| protection and confidentiality at the transmission layer. This |
| security model is also referred to as hop-by-hop security, |
| whereas the security is established between two communicating |
| peers. All of the security is removed when the AAA message is |
| processed by a receiving AAA entity. |
|-----------------------------------------------------------------|
| SNMPv3 security features satisfy this requirement. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.5. Data object confidentiality
It is important to note that this draft (throughout) interprets the
terms "data object" and "attribute" (as used in the AAA requirements
documents) as more or less synonymous.
Natale Expires December 2000 12
INTERNET-DRAFT SNMPv3 for AAA June 2000
In mapping such data objects/attributes to SNMPv3 concepts --
especially where protection (integrity and/or confidentiality) is
required -- this draft envisions a corresponding set of SNMP "MIB
objects". These may be thought of as something like:
- a group of related MIB objects (e.g., MIB sub-tree branch)
- a row of objects in a MIB table
- an opaque structure-like object comprised of a set of
MIB objects
- ...or anything that works better.
The key idea is that such an "AAA data object" is actually a fairly
"complex" life form, not a simple single object with a name and a
value. Furthermore, among the set of MIB objects comprising such an
AAA data object would be the necessary security parameters to allow
for integrity and confidentiality, including timeliness
verification.
The bottom line is that individual AAA data object security is
independent from the overall SNMPv3 message security. An easy way
to envision this is to imagine USM being applied to such a set of
MIB objects with a different set of valid securityNames from those
used at the message processing usmUserTable level. That is surely
not the only way to implement this -- and not necessarily the one
to be recommended -- but it might be the easiest to envision (and
critique!) quickly.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data object | M | M | S/M | T |
| Confidentiality | 26 | 6 | 33/40 | |
|-----------------------------------------------------------------|
| [e] The AAA protocol requires confidentiality at the object |
| level, where an object consists of one or more attributes. |
| Object level confidentiality implies that only the target AAA |
| entity for whom the data is ultimately destined may decrypt the |
| data, regardless of the fact that the message may traverse one |
| or more intermediate AAA entities (e.g. proxies, brokers). |
|-----------------------------------------------------------------|
| SNMPv3 security features (including the use of VACM for the |
| "attribute-by-attribute" stipulation in Sec. 4.2.6 of [ROAMOPS])|
| satisfy this requirement. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.6. Data object integrity
See explanatory comments in 6.1.5.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data object | M | M | M | P |
Natale Expires December 2000 13
INTERNET-DRAFT SNMPv3 for AAA June 2000
| Integrity | 16 | 6 | 31 39 | |
|-----------------------------------------------------------------|
| [f] The AAA protocol requires authentication and integrity |
| protection at the object level, which consists of one or more |
| attributes. Object level authentication must be persistent |
| across one or more intermediate AAA entity (e.g. proxy, broker, |
| etc), meaning that any AAA entity in a proxy chain may verify |
| the authentication. This implies that data that is covered by |
| object level security CANNOT be modified by intermediate |
| servers. |
|-----------------------------------------------------------------|
| There appear to be at least two different requirements in this |
| statement. On the one hand, SNMPv3 security features satisfy |
| the requirement for protection against modification of object |
| data by intermediate servers between two target end-points. On |
| the other hand, SNMPv3 security features also provide for |
| ensuring that object level authentication is persistent across |
| one or more intermediate AAA entities. But SNMPv3 security |
| would not, therefore, enable those intermediate AAA entities to |
| directly verify the authentication. Such a capability could |
| perhaps be enabled by wrapping an SNMPv3 payload inside another |
| SNMPv3 message, with the "outer wrapper" message carrying |
| authentication parameters verifiable by the next intermediate |
| entity. This document does not propose such a solution, |
| however, electing, instead, to leave SNMPv3 compliance with this|
| partial requirement unclear. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.7. Certificate transport
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate | M | | S/M | T |
| transport | 42 | |31,33/46 | |
|-----------------------------------------------------------------|
| [g] The AAA protocol MUST be capable of transporting |
| certificates. This requirement is intended as an optimization, |
| in lieu of requiring that an out-of-band protocol be used to |
| fetch certificates. |
|-----------------------------------------------------------------|
| Given resolution of concerns about certificate sizes relative to|
| SNMPv3 transport capacities and given the definition of MIB |
| objects for certificate transport, SNMPv3 is capable of |
| transporting certificate data. However, it is worth considering|
| whether the potential cost of this optimization truly offsets |
| the potential benefits of a specialized protocol or service to |
| handle transport and other certificate-related operations. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.8. Reliable AAA transport mechanism
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliable AAA | M | | M | P |
Natale Expires December 2000 14
INTERNET-DRAFT SNMPv3 for AAA June 2000
| transport mechanism | 22 | | 31 32 | |
|-----------------------------------------------------------------|
| [h] This requirement refers to resilience against packet loss, |
| including: |
| |
| 1. Hop-by-hop retransmission and fail-over so that reliability |
| does not solely depend on single hop transport |
| retransmission. |
| 2. Control of the retransmission mechanism by the AAA |
| application. |
| 3. Acknowledgment by the transport that a message was delivered |
| successfully, separate from message semantics or syntax |
| evaluation. |
| 4. Piggy-backing of acknowledgments in AAA messages. |
| 5. Timely delivery of AAA responses. |
|-----------------------------------------------------------------|
| Standard SNMPv3 over UDP meets some of these requirements; work |
| outlined in the NMRG enhancements for running SNMP over TCP (and|
| possibly other connection-oriented and/or "reliable" transports)|
| may satisfy additional aspects of this set of requirements: |
| |
| 1. Unsure what this means exactly. SNMPv3 application level |
| retransmission logic is typically end-to-end. |
| 2. This requirement is typically met by SNMPv3 engines and/or |
| application entities. |
| 3. For standard SNMPv3 over UDP, successfully delivered request|
| messages are "acknowledged" via a response message (where |
| "successfully delivered" means that it was received, parsed,|
| and authenticated without exception per the SNMPv3 elements |
| of procedure). |
| 4. SNMPv3 does not support piggy-backing of acknowledgements. |
| Furthermore, SNMPv3 logic questions the value of message |
| acknowledgment below the application level (i.e., what is |
| the value of knowing that a message was received but perhaps|
| not accepted or acted upon at the application level?). |
| 5. SNMPv3 imposes only moderate average overhead on its |
| payloads, and (based on extensive field experience with |
| earlier versions of SNMP) would not likely introduce a |
| performance bottleneck. The slowest part of a secure SNMPv3|
| transaction is the security processing which is performed |
| via protocols independent of SNMP (with the current defaults|
| being MD5 or SHA for authentication and DES for encryption |
| ...faster security models and/or protocols for use with |
| SNMPv3 may be introduced in the future). |
| |
| Finally, since SNMPv3 messages exhibit no intrinsic dependency |
| on the transport protocol used to carry them, SNMPv3 may be |
| malleable to running over any more reliable/capable/faster |
| transport layer protocol that the AAA standards may eventually |
| mandate. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Natale Expires December 2000 15
INTERNET-DRAFT SNMPv3 for AAA June 2000
6.1.9. Run over IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Run over IPv4 | M | M | M | T |
| | 11 | 1 | 17 | |
|-----------------------------------------------------------------|
| SNMPv3 satisfies this requirement. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.10. Run over IPv6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Run over IPv6 | M | | S | P |
| | 11 | 1 | 18 | |
|-----------------------------------------------------------------|
| Experimental versions of SNMPv3 currently satisfy this |
| requirement. Standardization of IPv6 support for SNMP is |
| underway and is expected to be straightforward (via new textual |
| conventions) for the protocol itself. SNMPv3 compliance with |
| this requirement can be expected when needed. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.11. Support proxy and routing brokers
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Support proxy and | M | | M | P |
| routing brokers | 12 | | 31 39 | |
|-----------------------------------------------------------------|
| [i] In the Mobile IP AAA architecture, brokers can be in the |
| forwarding path, in which case they act as transparent proxies |
| (proxy brokers). Alternatively, it is also possible to conceive|
| of brokers operating as certifying authorities outside of the |
| forwarding path (routing brokers). |
|-----------------------------------------------------------------|
| SNMPv3 proxy forwarding capabilities/applications appear to |
| satisfy this requirement. However, the issues raised wrt |
| authentication by intermediate AAA entities above (in Section |
| 6.1.6) may negate this apparent degree of compliance. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.12. Auditability
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auditability | S | | | F |
| | 25 | | | |
|-----------------------------------------------------------------|
| [j] An auditable process is one in which it is possible to |
| definitively determine what actions have been performed on AAA |
| packets as they travel from the home AAA server to the network |
| device and back. |
|-----------------------------------------------------------------|
| SNMPv3 does not incorporate auditability in the protocol itself.|
Natale Expires December 2000 16
INTERNET-DRAFT SNMPv3 for AAA June 2000
| SNMPv3 entities could satisfy this requirement in a variety of |
| ways at the application level. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.13. Shared secret not required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared secret | S | O | O/M | T |
| not required | 28 | 6 |34,39/40 | |
|-----------------------------------------------------------------|
| [k] The AAA protocol MUST allow communication to be secured. |
| However, the AAA protocol MUST also allow an underlying security|
| service (e.g. IP Security) to be used. When the latter is used, |
| the former MUST NOT be required. |
|-----------------------------------------------------------------|
| Use of the security features of SNMPv3 is optional. |
| |
| Moreover, the structure of SNMPv3 messages enables them to be |
| sent -- with or without using the security features -- over a |
| secure lower-layer protocol (such as IPsec), given appropriate |
| corresponding end-point security facilities. |
| |
| Use of the full intrinsic SNMPv3 security does require shared |
| secrets between SNMPv3 end-point entities; however, the protocol|
| incorporates a localization scheme which mitigates the |
| scalability and management problems often associated with shared|
| secret systems. |
| |
| In SNMPv3, USM is required for purposes of interoperability, |
| especially for troubleshooting, and a shared secret is the |
| standard approach for USM. For purposes other than |
| troubleshooting, a shared secret would not necessarily be |
| required. To put this another way, because SNMP would be |
| serving purposes beyond AAA, and for those non-AAA purposes |
| interoperability and availability are paramount, shared secrets |
| are required for those other, non-AAA, purposes. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.14. Ability to carry service-specific attributes
See explanatory comments in 6.1.5.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ability to carry | M | | S | T |
| service-specific attr.| 43 | | 31 33 | |
|-----------------------------------------------------------------|
| [l] The AAA protocol MUST be extensible by third parties (e.g. |
| other IETF Working Groups), in order to define attributes that |
| are specific to the service being defined. This requirement |
| simply means that the AAA protocol MUST allow groups other than |
| the AAA WG to define standard attributes. |
|-----------------------------------------------------------------|
Natale Expires December 2000 17
INTERNET-DRAFT SNMPv3 for AAA June 2000
| SNMPv3 satisfies this requirement via the use of MIBs. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2. Authentication Requirements
Note several of the responses in this section assume that SNMPv3
will be used as a tool (e.g., for transport, management, etc.) to
support out-of-band user authentication via other protocols (e.g.,
CHAP, EAP, PAP, etc.) in various AAA processes.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication | NASREQ | ROAMOPS | MOBILE | SNMPv3 |
| Requirements | | | IP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI Support | M | M | S | T |
| | | | | 6.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHAP Support | M | M | O | T |
| | | | | 6.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP Support | M | S | O | P |
| | | | | 6.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAP/Clear-Text | M | B | O | T |
| Support | | | | 6.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-authentication | M | | S | T |
| on demand | | | | 6.2.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authorization Only | M | | O | T |
| w/o Authentication | | | | 6.2.6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.1. NAI support
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI Support | M | M | S/M | |
| | 9 | 2 |32,34,38/| T |
| | | | 40 | |
|-----------------------------------------------------------------|
| [a] The AAA protocol MUST allow the use of Network Access |
| Identifiers (NAI) [8] to identify users and/or devices. |
|-----------------------------------------------------------------|
| SNMPv3 supports this requirement via MIB objects which can be |
| created for this purpose. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.2. CHAP support
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHAP Support | M | M | O | T |
| | 10 | 3 | | |
Natale Expires December 2000 18
INTERNET-DRAFT SNMPv3 for AAA June 2000
|-----------------------------------------------------------------|
| [b] The AAA protocol MUST allow CHAP [20] authentication |
| information to be transported. This is commonly used by Network |
| Access Servers that request authentication of a PPP user. |
|-----------------------------------------------------------------|
| SNMPv3 supports this requirement via MIB objects which can be |
| created for this purpose. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.3. EAP support
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP Support | M | S | O | P |
| | 10 | 3 | | |
|-----------------------------------------------------------------|
| [c] The AAA protocol MUST allow for Extensible Authentication |
| Protocol (EAP) [14] payload to be transported. Since some EAP |
| authentication mechanisms require more than one round trip, the |
| AAA protocol must allow for such authentication mechanisms to be|
| used. The actual EAP authentication mechanism negotiated MUST |
| be transparent to the AAA protocol. When EAP is used, |
| authentication typically occurs between the user being |
| authenticated and his/her home AAA server. |
|-----------------------------------------------------------------|
| SNMPv3 partially supports this requirement via MIB objects which|
| can be created for this purpose. A complete EAP-authentication |
| scheme built around AAA use of SNMPv3 will likely require |
| further analysis and design efforts, at a minimum. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.4. PAP/clear-text support
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAP/Clear-Text | M | B | O | T |
| Support | 10 | 3 | | |
|-----------------------------------------------------------------|
| [d] While PAP is deprecated, it is still in widespread use for |
| its original intended purpose, which is support of clear-text |
| passwords. As a result, a AAA protocol will need to be able to |
| securely transport clear-text passwords. This includes providing|
| for confidentiality of clear-text passwords traveling over the |
| wire, as well as protecting against disclosure of clear-text |
| passwords to proxies in the forwarding path. |
|-----------------------------------------------------------------|
| Given MIB objects designed for this purpose, SNMPv3 can carry |
| clear-text passwords as message data objects. When such |
| messages are sent using the privacy (encryption) facilities of |
| SNMPv3, both the confidentiality of these passwords on-the-wire |
| and protection from unauthorized disclosure of them at an end- |
| point are ensured. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Natale Expires December 2000 19
INTERNET-DRAFT SNMPv3 for AAA June 2000
6.2.5. Re-authentication on demand
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-authentication | M | | S | T |
| on demand | 17 | | 30 33 | |
|-----------------------------------------------------------------|
| [e] The AAA protocol MUST allow for a user to be re- |
| authenticated on-demand. The protocol MUST allow for this event |
| to be triggered by either the user, access device (AAA client), |
| or the home or visited AAA server. |
|-----------------------------------------------------------------|
| SNMPv3 AAA applications interfaces can support re-authentication|
| on demand by [re-]setting MIB objects designed to trigger agent |
| processor to [re-]authenticate the user. Application interfaces|
| of this nature may exist for users (via UIs), devices (via |
| SNMPv3 protocol messages), or software entities (via APIs, for |
| example). |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.6. Authorization only without authentication
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authorization Only | M | | O | T |
| w/o Authentication | 9 | | 30 | |
|-----------------------------------------------------------------|
| [f] This requirement refers to the ability to authorize usage |
| based on a user claim of identity, without requiring that the |
| claim be authenticated. |
|-----------------------------------------------------------------|
| SNMPv3 supports this requirement by virtue of the independence |
| of the View-based Access Control Model (VACM) from the security |
| features. That is, an unauthenticated (noAuth/noPriv) SNMPv3 |
| message is still subject to the access control (authorization) |
| policy of the entity which instruments the objects of interest. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3. Authorization Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authorization | NASREQ | ROAMOPS | MOBILE | SNMPv3 |
| Requirements | | | IP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static and Dynamic | M | M | M | T |
| IPv4/6 Addr. Assign.| | | | 6.3.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIUS gateway | M | M | O | T |
| capability | | | | 6.3.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reject | M | M | M | T |
| capability | | | | 6.3.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Precludes layer 2 | N | N | | ? |
Natale Expires December 2000 20
INTERNET-DRAFT SNMPv3 for AAA June 2000
| tunneling | | | | 6.3.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-Authorization on | M | | S | T |
| demand | | | | 6.3.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Support for Access | M | | O | T |
| Rules, Restrictions, | | | | 6.3.6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | M | | | T |
| Reconciliation | | | | 6.3.7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unsolicited | M | | | T |
| Disconnect | | | | 6.3.8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.1. Static and dynamic IPv4/6 address assignment
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static and Dynamic | M | M | M | T |
| IPv4/6 Addr. Assign.| 11 | 1 | 32 36 | |
|-----------------------------------------------------------------|
| [a] The AAA protocol MUST allow a server to provide a static or|
| dynamic address during the authorization phase of a user and/or |
| device. The address assigned MUST be either of type IPv4 or |
| IPv6. An address is considered static when a user requests a |
| specific address, and it is present in the authorization |
| request. An address is considered dynamic when the AAA server |
| assigns an address to the user that is either defined in his |
| profile, or from an address pool managed by the server. |
|-----------------------------------------------------------------|
| SNMPv3 can support both IPv4 and/or IPv6 MIB objects for use by |
| AAA authorization processes. Whether values for such objects |
| come from static or dynamic sources, as defined above, is |
| immaterial to the SNMPv3 layer. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.2. RADIUS gateway capability
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIUS gateway | M | M | O/M | T |
| capability | 44 | 3 | 30/45 | |
|-----------------------------------------------------------------|
| [b] This requirement refers to the ability of a new AAA |
| protocol to be sufficiently compatible with the large installed |
| base of attributes for existing approaches (RADIUS), such that a|
| server implementation could speak both protocols, or translate |
| between them. |
|-----------------------------------------------------------------|
| It is anticipated that all exiting RADIUS attributes can be |
| modeled as MIB objects for transport and manipulation by SNMPv3-|
| enabled AAA software processes which could then perform any |
| necessary RADIUS gateway functions. |
Natale Expires December 2000 21
INTERNET-DRAFT SNMPv3 for AAA June 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.3. Reject capability
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reject | M | M | M | T |
| capability | 12 | 4 | 39 | |
|-----------------------------------------------------------------|
| [c] This requirement refers to the ability of a proxy broker to|
| deny access without forwarding the access request to the AAA |
| server, or to deny access after receiving an access accept from |
| the AAA server. |
|-----------------------------------------------------------------|
| The essence of this requirement seems external to SNMPv3 per se.|
| Nothing in the SNMPv3 mapping to AAA requirements is known to |
| preclude or impede implementation of such a reject capability |
| in either proxy brokers or AAA servers. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.4. Precludes layer 2 tunneling
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Precludes layer 2 | N | N | | ? |
| tunneling | 11 | 5 | | |
|-----------------------------------------------------------------|
| Unclear about the meaning of this requirement at this time. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.5. Re-authorization on demand
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-authorization | M | | S | T |
| on demand | 18 | | 30 33 | |
|-----------------------------------------------------------------|
| [d] This requirement refers to the ability of the AAA client or|
| server to trigger re-authorization, or to the ability of the |
| server to send updated authorization information to the device, |
| such as "stop service." Authorization can allow for a time |
| period, then additional authorization can be sought to continue.|
| A server can initially authorize a user to connect and receive |
| services, but later decide the user is no longer allowed use of |
| the service, for example after N minutes. Authorizations can |
| have a time limit. Re-authorization does not necessarily imply |
| re-authentication. |
|-----------------------------------------------------------------|
| The essence of this requirement seems external to SNMPv3 per se.|
| MIB objects can be defined to represent the requisite states -- |
| including time limits on authorizations -- and transported |
| reliably via SNMPv3 messages to interested AAA processes. |
| Nothing in the SNMPv3 mapping to AAA requirements is known to |
| preclude or impede implementation of re-authorization by AAA |
| clients and/or servers or the transmission of updated |
Natale Expires December 2000 22
INTERNET-DRAFT SNMPv3 for AAA June 2000
| authorization information from AAA servers to AAA devices. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.6. Support for access rules, restrictions, filters
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Support for Access | M | | O | T |
| Rules, Restrictions, | 11, 19 | | 30 37 | |
|-----------------------------------------------------------------|
| [e] This requirement refers to the ability to of the protocol |
| to describe access operational limitations and authorization |
| restrictions to usage to the NAS which includes (but is not |
| limited to): |
| 1. Time/Day restrictions |
| 2. Port location restrictions |
| 3. Dialed/Dialing number |
| 4. Concurrent login limits |
| 5. Session expirations and Idle Timeouts |
| 6. Packet filters |
| 7. Static routes |
| 8. QoS parameters |
|-----------------------------------------------------------------|
| MIB objects describing all of the access operational limitations|
| and authorization restrictions listed in this requirement can be|
| defined and then transported and manipulated by SNMPv3-enabled |
| AAA software entities. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.7. State reconciliation
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | M | | T |
| reconciliation | | 20 | | |
|-----------------------------------------------------------------|
| [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. 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, the following capabilities are |
| required: |
| |
| 1. Re-authorization capabilities |
| 2. A session disconnect message |
| 3. Transport and application-layer reliability |
| 4. An interim message |
| 5. A mechanism for the AAA server to retrieve state |
| information from the NAS. This mechanism will provide |
Natale Expires December 2000 23
INTERNET-DRAFT SNMPv3 for AAA June 2000
| timely information though a complete state dump may not be |
| immediately available. |
| 6. A device reboot message. |
| 7. AAA On/Off messages. |
| |
| If non-volatile memory is present, it is believed that only |
| elements 1 - 3 are needed. However, since this will not always |
| be true, other mechanisms are also needed. Mechanism 4 provides |
| recovery time on the order of the interim interval, and so may |
| be too slow in many cases. Mechanisms 5-7 can be useful but are |
| not implementable at Internet scale for use in applications such|
| as roaming. |
|-----------------------------------------------------------------|
| The foregoing statement of this requirement is internally |
| inconsistent -- if mechanisms 5-7 are not implementable at |
| Internet scale how can they nonetheless be requirements? Be |
| that as it may several of these mechanisms (e.g., 1 and 3) have |
| been addressed (positively) in previous sections and all of |
| them may be implemented| in an SNMPv3 environment via |
| appropriate MIB and application-level support. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.8. Unsolicited disconnect
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unsolicited | M | | | T |
| disconnect | 18 | | | |
|-------------------=---------------------------------------------|
| [g] This requirement refers to the ability of the AAA server to|
| request the NAS to disconnect an active session for |
| authorization policy reasons. |
|-----------------------------------------------------------------|
| Such a request can be conveyed readily via an SNMPv3 Set |
| operation an appropriate MIB object. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4. Accounting Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accounting | NASREQ | ROAMOPS | MOBILE | SNMPv3 |
| Requirements | | | IP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Real-time | M | M | M | T |
| accounting | | | | 6.4.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Compact | | M | M | T |
| Encoding | | | | 6.4.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accounting Record | M | M | M | T |
| Extensibility | | | | 6.4.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch | S | | | T |
Natale Expires December 2000 24
INTERNET-DRAFT SNMPv3 for AAA June 2000
| accounting | | | | 6.4.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Guaranteed | M | | M | T |
| delivery | | | | 6.4.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accounting | M | | S | T |
| Time Stamps | | | | 6.4.6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dynamic | M | | S | T |
| accounting | | | | 6.4.7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4.1. Real-time accounting
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Real-time | M | M | M | T |
| accounting | 14 | 7 | 31 39 | |
|-----------------------------------------------------------------|
| [a] This requirement may be loosely defined as reporting |
| synchronously with events. Typically the time window is on the |
| order of seconds, not milliseconds. |
|-----------------------------------------------------------------|
| SNMPv3 solutions can support the real-time accounting |
| requirements by, for example, permitting Sets of MIB objects |
| designed to govern the timely transfer of accumulated accounting|
| data (perhaps via out-of-band means) and/or via the use of |
| InformRequest PDUs to send "real-time" accounting records. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4.2. Mandatory compact encoding
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory compact | | M | M | T |
| encoding | | 7 | 33 | |
|-----------------------------------------------------------------|
| [b] The AAA protocol's Accounting data format MUST NOT be |
| bloated, imposing a large overhead for one or more accounting |
| data elements. |
|-----------------------------------------------------------------|
| In general, SNMPv3 solutions will not impose any format |
| requirements on accounting data. In cases where large amounts |
| of accounting data are to be transmitted, this process will |
| likely be *managed* via SNMPv3 MIB objects, but actually |
| executed via some external protocol (e.g., FTP, HTTP) which may |
| or may not impose format requirements on the data. In cases |
| where smaller amounts of accounting data are to be transferred |
| via SNMPv3 messages -- as in the real-time accounting |
| requirements covered above -- a variety of appropriate MIB |
| object definitions will be available (e.g., perhaps |
| corresponding to [ADIF] specifications), some of which may |
| optimize for size while others may optimize for other factors, |
| depending upon the relevant AAA application(s). |
Natale Expires December 2000 25
INTERNET-DRAFT SNMPv3 for AAA June 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4.3. Accounting record extensibility
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accounting record | M | M | M | T |
| extensibility | 15 | 7 | 33 | |
|-----------------------------------------------------------------|
| SNMPv3 MIB objects will be used to represent accounting records |
| and other accounting data elements as may be required (e.g., |
| perhaps corresponding to [ADIF] specifications). SNMP MIBs are |
| extensible by definition. In cases of accounting data files, |
| the SNMPv3 MIB representation may be completely opaque (e.g., |
| OCTET_STRING type). |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4.4. Batch accounting
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch | S | | | T |
| accounting | 21 | | | |
|-----------------------------------------------------------------|
| [c] This requirement refers to the ability to buffer or store |
| multiple accounting records, and send them together at some |
| later time. |
|-----------------------------------------------------------------|
| SNMPv3 MIB objects will be used to control and schedule |
| accounting data collection (e.g., bucket size, time span) and |
| transfer (e.g., targets, protocol to be used, transmission |
| parameters) allowing for batch accounting. Note that some SNMP |
| MIBs (e.g., in the ATM space) already provide models for this |
| form of accounting. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4.5. Guaranteed delivery
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Guaranteed | M | | M | T |
| delivery | 22 | | 31 | |
|-----------------------------------------------------------------|
| [d] This is an application layer acknowledgment. This is sent |
| when the receiving server is willing to take responsibility for |
| the message data. |
|-----------------------------------------------------------------|
| For in-band transmission of accounting data (e.g., for real-time|
| accounting records), an SNMPv3 InformRequest message (receipt of|
| which will be acknowledged by the target entity) can be used to |
| actually carry the accounting data. For out-of-band |
| transmission of accounting data (e.g., batch file transfer), an |
| InformRequest message can be used to notify an interested |
| application that the data transfer has been initiated. In the |
| out-of-band case, the transfer protocol itself will have to |
Natale Expires December 2000 26
INTERNET-DRAFT SNMPv3 for AAA June 2000
| guarantee delivery, although SNMPv3 mechanisms (in-bound Gets |
| for "pull" mode or out-bound InformRequests for "push" mode) may|
| be used to check final delivery status at the receiving entity. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4.6. Accounting time stamps
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accounting | M | | S/M | T |
| time stamps | 23 | | 30/40 | |
|-----------------------------------------------------------------|
| [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. |
|-----------------------------------------------------------------|
| The SNMPv3 DateAndTime textual convention [RFC2579] can be used |
| to define MIB objects that satisfy this requirement for use in |
| AAA applications. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4.7. Dynamic accounting
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dynamic | M | | S | T |
| accounting | 18 | | 30 | |
|-----------------------------------------------------------------|
| [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. |
|-----------------------------------------------------------------|
| SNMPv3 facilities used in AAA applications will be agnostic to |
| the number of accounting records generated for a single session.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.5. Unique Mobile IP requirements
In addition to the above requirements, Mobile IP also has the
following additional requirements:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Mobile IP | NASREQ | ROAMOPS | MOBILE | SNMPv3 |
| Requirements | | | IP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding of Mobile IP| | | M | T |
| registration messages| | | | 6.5.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firewall | | | M | P |
| friendly | | | | 6.5.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Allocation of | | | S/M | ? |
| local Home agent | | | | 6.5.3 |
Natale Expires December 2000 27
INTERNET-DRAFT SNMPv3 for AAA June 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.5.1. Encoding of Mobile IP registration messages
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding of Mobile IP| | | M | T |
| registration messages| | | 33 | |
|-----------------------------------------------------------------|
| Given that the Mobile IP registration message may be represented|
| in an SNMPv3 solution as a set of one or more data objects then |
| it could be encoded at the object level and/or at the SNMPv3 |
| scopedPDU encryption level. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.5.2. Firewall friendly
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firewall | | | M | P |
| friendly | | | 35 | |
|-----------------------------------------------------------------|
| [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. |
|-----------------------------------------------------------------|
| SNMP over UDP is not generally considered firewall friendly. It|
| is possible, however, that SNMPv3 messages will be looked upon |
| more favorably by firewall administrators due to the advanced |
| security features it offers. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.5.3. Allocation of local Home agent
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Allocation of | | | S/M | ? |
| local Home agent | | | 37/41 | |
|-----------------------------------------------------------------|
| SNMPv3 compliance or non-compliance with this requirement is not|
| determinable at this time (due to lack of understanding of the |
| requirement on the part of this author!). |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. Conclusion
Based upon the foregoing caveats, explanations, analyses, and
responses, it would appear that SNMPv3 is well prepared to play
a significant role in an IETF standard AAA solution set. This
role would involve the SNMPv3 protocol itself, SNMP MIBs, SNMP-
enabled AAA applications, IETF-standard extensible SNMP agents,
SNMP distributed management mechanisms, and other related
components. So, while this draft does not propose a simple,
Natale Expires December 2000 28
INTERNET-DRAFT SNMPv3 for AAA June 2000
monolithic SNMPv3 answer to all of the AAA requirements, it
does hope to justify a significant role for SNMPv3 in the
overall AAA solution set.
8. References
[1] Aboba, B., et al., " Criteria for Evaluating AAA Protocols
for Network Access", Internet draft (work in progress),
draft-ietf-aaa-na-reqts-05.txt, April 2000.
[2] Aboba, B., Zorn, G., "Criteria for Evaluating Roaming
Protocols", RFC 2477, January 1999.
[3] Beadles, M., Mitton, D. "Criteria for Evaluating Network
Access Server Protocols", Internet draft (work in progress),
draft-ietf-nasreq-criteria-04.txt, February 2000.
[4] Hiller, T., et al., "Cdma2000 Wireless Data Requirements
for AAA", Internet draft (work in progress),
draft-hiller-cdma2000-AAA-00.txt, October 1999.
[5] Glass, S., Hiller, T., Jacobs, S., Perkins, C., "Mobile IP
Authentication, Authorization, and Accounting Requirements",
Internet draft (work in progress),
draft-ietf-mobileip-aaa-reqs-01.txt, January 2000.
[6] Case, J., Mundy, R., Partain, D., Stewart, B., "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.
[7] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing SNMP Management Frameworks", RFC 2571, April
1999.
[8] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[9] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
RFC 2573, April 1999.
[10] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[11] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[12] Frye, R., Levi, D., Routhier, S., Wijnen, B.,
"Coexistence between Version 1, Version 2, and Version
3 of the Internet-standard Network Management Framework",
Natale Expires December 2000 29
INTERNET-DRAFT SNMPv3 for AAA June 2000
RFC 2576, March 2000.
[13] McCloghrie, K., Perkins, D., Schoenwaelder, J., "Structure
of Management Information Version 2 (SMIv2)", RFC 2578,
April 1999.
[14] McCloghrie, K., Perkins, D., Schoenwaelder, J., "Textual
Conventions for SMIv2", RFC 2579, April 1999.
[15] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
"Conformance Statements for SMIv2", RFC 2580, April 1999.
[16] Daniele, M., Wijnen, B., Ellison, M., Francisco, D.,
"Agent Extensibility (AgentX) Protocol Version 1", RFC
2471, January 2000.
[17] Heintz, L., Gudur, S., Ellison, M., "Definitions of
Managed Objects for Extensible SNMP Agents", RFC 2472,
January 2000.
TBD:
[ACCT-MGMT]
[NMRG-1]
[NMRG-2]
[NMRG-3]
[PPP-ICP]
[TIA 45.6]
9. Security Considerations
This document, being a requirements comparison document, does not
have any security concerns. The security requirements on protocols
compared in this document are described in the referenced documents.
10. IANA Considerations
This draft does not create any new number spaces for IANA
administration.
11. Acknowledgments
Thanks to Bernard Aboba, Wes Hardaker, and David Harrington for
helpful feedback on version "-00" of this draft.
12. Author's Addresses
Bob Natale
ACE*COMM
704 Quince Orchard Rd
Gaithersburg MD 20078
Natale Expires December 2000 30
INTERNET-DRAFT SNMPv3 for AAA June 2000
Phone: +1 (301) 721-3000
Fax: +1 (301) 721-3001
Email: bnatale@acecomm.com
Natale Expires December 2000 31
INTERNET-DRAFT SNMPv3 for AAA June 2000
13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Natale Expires December 2000 32
INTERNET-DRAFT SNMPv3 for AAA June 2000
14. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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."
15. Expiration Date
This memo is filed as <draft-natale-snmpv3-comp-00.txt>, and
expires December 1, 2000.
Natale Expires December 2000 33
| PAFTECH AB 2003-2026 | 2026-04-22 06:03:21 |