RFC 3410

Introduction and Applicability Statements for Internet-Standard Management Framework

📅 published December 2002, from ietf

RFC 3410: Introduction and Applicability Statements for Internet Standard Management Framework 🎀

okay bestie, here's the title block tea ☕

Category: Informational 💅 Date: December 2002 📅 Obsoletes: RFC 2570 🙅‍♀️ Updates: none listed 🌸

Authors: J. Case (SNMP Research, Inc.), R. Mundy (Network Associates Laboratories), D. Partain (Ericsson), and B. Stewart (Retired) 🫶

Status of this Memo ✨

this one is giving "FYI, not a rulebook" energy 🧚. It provides information for the Internet community, it does not specify an Internet-standard of any kind, and distribution is unlimited. no cap, you can share it with everyone 💖

the legal bit, verbatim: Copyright (C) The Internet Society (2002). All Rights Reserved. 🙈

Abstract 🌈

so this doc is all about the third version of the Internet-Standard Management Framework, which people call the SNMP version 3 Framework (SNMPv3) 👑. It's built on top of the original Framework (SNMPv1) and the second one (SNMPv2), so it's literally a glow-up of both 💅.

the architecture is modular, which is iconic because it means the Framework can keep evolving over time 🦋

the doc also explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended 🔥. It further recommends that RFCs 1157, 1441, 1901, 1909 and 1910 get retired by moving them to Historic status 🪦, and this document obsoletes RFC 2570 💜.

Table of Contents 📚

   1 Introduction .................................................    2
   2 The Internet Standard Management Framework ...................    3
   2.1 Basic Structure and Components .............................    4
   2.2 Architecture of the Internet Standard Management Framework .    4
   3 The SNMPv1 Management Framework ..............................    5
   3.1 The SNMPv1 Data Definition Language ........................    6
   3.2 Management Information .....................................    6
   3.3 Protocol Operations ........................................    7
   3.4 SNMPv1 Security and Administration .........................    7
   4 The SNMPv2 Management Framework ..............................    8
   5 The SNMPv3 Working Group .....................................    8
   6 SNMPv3 Framework Module Specifications .......................   10
   6.1 Data Definition Language ...................................   11
   6.2 MIB Modules ................................................   12
   6.3 Protocol Operations and Transport Mappings .................   13
   6.4 SNMPv3 Security and Administration .........................   13
   7 Document Summaries ...........................................   14
   7.1 Structure of Management Information ........................   14
   7.1.1 Base SMI Specification ...................................   15
   7.1.2 Textual Conventions ......................................   15
   7.1.3 Conformance Statements ...................................   16
   7.2 Protocol Operations ........................................   16
   7.3 Transport Mappings .........................................   16
   7.4 Protocol Instrumentation ...................................   17
   7.5 Architecture / Security and Administration .................   17
   7.6 Message Processing and Dispatch (MPD) ......................   17
   7.7 SNMP Applications ..........................................   18
   7.8 User-based Security Model (USM) ............................   18
   7.9 View-based Access Control (VACM) ...........................   19
   7.10 SNMPv3 Coexistence and Transition .........................   19
   8 Standardization Status .......................................   20
   8.1 SMIv1 Status ...............................................   20
   8.2 SNMPv1 and SNMPv2 Standardization Status ...................   21
   8.3 Working Group Recommendation ...............................   22
   9 Security Considerations ......................................   22
   10 References ..................................................   22
   11 Editor's Addresses ..........................................   26
   12 Full Copyright Statement ....................................   27

1. Introduction ✨

okay so this doc is the intro to the third version of the Internet-Standard Management Framework, aka SNMPv3 🎀, and it has three main jobs 💅

First, it explains how SNMPv3 specs relate to the SNMPv1 Management Framework, the SNMPv2 Management Framework, and the Community-based Administrative Framework for SNMPv2 🫶.

Second, it gives you a roadmap to all the docs that hold the actual specs 🗺️.

Third, it gives a quick, easy-to-read summary of what's in each of those relevant spec docs 📝.

