diff options
Diffstat (limited to 'doc/rfc/rfc2570.txt')
| -rw-r--r-- | doc/rfc/rfc2570.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc2570.txt b/doc/rfc/rfc2570.txt new file mode 100644 index 0000000..b34f3bc --- /dev/null +++ b/doc/rfc/rfc2570.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group J. Case +Request for Comments: 2570 SNMP Research, Inc. +Category: Informational R. Mundy + TIS Labs at Network Associates, Inc. + D. Partain + Ericsson + B. Stewart + Cisco Systems + April 1999 + + Introduction to Version 3 of the + Internet-standard Network Management Framework + + + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + The purpose of this document is to provide an overview of the third + version of the Internet-standard Management Framework, termed the + SNMP version 3 Framework (SNMPv3). This Framework is derived from + and builds upon both the original Internet-standard Management + Framework (SNMPv1) and the second Internet-standard Management + Framework (SNMPv2). + + The architecture is designed to be modular to allow the evolution of + the Framework over time. + +Table of Contents + + 1 Introduction .....................................................2 + 2 The Internet Standard Management Framework .......................3 + 2.1 Basic Structure and Components .................................3 + 2.2 Architecture of the Internet Standard Management Framework .....3 + 3 The SNMPv1 Management Framework ..................................4 + 3.1 The SNMPv1 Data Definition Language ............................5 + 3.2 Management Information .........................................6 + 3.3 Protocol Operations ............................................6 + 3.4 SNMPv1 Security and Administration .............................6 + + + +Case, et al. Informational [Page 1] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + 4 The SNMPv2 Management Framework ..................................7 + 5 The SNMPv3 Working Group .........................................8 + 6 SNMPv3 Framework Module Specifications ..........................10 + 6.1 Data Definition Language ......................................10 + 6.2 MIB Modules ...................................................11 + 6.3 Protocol Operations and Transport Mappings ....................12 + 6.4 SNMPv3 Security and Administration ............................12 + 7 Document Summaries ..............................................13 + 7.1 Structure of Management Information ...........................13 + 7.1.1 Base SMI Specification ......................................13 + 7.1.2 Textual Conventions .........................................14 + 7.1.3 Conformance Statements ......................................15 + 7.2 Protocol Operations ...........................................15 + 7.3 Transport Mappings ............................................15 + 7.4 Protocol Instrumentation ......................................16 + 7.5 Architecture / Security and Administration ....................16 + 7.6 Message Processing and Dispatch (MPD) .........................16 + 7.7 SNMP Applications .............................................17 + 7.8 User-based Security Model (USM) ...............................17 + 7.9 View-based Access Control (VACM) ..............................18 + 7.10 SNMPv3 Coexistence and Transition ............................18 + 8 Security Considerations .........................................19 + 9 Editors' Addresses ..............................................19 + 10 References .....................................................20 + 11 Full Copyright Statement .......................................23 + +1 Introduction + + This document is an introduction to the third version of the + Internet-standard Management Framework, termed the SNMP version 3 + Management Framework (SNMPv3) and has multiple purposes. + + First, it describes the relationship between the SNMP version 3 + (SNMPv3) specifications and the specifications of the SNMP version 1 + (SNMPv1) Management Framework, the SNMP version 2 (SNMPv2) Management + Framework, and the Community-based Administrative Framework for + SNMPv2. + + Second, it provides a roadmap to the multiple documents which contain + the relevant specifications. + + Third, this document provides a brief easy-to-read summary of the + contents of each of the relevant specification documents. + + This document is intentionally tutorial in nature and, as such, may + occasionally be "guilty" of oversimplification. In the event of a + conflict or contradiction between this document and the more detailed + documents for which this document is a roadmap, the specifications in + + + +Case, et al. Informational [Page 2] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + the more detailed documents shall prevail. + + Further, the detailed documents attempt to maintain separation + between the various component modules in order to specify well- + defined interfaces between them. This roadmap document, however, + takes a different approach and attempts to provide an integrated view + of the various component modules in the interest of readability. + +2 The Internet Standard Management Framework + + The third version of the Internet Standard Management Framework (the + SNMPv3 Framework) is derived from and builds upon both the original + Internet-standard Management Framework (SNMPv1) and the second + Internet-standard Management Framework (SNMPv2). + + All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard + Management Framework share the same basic structure and components. + Furthermore, all versions of the specifications of the Internet + Standard Management Framework follow the same architecture. + +2.1 Basic Structure and Components + + An enterprise deploying the Internet Standard Management Framework + contains four basic components: + + * several (typically many) managed nodes, each with an SNMP entity + which provides remote access to management instrumentation + (traditionally called an agent); + + * at least one SNMP entity with management applications (typically + called a manager), + + * a management protocol used to convey management information + between the SNMP entities, and + + * management information. + + The management protocol is used to convey management information + between SNMP entities such as managers and agents. + + This basic structure is common to all versions of the Internet + Standard Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3. + +2.2 Architecture of the Internet Standard Management Framework + + The specifications of the Internet Standard Management Framework are + based on a modular architecture. This framework is more than just a + protocol for moving data. It consists of: + + + +Case, et al. Informational [Page 3] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + * a data definition language, + + * definitions of management information (the Management + Information Base, or MIB), + + * a protocol definition, and + + * security and administration. + + Over time, as the Framework has evolved from SNMPv1, through SNMPv2, + to SNMPv3, the definitions of each of these architectural components + have become richer and more clearly defined, but the fundamental + architecture has remained consistent. + + One prime motivator for this modularity was to enable the ongoing + evolution of the Framework as is documented in RFC 1052 [14]. When + originally envisioned, this capability was to be used to ease the + transition from SNMP-based management of internets to management + based on OSI protocols. To this end, the framework was architected + with a protocol-independent data definition language and Management + Information Base along with a MIB-independent protocol. This + separation was designed to allow the SNMP-based protocol to be + replaced without requiring the management information to be redefined + or reinstrumented. History has shown that the selection of this + architecture was the right decision for the wrong reason -- it turned + out that this architecture has eased the transition from SNMPv1 to + SNMPv2 and from SNMPv2 to SNMPv3 rather than easing the transition + away from management based on the Simple Network Management Protocol. + + The SNMPv3 Framework builds and extends these architectural + principles by: + + * building on these four basic architectural components, in some + cases incorporating them from the SNMPv2 Framework by reference, + and + + * by using these same layering principles in the definition of new + capabilities in the security and administration portion of the + architecture. + + Those who are familiar with the architecture of the SNMPv1 Management + Framework and the SNMPv2 Management Framework will find many familiar + concepts in the architecture of the SNMPv3 Management Framework. + However, in some cases, the terminology may be somewhat different. + + + + + + + +Case, et al. Informational [Page 4] + +RFC 2570 Introduction to SNMPv3 April 1999 + + +3 The SNMPv1 Management Framework + + The original Internet-standard Network Management Framework (SNMPv1) + is defined in the following documents: + + * STD 16, RFC 1155 [1] which defines the Structure of Management + Information (SMI), the mechanisms used for describing and naming + objects for the purpose of management. + + * STD 16, RFC 1212 [2] which defines a more concise description + mechanism for describing and naming management information objects, + but which is wholly consistent with the SMI. + + * STD 15, RFC 1157 [3] which defines the Simple Network Management + Protocol (SNMP), the protocol used for network access to managed + objects and event notification. Note this document also defines an + initial set of event notifications. + + Additionally, two documents are generally considered to be companions + to these three: + + * STD 17, RFC 1213 [13] which contains definitions for the base + set of management information + + * RFC 1215 [25] defines a concise description mechanism for + defining event notifications, which are called traps in the SNMPv1 + protocol. It also specifies the generic traps from RFC 1157 in the + concise notation. + + These documents describe the four parts of the first version of the + SNMP Framework. + +3.1 The SNMPv1 Data Definition Language + + The first two and the last document describe the SNMPv1 data + definition language. Note that due to the initial requirement that + the SMI be protocol-independent, the first two SMI documents do not + provide a means for defining event notifications (traps). Instead, + the SNMP protocol document defines a few standardized event + notifications (generic traps) and provides a means for additional + event notifications to be defined. The last document specifies a + straight-forward approach towards defining event notifications used + with the SNMPv1 protocol. At the time that it was written, use of + traps in the Internet-standard network management framework was + 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 + + + +Case, et al. Informational [Page 5] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + referred to as SMIv1. + +3.2 Management Information + + 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 + [12], and was subsequently used to define MIB-II as specified in RFC + 1213 [13]. + + Later, after the publication of MIB-II, a different approach to + management information definition was taken from the earlier approach + of having a single committee staffed by generalists work on a single + document to define the Internet-standard MIB. Rather, many mini-MIB + documents were produced in a parallel and distributed fashion by + groups chartered to produce a specification for a focused portion of + the Internet-standard MIB and staffed by personnel with expertise in + those particular areas ranging from various aspects of network + management, to system management, and application management. + +3.3 Protocol Operations + + The third document, STD 15, describes the SNMPv1 protocol operations + performed by protocol data units (PDUs) on lists of variable bindings + and describes the format of SNMPv1 messages. The operators defined by + SNMPv1 are: get, get-next, get-response, set-request, and trap. + Typical layering of SNMP on a connectionless transport service is + also defined. + +3.4 SNMPv1 Security and Administration + + STD 15 also describes an approach to security and administration. + Many 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 + SNMP messages between SNMP entities and distinguishes between + application entities and protocol entities. In SNMPv3, these are + renamed applications and engines, respectively. + + The SNMPv1 Framework also introduces the concept of an authentication + service supporting one or more authentication schemes. In addition + to authentication, SNMPv3 defines the additional security capability + 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. + + + + +Case, et al. Informational [Page 6] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + Finally, the SNMPv1 Framework introduces access control based on a + concept called an SNMP MIB view. The SNMPv3 Framework specifies a + 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 + multiple authentication schemes, it did not define any such schemes + other than a trivial authentication scheme based on community + strings. This was a known fundamental weakness in the SNMPv1 + Framework but it was thought at that time that the definition of + commercial grade security might be contentious in its design and + difficult to get approved because "security" means many different + things to different people. To that end, and because some users do + not require strong authentication, the SNMPv1 architected an + authentication service as a separate block to be defined "later" and + the SNMPv3 Framework provides an architecture for use within that + block as well as a definition for its subsystems. + +4 The SNMPv2 Management Framework + + The SNMPv2 Management Framework is fully described in [4-9] and + coexistence and transition issues relating to SNMPv1 and SNMPv2 are + discussed in [10]. + + SNMPv2 provides several advantages over SNMPv1, including: + + * expanded data types (e.g., 64 bit counter) + + * improved efficiency and performance (get-bulk operator) + + * confirmed event notification (inform operator) + + * richer error handling (errors and exceptions) + + * improved sets, especially row creation and deletion + + * fine tuning of the data definition language + + However, the SNMPv2 Framework, as described in these documents, is + incomplete in that it does not meet the original design goals of the + SNMPv2 project. The unmet goals included provision of security and + administration delivering so-called "commercial grade" security with + + * authentication: origin identification, message integrity, + and some aspects of replay protection; + + * privacy: confidentiality; + + + +Case, et al. Informational [Page 7] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + * authorization and access control; and + + * suitable remote configuration and administration capabilities + for these features. + + The SNMPv3 Management Framework, as described in this document and + the companion documents, addresses these significant deficiencies. + +5 The SNMPv3 Working Group + + This document, and its companion documents, were produced by the + SNMPv3 Working Group of the Internet Engineering Task Force (IETF). + The SNMPv3 Working Group was chartered to prepare recommendations for + the next generation of SNMP. The goal of the Working Group was to + produce the necessary set of documents that provide a single standard + for the next generation of core SNMP functions. The single, most + critical need in the next generation is a definition of security and + administration that makes SNMP-based management transactions secure + in a way which is useful for users who wish to use SNMPv3 to manage + networks, the systems that make up those networks, and the + applications which reside on those systems, including manager-to- + agent, agent-to-manager, and manager-to-manager transactions. + + In the several years prior to the chartering of the Working Group, + there were a number of activities aimed at incorporating security and + other improvements to SNMP. These efforts included: + + * "SNMP Security" circa 1991-1992 [RFC 1351 - RFC 1353], + + * "SMP" circa 1992-1993, + + * "The Party-based SNMPv2" circa 1993-1995 [RFC 1441 - RFC 1452]. + + Each of these efforts incorporated commercial grade, industrial + strength security including authentication, privacy, authorization, + view-based access control, and administration, including remote + configuration. + + These efforts fed the development of the SNMPv2 Management Framework + as described in RFCs 1902 - 1908. However, the Framework described + in those RFCs had no standards-based security and administrative + framework of its own; rather, it was associated with multiple + security and administrative frameworks, including: + + * "The Community-based SNMPv2" (SNMPv2c) [RFC 1901], + + * "SNMPv2u" [RFCs 1909 - 1910] and + + + + +Case, et al. Informational [Page 8] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + * "SNMPv2*". + + SNMPv2c had the endorsement of the IETF but no security and + administration whereas both SNMPv2u and SNMPv2* had security but + lacked the endorsement of the IETF. + + The SNMPv3 Working Group was chartered to produce a single set of + specifications for the next generation of SNMP, based upon a + convergence of the concepts and technical elements of SNMPv2u and + SNMPv2*, as was suggested by an advisory team which was formed to + provide a single recommended approach for SNMP evolution. + + In so doing, the Working Group charter defined the following + objectives: + + * accommodate the wide range of operational environments with + differing management demands; + + * facilitate the need to transition from previous, multiple + protocols to SNMPv3; + + * facilitate the ease of setup and maintenance activities. + + In the initial work of the SNMPv3 Working Group, the group focused on + security and administration, including + + * authentication and privacy, + + * authorization and view-based access control, and + + * standards-based remote configuration of the above. + + The SNMPv3 Working Group did not "reinvent the wheel," but reused the + SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for + those portions of the design that were outside the focused scope. + + Rather, the primary contributors to the SNMPv3 Working Group, and the + Working Group in general, devoted their considerable efforts to + addressing the missing link -- security and administration -- and in + the process made invaluable contributions to the state-of-the-art of + management. + + They produced a design based on a modular architecture with + evolutionary capabilities with emphasis on layering. As a result, + SNMPv3 can be thought of as SNMPv2 with additional security and + administration capabilities. + + + + + +Case, et al. Informational [Page 9] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + In doing so, the Working Group achieved the goal of producing a + single specification which has not only the endorsement of the IETF + but also has security and administration. + +6 SNMPv3 Framework Module Specifications + + The specification of the SNMPv3 Management Framework is partitioned + in a modular fashion among several documents. It is the intention of + the SNMPv3 Working Group that, with proper care, any or all of the + individual documents can be revised, upgraded, or replaced as + requirements change, new understandings are obtained, and new + technologies become available. + + Whenever feasible, the initial document set which defines the SNMPv3 + Management Framework leverages prior investments defining and + implementing the SNMPv2 Management Framework by incorporating by + reference each of the specifications of the SNMPv2 Management + Framework. + + The SNMPv3 Framework augments those specifications with + specifications for security and administration for SNMPv3. + + The documents which specify the SNMPv3 Management Framework follow + the same architecture as those of the prior versions and can be + organized for expository purposes into four main categories as + follows: + + * the data definition language, + + * Management Information Base (MIB) modules, + + * protocol operations, and + + * security and administration. + + The first three sets of documents are incorporated from SNMPv2. The + fourth set of documents are new to SNMPv3, but, as described + previously, build on significant prior related works. + +6.1 Data Definition Language + + The specifications of the data definition language includes STD 58, + RFC 2578, "Structure of Management Information Version 2 (SMIv2)" + [26], and related specifications. These documents are updates of + RFCs 1902 - 1904 [4-6] which have evolved independently from the + other parts of the framework and were republished as STD 58, RFCs + 2578 - 2580 [26-28] when promoted from Draft Standard. + + + + +Case, et al. Informational [Page 10] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + The Structure of Management Information (SMIv2) defines fundamental + data types, an object model, and the rules for writing and revising + MIB modules. Related specifications include STD 58, RFCs 2579, 2580. + The updated data definition language is sometimes referred to as + SMIv2. + + STD 58, RFC 2579, "Textual Conventions for SMIv2" [27], defines an + initial set of shorthand abbreviations which are available for use + within all MIB modules for the convenience of human readers and + writers. + + STD 58, RFC 2580, "Conformance Statements for SMIv2" [28], defines + the format for compliance statements which are used for describing + requirements for agent implementations and capability statements + which can be used to document the characteristics of particular + implementations. + +6.2 MIB Modules + + MIB modules usually contain object definitions, may contain + definitions of event notifications, and sometimes include compliance + statements specified in terms of appropriate object and event + notification groups. As such, MIB modules define the management + information maintained by the instrumentation in managed nodes, made + remotely accessible by management agents, conveyed by the management + protocol, and manipulated by management applications. + + MIB modules are defined according the rules defined in the documents + which specify the data definition language, principally the SMI as + supplemented by the related specifications. + + There is a large and growing number of standards-based MIB modules, + as defined in the periodically updated list of standard protocols + [STD 1, RFC 2400]. As of this writing, there are nearly 100 + standards-based MIB modules with a total number of defined objects + approaching 10,000. In addition, there is an even larger and growing + number of enterprise-specific MIB modules defined unilaterally by + various vendors, research groups, consortia, and the like resulting + in an unknown and virtually uncountable number of defined objects. + + In general, management information defined in any MIB module, + regardless 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 of the SNMPv1 SMI (SMIv1) are compatible with the + SNMPv3 Management Framework and can be conveyed by the protocols + specified therein. Furthermore, MIB modules defined in terms of the + SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and + can be conveyed by it. However, there is one noteworthy exception: + + + +Case, et al. Informational [Page 11] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + the Counter64 datatype which can be defined in a MIB module defined + in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol + engine. + +6.3 Protocol Operations and Transport Mappings + + The specifications for the protocol operations and transport mappings + of the SNMPv3 Framework are incorporated by reference to the two + SNMPv2 Framework documents. + + The specification for protocol operations is found in RFC 1905, + "Protocol Operations for Version 2 of the Simple Network Management + 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 Mappings for Version 2 of the Simple Network Management + Protocol (SNMPv2)" [8]. + +6.4 SNMPv3 Security and Administration + + The SNMPv3 document series defined by the SNMPv3 Working Group + consists of seven documents at this time: + + RFC 2570, "Introduction to Version 3 of the Internet-standard + Network Management Framework", which is this document. + + RFC 2571, "An Architecture for Describing SNMP Management + Frameworks" [15], describes the overall architecture with special + emphasis on the architecture for security and administration. + + RFC 2572, "Message Processing and Dispatching for the Simple + Network Management Protocol (SNMP)" [16], describes the possibly + multiple message processing models and the dispatcher portion that + can be a part of an SNMP protocol engine. + + RFC 2573, "SNMP Applications" [17], describes the five types of + applications that can be associated with an SNMPv3 engine and + their elements of procedure. + + RFC 2574, "The User-Based Security Model for Version 3 of the + Simple Network Management Protocol (SNMPv3)" [18], describes the + threats, mechanisms, protocols, and supporting data used to + provide SNMP message-level security. + + + + +Case, et al. Informational [Page 12] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + RFC 2575, "View-based Access Control Model for the Simple Network + Management Protocol (SNMP)" [19], describes how view-based access + control can be applied within command responder and notification + originator applications. + + The Work in Progress, "Coexistence between 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 + + The following sections provide brief summaries of each document with + slightly more detail than is provided in the overviews above. + +7.1 Structure of Management Information + + Management information is viewed as a collection of managed objects, + residing in a virtual information store, termed the Management + Information Base (MIB). Collections of related objects are defined + in MIB modules. These modules are written in the SNMP MIB module + language, which contains elements of OSI's Abstract Syntax Notation + One (ASN.1) [11] language. STD 58, RFCs 2578, 2579, 2580, together + define the MIB module language, specify the base data types for + objects, specify a core set of short-hand specifications for data + types called textual conventions, and specify a few administrative + assignments of object identifier (OID) values. + + The SMI is divided into three parts: module definitions, object + definitions, and notification definitions. + + (1) Module definitions are used when describing information modules. + An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the + semantics of an information module. + + (2) Object definitions are used when describing managed objects. An + ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax + and semantics of a managed object. + + (3) Notification definitions are used when describing unsolicited + transmissions of management information. An ASN.1 macro, + NOTIFICATION-TYPE, is used to convey concisely the syntax and + semantics of a notification. + + + + + + + +Case, et al. Informational [Page 13] + +RFC 2570 Introduction to SNMPv3 April 1999 + + +7.1.1 Base SMI Specification + + STD 58, RFC 2578 specifies the base data types for the MIB module + language, which include: Integer32, enumerated integers, Unsigned32, + Gauge32, Counter32, Counter64, TimeTicks, INTEGER, OCTET STRING, + OBJECT IDENTIFIER, IpAddress, Opaque, and BITS. It also assigns + values to several object identifiers. STD 58, RFC 2578 further + defines the following constructs of the MIB module language: + + * IMPORTS to allow the specification of items that are used + in a MIB module, but defined in another MIB module. + + * MODULE-IDENTITY to specify for a MIB module a description + and administrative information such as contact and revision + history. + + * OBJECT-IDENTITY and OID value assignments to specify a + an OID value. + + * OBJECT-TYPE to specify the data type, status, and the semantics + of managed objects. + + * SEQUENCE type assignment to list the columnar objects in + a table. + + * NOTIFICATION-TYPE construct to specify an event notification. + +7.1.2 Textual Conventions + + 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 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 with more restrictive semantics. These newly + defined types are termed textual conventions, and are used for the + convenience of humans reading a MIB module and potentially by + "intelligent" management applications. It is the purpose of STD 58, + RFC 2579, Textual Conventions for SMIv2 [27], to define the + construct, TEXTUAL-CONVENTION, of the MIB module language used to + define such new types and to specify an initial set of textual + conventions available to all MIB modules. + + + + + + + + + + +Case, et al. Informational [Page 14] + +RFC 2570 Introduction to SNMPv3 April 1999 + + +7.1.3 Conformance Statements + + It may be useful to define the acceptable lower-bounds of + implementation, along with the actual level of implementation + achieved. It is the purpose of STD 58, RFC 2580, Conformance + Statements for SMIv2 [28], to define the constructs of the MIB module + language used for these purposes. There are two kinds of constructs: + + (1) Compliance statements are used when describing requirements for + agents with respect to object and event notification + definitions. The MODULE-COMPLIANCE construct is used to convey + concisely such requirements. + + (2) Capability statements are used when describing capabilities of + agents with respect to object and event notification + definitions. The AGENT-CAPABILITIES construct is used to convey + concisely such capabilities. + + Finally, collections of related objects and collections of related + event notifications are grouped together to form a unit of + conformance. The OBJECT-GROUP construct is used to convey concisely + the objects in and the semantics of an object group. The + NOTIFICATION-GROUP construct is used to convey concisely the event + notifications in and the semantics of an event notification group. + +7.2 Protocol Operations + + The management protocol provides for the exchange of messages which + convey management information between the agents and the management + stations. The form of these messages is a message "wrapper" which + encapsulates a Protocol Data Unit (PDU). + + 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 + receiving of the PDUs. + +7.3 Transport Mappings + + SNMP Messages may be used over a variety of protocol suites. It is + the purpose of RFC 1906, Transport Mappings for SNMPv2 [8], to define + how SNMP messages maps onto an initial set of transport domains. + Other mappings may be defined in the future. + + Although several mappings are defined, the mapping onto UDP is the + preferred mapping. As such, to provide for the greatest level of + interoperability, systems which choose to deploy other mappings + should also provide for proxy service to the UDP mapping. + + + + +Case, et al. Informational [Page 15] + +RFC 2570 Introduction to SNMPv3 April 1999 + + +7.4 Protocol Instrumentation + + It is the purpose of RFC 1907, the Management Information Base for + SNMPv2 document [9] to define managed objects which describe the + behavior of an SNMPv2 entity. + +7.5 Architecture / Security and Administration + + It is the purpose of RFC 2571, "An Architecture for Describing SNMP + Management Frameworks" [15], to define an architecture for specifying + SNMP Management Frameworks. While addressing general architectural + issues, it focuses on aspects related to security and administration. + It defines a number of terms used throughout the SNMPv3 Management + Framework and, in so doing, clarifies and extends the naming of + + * engines and applications, + + * entities (service providers such as the engines in agents + and managers), + + * identities (service users), and + + * management information, including support for multiple + logical contexts. + + The document contains a small MIB module which is implemented by all + authoritative SNMPv3 protocol engines. + +7.6 Message Processing and Dispatch (MPD) + + RFC 2572, "Message Processing and Dispatching for the Simple Network + Management Protocol (SNMP)" [16], describes the Message Processing + and Dispatching for SNMP messages within the SNMP architecture. It + defines the procedures for dispatching potentially multiple versions + of SNMP messages to the proper SNMP Message Processing Models, and + for dispatching PDUs to SNMP applications. This document also + describes one Message Processing Model - the SNMPv3 Message + Processing Model. + + It is expected that an SNMPv3 protocol engine MUST support at least + one Message Processing Model. An SNMPv3 protocol engine MAY support + more than one, for example in a multi-lingual system which provides + simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c. + + + + + + + + +Case, et al. Informational [Page 16] + +RFC 2570 Introduction to SNMPv3 April 1999 + + +7.7 SNMP Applications + + It is the purpose of RFC 2573, "SNMP Applications" to describe the + five types of applications which can be 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 + management operations (including notifications), for notification + filtering, and for proxy forwarding. + +7.8 User-based Security Model (USM) + + RFC 2574, the "User-based Security Model (USM) for version 3 of the + Simple Network Management Protocol (SNMPv3)" describes the User-based + Security Model for SNMPv3. It defines the Elements of Procedure for + providing SNMP message-level security. + + The document describes the two primary and two secondary threats + which are defended against by the User-based Security Model. They + are: modification of information, masquerade, message stream + modification, and disclosure. + + The USM utilizes MD5 [21] and the Secure Hash Algorithm [22] as keyed + hashing algorithms [23] for digest computation to provide data + integrity + + * to directly protect against data modification attacks, + + * to indirectly provide data origin authentication, and + + * to defend against masquerade attacks. + + The USM uses loosely synchronized monotonically increasing time + indicators to defend against certain message stream modification + attacks. Automatic clock synchronization mechanisms based on the + protocol are specified without dependence on third-party time sources + and concomitant security considerations. + + The USM uses the Data Encryption Standard (DES) [24] in the cipher + block 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. + + + + + + +Case, et al. Informational [Page 17] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + The document also includes a MIB suitable for remotely monitoring and + managing the configuration parameters for the USM, including key + distribution and key management. + + An entity may provide simultaneous support for multiple security + models 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 key mechanisms. The SNMPv3 architecture permits the use of + asymmetric mechanisms and protocols (commonly called "public key + cryptography") but as of this writing, no such SNMPv3 security models + utilizing public key cryptography have been published. + +7.9 View-based Access Control (VACM) + + The purpose of RFC 2575, the "View-based Access Control Model (VACM) + for the Simple Network Management Protocol (SNMP)" is to describe the + View-based Access Control Model for use in the SNMP architecture. + The VACM 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 + Control Models active and present simultaneously in a single engine + implementation, but this is expected to be *_very_* rare in practice + and *_far_* less common than simultaneous support for multiple + Message Processing Models and/or multiple Security Models. + +7.10 SNMPv3 Coexistence and Transition + + The purpose of "Coexistence between Version 1, Version 2, and Version + 3 of the Internet-standard Network Management Framework" is to + describe coexistence between the SNMPv3 Management Framework, the + SNMPv2 Management Framework, and the original SNMPv1 Management + Framework. In particular, this document describes four aspects of + coexistence: + + * Conversion of MIB documents from SMIv1 to SMIv2 format + + * Mapping of notification parameters + + * Approaches to coexistence between entities which support + the various versions of SNMP in a multi-lingual network, in + particular the processing of protocol operations in + multi-lingual implementations, as well as behavior of + proxy implementations + + + + + + +Case, et al. Informational [Page 18] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + * 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 + + As this document is primarily a roadmap document, it introduces no + new security considerations. The reader is referred to the relevant + sections of each of the referenced documents for information about + security considerations. + +9 Editors' Addresses + + Jeffrey Case + SNMP Research, Inc. + 3001 Kimberlin Heights Road + Knoxville, TN 37920-9716 + USA + Phone: +1 423 573 1434 + EMail: case@snmp.com + + Russ Mundy + TIS Labs at Network Associates + 3060 Washington Rd + Glenwood, MD 21738 + USA + Phone: +1 301 854 6889 + EMail: mundy@tislabs.com + + David Partain + Ericsson Radio Systems + Research and Innovation + P.O. Box 1248 + SE-581 12 Linkoping + Sweden + Phone: +46 13 28 41 44 + EMail: David.Partain@ericsson.com + + Bob Stewart + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + U.S.A. + Phone: +1 603 654 6923 + EMail: bstewart@cisco.com + + + + + +Case, et al. Informational [Page 19] + +RFC 2570 Introduction to SNMPv3 April 1999 + + +10 References + + [1] Rose, M. and K. McCloghrie, "Structure and Identification of + Management Information for TCP/IP-based internets", STD 16, RFC + 1155, May 1990. + + [2] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, + RFC 1212, March 1991. + + [3] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple + Network Management Protocol", STD 15, RFC 1157, May 1990. + + [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. + Waldbusser, "Structure of Management Information for Version 2 + of the Simple Network Management Protocol (SNMPv2)", RFC 1902, + January 1996. + + [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. + Waldbusser, "Textual Conventions for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + + [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. + Waldbusser, "Conformance Statements for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1904, January 1996. + + [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. + Waldbusser, "Protocol Operations for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1905, January 1996. + + [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. + Waldbusser, "Transport Mappings for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1906, January 1996. + + [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. + Waldbusser, "Management Information Base for Version 2 of the + Simple Network Management Protocol (SNMPv2)", RFC 1907, January + 1996. + + [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. + Waldbusser, "Coexistence between Version 1 and Version 2 of the + Internet-standard Network Management Framework", RFC 1908, + January 1996. + + [11] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization. International + Standard 8824, (December, 1987). + + + + +Case, et al. Informational [Page 20] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + [12] McCloghrie, K. and M. Rose, "Management Information Base for + Network Management of TCP/IP-based Internets", RFC 1066, August + 1988. + + [13] McCloghrie, K. and M. Rose, "Management Information Base for + Network Management of TCP/IP-based internets: MIB-II, STD 17, + RFC 1213, March 1991. + + [14] Cerf, V., "IAB Recommendations for the Development of Internet + Network Management Standards", RFC 1052, April 1988. + + [15] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for + Describing SNMP Management Frameworks", RFC 2571, April 1999. + + [16] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message + Processing and Dispatching for the Simple Network Management + Protocol (SNMP)", RFC 2572, April 1999. + + [17] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC + 2573, April 1999. + + [18] Blumenthal, U. and B. Wijnen, "The User-Based Security Model for + Version 3 of the Simple Network Management Protocol (SNMPv3)", + RFC 2574, April 1999. + + [19] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access + Control Model for the Simple Network Management Protocol + (SNMP)", RFC 2575, April 1999. + + [20] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence + between Version 1, Version 2, and Version 3 of the Internet- + standard Network Management Framework", Work in Progress. + + [21] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April + 1992. + + [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.ps (Postscript) + + [23] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing + for Message Authentication", RFC 2104, February 1997. + + [24] Data Encryption Standard, National Institute of Standards and + Technology. Federal Information Processing Standard (FIPS) + Publication 46-1. Supersedes FIPS Publication 46, (January, + 1977; reaffirmed January, 1988). + + + + +Case, et al. Informational [Page 21] + +RFC 2570 Introduction to SNMPv3 April 1999 + + + [25] Rose, M., "A Convention for Defining Traps for use with the + SNMP", RFC 1215, March 1991. + + [26] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [27] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, + RFC 2579, April 1999. + + [28] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Conformance Statements for SMIv2", STD + 58, RFC 2580, April 1999. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Case, et al. Informational [Page 22] + +RFC 2570 Introduction to SNMPv3 April 1999 + + +11 Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +Acknowledgement + + Funding for the RFC Editor function is currently provided by + the Internet Society. + + + + + + + + + + + + + + + + + + + +Case, et al. Informational [Page 23] + |