RFC 2570

Introduction to Version 3 of the Internet-standard Network Management Framework

📅 published April 1999, from ietf

RFC 2570 💖 Introduction to Version 3 of the Internet-standard Network Management Framework

Okay bestie, here are the deets 🎀. This is RFC 2570, titled Introduction to Version 3 of the Internet-standard Network Management Framework. It came out in April 1999 from the Network Working Group and it's Informational, so it's giving "here's some context," not a standard 🧚.

The authors are J. Case (SNMP Research, Inc.), R. Mundy (TIS Labs at Network Associates, Inc.), D. Partain (Ericsson), and B. Stewart (Cisco Systems). The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🦋.

Status of this Memo ✨

This memo is info for the Internet community. It is not a standard of any kind, so don't go treating it like one 💅. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 💜

This doc gives you an overview of the third version of the Internet-standard Management Framework, which is called the SNMP version 3 Framework (SNMPv3). SNMPv3 is derived from and builds on both the original Internet-standard Management Framework (SNMPv1) and the second one (SNMPv2). It's giving main character glow-up energy 👑.

The architecture is designed to be modular, so the Framework can keep evolving 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
   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, which is called the SNMP version 3 Management Framework (SNMPv3). It has three jobs 🌈.

First, it explains how the SNMP version 3 (SNMPv3) specs relate to the SNMP version 1 (SNMPv1) Management Framework, the SNMP version 2 (SNMPv2) Management Framework, and the Community-based Administrative Framework for SNMPv2.

Second, it gives you a roadmap to all the multiple documents that hold the relevant specs.

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

This document is intentionally tutorial, so it may occasionally be "guilty" of oversimplifying things 🙈. If this document ever conflicts with the more detailed documents it's a roadmap for, the specs in those detailed documents shall prevail. Don't trust my summary over the real thing, bestie 💅.

The detailed documents try to keep the different component modules separate so they can define clean interfaces between them. This roadmap doc takes a different approach. It tries to give you one integrated view of the component modules so it's easier to read ✨.

2 The Internet Standard Management Framework 💖

The third version of the Internet Standard Management Framework (the SNMPv3 Framework) is derived from and builds on both the original Internet-standard Management Framework (SNMPv1) and the second one (SNMPv2).

All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard Management Framework share the same basic structure and components. On top of that, every version of the specs follows the same architecture 🎀.

2.1 Basic Structure and Components 🫶

An enterprise that deploys 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. Same bones, different glow-up 🌸.

2.2 Architecture of the Internet Standard Management Framework 🏗️

The specs of the Internet Standard Management Framework are based on a modular architecture. The framework is more than just a protocol for moving data. It has four parts:

  • a data definition language;
  • definitions of management information (the Management Information Base, or MIB);
  • a protocol definition; and
  • security and administration.

As the Framework has evolved from SNMPv1, through SNMPv2, to SNMPv3, the definitions of each of these architectural components have gotten richer and more clearly defined. The fundamental architecture has stayed consistent though 💜.

One big reason for this modularity was to enable the ongoing evolution of the Framework, as documented in RFC 1052 [14]. Originally, this was meant to ease the move from SNMP-based management of internets to management based on OSI protocols. To make that work, the framework was built with a protocol-independent data definition language and Management Information Base, along with a MIB-independent protocol. This separation was designed so the SNMP-based protocol could be replaced without having to redefine or reinstrument the management information. Plot twist 🙃: history shows that picking this architecture was the right decision for the wrong reason. It ended up easing the transition from SNMPv1 to SNMPv2 and from SNMPv2 to SNMPv3, rather than easing a move away from management based on the Simple Network Management Protocol.

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 to define new capabilities in the security and administration portion of the architecture.

If you already know the architecture of the SNMPv1 Management Framework and the SNMPv2 Management Framework, you'll spot a lot of familiar concepts in the SNMPv3 Management Framework. Sometimes the terminology is a little different though, so keep your eyes open 👀.

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.

Two more documents are generally considered companions to these three:

  • STD 17, RFC 1213 [13], which contains definitions for the base set of management information.
  • RFC 1215 [25], which 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 because the SMI had to be protocol-independent at the start, the first two SMI documents don't provide a way to define event notifications (traps). Instead, the SNMP protocol document defines a few standardized event notifications (generic traps) and provides a way for additional event notifications to be defined. The last document specifies a straightforward approach to defining event notifications used with the SNMPv1 protocol.