this doc is intentionally tutorial, so it might be a little "guilty" of oversimplifying things 🙈. If this doc and the detailed docs it's a roadmap for ever disagree, the specs in the detailed docs shall prevail 👑. that's the rule, periodt.

the detailed docs also try to keep the different component modules separate so they can define well-defined interfaces between them 🧩. This roadmap doc takes a different approach, though. It tries to give you an integrated view of all the modules, because readability is the whole vibe 💖.

This document is a work product of the SNMPv3 Working Group of the Internet Engineering Task Force (IETF) 🌸.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] ⭐.

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 SNMP Framework share the same basic structure and components 🍓. They also all follow the same architecture, which is honestly so consistent of them 💅.

2.1. Basic Structure and Components 🧚

an enterprise deploying the Internet Standard Management Framework has 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 specs of the Internet Standard Management Framework are based on a modular architecture 🧱. This framework is more than just a protocol for moving data, it's giving full package 🎁. It consists of:

  • 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 stayed consistent 💖.

one big motivator for this modularity was to enable the ongoing evolution of the Framework, as is documented in RFC 1052 [2] 📖. Originally, this capability was supposed to ease the transition from SNMP-based management of internets to management based on OSI protocols 🌐. So the framework was built with a protocol-independent data definition language and Management Information Base, plus a MIB-independent protocol 🧠. This separation was designed so the SNMP-based protocol could be replaced without the management information having to be redefined or reinstrumented 🔁.

history has shown that choosing this architecture was the right decision for the wrong reason 🙃 -- it turned out this architecture 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 😭. Iconic plot twist, honestly.

The SNMPv3 Framework builds on 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
  • using these same layering principles in the definition of new capabilities in the security and administration portion of the architecture.

if you're familiar with the architecture of the SNMPv1 Management Framework and the SNMPv2 Management Framework, you'll find lots of familiar concepts in the SNMPv3 Management Framework 🥰. Just know that in some cases the terminology might be a little different 👀.

3. The SNMPv1 Management Framework 🎀

the original Internet-Standard Network Management Framework (SNMPv1) is defined in the following docs 📚:

  • STD 16, RFC 1155 [3] 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 [4] 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 [5] 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 docs are generally considered companions to these three 🫶:

  • STD 17, RFC 1213 [6] which contains definitions for the base set of management information
  • RFC 1215 [7] 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 docs describe the four parts of the first version of the SNMP Framework 💜🌸.

3.1. The SNMPv1 Data Definition Language ✨

okay so RFCs 1155, 1212, and 1215 are the three docs that describe the SNMPv1 data definition language, and people lowkey call them "SMIv1" 💅. Quick tea: because the SMI was supposed to be protocol-independent at first, the first two SMI docs don't give you a way to define event notifications (traps) 🙈. Instead, the SNMP protocol doc defines a few standardized event notifications (generic traps) and leaves room for more to be defined. The last doc is the straight-forward way to define event notifications for SNMPv1 🎀. At the time, using traps in the Internet-Standard network management framework was super controversial 💀, so RFC 1215 was put out as "Informational" and never got updated, because everyone figured the second version of the SNMP Framework would replace the first one anyway 🫶.

3.2. Management Information 🍓

the data definition language from the first two docs was first used to define MIB-I, which is now historic and was specified in RFC 1066 [8]. Then it got used again to define MIB-II, specified in RFC 1213 [6] 💖.

After MIB-II came out, the approach changed 👑. Before, one committee of generalists worked on one single document to define the Internet-Standard MIB. Now, lots of mini-MIB documents were produced in parallel and in a distributed way ✨. Groups were chartered to write a spec for one focused part of the Internet-Standard MIB, and they were staffed by people who were actual experts in those areas, from different parts of network management, to system management, and application management 🦋. Iconic restructuring, honestly.

3.3. Protocol Operations 🧚

