draft-ietf-snmpv3-intro-01.txt   draft-ietf-snmpv3-intro-02.txt 
skipping to change at page 1, line 15 skipping to change at page 2, line ?
Russ Mundy Russ Mundy
Trusted Information Systems, Inc. Trusted Information Systems, Inc.
David Partain David Partain
SNMP Research Europe SNMP Research Europe
Bob Stewart Bob Stewart
Cisco Systems Cisco Systems
Introduction to Version 3 of the Introduction to Version 3 of the
Internet-standard Network Management Framework Internet-standard Network Management Framework
1998/08/07 13:38:54 1998/10/14 19:33:28
draft-ietf-snmpv3-intro-02.txt
draft-ietf-snmpv3-intro-01.txt 1.6 -- 1998/10/14 19:33:28
1.3 -- 1998/08/07 13:38:54
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas, and
and its working groups. Note that other groups may also distribute its working groups. Note that other groups may also distribute working
working documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference material
material or to cite them other than as "work in progress." or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
The purpose of this document is to provide an overview of the third The purpose of this document is to provide an overview of the
version of the Internet-standard Management Framework, termed the third version of the Internet-standard Management Framework,
SNMP version 3 Framework (SNMPv3). This Framework is derived from termed the SNMP version 3 Framework (SNMPv3). This Framework is
and builds upon both the original Internet-standard Management derived from and builds upon both the original Internet-standard
Framework (SNMPv1) and the second Internet-standard Management Management Framework (SNMPv1) and the second Internet-standard
Framework (SNMPv2). Management Framework (SNMPv2).
The architecture is designed to be modular to allow the evolution of The architecture is designed to be modular to allow the evolu-
the Framework over time. tion of the Framework over time.
0. Revision History:
Version 1.5: 1998/08/30 00:00:00
. incorporate final comments from russ (got both mailgrams incorporated)
Version 1.4: 1998/09/24 00:00:00
. added this revision history -- to be deleted when published as an
rfc
. removed statement about someday containing information regarding
compliance
. incorporated input from chicago ietf meeting:
- beef up the praise for the snmpv3 design team to address this
comment:
I think that the current draft gives bit too much
credit to the original designers of SNMP and sort of
discredits the effort of the SNMPv3 WG members as being
"nothing new".
- add table of contents
- fix spelling error in copyright notice
. reviewed mailing list and incorporated all comments there since
the last draft (none to incorporate not covered above)
. added change bars ... changed from last draft (version 1.3) -- also
known as draft-ietf-snmpv3-intro-01.txt
Open Issues
. section about the coex/transition document needs finality
1. Introduction 1. Introduction
This document is an introduction to the third version of the This document is an introduction to the third version of the Internet-
Internet-standard Management Framework, termed the SNMP version 3 standard Management Framework, termed the SNMP version 3 Management
Management Framework (SNMPv3) and has multiple purposes. Framework (SNMPv3) and has multiple purposes.
First, it describes the relationship between the SNMP version 3 First, it describes the relationship between the SNMP version 3 (SNMPv3)
(SNMPv3) specifications and the specifications of the SNMP version 1 specifications and the specifications of the SNMP version 1 (SNMPv1)
(SNMPv1) Management Framework, the SNMP version 2 (SNMPv2) Management Management Framework, the SNMP version 2 (SNMPv2) Management Framework,
Framework, and the Community-based Administrative Framework for and the Community-based Administrative Framework for SNMPv2.
SNMPv2.
Second, it provides a roadmap to the multiple documents which contain Second, it provides a roadmap to the multiple documents which contain
the relevant specifications. the relevant specifications.
Third, this document provides a brief easy-to-read summary of the Third, this document provides a brief easy-to-read summary of the
contents of each of the relevant specification documents. contents of each of the relevant specification documents.
[Finally, this document may someday contain information regarding
what it means to be a compliant SNMPv3 implementation, i.e., a set of
applicability statements, but it does not now, and if it never does,
then this sentence will be deleted.]
This document is intentionally tutorial in nature and, as such, may This document is intentionally tutorial in nature and, as such, may
occasionally be "guilty" of oversimplification. In the event of a occasionally be "guilty" of oversimplification. In the event of a
conflict or contradiction between this document and the more detailed conflict or contradiction between this document and the more detailed
documents for which this document is a roadmap, the specifications in documents for which this document is a roadmap, the specifications in
the more detailed documents shall prevail. the more detailed documents shall prevail.
Further, the detailed documents attempt to maintain separation Further, the detailed documents attempt to maintain separation between
between the various component modules in order to specify well- the various component modules in order to specify well-defined
defined interfaces between them. This roadmap document, however, interfaces between them. This roadmap document, however, takes a
takes a different approach and attempts to provide an integrated view different approach and attempts to provide an integrated view of the
of the various component modules in the interest of readability. various component modules in the interest of readability.
2. The Internet Standard Management Framework 2. The Internet Standard Management Framework
The third version of the Internet Standard Management Framework (the The third version of the Internet Standard Management Framework (the
SNMPv3 Framework) is derived from and builds upon both the original SNMPv3 Framework) is derived from and builds upon both the original
Internet-standard Management Framework (SNMPv1) and the second Internet-standard Management Framework (SNMPv1) and the second
Internet-standard Management Framework (SNMPv2). Internet-standard Management Framework (SNMPv2).
All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard
Management Framework share the same basic structure and components. Management Framework share the same basic structure and components.
Furthermore, all versions of the specifications of the Internet Furthermore, all versions of the specifications of the Internet Standard
Standard Management Framework follow the same architecture. Management Framework follow the same architecture.
2.1 Basic Structure and Components 2.1. Basic Structure and Components
An enterprise deploying the Internet Standard Management Framework An enterprise deploying the Internet Standard Management Framework
contains four basic components: contains four basic components:
* several (typically many) managed nodes, each with an SNMP entity * several (typically many) managed nodes, each with an SNMP entity
which provides remote access to management instrumentation which provides remote access to management instrumentation
(traditionally called an agent); (traditionally called an agent);
* at least one SNMP entity with management applications (typically * at least one SNMP entity with management applications (typically
called a manager), called a manager),
* a management protocol used to convey management information * a management protocol used to convey management information
between the SNMP entities, and between the SNMP entities, and
* management information. * management information.
The management protocol is used to convey management information The management protocol is used to convey management information between
between SNMP entities such as managers and agents. SNMP entities such as managers and agents.
This basic structure is common to all versions of the Internet This basic structure is common to all versions of the Internet Standard
Standard Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3. Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3.
2.2 Architecture of the Internet Standard Management Framework 2.2. Architecture of the Internet Standard Management Framework
The specifications of the Internet Standard Management Framework are The specifications of the Internet Standard Management Framework are
based on a modular architecture. This framework is more than just a based on a modular architecture. This framework is more than just a
protocol for moving data. It consists of: protocol for moving data. It consists of:
* a data definition language, * a data definition language,
* definitions of management information (the Management * definitions of management information (the Management
Information Base, or MIB), Information Base, or MIB),
* a protocol definition, and * a protocol definition, and
* security and administration. * security and administration.
Over time, as the Framework has evolved from SNMPv1, through SNMPv2, Over time, as the Framework has evolved from SNMPv1, through SNMPv2, to
to SNMPv3, the definitions of each of these architectural components SNMPv3, the definitions of each of these architectural components have
have become richer and more clearly defined, but the fundamental become richer and more clearly defined, but the fundamental architecture
architecture has remained consistent. has remained consistent.
One prime motivator for this modularity was to enable the ongoing One prime motivator for this modularity was to enable the ongoing
evolution of the Framework as is documented in RFC 1052 [14]. When evolution of the Framework as is documented in RFC 1052 [14]. When
originally envisioned, this capability was to be used to ease the originally envisioned, this capability was to be used to ease the
transition from SNMP-based management of internets to management transition from SNMP-based management of internets to management based
based on OSI protocols. To this end, the framework was architected on OSI protocols. To this end, the framework was architected with a
with a protocol-independent data definition language and Management protocol-independent data definition language and Management Information
Information Base along with a MIB-independent protocol. This Base along with a MIB-independent protocol. This separation was
separation was designed to allow the SNMP-based protocol to be designed to allow the SNMP-based protocol to be replaced without
replaced without requiring the management information to be redefined requiring the management information to be redefined or reinstrumented.
or reinstrumented. History has shown that the selection of this History has shown that the selection of this architecture was the right
architecture was the right decision for the wrong reason -- it turned decision for the wrong reason -- it turned out that this architecture
out that this architecture has eased the transition from SNMPv1 to has eased the transition from SNMPv1 to SNMPv2 and from SNMPv2 to SNMPv3
SNMPv2 and from SNMPv2 to SNMPv3 rather than easing the transition rather than easing the transition away from management based on the
away from management based on the Simple Network Management Protocol. Simple Network Management Protocol.
The SNMPv3 Framework builds and extends these architectural The SNMPv3 Framework builds and extends these architectural principles
principles by: by:
* building on these four basic architectural components, in some * building on these four basic architectural components, in some
cases incorporating them from the SNMPv2 Framework by reference, cases incorporating them from the SNMPv2 Framework by reference,
and and
* by using these same layering principles in the definition of new * by using these same layering principles in the definition of new
capabilities in the security and administration portion of the capabilities in the security and administration portion of the
architecture. architecture.
Those who are familiar with the architecture of the SNMPv1 Management Those who are familiar with the architecture of the SNMPv1 Management
Framework and the SNMPv2 Management Framework will find many familiar Framework and the SNMPv2 Management Framework will find many familiar
concepts in the architecture of the SNMPv3 Management Framework. concepts in the architecture of the SNMPv3 Management Framework.
However, in some cases, the terminology may be somewhat different. However, in some cases, the terminology may be somewhat different.
3. The SNMPv1 Management Framework 3. The SNMPv1 Management Framework
The original Internet-standard Network Management Framework (SNMPv1) The original Internet-standard Network Management Framework (SNMPv1) is
is defined in the following documents: defined in the following documents:
* STD 16, RFC 1155 [1] which defines the Structure of Management * STD 16, RFC 1155 [1] which defines the Structure of Management
Information (SMI), the mechanisms used for describing and naming Information (SMI), the mechanisms used for describing and naming
objects for the purpose of management. objects for the purpose of management.
* STD 16, RFC 1212 [2] which defines a more concise description * STD 16, RFC 1212 [2] which defines a more concise description
mechanism for describing and naming management information objects, mechanism for describing and naming management information objects,
but which is wholly consistent with the SMI. but which is wholly consistent with the SMI.
* STD 15, RFC 1157 [3] which defines the Simple Network Management * STD 15, RFC 1157 [3] which defines the Simple Network Management
Protocol (SNMP), the protocol used for network access to managed Protocol (SNMP), the protocol used for network access to managed
objects and event notification. Note this document also defines an objects and event notification. Note this document also defines an
initial set of event notifications. initial set of event notifications.
Additionally, two documents are generally considered to be companions Additionally, two documents are generally considered to be companions to
to these three: these three:
* STD 17, RFC 1213 [13] which contains definitions for the base * STD 17, RFC 1213 [13] which contains definitions for the base
set of management information set of management information
* RFC 1215 [25] defines a concise description mechanism for * RFC 1215 [25] defines a concise description mechanism for
defining event notifications, which are called traps in the SNMPv1 defining event notifications, which are called traps in the SNMPv1
protocol. It also specifies the generic traps from RFC 1157 in the protocol. It also specifies the generic traps from RFC 1157 in the
concise notation. concise notation.
These documents describe the four parts of the first version of the These documents describe the four parts of the first version of the SNMP
SNMP Framework. Framework.
3.1 The SNMPv1 Data Definition Language. 3.1. The SNMPv1 Data Definition Language
The first two and the last document describe the SNMPv1 data The first two and the last document describe the SNMPv1 data definition
definition language. Note that due to the initial requirement that language. Note that due to the initial requirement that the SMI be
the SMI be protocol-independent, the first two SMI documents do not protocol-independent, the first two SMI documents do not provide a means
provide a means for defining event notifications (traps). Instead, for defining event notifications (traps). Instead, the SNMP protocol
the SNMP protocol document defines a few standardized event document defines a few standardized event notifications (generic traps)
notifications (generic traps) and provides a means for additional and provides a means for additional event notifications to be defined.
event notifications to be defined. The last document specifies a The last document specifies a straight-forward approach towards defining
straight-forward approach towards defining event notifications used event notifications used with the SNMPv1 protocol. At the time that it
with the SNMPv1 protocol. At the time that it was written, use of was written, use of traps in the Internet-standard network management
traps in the Internet-standard network management framework was framework was controversial. As such, RFC 1215 was put forward with the
controversial. As such, RFC 1215 was put forward with the status of
"Informational", which was never updated because it was believed that
the second version of the SNMP Framework would replace the first
version. Note that the SNMPv1 data definition language is sometimes
refered to as SMIv1.
3.2 Management Information. status of "Informational", which was never updated because it was
believed that the second version of the SNMP Framework would replace the
first version. Note that the SNMPv1 data definition language is
sometimes refered to as SMIv1.
3.2. Management Information
The data definition language described in the first two documents was The data definition language described in the first two documents was
first used to define the now-historic MIB-I as specified in RFC 1066 first used to define the now-historic MIB-I as specified in RFC 1066
[12], and was subsequently used to define MIB-II as specified in RFC [12], and was subsequently used to define MIB-II as specified in RFC
1213 [13]. 1213 [13].
Later, after the publication of MIB-II, a different approach to Later, after the publication of MIB-II, a different approach to
management information definition was taken from the earlier approach management information definition was taken from the earlier approach of
of having a single committee staffed by generalists work on a single having a single committee staffed by generalists work on a single
document to define the Internet-standard MIB. Rather, many mini-MIB document to define the Internet-standard MIB. Rather, many mini-MIB
documents were produced in a parallel and distributed fashion by documents were produced in a parallel and distributed fashion by groups
groups chartered to produce a specification for a focused portion of chartered to produce a specification for a focused portion of the
the Internet-standard MIB and staffed by personnel with expertise in Internet-standard MIB and staffed by personnel with expertise in those
those particular areas ranging from various aspects of network particular areas ranging from various aspects of network management, to
management, to system management, and application management. system management, and application management.
3.3 Protocol Operations. 3.3. Protocol Operations
The third document, STD 15, describes the SNMPv1 protocol operations The third document, STD 15, describes the SNMPv1 protocol operations
performed by protocol data units (PDUs) on lists of variable bindings performed by protocol data units (PDUs) on lists of variable bindings
and describes the format of SNMPv1 messages. The operators defined by and describes the format of SNMPv1 messages. The operators defined by
SNMPv1 are: get, get-next, get-response, set-request, and trap. SNMPv1 are: get, get-next, get-response, set-request, and trap.
Typical layering of SNMP on a connectionless transport service is Typical layering of SNMP on a connectionless transport service is also
also defined. defined.
3.4 SNMPv1 Security and Administration. 3.4. SNMPv1 Security and Administration
STD 15 also describes an approach to security and administration. STD 15 also describes an approach to security and administration. Many
Many of these concepts are carried forward into the SNMPv3 Framework. of these concepts are carried forward and some, particularly security,
are extended by the SNMPv3 Framework.
The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in SNMP
SNMP messages between SNMP entities and distinguishes between messages between SNMP entities and distinguishes between application
application entities and protocol entities. In SNMPv3, these are entities and protocol entities. In SNMPv3, these are renamed
renamed applications and engines, respectively. applications and engines, respectively.
The SNMPv1 Framework also introduces the concept of an authentication The SNMPv1 Framework also introduces the concept of an authentication
service supporting one or more authentication schemes. In SNMPv3, service supporting one or more authentication schemes. In addition to
the concept of an authentication service is expanded to include other authentication, SNMPv3 defines the additional security capability
services, such as privacy. referred to as privacy. (Note: some literature from the security
community would describe SNMPv3 security capabilities as providing data
integrity, source authenticity, and confidentiality.) The modular
nature of the SNMPv3 Framework permits both changes and additions to the
security capabilities.
Finally, the SNMPv1 Framework introduces access control based on a Finally, the SNMPv1 Framework introduces access control based on a
concept called an SNMP MIB view. The SNMPv3 Framework specifies a concept called an SNMP MIB view. The SNMPv3 Framework specifies a
fundamentally similar concept called view-based access control. fundamentally similar concept called view-based access control. With
this capability, SNMPv3 provides the means for controlling access to
information on managed devices.
However, while the SNMPv1 Framework anticipated the definition of However, while the SNMPv1 Framework anticipated the definition of
multiple authentication schemes, it did not define any such schemes multiple authentication schemes, it did not define any such schemes
other than a trivial authentication scheme based on community other than a trivial authentication scheme based on community strings.
strings. This was a known fundamental weakness in the SNMPv1 This was a known fundamental weakness in the SNMPv1 Framework but it was
Framework but it was thought at that time that the definition of thought at that time that the definition of commercial grade security
commercial grade security might be contentious in its design and might be contentious in its design and difficult to get approved because
difficult to get approved because "security" means many different "security" means many different things to different people. To that
things to different people. To that end, and because some users do end, and because some users do not require strong authentication, the
not require strong authentication, the SNMPv1 architected an SNMPv1 architected an authentication service as a separate block to be
authentication service as a separate block to be defined "later" and defined "later" and the SNMPv3 Framework provides an architecture for
the SNMPv3 Framework provides an architecture for use within that use within that block as well as a definition for its subsystems.
block as well as a definition for its subsystems.
4. The SNMPv2 Management Framework 4. The SNMPv2 Management Framework
The SNMPv2 Management Framework is fully described in [4-9] and The SNMPv2 Management Framework is fully described in [4-9] and
coexistence and transition issues relating to SNMPv1 and SNMPv2 are coexistence and transition issues relating to SNMPv1 and SNMPv2 are
discussed in [10]. discussed in [10].
SNMPv2 provides several advantages over SNMPv1, including: SNMPv2 provides several advantages over SNMPv1, including:
* expanded data types (e.g., 64 bit counter) * expanded data types (e.g., 64 bit counter)
skipping to change at page 8, line 42 skipping to change at page 9, line 23
* authentication: origin identification, message integrity, * authentication: origin identification, message integrity,
and some aspects of replay protection; and some aspects of replay protection;
* privacy: confidentiality; * privacy: confidentiality;
* authorization and access control; and * authorization and access control; and
* suitable remote configuration and administration capabilities * suitable remote configuration and administration capabilities
for these features. for these features.
The SNMPv3 Management Framework, as described in this document and The SNMPv3 Management Framework, as described in this document and the
the companion documents, addresses these significant deficiencies. companion documents, addresses these significant deficiencies.
5. The SNMPv3 Working Group 5. The SNMPv3 Working Group
This document, and its companion documents, were produced by the This document, and its companion documents, were produced by the SNMPv3
SNMPv3 Working Group of the Internet Engineering Task Force (IETF). Working Group of the Internet Engineering Task Force (IETF). The SNMPv3
The SNMPv3 Working Group was chartered to prepare recommendations for Working Group was chartered to prepare recommendations for the next
the next generation of SNMP. The goal of the Working Group was to generation of SNMP. The goal of the Working Group was to produce the
produce the necessary set of documents that provide a single standard necessary set of documents that provide a single standard for the next
for the next generation of core SNMP functions. The single, most generation of core SNMP functions. The single, most critical need in
critical need in the next generation is a definition of security and the next generation is a definition of security and administration that
administration that makes SNMP-based management transactions secure makes SNMP-based management transactions secure in a way which is useful
in a way which is useful for users who wish to use SNMPv3 to manage for users who wish to use SNMPv3 to manage networks, the systems that
networks, the systems that make up those networks, and the make up those networks, and the applications which reside on those
applications which reside on those systems, including manager-to- systems, including manager-to-agent, agent-to-manager, and manager-to-
agent, agent-to-manager, and manager-to-manager transactions. manager transactions.
In the several years prior to the chartering of the Working Group, In the several years prior to the chartering of the Working Group, there
there were a number of activities aimed at incorporating security and were a number of activities aimed at incorporating security and other
other improvements to SNMP. These efforts included: improvements to SNMP. These efforts included:
* "SNMP Security" circa 1991-1992 [RFC 1351 - RFC 1353], * "SNMP Security" circa 1991-1992 [RFC 1351 - RFC 1353],
* "SMP" circa 1992-1993, * "SMP" circa 1992-1993,
* "The Party-based SNMPv2" circa 1993-1995 [RFC 1441 - RFC 1452]. * "The Party-based SNMPv2" circa 1993-1995 [RFC 1441 - RFC 1452].
Each of these efforts incorporated commercial grade, industrial Each of these efforts incorporated commercial grade, industrial strength
strength security including authentication, privacy, authorization, security including authentication, privacy, authorization, view-based
view-based access control, and administration, including remote access control, and administration, including remote configuration.
configuration.
These efforts fed the development of the SNMPv2 Management Framework These efforts fed the development of the SNMPv2 Management Framework as
as described in RFCs 1902 - 1908. However, the Framework described described in RFCs 1902 - 1908. However, the Framework described in
in those RFCs had no standards-based security and administrative those RFCs had no standards-based security and administrative framework
framework of its own; rather, it was associated with multiple of its own; rather, it was associated with multiple security and
security and administrative frameworks, including: administrative frameworks, including:
* "The Community-based SNMPv2" (SNMPv2c) [RFC 1901], * "The Community-based SNMPv2" (SNMPv2c) [RFC 1901],
* "SNMPv2u" [RFCs 1909 - 1910] and * "SNMPv2u" [RFCs 1909 - 1910] and
* "SNMPv2*." * "SNMPv2*."
SNMPv2c had the endorsement of the IETF but no security and SNMPv2c had the endorsement of the IETF but no security and
administration whereas both SNMPv2u and SNMPv2* had security but administration whereas both SNMPv2u and SNMPv2* had security but lacked
lacked the endorsement of the IETF. the endorsement of the IETF.
The SNMPv3 Working Group was chartered to produce a single set of The SNMPv3 Working Group was chartered to produce a single set of
specifications for the next generation of SNMP, based upon a specifications for the next generation of SNMP, based upon a convergence
convergence of the concepts and technical elements of SNMPv2u and of the concepts and technical elements of SNMPv2u and SNMPv2*, as was
SNMPv2*, as was suggested by an advisory team which was formed to suggested by an advisory team which was formed to provide a single
provide a single recommended approach for SNMP evolution. recommended approach for SNMP evolution.
In so doing, the Working Group charter defined the following In so doing, the Working Group charter defined the following objectives:
objectives:
* accommodate the wide range of operational environments with * accommodate the wide range of operational environments with
differing management demands; differing management demands;
* facilitate the need to transition from previous, multiple * facilitate the need to transition from previous, multiple
protocols to SNMPv3; protocols to SNMPv3;
* facilitate the ease of setup and maintenance activities. * facilitate the ease of setup and maintenance activities.
In the initial work of the SNMPv3 Working Group, the group focused on In the initial work of the SNMPv3 Working Group, the group focused on
skipping to change at page 10, line 19 skipping to change at page 11, line 4
protocols to SNMPv3; protocols to SNMPv3;
* facilitate the ease of setup and maintenance activities. * facilitate the ease of setup and maintenance activities.
In the initial work of the SNMPv3 Working Group, the group focused on In the initial work of the SNMPv3 Working Group, the group focused on
security and administration, including security and administration, including
* authentication and privacy, * authentication and privacy,
* authorization and view-based access control, and * authorization and view-based access control, and
* standards-based remote configuration of the above. * standards-based remote configuration of the above.
The SNMPv3 Working Group did not "reinvent the wheel," but reused the The SNMPv3 Working Group did not "reinvent the wheel," but reused the
SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908. SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for those
portions of the design that were outside the focused scope.
The SNMPv3 Working Group produced a design based on a modular Rather, the primary contributors to the SNMPv3 Working Group, and the
architecture with evolutionary capabilities with emphasis on Working Group in general, devoted their considerable efforts to
layering. As a result, SNMPv3 is SNMPv2 plus security and addressing the missing link -- security and administration -- and in the
administration. process made invaluable contributions to the state-of-the-art of
management.
In doing so, the Working Group achieved the goal of producing a They produced a design based on a modular architecture with evolutionary
single specification which has both the endorsement of the IETF and capabilities with emphasis on layering. As a result, SNMPv3 can be
security and administration. thought of as SNMPv2 with additional security and administration
capabilities.
In doing so, the Working Group achieved the goal of producing a single
specification which has both the endorsement of the IETF and security
and administration.
6. SNMPv3 Framework Module Specifications 6. SNMPv3 Framework Module Specifications
The specification of the SNMPv3 Management Framework is partitioned The specification of the SNMPv3 Management Framework is partitioned in a
in a modular fashion among several documents. It is the intention of modular fashion among several documents. It is the intention of the
the SNMPv3 Working Group that, with proper care, any or all of the SNMPv3 Working Group that, with proper care, any or all of the
individual documents can be revised, upgraded, or replaced as individual documents can be revised, upgraded, or replaced as
requirements change, new understandings are obtained, and new requirements change, new understandings are obtained, and new
technologies become available. technologies become available.
Whenever feasible, the initial document set which defines the SNMPv3 Whenever feasible, the initial document set which defines the SNMPv3
Management Framework leverages prior investments defining and Management Framework leverages prior investments defining and
implementing the SNMPv2 Management Framework by incorporating by implementing the SNMPv2 Management Framework by incorporating by
reference each of the specifications of the SNMPv2 Management reference each of the specifications of the SNMPv2 Management Framework.
Framework.
The SNMPv3 Framework augments those specifications with The SNMPv3 Framework augments those specifications with specifications
specifications for security and administration for SNMPv3. for security and administration for SNMPv3.
The documents which specify the SNMPv3 Management Framework follow The documents which specify the SNMPv3 Management Framework follow the
the same architecture as those of the prior versions and can be same architecture as those of the prior versions and can be organized
organized for expository purposes into four main categories as for expository purposes into four main categories as follows:
follows:
* the data definition language, * the data definition language,
* Management Information Base (MIB) modules, * Management Information Base (MIB) modules,
* protocol operations, and * protocol operations, and
* security and administration. * security and administration.
The first three sets of documents are incorporated from SNMPv2. The The first three sets of documents are incorporated from SNMPv2. The
fourth set of documents are new to SNMPv3, but, as described fourth set of documents are new to SNMPv3, but, as described previously,
previously, build on significant prior related works. build on significant prior related works.
6.1 Data Definition Language 6.1. Data Definition Language
The specifications of the data definition language includes RFC 1902, The specifications of the data definition language includes RFC 1902,
"The Structure of Management Information for Version 2 of the Simple "The Structure of Management Information for Version 2 of the Simple
Network Management Protocol (SNMPv2)" [4], and related Network Management Protocol (SNMPv2)" [4], and related specifications.
specifications. The Structure of Management Information (SMI) The Structure of Management Information (SMI) defines fundamental data
defines fundamental data types, an object model, and the rules for types, an object model, and the rules for writing and revising MIB
writing and revising MIB modules. Related specifications include RFC modules. Related specifications include RFC 1903 and RFC 1904. The
1903 and RFC 1904. The updated data definition language is sometimes updated data definition language is sometimes refered to as SMIv2.
refered to as SMIv2.
RFC 1903, "Textual Conventions for Version 2 of the Simple Network RFC 1903, "Textual Conventions for Version 2 of the Simple Network
Management Protocol (SNMPv2)" [5], defines an initial set of Management Protocol (SNMPv2)" [5], defines an initial set of shorthand
shorthand abbreviations which are available for use within all MIB abbreviations which are available for use within all MIB modules for the
modules for the convenience of human readers and writers. convenience of human readers and writers.
RFC 1904, "Conformance Statements for Version 2 of the Simple Network RFC 1904, "Conformance Statements for Version 2 of the Simple Network
Management Protocol (SNMPv2)" [6], defines the format for compliance Management Protocol (SNMPv2)" [6], defines the format for compliance
statements which are used for describing requirements for agent statements which are used for describing requirements for agent
implementations and capability statements which can be used to implementations and capability statements which can be used to document
document the characteristics of particular implementations. the characteristics of particular implementations.
6.2 MIB Modules 6.2. MIB Modules
MIB modules usually contain object definitions, may contain MIB modules usually contain object definitions, may contain definitions
definitions of event notifications, and sometimes include compliance of event notifications, and sometimes include compliance statements
statements specified in terms of appropriate object and event specified in terms of appropriate object and event notification groups.
notification groups. As such, MIB modules define the management As such, MIB modules define the management information maintained by the
information maintained by the instrumentation in managed nodes, made instrumentation in managed nodes, made remotely accessible by management
remotely accessible by management agents, conveyed by the management agents, conveyed by the management protocol, and manipulated by
protocol, and manipulated by management applications. management applications.
MIB modules are defined according the rules defined in the documents MIB modules are defined according the rules defined in the documents
which specify the data definition language, principally the SMI as which specify the data definition language, principally the SMI as
supplemented by the related specifications. supplemented by the related specifications.
There is a large and growing number of standards-based MIB modules, There is a large and growing number of standards-based MIB modules, as
as defined in the periodically updated list of standard protocols defined in the periodically updated list of standard protocols [STD
[STD 0001, RFC 2000]. As of this writing, there are nearly 100 0001, RFC 2000]. As of this writing, there are nearly 100 standards-
standards-based MIB modules with a total number of defined objects based MIB modules with a total number of defined objects approaching
approaching 10,000. In addition, there is an even larger and growing 10,000. In addition, there is an even larger and growing number of
number of enterprise-specific MIB modules defined unilaterally by enterprise-specific MIB modules defined unilaterally by various vendors,
various vendors, research groups, consortia, and the like resulting research groups, consortia, and the like resulting in an unknown and
in an unknown and virtually uncountable number of defined objects. virtually uncountable number of defined objects.
In general, management information defined in any MIB module, In general, management information defined in any MIB module, regardless
regardless of the version of the data definition language used, can of the version of the data definition language used, can be used with
be used with any version of the protocol. For example, MIB modules any version of the protocol. For example, MIB modules defined in terms
defined in terms of the SNMPv1 SMI (SMIv1) are compatible with the of the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management
SNMPv3 Management Framework and can be conveyed by the protocols Framework and can be conveyed by the protocols specified therein.
specified therein. Furthermore, MIB modules defined in terms of the Furthermore, MIB modules defined in terms of the SNMPv2 SMI (SMIv2) are
SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and compatible with SNMPv1 protocol operations and can be conveyed by it.
can be conveyed by it. However, there is one noteworthy exception: However, there is one noteworthy exception: the Counter64 datatype
the Counter64 datatype which can be defined in a MIB module defined which can be defined in a MIB module defined in SMIv2 format but which
in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol cannot be conveyed by an SNMPv1 protocol engine.
engine.
6.3 Protocol Operations and Transport Mappings 6.3. Protocol Operations and Transport Mappings
The specifications for the protocol operations and transport mappings The specifications for the protocol operations and transport mappings of
of the SNMPv3 Framework are incorporated by reference to the two the SNMPv3 Framework are incorporated by reference to the two SNMPv2
SNMPv2 Framework documents. Framework documents.
The specification for protocol operations is found in RFC 1905, The specification for protocol operations is found in RFC 1905,
"Protocol Operations for Version 2 of the Simple Network Management "Protocol Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)" [7]. Protocol (SNMPv2)" [7].
The specification of transport mappings is found in RFC 1906, The specification of transport mappings is found in RFC 1906, "Transport
"Transport Mappings for Version 2 of the Simple Network Management Mappings for Version 2 of the Simple Network Management Protocol
Protocol (SNMPv2)" [8]. (SNMPv2)" [8].
6.4 SNMPv3 Security and Administration 6.4. SNMPv3 Security and Administration
The SNMPv3 document series defined by the SNMPv3 Working Group The SNMPv3 document series defined by the SNMPv3 Working Group consists
consists of six [seven] documents at this time: of six [seven] documents at this time:
RFC xxxx, "Introduction to the Third Version of the Internet RFC xxxx, "Introduction to the Third Version of the Internet
Standard Management Framework (SNMPv3)," which is this document. Standard Management Framework (SNMPv3)," which is this document.
RFC 2271, "An Architecture for Describing SNMP Management RFC 2271, "An Architecture for Describing SNMP Management
Frameworks" [15], describes the overall architecture with special Frameworks" [15], describes the overall architecture with special
emphasis on the architecture for security and administration. emphasis on the architecture for security and administration.
RFC 2272, "Message Processing and Dispatching for the Simple RFC 2272, "Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)" [16], describes the possibly Network Management Protocol (SNMP)" [16], describes the possibly
skipping to change at page 14, line 10 skipping to change at page 16, line 10
originator applications. originator applications.
RFC yyyy, "SNMPv3 Coexistence and Transition" [20], does not exist RFC yyyy, "SNMPv3 Coexistence and Transition" [20], does not exist
yet and is still in development. yet and is still in development.
7. Document Summaries 7. Document Summaries
The following sections provide brief summaries of each document with The following sections provide brief summaries of each document with
slightly more detail than is provided in the overviews, above. slightly more detail than is provided in the overviews, above.
7.1 Structure of Management Information 7.1. Structure of Management Information
Management information is viewed as a collection of managed objects, Management information is viewed as a collection of managed objects,
residing in a virtual information store, termed the Management residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined Information Base (MIB). Collections of related objects are defined in
in MIB modules. These modules are written in the SNMP MIB module MIB modules. These modules are written in the SNMP MIB module language,
language, which contains elements of OSI's Abstract Syntax Notation which contains elements of OSI's Abstract Syntax Notation One (ASN.1)
One (ASN.1) [11] language. RFC 1902, RFC 1903, and RFC 1904 together [11] language. RFC 1902, RFC 1903, and RFC 1904 together define the MIB
define the MIB module language, specify the base data types for module language, specify the base data types for objects, specify a core
objects, specify a core set of short-hand specifications for data set of short-hand specifications for data types called textual
types called textual conventions, and specify a few administrative conventions, and specify a few administrative assignments of object
assignments of object identifier (OID) values. identifier (OID) values.
The SMI is divided into three parts: module definitions, object The SMI is divided into three parts: module definitions, object
definitions, and, trap definitions. definitions, and, trap definitions.
(1) Module definitions are used when describing information modules. (1) Module definitions are used when describing information modules.
An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the
semantics of an information module. semantics of an information module.
(2) Object definitions are used when describing managed objects. An (2) Object definitions are used when describing managed objects. An
ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax
and semantics of a managed object. and semantics of a managed object.
(3) Notification definitions are used when describing unsolicited (3) Notification definitions are used when describing unsolicited
transmissions of management information. An ASN.1 macro, transmissions of management information. An ASN.1 macro,
NOTIFICATION-TYPE, is used to convey concisely the syntax and NOTIFICATION-TYPE, is used to convey concisely the syntax and
semantics of a notification. semantics of a notification.
7.1.1 Base SMI Specification 7.1.1. Base SMI Specification
RFC 1902 specifies the base data types for the MIB module language, RFC 1902 specifies the base data types for the MIB module language,
which include: Integer32, enumerated integers, Unsigned32, Gauge32, which include: Integer32, enumerated integers, Unsigned32, Gauge32,
Counter32, Counter64, TimeTicks, OCTET STRING, OBJECT IDENTIFIER, Counter32, Counter64, TimeTicks, OCTET STRING, OBJECT IDENTIFIER,
IpAddress, Opaque, and BITS. It also assigns values to several object IpAddress, Opaque, and BITS. It also assigns values to several object
identifiers. RFC 1902 further defines the following constructs of identifiers. RFC 1902 further defines the following constructs of the
the MIB module language: MIB module language:
* IMPORTS to allow the specification of items that are used * IMPORTS to allow the specification of items that are used
in a MIB module, but defined in another MIB module. in a MIB module, but defined in another MIB module.
* MODULE-IDENTITY to specify for a MIB module a description * MODULE-IDENTITY to specify for a MIB module a description
and administrative information such as contact and revision and administrative information such as contact and revision
history. history.
* OBJECT-IDENTITY and OID value assignments to specify a * OBJECT-IDENTITY and OID value assignments to specify a
an OID value. an OID value.
* OBJECT-TYPE to specify the data type, status, and the semantics * OBJECT-TYPE to specify the data type, status, and the semantics
of managed objects. of managed objects.
* SEQUENCE type assignement to list the columnar objects in * SEQUENCE type assignement to list the columnar objects in
a table. a table.
* NOTIFICATION-TYPE construct to describe an event notification. * NOTIFICATION-TYPE construct to describe an event notification.
7.1.2 Textual Conventions 7.1.2. Textual Conventions
When designing a MIB module, it is often useful to specify in a When designing a MIB module, it is often useful to specify in a short-
short-hand way the semantics for a set of objects with similar hand way the semantics for a set of objects with similar behavior. This
behavior. This is done by defining a new data type using a base data is done by defining a new data type using a base data type specified in
type specified in the SMI. Each new type has a different name, and the SMI. Each new type has a different name, and specifies a base type
specifies a base type with more restrictive semantics. These newly with more restrictive semantics. These newly defined types are termed
defined types are termed textual conventions, and are used for the textual conventions, and are used for the convenience of humans reading
convenience of humans reading a MIB module and potentially by a MIB module and potentially by "intelligent" management applications.
"intelligent" management applications. It is the purpose of RFC It is the purpose of RFC 1903, Textual Conventions for SNMPv2 [5], to
1903, Textual Conventions for SNMPv2 [5], to define the construct, define the construct, TEXTUAL-CONVENTION, of the MIB module language
TEXTUAL-CONVENTION, of the MIB module language used to define such used to define such new types and to specify an initial set of textual
new types and to specify an initial set of textual conventions conventions available to all MIB modules.
available to all MIB modules.
7.1.3 Conformance Statements 7.1.3. Conformance Statements
It may be useful to define the acceptable lower-bounds of It may be useful to define the acceptable lower-bounds of
implementation, along with the actual level of implementation implementation, along with the actual level of implementation achieved.
achieved. It is the purpose of RFC 1904, Conformance Statements for It is the purpose of RFC 1904, Conformance Statements for SNMPv2 [6], to
SNMPv2 [6], to define the constructs of the MIB module language used define the constructs of the MIB module language used for these
for these purposes. There are two kinds of constructs: purposes. There are two kinds of constructs:
(1) Compliance statements are used when describing requirements for (1) Compliance statements are used when describing requirements for
agents with respect to object and event notification definitions. agents with respect to object and event notification definitions.
The MODULE-COMPLIANCE construct is used to convey concisely The MODULE-COMPLIANCE construct is used to convey concisely
such requirements. such requirements.
(2) Capability statements are used when describing capabilities of (2) Capability statements are used when describing capabilities of
agents with respect to object and event notification definitions. agents with respect to object and event notification definitions.
The AGENT-CAPABILITIES construct is used to convey concisely such The AGENT-CAPABILITIES construct is used to convey concisely such
capabilities. capabilities.
Finally, collections of related objects and collections of related Finally, collections of related objects and collections of related event
event notifications are grouped together to form a unit of notifications are grouped together to form a unit of conformance. The
conformance. The OBJECT-GROUP construct is used to convey concisely OBJECT-GROUP construct is used to convey concisely the objects in and
the objects in and the semantics of an object group. The the semantics of an object group. The NOTIFICATION-GROUP construct is
NOTIFICATION-GROUP construct is used to convey concisely the event used to convey concisely the event notifications in and the semantics of
notifications in and the semantics of an event notification group. an event notification group.
7.2 Protocol Operations 7.2. Protocol Operations
The management protocol provides for the exchange of messages which The management protocol provides for the exchange of messages which
convey management information between the agents and the management convey management information between the agents and the management
stations. The form of these messages is a message "wrapper" which stations. The form of these messages is a message "wrapper" which
encapsulates a Protocol Data Unit (PDU). encapsulates a Protocol Data Unit (PDU).
It is the purpose of RFC 1905, Protocol Operations for SNMPv2 [7], to It is the purpose of RFC 1905, Protocol Operations for SNMPv2 [7], to
define the operations of the protocol with respect to the sending and define the operations of the protocol with respect to the sending and
receiving of the PDUs. receiving of the PDUs.
7.3 Transport Mappings 7.3. Transport Mappings
SNMP Messages may be used over a variety of protocol suites. It is SNMP Messages may be used over a variety of protocol suites. It is the
the purpose of RFC 1906, Transport Mappings for SNMPv2 [8], to define purpose of RFC 1906, Transport Mappings for SNMPv2 [8], to define how
how SNMP messages maps onto an initial set of transport domains. SNMP messages maps onto an initial set of transport domains. Other
Other mappings may be defined in the future. mappings may be defined in the future.
Although several mappings are defined, the mapping onto UDP is the Although several mappings are defined, the mapping onto UDP is the
preferred mapping. As such, to provide for the greatest level of preferred mapping. As such, to provide for the greatest level of
interoperability, systems which choose to deploy other mappings interoperability, systems which choose to deploy other mappings should
should also provide for proxy service to the UDP mapping. also provide for proxy service to the UDP mapping.
7.4 Protocol Instrumentation 7.4. Protocol Instrumentation
It is the purpose of RFC 1907, the Management Information Base for It is the purpose of RFC 1907, the Management Information Base for
SNMPv2 document [9] to define managed objects which describe the SNMPv2 document [9] to define managed objects which describe the
behavior of an SNMPv2 entity. behavior of an SNMPv2 entity.
7.5 Architecture / Security and Administration 7.5. Architecture / Security and Administration
It is the purpose of RFC 2271, "SNMPv3 Architecture" [15], to define It is the purpose of RFC 2271, "Architecture Document" [15], to define
an architecture for defining SNMP Management Frameworks. While an architecture for specifying SNMP Management Frameworks. While
addressing general architectural issues, it focuses on aspects addressing general architectural issues, it focuses on aspects related
related to security and administration. It defines a number of terms to security and administration. It defines a number of terms used
used throughout the SNMPv3 Management Framework and, in so doing, throughout the SNMPv3 Management Framework and, in so doing, clarifies
clarifies and extends the naming of and extends the naming of
* engines and applications, * engines and applications,
* entities (service providers such as the engines in agents * entities (service providers such as the engines in agents
and managers), and managers),
* identities (service users), and * identities (service users), and
* management information, including support for multiple * management information, including support for multiple
logical contexts. logical contexts.
The document contains a small MIB module which is implemented by all The document contains a small MIB module which is implemented by all
authoritative SNMPv3 protocol engines. authoritative SNMPv3 protocol engines.
7.6 Message Processing and Dispatch (MPD) 7.6. Message Processing and Dispatch (MPD)
RFC 2272, "Message Processing and Dispatching for the Simple Network RFC 2272, "Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)" [16], describes the Message Processing Management Protocol (SNMP)" [16], describes the Message Processing and
and Dispatching for SNMP messages within the SNMP architecture. It Dispatching for SNMP messages within the SNMP architecture. It defines
defines the procedures for dispatching potentially multiple versions the procedures for dispatching potentially multiple versions of SNMP
of SNMP messages to the proper SNMP Message Processing Models, and messages to the proper SNMP Message Processing Models, and for
for dispatching PDUs to SNMP applications. This document also dispatching PDUs to SNMP applications. This document also describes one
describes one Message Processing Model - the SNMPv3 Message Message Processing Model - the SNMPv3 Message Processing Model.
Processing Model.
It is expected that an SNMPv3 protocol engine MUST support at least It is expected that an SNMPv3 protocol engine MUST support at least one
one Message Processing Model. An SNMPv3 protocol engine MAY support Message Processing Model. An SNMPv3 protocol engine MAY support more
more than one, for example in a multilingual system which provides than one, for example in a multilingual system which provides
simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c. simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c.
7.7 SNMPv3 Applications 7.7. SNMPv3 Applications
It is the purpose of RFC 2273, "SNMPv3 Applications" to describe the It is the purpose of RFC 2273, "SNMPv3 Applications" to describe the
five types of applications which can be associated with an SNMP five types of applications which can be associated with an SNMP engine.
engine. They are: Command Generators, Command Responders, They are: Command Generators, Command Responders, Notification
Notification Originators, Notification Receivers, and Proxy Originators, Notification Receivers, and Proxy Forwarders.
Forwarders.
The document also defines MIB modules for specifying targets of The document also defines MIB modules for specifying targets of
management operations (including notifications), for notification management operations (including notifications), for notification
filtering, and for proxy forwarding. filtering, and for proxy forwarding.
7.8 User-based Security Model (USM) 7.8. User-based Security Model (USM)
RFC 2274, the "User-based Security Model (USM) for version 3 of the RFC 2274, the "User-based Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3)" describes the User-based Simple Network Management Protocol (SNMPv3)" describes the User-based
Security Model for SNMPv3. It defines the Elements of Procedure for Security Model for SNMPv3. It defines the Elements of Procedure for
providing SNMP message-level security. providing SNMP message-level security.
The document describes the two primary and two secondary threats The document describes the two primary and two secondary threats which
which are defended against by the User-based Security Model. They are defended against by the User-based Security Model. They are:
are: modification of information, masquerade, message stream modification of information, masquerade, message stream modification,
modification, and [optionally] disclosure. and [optionally] disclosure.
The USM utilizes MD5 [21] and the Secure Hash Algorithm [22] as keyed The USM utilizes MD5 [21] and the Secure Hash Algorithm [22] as keyed
hashing algorithms [22] for digest computation to provide data hashing algorithms [22] for digest computation to provide data integrity
integrity
* to directly protect against data modification attacks, * to directly protect against data modification attacks,
* to indirectly provide data origin authentication, and * to indirectly provide data origin authentication, and
* to defend against masquerade attacks. * to defend against masquerade attacks.
The USM uses loosely synchronized monotonically increasing time The USM uses loosely synchronized monotonically increasing time
indicators to defend against certain message stream modification indicators to defend against certain message stream modification
attacks. Automatic clock synchronization mechanisms based on the attacks. Automatic clock synchronization mechanisms based on the
protocol are specified without dependence on third-party time sources protocol are specified without dependence on third-party time sources
and concomitant security considerations. and concomitant security considerations.
The USM uses the Data Encryption Standard (DES) [24] in the cipher The USM uses the Data Encryption Standard (DES) [24] in the cipher block
block chaining mode (CBC) [optionally] to protect against disclosure. chaining mode (CBC) if disclosure protection is desired.
The document also includes a MIB suitable for remotely monitoring and The document also includes a MIB suitable for remotely monitoring and
managing the configuration parameters for the USM, including key managing the configuration parameters for the USM, including key
distribution and key management. distribution and key management.
A single protocol entity may provide simultaneous support for An entity may provide simultaneous support for multiple security models
multiple security models as well as multiple authentication and as well as multiple authentication and privacy protocols. All of the
privacy protocols. All of the protocols used by the USM are based on protocols used by the USM are based on pre-placed keys, i.e., private
symmetric cryptography, i.e., private key mechanisms. The SNMPv3 key mechanisms. The SNMPv3 architecture permits the use of asymetric
architecture admits the use of public key cryptography, but as of mechanisms and protocols (commonly called but as of this writing, no
this writing, no SNMPv3 security models utilizing public key such SNMPv3 security models utilizing public key cryptography have been
cryptography have been published.
7.9 View-based Access Control (VACM) published.
The purpose of RFC 2275, the "View-based Access Control Model (VACM) 7.9. View-based Access Control (VACM)
for the Simple Network Management Protocol (SNMP)" is to describe the
View-based Access Control Model for use in the SNMP architecture. The purpose of RFC 2275, the "View-based Access Control Model (VACM) for
The VACM can simultaneously be associated in a single engine the Simple Network Management Protocol (SNMP)" is to describe the View-
implementation with multiple Message Processing Models and multiple based Access Control Model for use in the SNMP architecture. The VACM
Security Models. can simultaneously be associated in a single engine implementation with
multiple Message Processing Models and multiple Security Models.
It is architecturally possible to have multiple, different, Access It is architecturally possible to have multiple, different, Access
Control Models active and present simultaneously in a single engine Control Models active and present simultaneously in a single engine
implementation, but this is expected to be *_very_* rare in practice implementation, but this is expected to be *_very_* rare in practice and
and *_far_* less common than simultaneous support for multiple *_far_* less common than simultaneous support for multiple Message
Message Processing Models and/or multiple Security Models. Processing Models and/or multiple Security Models.
7.10. SNMPv3 Coexistence and Transition
7.10 SNMPv3 Coexistence and Transition
This document does not exist yet. It needs to contain: This document does not exist yet. It needs to contain:
background of 2 approaches to coexistence and transition background of 2 approaches to coexistence and transition
multilingual approach multilingual approach
proxy approach proxy approach
mapping functions derived from rfc 2089 but incorporated by value mapping functions derived from rfc 2089 but incorporated by value
rather than by reference in order to get these functions onto the rather than by reference in order to get these functions onto the
standards track and to fix up any lingering problems standards track and to fix up any lingering problems
a community-based security model consistent with the architecture a community-based security model consistent with the architecture
and containing a suitable MIB module for remote configuration thereof and containing a suitable MIB module for remote configuration thereof
for use by multilingual engines supporting snmpv1 and snmpv2c in for use by multilingual engines supporting snmpv1 and snmpv2c in
addition to snmpv3 addition to snmpv3
This could be multiple documents, but it really isn't necessary to have more This could be multiple documents, but it really isn't necessary to have more
than one and fewer are better than many. than one and fewer are better than many.
8. Security Considerations 8. Security Considerations
As this document is primarily a roadmap document, it introduces no As this document is primarily a roadmap document, it introduces no new
new security considerations. The reader is referred to the relevant security considerations. The reader is referred to the relevant
sections of each of the referenced documents for information about sections of each of the referenced documents for information about
security considerations. security considerations.
9. Editors' Addresses 9. Editors' Addresses
Jeffrey Case Jeffrey Case
SNMP Research, Inc. SNMP Research, Inc.
3001 Kimberlin Heights Road 3001 Kimberlin Heights Road
Knoxville, TN 37920-9716 Knoxville, TN 37920-9716
USA USA
Phone: +1 423 573 1434 Phone: +1 423 573 1434
EMail: case@snmp.com EMail: case@snmp.com
Russ Mundy Russ Mundy
Trusted Information Systems TIS Labs at Network Associates
3060 Washington Rd 3060 Washington Rd
Glenwood, MD 21738 Glenwood, MD 21738
USA USA
Phone: +1 301 854 6889 Phone: +1 301 854 6889
Email: mundy@tis.com Email: mundy@tis.com
David Partain David Partain
SNMP Research Europe SNMP Research Europe
Teknikringen 1 Teknikringen 1
S-583 30 Linkoping S-583 30 Linkoping
skipping to change at page 21, line 11 skipping to change at page 23, line 11
U.S.A. U.S.A.
Phone: +1 603 654 6923 Phone: +1 603 654 6923
EMail: bstewart@cisco.com EMail: bstewart@cisco.com
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
skipping to change at page 22, line 37 skipping to change at page 24, line 42
S. Waldbusser, "Coexistence between Version 1 and Version 2 of the S. Waldbusser, "Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework", RFC 1908, Internet-standard Network Management Framework", RFC 1908,
January 1996. January 1996.
[11] Information processing systems - Open Systems Interconnection - [11] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International International Organization for Standardization. International
Standard 8824, (December, 1987). Standard 8824, (December, 1987).
[12] McCloghrie, K., and M. Rose, "Management Information Base for [12] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based Internets", RFC 1066, August 1988. Network Management of TCP/IP-based Internets", RFC 1066,
August 1988.
[13] McCloghrie, K., and M. Rose, "Management Information Base for [13] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets: MIB-II, RFC 1213, Network Management of TCP/IP-based internets: MIB-II, RFC 1213,
March 1991. March 1991.
[14] Cerf, V., "IAB Recommendations for the Development of Internet [14] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, April 1988. Network Management Standards", RFC 1052, April 1988.
[15] Harrington, D, R. Presuhn, and B. Wijnen, "An Architecture for [15] Harrington, D, R. Presuhn, and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks, RFC 2271, January, 1998. Describing SNMP Management Frameworks, RFC 2271, January, 1998.
[16] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message [16] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2272, January 1998. Protocol (SNMP)", RFC 2272, January 1998.
[17] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, [17] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
January 1998. RFC 2273, January 1998.
[18] Blumenthal, U., and B. Wijnen, "The User-Based Security Model for [18] Blumenthal, U., and B. Wijnen, "The User-Based Security Model for
Version 3 of the Simple Network Management Protocol (SNMPv3)", Version 3 of the Simple Network Management Protocol (SNMPv3)",
RFC 2274, January 1998. RFC 2274, January 1998.
[19] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control [19] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Model for the Simple Network Management Protocol (SNMP)", RFC 2275, Control Model for the Simple Network Management Protocol (SNMP)",
January 1998. RFC 2275, January 1998.
[20] TBD, "SNMPv3 Coexistence and Transition", RFC yyyy, Work in progress, [20] TBD, "SNMPv3 Coexistence and Transition", RFC yyyy, Work in
date TBD. progress, date TBD.
[21] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992. [21] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[22] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) [22] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995)
http://csrc.nist.gov/fips/fip180-1.txt (ASCII) http://csrc.nist.gov/fips/fip180-1.txt (ASCII)
http://csrc.nist.gov/fips/fip180-1.ps (Postscript) http://csrc.nist.gov/fips/fip180-1.ps (Postscript)
[23] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: [23] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104, February Keyed-Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[24] Data Encryption Standard, National Institute of Standards [24] Data Encryption Standard, National Institute of Standards
and Technology. Federal Information Processing Standard (FIPS) and Technology. Federal Information Processing Standard (FIPS)
Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; Publication 46-1. Supersedes FIPS Publication 46, (January, 1977;
reaffirmed January, 1988). reaffirmed January, 1988).
[25] M.T. Rose, "A Convention for Defining Traps for use with the [25] M.T. Rose, "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991. SNMP", RFC 1215, March 1991.
Table of Contents
0 Revision History: ............................................... 2
1 Introduction .................................................... 3
2 The Internet Standard Management Framework ...................... 4
2.1 Basic Structure and Components ................................ 4
2.2 Architecture of the Internet Standard Management Framework .... 4
3 The SNMPv1 Management Framework ................................. 6
3.1 The SNMPv1 Data Definition Language ........................... 6
3.2 Management Information ........................................ 7
3.3 Protocol Operations ........................................... 7
3.4 SNMPv1 Security and Administration ............................ 7
4 The SNMPv2 Management Framework ................................. 8
5 The SNMPv3 Working Group ........................................ 9
6 SNMPv3 Framework Module Specifications .......................... 12
6.1 Data Definition Language ...................................... 12
6.2 MIB Modules ................................................... 13
6.3 Protocol Operations and Transport Mappings .................... 14
6.4 SNMPv3 Security and Administration ............................ 14
7 Document Summaries .............................................. 16
7.1 Structure of Management Information ........................... 16
7.1.1 Base SMI Specification ...................................... 16
7.1.2 Textual Conventions ......................................... 17
7.1.3 Conformance Statements ...................................... 17
7.2 Protocol Operations ........................................... 18
7.3 Transport Mappings ............................................ 18
7.4 Protocol Instrumentation ...................................... 18
7.5 Architecture / Security and Administration .................... 19
7.6 Message Processing and Dispatch (MPD) ......................... 19
7.7 SNMPv3 Applications ........................................... 19
7.8 User-based Security Model (USM) ............................... 20
7.9 View-based Access Control (VACM) .............................. 21
7.10 SNMPv3 Coexistence and Transition ............................ 21
8 Security Considerations ......................................... 22
9 Editors' Addresses .............................................. 22
10 Full Copyright Statement ....................................... 23
11 References ..................................................... 23
 End of changes. 106 change blocks. 
334 lines changed or deleted 368 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/