Back then, using traps in the Internet-standard network management framework was controversial 😬. Because of that, RFC 1215 was published with the status of "Informational". That status was never updated, since people believed the second version of the SNMP Framework would replace the first. Note that the SNMPv1 data definition language is sometimes referred to as SMIv1 🫶.

3.2 Management Information ✨

okay so the data definition language we just met was first used to define the now-historic MIB-I 🕰️, which is in [RFC 1066 — no wait, keep as written: "RFC 1066 [12]"] 💅 and then it got used again for MIB-II, specified in RFC 1213 [13] 🎀

Okay, here's where it gets spicy 🌶️. After MIB-II came out, the whole vibe for writing management information changed. The old way was one committee of generalists working on one single document to define the Internet-standard MIB. The new way? Way better, imo 🫶. Instead, a bunch of mini-MIB documents got made at the same time, by different groups. Each group had a focused slice of the Internet-standard MIB to work on, and each was staffed by people who were actually experts in that area 🧠. Those areas ranged from network management to system management to application management. Main character energy for the specialists 👑

3.3 Protocol Operations 🦋

the third document, STD 15, is the one that describes the SNMPv1 protocol operations 📨. Those operations 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 🧚. And typical layering of SNMP on a connectionless transport service is defined too 🌸

3.4 SNMPv1 Security and Administration 🔐

STD 15 also has an approach to security and administration 💜. Lots of these concepts got carried forward into SNMPv3, and some of them, especially security, got extended by the SNMPv3 Framework ✨

The SNMPv1 Framework describes how SNMPv1 PDUs get encapsulated in SNMP messages between SNMP entities 📦. It also makes a distinction between application entities and protocol entities. In SNMPv3, those get renamed to applications and engines, respectively 🔄

The SNMPv1 Framework also introduces the concept of an authentication service, which 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 both changes and additions to the security capabilities are possible 🧩

Finally, the SNMPv1 Framework introduces access control based on a concept called an SNMP MIB view 👀. The SNMPv3 Framework has a fundamentally similar concept called view-based access control. With this, SNMPv3 gives you the means to control access to information on managed devices 🔑

BUT, and this is a big but 😭, even though the SNMPv1 Framework expected multiple authentication schemes, it didn't actually define any except a trivial one based on community strings. This was a known fundamental weakness in the SNMPv1 Framework 💀. People thought at the time that defining commercial grade security might be contentious in its design and hard to get approved, because "security" means many different things to different people 🙃. So, because some users don't need strong authentication, SNMPv1 set up an authentication service as a separate block to be defined "later" 🗓️. The SNMPv3 Framework then provides an architecture for use within that block, plus a definition for its subsystems 🫶

4. SNMPv2 Management Framework ✨

The SNMPv2 Management Framework is fully described in [4-9], and coexistence and transition issues between SNMPv1 and SNMPv2 are discussed in [10] 📚

SNMPv2 gives you 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 does not meet the original design goals of the SNMPv2 project. The unmet goals included the 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;
  • 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. 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 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 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 activities aimed at adding security and other improvements to SNMP 🧵. These efforts included:

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 😭. Instead, it was associated with multiple security and administrative frameworks, including:

  • "The Community-based SNMPv2" (SNMPv2c) [RFC 1901],
  • "SNMPv2u" [RFCs 1909 - 1910] and
  • "SNMPv2*" (SNMPv2*).

SNMPv2c had the endorsement of the IETF but no security and administration 🙈. Meanwhile, 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. It was based on a convergence of the concepts and technical elements of SNMPv2u and SNMPv2*, as suggested by an advisory team that was formed to provide a single recommended approach for SNMP evolution 🦋

In doing so, 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" 🛞. Instead, it reused the SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908, for those portions of the design that were outside the focused scope 🙌

The primary contributors to the SNMPv3 Working Group, and the Working Group in general, put their considerable efforts into addressing the missing link, which is security and administration 🔗. In the process they 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 ✨

By doing so, the Working Group achieved the goal of producing a single specification that has not only the endorsement of the IETF but also security and administration 🎉

6. SNMPv3 Framework Module Specifications 🧚

The specification of the SNMPv3 Management Framework is partitioned in a modular fashion among 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 🔄

Whenever feasible, the initial document set that defines the SNMPv3 Management Framework leverages prior investments in defining and implementing the SNMPv2 Management Framework 💰. It does this 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 that specify the SNMPv3 Management Framework follow the same architecture as those of the prior versions. For expository purposes, they can be organized 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 is new to SNMPv3 but, as described previously, builds on significant prior related works 💜