the third doc, STD 15 [5], describes the SNMPv1 protocol operations, which are performed by protocol data units (PDUs) on lists of variable bindings 💜. It also describes the format of SNMPv1 messages. The operators SNMPv1 defines are get, get-next, get-response, set-request, and trap 🔥. It also defines typical layering of SNMP on a connectionless transport service 🌈.

3.4. SNMPv1 Security and Administration 🔐

STD 15 [5] also has an approach to security and administration 💅. A lot of these concepts get carried forward, and some of them, security especially, get extended by the SNMPv3 Framework 🫶.

The SNMPv1 Framework describes how SNMPv1 PDUs get encapsulated in SNMP messages between SNMP entities, and it makes a split between application entities and protocol entities 🎀. In SNMPv3, those are renamed to applications and engines, respectively ✨.

The SNMPv1 Framework also brings in the idea of an authentication service that supports one or more authentication schemes 🦋. On top of authentication, SNMPv3 adds another security capability called 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 means the security capabilities can be changed and added to 👑.

Last, the SNMPv1 Framework introduces access control based on something called an SNMP MIB view 💖. The SNMPv3 Framework specifies a fundamentally similar concept called view-based access control. With this, SNMPv3 gives you the means to control access to information on managed devices 💅.

the big weakness: SNMPv1 anticipated multiple authentication schemes, but it didn't actually define any except a trivial one based on community strings 💀. This was a known fundamental weakness in the SNMPv1 Framework. The reasoning back then was that commercial grade security might be contentious in its design and hard to get approved, because "security" means many different things to different people 🙈. Also, some users don't need strong authentication. So SNMPv1 set up the authentication service as a separate block to be defined "later" 🧚. The SNMPv3 Framework provides an architecture for use within that block, plus a definition for its subsystems ✨.

4. The SNMPv2 Management Framework ✨

The SNMPv2 Management Framework is described in [8-13], and coexistence and transition issues between SNMPv1 and SNMPv2 are discussed in [15] 🫶.

SNMPv2 has 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 💀. It doesn't meet the original design goals of the SNMPv2 project. The unmet goals included security and administration that would deliver so-called "commercial grade" security, with:

  • authentication: origin identification, message integrity, and some aspects of replay protection 🔐;
  • privacy: confidentiality 🌸;
  • 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 Working Group was chartered to prepare recommendations for the next generation of SNMP ✨. The goal was to produce the set of documents needed to provide a single standard for the next generation of core SNMP functions 🫶. The single most critical need was a definition of security and administration that makes SNMP-based management transactions secure in a way that's actually useful for users who want to use SNMPv3 to manage networks, the systems that make up those networks, and the applications that live on those systems 🔥. That includes manager-to-agent, agent-to-manager, and manager-to-manager transactions 💅.

In the several years before the Working Group was chartered, there were a bunch of efforts aimed at adding security and other improvements to SNMP 🦋. These included:

  • "SNMP Security" circa 1991-1992 (RFC 1351 - RFC 1353), 🧚
  • "SMP" circa 1992-1993, and 💜
  • "The Party-based SNMPv2" (sometimes called "SNMPv2p") circa 1993-1995 (RFC 1441 - RFC 1452). 👑

Each of these efforts included commercial grade, industrial strength security, covering authentication, privacy, authorization, view-based access control, and administration, including remote configuration 💖.

These efforts fed into the development of the SNMPv2 Management Framework, as described in RFCs 1902 - 1908 ✨. But the Framework in those RFCs didn't have a standards-based security and administrative framework of its own 🙈. Instead, it was associated with multiple security and administrative frameworks, including:

  • "The Community-based SNMPv2" (SNMPv2c) as described in RFC 1901 [16], 🌈
  • "SNMPv2u" as described in RFCs 1909 and 1910, and 🔐
  • "SNMPv2*." 💀

SNMPv2c had the most support within the IETF, but it had no security and administration 😭. Meanwhile, SNMPv2u and SNMPv2* both had security but lacked consensus support within the IETF 🫶.

