draft-ietf-snmpv3-intro-02.txt   draft-ietf-snmpv3-intro-03.txt 
skipping to change at page 2, line ? 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/10/14 19:33:28 1999/01/21 22:03:06
draft-ietf-snmpv3-intro-02.txt draft-ietf-snmpv3-intro-03.txt
1.6 -- 1998/10/14 19:33:28 1.12 -- 1999/01/21 22:03:06
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, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute 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
skipping to change at page 2, line ? skipping to change at page 2, line ?
The purpose of this document is to provide an overview of the The purpose of this document is to provide an overview of the
third version of the Internet-standard Management Framework, third version of the Internet-standard Management Framework,
termed the SNMP version 3 Framework (SNMPv3). This Framework is termed the SNMP version 3 Framework (SNMPv3). This Framework is
derived from and builds upon both the original Internet-standard 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). Management Framework (SNMPv2).
The architecture is designed to be modular to allow the evolu- The architecture is designed to be modular to allow the evolu-
tion of 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 Internet- This document is an introduction to the third version of the Internet-
standard Management Framework, termed the SNMP version 3 Management standard Management Framework, termed the SNMP version 3 Management
Framework (SNMPv3) and has multiple purposes. Framework (SNMPv3) and has multiple purposes.
First, it describes the relationship between the SNMP version 3 (SNMPv3) First, it describes the relationship between the SNMP version 3 (SNMPv3)
specifications and the specifications of the SNMP version 1 (SNMPv1) specifications and the specifications of the SNMP version 1 (SNMPv1)
Management Framework, the SNMP version 2 (SNMPv2) Management Framework, Management Framework, the SNMP version 2 (SNMPv2) Management Framework,
and the Community-based Administrative Framework for SNMPv2. and the Community-based Administrative Framework for SNMPv2.
skipping to change at page 7, line 8 skipping to change at page 6, line 8
document defines a few standardized event notifications (generic traps) document defines a few standardized event notifications (generic traps)
and provides a means for additional event notifications to be defined. and provides a means for additional event notifications to be defined.
The last document specifies a straight-forward approach towards defining The last document specifies a straight-forward approach towards defining
event notifications used with the SNMPv1 protocol. At the time that it event notifications used with the SNMPv1 protocol. At the time that it
was written, use of traps in the Internet-standard network management was written, use of traps in the Internet-standard network management
framework was controversial. As such, RFC 1215 was put forward with the framework was controversial. As such, RFC 1215 was put forward with the
status of "Informational", which was never updated because it was status of "Informational", which was never updated because it was
believed that the second version of the SNMP Framework would replace the believed that the second version of the SNMP Framework would replace the
first version. Note that the SNMPv1 data definition language is first version. Note that the SNMPv1 data definition language is
sometimes refered to as SMIv1. sometimes referred to as SMIv1.
3.2. Management Information 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 of management information definition was taken from the earlier approach of
skipping to change at page 10, line 20 skipping to change at page 9, line 20
These efforts fed the development of the SNMPv2 Management Framework as These efforts fed the development of the SNMPv2 Management Framework as
described in RFCs 1902 - 1908. However, the Framework described in described in RFCs 1902 - 1908. However, the Framework described in
those RFCs had no standards-based security and administrative framework those RFCs had no standards-based security and administrative framework
of its own; rather, it was associated with multiple security and of its own; rather, it was associated with multiple 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 lacked administration whereas both SNMPv2u and SNMPv2* had security but 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 convergence specifications for the next generation of SNMP, based upon a convergence
of the concepts and technical elements of SNMPv2u and SNMPv2*, as was of the concepts and technical elements of SNMPv2u and SNMPv2*, as was
suggested by an advisory team which was formed to provide a single suggested by an advisory team which was formed to provide a single
recommended approach for SNMP evolution. recommended approach for SNMP evolution.
skipping to change at page 11, line 22 skipping to change at page 10, line 22
addressing the missing link -- security and administration -- and in the addressing the missing link -- security and administration -- and in the
process made invaluable contributions to the state-of-the-art of process made invaluable contributions to the state-of-the-art of
management. management.
They produced a design based on a modular architecture with evolutionary They produced a design based on a modular architecture with evolutionary
capabilities with emphasis on layering. As a result, SNMPv3 can be capabilities with emphasis on layering. As a result, SNMPv3 can be
thought of as SNMPv2 with additional security and administration thought of as SNMPv2 with additional security and administration
capabilities. capabilities.
In doing so, the Working Group achieved the goal of producing a single In doing so, the Working Group achieved the goal of producing a single
specification which has both the endorsement of the IETF and security specification which has not only the endorsement of the IETF but also
and administration. has security and administration.
6. SNMPv3 Framework Module Specifications 6. SNMPv3 Framework Module Specifications
The specification of the SNMPv3 Management Framework is partitioned in a The specification of the SNMPv3 Management Framework is partitioned in a
modular fashion among several documents. It is the intention of the modular fashion among several documents. It is the intention of 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.
skipping to change at page 12, line 46 skipping to change at page 11, line 46
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 specifications. Network Management Protocol (SNMPv2)" [4], and related specifications.
The Structure of Management Information (SMI) defines fundamental data The Structure of Management Information (SMI) defines fundamental data
types, an object model, and the rules for writing and revising MIB types, an object model, and the rules for writing and revising MIB
modules. Related specifications include RFC 1903 and RFC 1904. The modules. Related specifications include RFC 1903 and RFC 1904. The
updated data definition language is sometimes refered to as SMIv2. updated data definition language is sometimes referred 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 shorthand Management Protocol (SNMPv2)" [5], defines an initial set of shorthand
abbreviations which are available for use within all MIB modules for the abbreviations which are available for use within all MIB 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 document implementations and capability statements which can be used to document
skipping to change at page 13, line 32 skipping to change at page 12, line 32
instrumentation in managed nodes, made remotely accessible by management instrumentation in managed nodes, made remotely accessible by management
agents, conveyed by the management protocol, and manipulated by agents, conveyed by the management 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, as There is a large and growing number of standards-based MIB modules, as
defined in the periodically updated list of standard protocols [STD defined in the periodically updated list of standard protocols [STD
0001, RFC 2000]. As of this writing, there are nearly 100 standards- 0001, RFC 2400]. As of this writing, there are nearly 100 standards-
based MIB modules with a total number of defined objects approaching based MIB modules with a total number of defined objects approaching
10,000. In addition, there is an even larger and growing number of 10,000. In addition, there is an even larger and growing number of
enterprise-specific MIB modules defined unilaterally by various vendors, enterprise-specific MIB modules defined unilaterally by various vendors,
research groups, consortia, and the like resulting in an unknown and research groups, consortia, and the like resulting 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, regardless In general, management information defined in any MIB module, regardless
of the version of the data definition language used, can be used with of the version of the data definition language used, can be used with
any version of the protocol. For example, MIB modules defined in terms any version of the protocol. For example, MIB modules defined in terms
of the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management of the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management
skipping to change at page 14, line 13 skipping to change at page 13, line 13
cannot be conveyed by an SNMPv1 protocol engine. cannot be conveyed by an SNMPv1 protocol engine.
6.3. Protocol Operations and Transport Mappings 6.3. Protocol Operations and Transport Mappings
The specifications for the protocol operations and transport mappings of The specifications for the protocol operations and transport mappings of
the SNMPv3 Framework are incorporated by reference to the two SNMPv2 the SNMPv3 Framework are incorporated by reference to the two 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 SNMPv3 Framework is designed to allow
various portions of the architecture to evolve independently. For
example, it might be possible for a new specification of protocol
operations to be defined within the Framework to allow for additional
protocol operations.
The specification of transport mappings is found in RFC 1906, "Transport The specification of transport mappings is found in RFC 1906, "Transport
Mappings for Version 2 of the Simple Network Management Protocol Mappings for Version 2 of the Simple Network Management 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 consists The SNMPv3 document series defined by the SNMPv3 Working Group consists
of six [seven] documents at this time: of seven documents at this time:
RFC xxxx, "Introduction to the Third Version of the Internet RFC xxxx (draft-ietf-snmpv3-intro-03.txt), "Introduction to
Standard Management Framework (SNMPv3)," which is this document. Version 3 of the Internet-standard Network Management Framework",
which is this document.
RFC 2271, "An Architecture for Describing SNMP Management RFC xxx1 (draft-ietf-snmpv3-arch-03.txt), "An Architecture for
Frameworks" [15], describes the overall architecture with special Describing SNMP Management Frameworks" [15], describes the overall
emphasis on the architecture for security and administration. architecture with special emphasis on the architecture for
security and administration.
RFC 2272, "Message Processing and Dispatching for the Simple RFC xxx2 (draft-ietf-snmpv3-mpc-03.txt), "Message Processing and
Network Management Protocol (SNMP)" [16], describes the possibly Dispatching for the Simple Network Management Protocol (SNMP)"
multiple message processing models and the dispatcher portion that [16], describes the possibly multiple message processing models
can be a part of an SNMP protocol engine. and the dispatcher portion that can be a part of an SNMP protocol
engine.
RFC 2273, "SNMPv3 Applications" [17], describes the five types of RFC xxx3 (draft-ietf-snmpv3-appl-v2-02.txt), "SNMP Applications"
applications that can be associated with an SNMPv3 engine and [17], describes the five types of applications that can be
their elements of procedure. associated with an SNMPv3 engine and their elements of procedure.
RFC 2274, "The User-Based Security Model for Version 3 of the RFC xxx4 (draft-ietf-snmpv3-usm-v2-04.txt), "The User-Based
Simple Network Management Protocol (SNMPv3)" [18], describes the Security Model for Version 3 of the Simple Network Management
threats, mechanisms, protocols, and supporting data used to Protocol (SNMPv3)" [18], describes the threats, mechanisms,
provide SNMP message-level security. protocols, and supporting data used to provide SNMP message-level
security.
RFC 2275, "View-based Access Control Model for the Simple Network RFC xxx5 (draft-ietf-snmpv3-vacm-03.txt), "View-based Access
Management Protocol (SNMP)" [19], describes how view-based access Control Model for the Simple Network Management Protocol (SNMP)"
control can be applied within command responder and notification [19], describes how view-based access control can be applied
originator applications. within command responder and notification originator applications.
RFC yyyy, "SNMPv3 Coexistence and Transition" [20], does not exist RFC yyyy (draft-ietf-snmpv3-coex-03.txt), "Coexistence between
yet and is still in development. Version 1, Version 2, and Version 3 of the Internet-standard
Network Management Framework" [20], describes coexistence between
the SNMPv3 Management Framework, the SNMPv2 Management Framework,
and the original SNMPv1 Management Framework.
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 in Information Base (MIB). Collections of related objects are defined in
MIB modules. These modules are written in the SNMP MIB module language, MIB modules. These modules are written in the SNMP MIB module language,
which contains elements of OSI's Abstract Syntax Notation One (ASN.1) which contains elements of OSI's Abstract Syntax Notation One (ASN.1)
[11] language. RFC 1902, RFC 1903, and RFC 1904 together define the MIB [11] language. RFC 1902, RFC 1903, and RFC 1904 together define the MIB
module language, specify the base data types for objects, specify a core module language, specify the base data types for objects, specify a core
set of short-hand specifications for data types called textual set of short-hand specifications for data types called textual
conventions, and specify a few administrative assignments of object conventions, and specify a few administrative 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 notification 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, INTEGER, OCTET STRING, OBJECT
IpAddress, Opaque, and BITS. It also assigns values to several object IDENTIFIER, IpAddress, Opaque, and BITS. It also assigns values to
identifiers. RFC 1902 further defines the following constructs of the several object identifiers. RFC 1902 further defines the following
MIB module language: constructs of the 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 assignment to list the columnar objects in
a table. a table.
* NOTIFICATION-TYPE construct to describe an event notification. * NOTIFICATION-TYPE construct to specify 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 short- When designing a MIB module, it is often useful to specify in a short-
hand way the semantics for a set of objects with similar behavior. This hand way the semantics for a set of objects with similar behavior. This
is done by defining a new data type using a base data type specified in is done by defining a new data type using a base data type specified in
the SMI. Each new type has a different name, and specifies a base type the SMI. Each new type has a different name, and specifies a base type
with more restrictive semantics. These newly defined types are termed with more restrictive semantics. These newly defined types are termed
textual conventions, and are used for the convenience of humans reading textual conventions, and are used for the convenience of humans reading
a MIB module and potentially by "intelligent" management applications. a MIB module and potentially by "intelligent" management applications.
skipping to change at page 19, line 7 skipping to change at page 18, line 7
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, "Architecture Document" [15], to define It is the purpose of RFC xxx1 (draft-ietf-snmpv3-arch-03.txt), "An
Architecture for Describing SNMP Management Frameworks" [15], to define
an architecture for specifying SNMP Management Frameworks. While an architecture for specifying SNMP Management Frameworks. While
addressing general architectural issues, it focuses on aspects related addressing general architectural issues, it focuses on aspects related
to security and administration. It defines a number of terms used to security and administration. It defines a number of terms used
throughout the SNMPv3 Management Framework and, in so doing, clarifies throughout the SNMPv3 Management Framework and, in so doing, 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),
skipping to change at page 19, line 29 skipping to change at page 18, line 30
* 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 xxx2 (draft-ietf-snmpv3-mpc-03.txt), "Message Processing and
Management Protocol (SNMP)" [16], describes the Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [16],
Dispatching for SNMP messages within the SNMP architecture. It defines describes the Message Processing and Dispatching for SNMP messages
the procedures for dispatching potentially multiple versions of SNMP within the SNMP architecture. It defines the procedures for dispatching
messages to the proper SNMP Message Processing Models, and for potentially multiple versions of SNMP messages to the proper SNMP
dispatching PDUs to SNMP applications. This document also describes one Message Processing Models, and for dispatching PDUs to SNMP
Message Processing Model - the SNMPv3 Message Processing Model. applications. This document also describes one Message Processing Model
- the SNMPv3 Message Processing Model.
the SNMPv3 Message Processing Model.
It is expected that an SNMPv3 protocol engine MUST support at least one It is expected that an SNMPv3 protocol engine MUST support at least one
Message Processing Model. An SNMPv3 protocol engine MAY support more Message Processing Model. An SNMPv3 protocol engine MAY support more
than one, for example in a multilingual system which provides than one, for example in a multi-lingual 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. SNMP Applications
It is the purpose of RFC 2273, "SNMPv3 Applications" to describe the It is the purpose of RFC xxx3 (draft-ietf-snmpv3-appl-v2-02.txt), "SNMP
five types of applications which can be associated with an SNMP engine. Applications" to describe the five types of applications which can be
They are: Command Generators, Command Responders, Notification
Originators, Notification Receivers, and Proxy Forwarders. associated with an SNMP engine. They are: Command Generators, Command
Responders, Notification Originators, Notification Receivers, and Proxy
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 xxx4 (draft-ietf-snmpv3-usm-v2-04.txt), the "User-based Security
Simple Network Management Protocol (SNMPv3)" describes the User-based Model (USM) for version 3 of the Simple Network Management Protocol
Security Model for SNMPv3. It defines the Elements of Procedure for (SNMPv3)" describes the User-based Security Model for SNMPv3. It
providing SNMP message-level security. defines the Elements of Procedure for providing SNMP message-level
security.
The document describes the two primary and two secondary threats which The document describes the two primary and two secondary threats which
are defended against by the User-based Security Model. They are: are defended against by the User-based Security Model. They are:
modification of information, masquerade, message stream modification, modification of information, masquerade, message stream modification,
and [optionally] disclosure. and 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 integrity hashing algorithms [23] for digest computation to provide data 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 block The USM uses the Data Encryption Standard (DES) [24] in the cipher block
chaining mode (CBC) if disclosure protection is desired. chaining mode (CBC) if disclosure protection is desired. Support for
DES in the USM is optional, primarily because export and usage
restrictions in many countries make it difficult to export and use
products which include cryptographic technology.
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.
An entity may provide simultaneous support for multiple security models An entity may provide simultaneous support for multiple security models
as well as multiple authentication and privacy protocols. All of the as well as multiple authentication and privacy protocols. All of the
protocols used by the USM are based on pre-placed keys, i.e., private protocols used by the USM are based on pre-placed keys, i.e., private
key mechanisms. The SNMPv3 architecture permits the use of asymetric key mechanisms. The SNMPv3 architecture permits the use of asymmetric
mechanisms and protocols (commonly called but as of this writing, no mechanisms and protocols (commonly called "public key cryptography") but
such SNMPv3 security models utilizing public key cryptography have been as of this writing, no such SNMPv3 security models utilizing public key
cryptography have been published.
published.
7.9. View-based Access Control (VACM) 7.9. View-based Access Control (VACM)
The purpose of RFC 2275, the "View-based Access Control Model (VACM) for The purpose of RFC xxx5 (draft-ietf-snmpv3-vacm-03.txt), the "View-based
the Simple Network Management Protocol (SNMP)" is to describe the View- Access Control Model (VACM) for the Simple Network Management Protocol
based Access Control Model for use in the SNMP architecture. The VACM (SNMP)" is to describe the View-based Access Control Model for use in
can simultaneously be associated in a single engine implementation with the SNMP architecture. The VACM can simultaneously be associated in a
multiple Message Processing Models and multiple Security Models. 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 and implementation, but this is expected to be *_very_* rare in practice and
*_far_* less common than simultaneous support for multiple Message *_far_* less common than simultaneous support for multiple 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: The purpose of RFC yyyy (draft-ietf-snmpv3-coex-03.txt), "Coexistence
background of 2 approaches to coexistence and transition between Version 1, Version 2, and Version 3 of the Internet-standard
multilingual approach Network Management Framework" is to describe coexistence between the
proxy approach SNMPv3 Management Framework, the SNMPv2 Management Framework, and the
original SNMPv1 Management Framework. In particular, this document
describes four aspects of coexistence:
mapping functions derived from rfc 2089 but incorporated by value * Conversion of MIB documents from SMIv1 to SMIv2 format
rather than by reference in order to get these functions onto the
standards track and to fix up any lingering problems
a community-based security model consistent with the architecture * Mapping of notification parameters
and containing a suitable MIB module for remote configuration thereof
for use by multilingual engines supporting snmpv1 and snmpv2c in
addition to snmpv3
This could be multiple documents, but it really isn't necessary to have more * Approaches to coexistence between entities which support
than one and fewer are better than many. the various versions of SNMP in a multi-lingual network, in
particular the processing of protocol operations in
multi-lingual implementations, as well as behaviour of
proxy implementations
* The SNMPv1 Message Processing Model and Community-Based
Security Model, which provides mechanisms for adapting
SNMPv1 and SNMPv2c into the View-Based Access Control Model
(VACM) [19]
8. Security Considerations 8. Security Considerations
As this document is primarily a roadmap document, it introduces no new As this document is primarily a roadmap document, it introduces no 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
skipping to change at page 22, line 28 skipping to change at page 22, line 28
USA USA
Phone: +1 423 573 1434 Phone: +1 423 573 1434
EMail: case@snmp.com EMail: case@snmp.com
Russ Mundy Russ Mundy
TIS Labs at Network Associates 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
Sweden Sweden
Phone: +46 13 21 18 81 Phone: +46 13 21 18 81
Email: partain@europe.snmp.com EMail: partain@europe.snmp.com
Bob Stewart Bob Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
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
skipping to change at page 25, line 8 skipping to change at page 25, line 8
Network Management of TCP/IP-based Internets", RFC 1066, Network Management of TCP/IP-based Internets", RFC 1066,
August 1988. 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., Presuhn, R., and B. Wijnen, "An Architecture
Describing SNMP Management Frameworks, RFC 2271, January, 1998. for Describing SNMP Management Frameworks",
<draft-ietf-snmpv3-arch-03.txt>, January 1999.
[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)", <draft-ietf-snmpv3-mpc-03.txt>,
January, 1999.
[17] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", [17] Levi, D., Meyer, P., and B. Stewart, "SNMP Applications",
RFC 2273, January 1998. <draft-ietf-snmpv3-appl-v2-02.txt>, January 1999.
[18] Blumenthal, U., and B. Wijnen, "The User-Based Security Model for [18] Blumenthal, U. and B. Wijnen, "The User-Based Security
Version 3 of the Simple Network Management Protocol (SNMPv3)", Model for Version 3 of the Simple Network Management Protocol
RFC 2274, January 1998. (SNMPv3)", <draft-ietf-snmpv3-usm-v2-04.txt>, January 1999.
[19] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access [19] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Control Model for the Simple Network Management Protocol (SNMP)", Access Control Model for the Simple Network Management Protocol
RFC 2275, January 1998. (SNMP)", <draft-ietf-snmpv3-vacm-03.txt>, January 1999.
[20] TBD, "SNMPv3 Coexistence and Transition", RFC yyyy, Work in [20] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence
progress, date TBD. between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework",
<draft-ietf-snmpv3-coex-03.txt>, January 1999.
[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.
skipping to change at page 26, line 7 skipping to change at page 26, line 7
[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 Table of Contents
0 Revision History: ............................................... 2 1 Introduction .................................................... 2
1 Introduction .................................................... 3 2 The Internet Standard Management Framework ...................... 3
2 The Internet Standard Management Framework ...................... 4 2.1 Basic Structure and Components ................................ 3
2.1 Basic Structure and Components ................................ 4 2.2 Architecture of the Internet Standard Management Framework .... 3
2.2 Architecture of the Internet Standard Management Framework .... 4 3 The SNMPv1 Management Framework ................................. 5
3 The SNMPv1 Management Framework ................................. 6 3.1 The SNMPv1 Data Definition Language ........................... 5
3.1 The SNMPv1 Data Definition Language ........................... 6 3.2 Management Information ........................................ 6
3.2 Management Information ........................................ 7 3.3 Protocol Operations ........................................... 6
3.3 Protocol Operations ........................................... 7 3.4 SNMPv1 Security and Administration ............................ 6
3.4 SNMPv1 Security and Administration ............................ 7 4 The SNMPv2 Management Framework ................................. 7
4 The SNMPv2 Management Framework ................................. 8 5 The SNMPv3 Working Group ........................................ 8
5 The SNMPv3 Working Group ........................................ 9 6 SNMPv3 Framework Module Specifications .......................... 11
6 SNMPv3 Framework Module Specifications .......................... 12 6.1 Data Definition Language ...................................... 11
6.1 Data Definition Language ...................................... 12 6.2 MIB Modules ................................................... 12
6.2 MIB Modules ................................................... 13 6.3 Protocol Operations and Transport Mappings .................... 13
6.3 Protocol Operations and Transport Mappings .................... 14 6.4 SNMPv3 Security and Administration ............................ 13
6.4 SNMPv3 Security and Administration ............................ 14 7 Document Summaries .............................................. 15
7 Document Summaries .............................................. 16 7.1 Structure of Management Information ........................... 15
7.1 Structure of Management Information ........................... 16 7.1.1 Base SMI Specification ...................................... 15
7.1.1 Base SMI Specification ...................................... 16 7.1.2 Textual Conventions ......................................... 16
7.1.2 Textual Conventions ......................................... 17 7.1.3 Conformance Statements ...................................... 16
7.1.3 Conformance Statements ...................................... 17 7.2 Protocol Operations ........................................... 17
7.2 Protocol Operations ........................................... 18 7.3 Transport Mappings ............................................ 17
7.3 Transport Mappings ............................................ 18 7.4 Protocol Instrumentation ...................................... 17
7.4 Protocol Instrumentation ...................................... 18 7.5 Architecture / Security and Administration .................... 18
7.5 Architecture / Security and Administration .................... 19 7.6 Message Processing and Dispatch (MPD) ......................... 18
7.6 Message Processing and Dispatch (MPD) ......................... 19 7.7 SNMP Applications ............................................. 18
7.7 SNMPv3 Applications ........................................... 19 7.8 User-based Security Model (USM) ............................... 19
7.8 User-based Security Model (USM) ............................... 20 7.9 View-based Access Control (VACM) .............................. 20
7.9 View-based Access Control (VACM) .............................. 21 7.10 SNMPv3 Coexistence and Transition ............................ 20
7.10 SNMPv3 Coexistence and Transition ............................ 21
8 Security Considerations ......................................... 22 8 Security Considerations ......................................... 22
9 Editors' Addresses .............................................. 22 9 Editors' Addresses .............................................. 22
10 Full Copyright Statement ....................................... 23 10 Full Copyright Statement ....................................... 23
11 References ..................................................... 23 11 References ..................................................... 23
 End of changes. 47 change blocks. 
169 lines changed or deleted 159 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/