6.1 Data Definition Language 📖

The specifications of the data definition language include 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 evolved independently from the other parts of the framework. They were republished as STD 58, RFCs 2578 - 2580 [26-28] when they were promoted from Draft Standard 🦋

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. These 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. These are used for describing requirements for agent implementations, and for capability statements that can be used to document the characteristics of particular implementations 📝

6.2 MIB Modules ✨

okay so MIB modules are basically where the good stuff lives 💖 they usually have object definitions, can have event notification definitions, and sometimes come with compliance statements that talk about object and event notification groups. so a MIB module is what defines the management info that the instrumentation in managed nodes keeps track of, that management agents make reachable remotely, that the management protocol carries around, and that management apps actually work with 🦋

MIB modules follow the rules in the documents that define the data definition language, mainly the SMI plus whatever related specs supplement it 📚

there are SO many standards-based MIB modules rn 😭 they're listed 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 of almost 10,000 defined objects 🔥 and then there's an even bigger, still-growing pile of enterprise-specific MIB modules that vendors, research groups, consortia, and similar folks define on their own, so the number of defined objects is unknown and basically uncountable 💀

here's the iconic part: management info defined in any MIB module works with any version of the protocol, no matter which version of the data definition language was used 👑 for example, MIB modules written with the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management Framework and can be carried by the protocols specified there 🧚 MIB modules written with the SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and can be carried by them too 🌸 BUT there's one noteworthy exception 👀

the exception is the Counter64 datatype. it can be defined in a SMIv2-format MIB module, but an SNMPv1 protocol engine can't carry it 🙈

6.3 Protocol Operations and Transport Mappings 🎀

the protocol operations and transport mappings for the SNMPv3 Framework are incorporated by reference, which means they point back to the two SNMPv2 Framework documents 🫶

the protocol operations spec is RFC 1905, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)" [7]. the SNMPv3 Framework is built so different parts of the architecture can evolve on their own 🦋 like, a new protocol operations spec could be defined inside the Framework to add extra protocol operations. main character architecture ✨

the transport mappings spec is 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 from the SNMPv3 Working Group has seven documents right now 🌈 here's the lineup:

  • 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], which describes the overall architecture with special focus on the security and administration architecture 🔥
  • RFC 2572, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [16], which describes the possibly multiple message processing models and the dispatcher portion that can be part of an SNMP protocol engine 💅
  • RFC 2573, "SNMP Applications" [17], which 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], which describes the threats, mechanisms, protocols, and supporting data used to provide SNMP message-level security 🔒
  • RFC 2575, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)" [19], which 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], which describes coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework 🫶

7 Document Summaries 📝

the next sections give quick summaries of each document with a bit more detail than the overviews above 💅

7.1 Structure of Management Information 🌸

management info is treated like a collection of managed objects that live in a virtual information store called the Management Information Base (MIB) 🧠 related objects get grouped into MIB modules, and those modules are written in the SNMP MIB module language. that language has bits of OSI's Abstract Syntax Notation One (ASN.1) [11] in it 🤓 STD 58, RFCs 2578, 2579, and 2580 together define the MIB module language, set the base data types for objects, set a core group of short-hand specs for data types called textual conventions, and make a few administrative assignments of object identifier (OID) values ✨

the SMI is split into three parts:

  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. 🔔

7.1.1 Base SMI Specification 🍓

STD 58, RFC 2578 specifies the base data types for the MIB module language. those are: 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. on top of that, STD 58, RFC 2578 defines these 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 info such as contact and revision history. 🪪
  • OBJECT-IDENTITY and OID value assignments to specify 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 you're designing a MIB module, it's often super useful to describe, in a short-hand way, the semantics for a set of objects that behave similarly 🙌 you do that by defining a new data type based on a base data type from the SMI. every new type gets its own name and a base type with more restrictive semantics. these new types are called textual conventions, and they're there for humans reading a MIB module and, potentially, "intelligent" management apps 🤖 STD 58, RFC 2579, Textual Conventions for SMIv2 [27], is the spec that defines the TEXTUAL-CONVENTION construct for making these new types, plus an initial set of textual conventions that every MIB module can use 💖

7.1.3 Conformance Statements 📜