The SNMPv3 Working Group was chartered to produce a single set of specifications for the next generation of SNMP 🎀. Those specs were based on a convergence of the concepts and technical elements of SNMPv2u and SNMPv2*, as suggested by an advisory team formed to provide a single recommended approach for SNMP evolution 💅.

The Working Group charter defined these 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, the Working 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" 🙈. It reused the SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908, for the parts of the design that were outside the focused scope 💖.

Instead, the primary contributors, and the Working Group in general, put their considerable effort into the missing link, security and administration 🔥. In the process, they made invaluable contributions to the state-of-the-art of management 🫶✨.

They produced a design built on a modular architecture with evolutionary capabilities, with an emphasis on layering 🌈. As a result, SNMPv3 can be thought of as SNMPv2 with additional security and administration capabilities 💜.

By doing that, the Working Group reached its goal of producing a single specification that has not only the endorsement of the IETF but also has security and administration 👑💅.

6. SNMPv3 Framework Module Specifications 🧚

The SNMPv3 Management Framework spec is split up in a modular way across several documents 🦋. The SNMPv3 Working Group intends that, with proper care, any or all of the individual documents can be revised, upgraded, or replaced as requirements change, new understandings are gained, and new technologies become available ✨.

Wherever it's feasible, the initial document set that defines the SNMPv3 Management Framework builds on earlier work defining and implementing the SNMPv2 Management Framework 🫶. It does this by incorporating by reference each of the SNMPv2 Management Framework specifications 💖.

The SNMPv3 Framework adds to those specifications with new specs for security and administration for SNMPv3 🔐.

The documents that specify the SNMPv3 Management Framework follow the same architecture as the prior versions, and for expository purposes they can be organized into four main categories 🎀:

  • 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 documents in the fourth set are new to SNMPv3, but, as described previously, they build on significant prior related works 💜🫶

6.1. Data Definition Language ✨

okay so the data definition language lives in STD 58, RFC 2578, "Structure of Management Information Version 2 (SMIv2)" [17], plus some related specs 💅. These docs are updates of RFCs 1902 - 1904 [9-11], which evolved independently from the other parts of the framework. They were republished with minor editorial changes as STD 58, RFCs 2578 - 2580 [17-19] when they got promoted from Draft Standard to full Standard 🎀

The Structure of Management Information (SMIv2) defines the fundamental data types, an object model, and the rules for writing and revising MIB modules 🦋 The related specs here are STD 58, RFCs 2579 and 2580.

STD 58, RFC 2579, "Textual Conventions for SMIv2" [18], defines an initial set of shorthand abbreviations that can be used inside all MIB modules, just to make life easier for human readers and writers 🌸

STD 58, RFC 2580, "Conformance Statements for SMIv2" [19], defines the format for compliance statements (used to describe requirements for agent implementations) and capability statements (which document the characteristics of particular implementations) 🧚

ngl the term "SMIv2" is a little bit confusing 🙈 people use it to mean at least two different things. Sometimes it refers to the entire data definition language of STD 58, which is defined collectively in RFCs 2578 - 2580. Other times it only means the part of that language defined in RFC 2578. It's unfortunate, but it's rarely a real problem in practice 💜

6.2. MIB Modules 🌈

MIB modules usually contain object definitions. They may also contain definitions of event notifications, and sometimes they include compliance statements written in terms of the appropriate object and event notification groups. So basically, MIB modules define the management information that gets 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 to the rules in the documents that specify the data definition language, mainly the SMI as supplemented by the related specifications ✨

There is a large and growing number of standards-track MIB modules, as listed in the periodically updated "Internet Official Protocol Standards" list [20] 🔥 As of this writing, there are more than 100 standards-track MIB modules, with a total number of defined objects exceeding 10,000. On top of that, there is an even larger and growing number of enterprise-specific MIB modules that various vendors, research groups, consortia, and the like have defined on their own. That gives an unknown and virtually uncountable number of defined objects 🤯

In general, management information defined in any MIB module can be used with any version of the protocol, no matter which version of the data definition language was used. 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 there. Also, MIB modules defined in terms of the SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and can be conveyed by them 💖

There is one noteworthy exception 🙈 The Counter64 datatype can be defined in a MIB module written in SMIv2 format, but it cannot be conveyed by an SNMPv1 protocol engine. It can be conveyed by an SNMPv2 or an SNMPv3 engine, but it cannot be conveyed by an engine that exclusively supports SNMPv1 💀

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 that have since been updated 🎀

The specification for protocol operations is STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21] 💅

The SNMPv3 Framework is designed so that various parts of the architecture can evolve independently. For example, a new specification of protocol operations could be defined within the Framework to allow for additional protocol operations. main character energy 👑

The specification of transport mappings is STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22] ✨

6.4. SNMPv3 Security and Administration 🔐

The document series for SNMPv3 Security and Administration, defined by the SNMPv3 Working Group, currently consists of seven documents 🌸

  • RFC 3410, "Introduction and Applicability Statements for the Internet-Standard Management Framework", which is this document.
  • STD 62, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" [23], describes the overall architecture, with special emphasis on the architecture for security and administration.
  • STD 62, RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [24], describes the possibility of multiple message processing models, and the dispatcher portion that can be a part of an SNMP protocol engine.
  • STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) Applications" [25], describes the five initial types of applications that can be associated with an SNMPv3 engine, and their elements of procedure.
  • STD 62, RFC 3414, "User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)" [26], describes the threats against which protection is provided, as well as the mechanisms, protocols, and supporting data used to provide SNMP message-level security with the user-based security model 🔒
  • STD 62, RFC 3415, "View-based Access Control Model (VCAM) for the Simple Network Management Protocol (SNMP)" [27], describes how view-based access control can be applied within command responder and notification originator applications.
  • RFC 2576, "SNMPv3 Coexistence and Transition" [28], describes coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework. It is in the process of being updated by a Work in Progress 🚧

7. Document Summaries 🍓

The following sections give brief summaries of each document, with a bit more detail than 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 called the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written in the SNMP data definition language, which evolved from an adapted subset of OSI's Abstract Syntax Notation One (ASN.1) [29] language 💜 STD 58, RFCs 2578, 2579, and 2580 collectively define the data definition language. They specify the base data types for objects, a core set of shorthand specifications for data types called textual conventions, and 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 concisely convey the semantics of an information module.
  2. Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey 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 concisely convey the syntax and semantics of a notification.

As noted earlier, the term "SMIv2" is a little ambiguous because people use it to mean at least two different things. Sometimes it refers to the entire data definition language of STD 58, defined collectively in RFCs 2578 - 2580. Other times it only refers to the part of that language defined in RFC 2578. It's unfortunate, but it's rarely a significant problem in practice 🙈

7.1.1. Base SMI Specification 💎

STD 58, RFC 2578 specifies the base data types for the data definition language. These 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 data definition language:

  • IMPORTS lets you specify items that are used in a MIB module but defined in another MIB module.
  • MODULE-IDENTITY specifies a description and administrative information for a MIB module, such as contact and revision history.
  • OBJECT-IDENTITY and OID value assignments specify an OID value.
  • OBJECT-TYPE specifies the data type, status, and semantics of managed objects.
  • SEQUENCE type assignment lists the columnar objects in a table.
  • NOTIFICATION-TYPE specifies an event notification.

7.1.2. Textual Conventions 🦋

When designing a MIB module, it's often useful to specify, in a shorthand way, the semantics for a set of objects with similar behavior. This is done by defining a new data type based on 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 called textual conventions. They're 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 [18], to define the TEXTUAL-CONVENTION construct of the data definition language, which is used to define these new types, and to specify an initial set of textual conventions available to all MIB modules ✨

7.1.3. Conformance Statements 📋

It can be useful to define the acceptable lower bounds of an implementation, along with the actual level of implementation achieved. It is the purpose of STD 58, RFC 2580, Conformance Statements for SMIv2 [19], to define the constructs of the data definition 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 concisely convey 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 concisely convey 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 concisely convey the objects in an object group, and the semantics of that group. The NOTIFICATION-GROUP construct is used to concisely convey the event notifications in an event notification group, and the semantics of that group 💖