sometimes it's handy to define the acceptable lower bounds of an implementation, along with the level actually achieved 👀 that's what STD 58, RFC 2580, Conformance Statements for SMIv2 [28], is for. it defines the MIB module language constructs used for this, and there are two kinds:

  1. Compliance statements describe requirements for agents with respect to object and event notification definitions. The MODULE-COMPLIANCE construct is used to convey these requirements concisely. ✅
  2. Capability statements describe the capabilities of agents with respect to object and event notification definitions. The AGENT-CAPABILITIES construct is used to convey these capabilities concisely. 🌟

finally, collections of related objects and collections of related event notifications get grouped together into a unit of conformance 🧩 the OBJECT-GROUP construct conveys concisely the objects in an object group and that group's semantics. the NOTIFICATION-GROUP construct conveys concisely the event notifications in an event notification group and that group's semantics. 🫶

7.2 Protocol Operations 🚀

the management protocol lets agents and management stations swap messages that carry management info 💌 each message has a "wrapper" that encapsulates a Protocol Data Unit (PDU) 📨

RFC 1905, Protocol Operations for SNMPv2 [7], exists to define the operations of the protocol for sending and receiving those PDUs 🦋

7.3 Transport Mappings 🌈

SNMP messages can ride over a bunch of different protocol suites 🛣️ RFC 1906, Transport Mappings for SNMPv2 [8], is the spec that defines how SNMP messages map onto an initial set of transport domains. other mappings might get defined later on 🔮

even though several mappings are defined, the mapping onto UDP is the preferred one 💜 so for the best interoperability, systems that choose to deploy other mappings should also provide proxy service to the UDP mapping 🫶

7.4 Protocol Instrumentation 🔧

RFC 1907, the Management Information Base for SNMPv2 document [9], exists to define managed objects that describe the behavior of an SNMPv2 entity 🧚

7.5 Architecture / Security and Administration 🏰

RFC 2571, "An Architecture for Describing SNMP Management Frameworks" [15], exists to define an architecture for specifying SNMP Management Frameworks 🏗️ while it covers general architecture issues, it focuses on security and administration. it defines a bunch of terms used across the SNMPv3 Management Framework, and in doing so it 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 also contains a small MIB module that every authoritative SNMPv3 protocol engine implements 💖

7.6 Message Processing and Dispatch (MPD) 📬✨

Okay so RFC 2572, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [16], is all about the Message Processing and Dispatching for SNMP messages inside the SNMP architecture 🧚. It spells out how to send potentially multiple versions of SNMP messages to the right SNMP Message Processing Models, and how to dispatch 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 that gives you simultaneous support for SNMPv3 and SNMPv1 and/or SNMPv2c 🌈.

7.7 SNMP Applications 🎈

It's the whole purpose of RFC 2573, "SNMP Applications" 🦋, to describe the five types of applications that can be hooked up to 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)", is the one that 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 that the User-based Security Model defends against 😭. They are: modification of information, masquerade, message stream modification, and disclosure 👀.

The USM uses MD5 [21] and the Secure Hash Algorithm [22] as keyed hashing algorithms [23] for digest computation, and that's how it gets 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 depending on third-party time sources, and without the concomitant security considerations that would come with them 🌸.

The USM uses the Data Encryption Standard (DES) [24] in cipher block chaining mode (CBC) if you want disclosure protection 🙈. 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 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 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 be associated with multiple Message Processing Models and multiple Security Models at the same time in a single engine implementation 💅.

It is architecturally possible to have multiple, different, Access Control Models active and present at once 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 🫠. Specifically, this document covers 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) [19] 🦋

8 Security Considerations 🛡️

🚨 Okay bestie, this part is SERIOUS. 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. Go read those, no skipping! 😭

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

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).

[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).

[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.

Okay bestie, the legal bit 🫶 The copyright line is Copyright (C) The Internet Society (1998). All Rights Reserved.

So you can copy this doc and pass it around, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those in whole or in part with no restrictions at all, as long as the copyright notice and this paragraph are on every copy and every derivative. 💖

The doc itself is a different story. It can't be modified in any way, like deleting the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. You can change it while developing Internet standards, but then you have to follow the copyright procedures in the Internet Standards process. You can also change it to translate it into languages other than English. 💅

These permissions are perpetual, and the Internet Society and its successors or assigns won't revoke them. 🦋

The doc and its info come "AS IS," and the Internet Society and the Internet Engineering Task Force are not making any promises. Here's the exact disclaimer:

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."
Translation: no warranties, express or implied, not even that using the info won't infringe anyone's rights, or that it's merchantable or fit for a particular purpose. Use it with your eyes open! 👀

Acknowledgement 🎀

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸

📦 where this page comes from