7.2. Protocol Operations ✨

okay so the management protocol is all about swapping messages between the agents and the management stations 💌 each message is basically a little "wrapper" that wraps up a Protocol Data Unit (PDU) 🎀

the one who actually decides how PDUs get sent and received is STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21] 💅 that's the protocol operations doc, bestie

7.3. Transport Mappings 🦋

SNMP messages can ride on a bunch of different protocol suites 🌈 STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22] is the one that explains how SNMP messages map onto an initial set of transport domains ✨ more mappings might show up later too 👀

Here's the tea: even though several mappings exist, the mapping onto UDP is the preferred mapping 💖 so for the best interoperability 🫶, systems that pick some other mapping should also provide proxy service to the UDP mapping 🌸

7.4. Protocol Instrumentation 🧚

STD 62, RFC 3418, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)" [30] is where the managed objects live 🍓 they describe the behavior of portions of an SNMP entity, so it's basically the instrumentation glow-up 💜

7.5. Architecture / Security and Administration 🔐

STD 62, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" [23] is the architecture doc for specifying Management Frameworks 🏛️ it's all about general architecture, but it zooms in on security and administration stuff 🔒 it also defines a bunch of terms used across the whole SNMPv3 Management Framework and, while it's doing that, 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 doc also has a small MIB module that every authoritative SNMPv3 protocol engine implements 🙌

7.6. Message Processing and Dispatch (MPD) 📬

STD 62, RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [24] describes how SNMP messages get processed and dispatched inside the SNMP architecture 🚚 it defines the procedures for dispatching potentially multiple versions of SNMP messages to the right SNMP Message Processing Models, and for dispatching PDUs to SNMP applications 💫 it also describes one Message Processing Model, which is the SNMPv3 Message Processing Model 🎀

Big deal: an SNMPv3 protocol engine MUST support at least one Message Processing Model 🚨 it MAY support more than one, like in a multi-lingual system that supports SNMPv3 and SNMPv1 and/or SNMPv2c at the same time 🌈 for example, a tri-lingual system that supports SNMPv1, SNMPv2c, and SNMPv3 all at once supports three message processing models 🤯

7.7. SNMP Applications 🧑‍💻

STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) Applications" [25] describes the five types of applications that 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) 🔑

STD 62, RFC 3414, the "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)" [26] describes the User-based Security Model for SNMPv3 🛡️ it defines the Elements of Procedure for providing SNMP message-level security 🫶

the doc describes the two primary and two secondary threats the User-based Security Model defends against 😤 they are: modification of information, masquerade, message stream modification, and disclosure 💀

the USM uses MD5 [31] and the Secure Hash Algorithm [32] as keyed hashing algorithms [33] for digest computation to provide data integrity 🔐 that helps in a few ways:

  • 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 depending on third-party time sources and the security considerations that come with them 🕰️

the USM uses the Data Encryption Standard (DES) [34] in the cipher block chaining mode (CBC) if disclosure protection is desired 🔏 support for DES in the USM is optional, mainly because export and usage restrictions in many countries make it hard to export and use products that include cryptographic technology 🌍

the document also includes a MIB that's great for remotely monitoring and managing the USM's configuration parameters, 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 the USM uses are based on pre-placed keys, aka private key mechanisms 🔑 the SNMPv3 architecture allows symmetric and asymmetric mechanisms and protocols (asymmetric mechanisms are commonly called public key cryptography) 🧠 but, as of this writing, there are no SNMPv3 security models on the IETF standards track that use public key cryptography 🙈

Coming soon: work is underway to specify how AES is to be used within the User-based Security Model (USM) 🎉 this will be a separate document 📄

7.9. View-based Access Control (VACM) 👀

the purpose of STD 62, RFC 3415, the "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)" [27], is to describe the View-based Access Control Model for use in the SNMP architecture 🦋 the VACM can be associated with multiple Message Processing Models and multiple Security Models at the same time, inside a single engine implementation 🌸

it's architecturally possible to have multiple, different, Access Control Models active and present at the same time 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 RFC 2576, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework" [28], 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 that 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
  • 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) [27]

8. Standardization Status 📜

readers should consult the latest version of the "Internet Official Protocol Standards" list [20] to find the standardization status of any document 🔍

however, the SNMPv3 Working Group explicitly asked for text to be included in this document to amplify on the status of SMIv1, SNMPv1, and SNMPv2c 💜

8.1. SMIv1 Status 🕰️

SMIv1, as described in STD 16, RFCs 1155 and 1212, was promoted to full Standard status in 1990 and has stayed a Standard even after SMIv2 reached full Standard (see RFC 2026 [35] for more information about the Internet Standards Process) 🍰 in a lot of cases, a Standard gets declared "Historic" when its replacement reaches full Standard 🥀 for example, MIB-1 [8] was declared "Historic" when MIB-2 [6] reached full Standard 🌷

similarly, when SMIv2 reached full Standard, it might have been reasonable to retire SMIv1 and declare it "Historic" 🤔 but as the result of a conscious decision, STD 16, RFCs 1155 and 1212 continue to have the standardization status of full "Standard" but are not recommended 🙃 these documents were not declared "Historic" and remain on the standards track because they provide normative references for other documents on the standards track, and they cannot be declared "Historic" without making the documents that rely on them "Historic" too 🫠 so STD 16 keeps its standardization status but is not recommended, because it has been superseded by the newer SMIv2 specifications, which are identified somewhat later in this document 💫

Real talk: on a pragmatic level, since about 1993 it has been wise for users of the data definition language to use SMIv2 for all new work 🧁 the realities of the marketplace have occasionally required support for data definitions in both the SMIv1 and SMIv2 formats 🛒 there are tools widely available at low or no cost that translate SMIv2 definitions to SMIv1 definitions, but it's impractical to build automatic tools that translate SMIv1 definitions to SMIv2 definitions 🚫 so if you work primarily in SMIv2, the cost of providing data definitions in both SMIv1 and SMIv2 formats is trivial 🥳 if you work primarily in SMIv1 format, providing data definitions in both SMIv1 and SMIv2 is significantly more expensive 💸 the market requirements for providing data definitions in SMIv1 format today are greatly diminished compared to 1993, and SMIv2 continues to be the strongly preferred format even though SMIv1 has not been declared "Historic" 👑 indeed, the IETF currently requires that new MIB modules be written using SMIv2 🎀

8.2. SNMPv1 and SNMPv2 Standardization Status ✨

okay bestie, SNMPv1 and SNMPv2c message wrappers only do trivial authentication with plain-text community strings, so they're fundamentally insecure 😭 when the SNMPv3 specs for security and administration (the strong-security ones!) hit full Standard status, the full Standard SNMPv1 (formerly STD 15 [5]) and the experimental SNMPv2c specs in RFC 1901 [16] got declared Historic 🍓 because of their security weaknesses. it was a clear message: SNMPv3 is the framework of choice now 👑 the Party-based SNMPv2 (SNMPv2p), SNMPv2u, and SNMPv2* were either declared Historic around 1995 or were never on the standards track, so they're basically background characters 💀

on a pragmatic level, vendors are still gonna make and users are still gonna deploy multi-lingual implementations that do SNMPv1 and/or SNMPv2c alongside SNMPv3 🌈 the IETF standards process can't control what vendors or users choose to promote or deploy, even if they're historic protocols with known short-comings. but it's not expected that vendors will produce, or that users will deploy, multi-lingual implementations that support the Party-based SNMPv2p (SNMPv2p), SNMPv2u, or SNMPv2* 🙈

and yes, one of the SNMPv3 specs, RFC 2576, Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Management Framework [28], handles exactly these issues 🦋

⚠️ real talk: if you're running multi-lingual systems with insecure protocols, you have to do your due diligence and make sure your configs limit SNMPv1 and SNMPv2c access properly, in line with your organization's security policy. same energy as limiting SNMPv3 access at security level no authentication and no privacy, because that's roughly equivalent from a security point of view 🫶 it's probably unwise to give SNMPv1 or SNMPv2c more access than unauthenticated SNMPv3 users get. it does not make sense to guard the front door with armed guards, trained attack dogs, moats and drawbridges while leaving an open back door 🏰💅

the SNMPv1 framework, SNMPv2 framework, and SNMPv2c had pretty limited abilities to administer the SNMPv1 and SNMPv2c protocols. for example, there are no objects defined to view or configure communities or destinations for notifications (traps and informs) 😩 so vendors came up with their own admin mechanisms, ranging from proprietary-format config files that can't be viewed or configured via SNMP to enterprise-specific object definitions. the SNMPv3 framework, though, has a rich standards-based approach to administration that, by design, can be used for SNMPv1 and SNMPv2c too ✨ so to foster interoperability of administration in multi-lingual systems, the mechanisms and objects specified in [25], [27], and [28] should be used to supplement or replace the equivalent proprietary mechanisms 🧚

8.3. Working Group Recommendation

based on everything above, the SNMPv3 Working Group recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be reclassified as Historical documents 📜🎀

9. 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. so go check those, bestie, they've got the real security tea 🫖

10. References 📚

10.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.

10.2. Informative References

  • [2] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, April 1988.
  • [3] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
  • [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
  • [5] Case, J., Fedor, M., Schoffstall, M. and Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
  • [6] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
  • [7] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
  • [8] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, March 1990.
  • [9] 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.
  • [10] 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.
  • [11] 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.
  • [12] 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.
  • [13] 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.
  • [14] 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.
  • [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-Standard Network Management Framework", RFC 2576, January 1996.
  • [16] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
  • [17] 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.
  • [18] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
  • [19] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
  • [20] "Official Internet Protocol Standards", http://www.rfc-editor.org/rfcxx00.html also STD0001.
  • [21] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
  • [22] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
  • [23] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
  • [24] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
  • [25] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
  • [26] Blumenthal, U. and B. Wijnen, "User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
  • [27] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
  • [28] 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", RFC 2576, March 2000.
  • [29] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).
  • [30] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
  • [31] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
  • [32] 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)
  • [33] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [34] 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).
  • [35] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October, 1996.

11. Editors' Addresses 💌

Jeffrey Case
SNMP Research, Inc.
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
USA

Phone: +1 865 573 1434
EMail: case@snmp.com


Russ Mundy
Network Associates Laboratories
15204 Omega Drive, Suite 300
Rockville, MD 20850-4601
USA

Phone: +1 301 947 7107
EMail: mundy@tislabs.com


David Partain
Ericsson
P.O. Box 1248
SE-581 12 Linkoping
Sweden

Phone: +46 13 28 41 44
EMail: David.Partain@ericsson.com


Bob Stewart
Retired

Copyright (C) The Internet Society (2002). All Rights Reserved. 🎀

okay so this part is the legal stuff, but it's actually pretty chill 💅 You're allowed to copy this doc and share it with your friends, and you can even write derivative works that comment on it, explain it, or help people implement it. You can publish and distribute all of that, whole or in part, with no restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work 🫶

BUT the doc itself can't be changed in any way. You can't strip out the copyright notice or the references to the Internet Society or other Internet orgs 🙅‍♀️ The one exceptions are developing Internet standards (then you follow the copyright procedures in the Internet Standards process) or translating it into languages other than English 🌍

The permissions are perpetual, so the Internet Society (or whoever takes over for them) can't take them back. Forever and ever 💜

The document and the information in it are provided "AS IS", 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. 💀

translation: they're not promising it'll be perfect or that it won't break your stuff 😭 use your brain, bestie

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 🦋 Thank you to the Internet Society for keeping the RFC Editor running, because honestly the RFC library would not exist without that support 🫶✨

📦 where this page comes from