RFC 3584
Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework ✨
Okay bestie, this is RFC 3584 🎀, a Best Current Practice (BCP: 74) from the Network Working Group, dated August 2003 📅. The authors are R. Frye (Vibrant Solutions), D. Levi (Nortel Networks), S. Routhier (Wind River Systems, Inc.), and B. Wijnen (Lucent Technologies) 🫶. It obsoletes RFC 2576 💅, so that older doc is out and this is the one to read.
Status of this Memo
This document specifies an Internet Best Current Practice for the Internet Community, and it asks for discussion and suggestions for improvements 💜. Distribution of this memo is unlimited 🌈.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved 🔥.
Abstract
The whole point of this doc 🧚 is to explain how three generations of SNMP get along: version 3 of the Internet-standard Network Management Framework (SNMPv3), version 2 (SNMPv2), and the original version (SNMPv1). It also shows you how to turn MIB modules from SMIv1 format into SMIv2 format 🦋. And yes, it obsoletes RFC 2576 💅.
Table Of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 5
2. SMI and Management Information Mappings. . . . . . . . . . . 5
2.1. MIB Modules. . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Object Definitions . . . . . . . . . . . . . . 6
2.1.2. Trap and Notification Definitions . . . . . . 8
2.2. Compliance Statements. . . . . . . . . . . . . . . . . 9
2.3. Capabilities Statements. . . . . . . . . . . . . . . . 9
3. Translating Notification Parameters. . . . . . . . . . . . . 10
3.1. Translating SNMPv1 Notification Parameters to
SNMPv2 Notification Parameters . . . . . . . . . . . . 11
3.2. Translating SNMPv2 Notification Parameters to
SNMPv1 Notification Parameters . . . . . . . . . . . . 12
4. Approaches to Coexistence in a Multi-lingual Network . . . . 14
4.1. SNMPv1 and SNMPv2 Access to MIB Data . . . . . . . . . 14
4.2. Multi-lingual implementations. . . . . . . . . . . . . 15
4.2.1. Command Generator. . . . . . . . . . . . . . . 15
4.2.2. Command Responder. . . . . . . . . . . . . . . 16
4.2.2.1. Handling Counter64 . . . . . . . . . 16
4.2.2.2. Mapping SNMPv2 Exceptions. . . . . . 17
4.2.2.2.1. Mapping noSuchObject
and noSuchInstance. . . . 18
4.2.2.2.2. Mapping endOfMibView. . . 18
4.2.2.3. Processing An SNMPv1 GetReques . . . 18
4.2.2.4. Processing An SNMPv1 GetNextRequest. 19
4.2.2.5. Processing An SNMPv1 SetRequest. . . 20
4.2.3. Notification Originator. . . . . . . . . . . . 21
4.2.4. Notification Receiver. . . . . . . . . . . . . 21
4.3. Proxy Implementations. . . . . . . . . . . . . . . . . 22
4.3.1. Upstream Version Greater Than Downstream
Version. . . . . . . . . . . . . . . . . . . . 22
4.3.2. Upstream Version Less Than Downstream Version. 23
4.4. Error Status Mappings. . . . . . . . . . . . . . . . . 25
5. Message Processing Models and Security Models. . . . . . . . 26
5.1. Mappings . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. The SNMPv1 MP Model and SNMPv1 Community-based
Security Model . . . . . . . . . . . . . . . . . . . . 26
5.2.1. Processing An Incoming Request . . . . . . . . 27
5.2.2. Generating An Outgoing Response. . . . . . . . 29
5.2.3. Generating An Outgoing Notification. . . . . . 29
5.2.4. Proxy Forwarding Of Requests . . . . . . . . . 30
5.3. The SNMP Community MIB Module. . . . . . . . . . . . . 30
6. Intellectual Property Statement. . . . . . . . . . . . . . . 42
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations. . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . 46
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 47
A.1. Changes From RFC 2576 . . . . . . . . . . . . . . . . . 47
A.2. Changes Between RFC 1908 and RFC 2576 . . . . . . . . . 49
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 511. Overview 🌸
The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, which we call the SNMP version 3 framework (SNMPv3), version 2 of the Internet-standard Network Management Framework, which we call the SNMP version 2 framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1) ✨.
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 RFC 2119 [RFC2119] 💅. These are the official requirement words, so they're doing a lot of heavy lifting here 🙈.
Okay so there are four big topics 💖, and each one gets its own section:
- Converting MIB documents between SMIv1 and SMIv2 formats is covered in section 2 🦋.
- Mapping notification parameters is covered in section 3 🔔.
- Coexistence between entities that support the different SNMP versions in a multi-lingual network is covered in section 4 🌈. This section looks at how protocol operations get processed in multi-lingual implementations, and how proxy implementations behave 👑.
- The SNMPv1 Message Processing Model and Community-Based Security Model, which give you a way to adapt SNMPv1 into the View-Based Access Control Model (VACM) [20], are covered in section 5 💜. This section also talks about the SNMPv2c Message Processing Model and Community-Based Security Model, so it's a double feature 🎀.
1.1. SNMPv1 🧸
SNMPv1 is defined by these documents:
- STD 15, RFC 1157 [RFC1157] defines the Simple Network Management Protocol (SNMPv1), which is the protocol used for network access to managed objects 🔑.
- STD 16, RFC 1155 [RFC1155] defines the Structure of Management Information (SMIv1), which gives the mechanisms for describing and naming objects for management purposes 📚.
- STD 16, RFC 1212 [RFC1212] defines a more concise description mechanism, and it is wholly consistent with SMIv1 ✨.
- RFC 1215 [RFC1215] defines a convention for defining Traps to be used with SMIv1 🚨.
Note that throughout this document, the term 'SMIv1' is used. This term generally refers to the info in RFC 1155, RFC 1212, and RFC 1215 🍓.
1.2. SNMPv2 🦋
SNMPv2 is defined by these documents:
- STD 58, RFC 2578 defines Version 2 of the Structure of Management Information (SMIv2) [RFC2578] 💎.
- STD 58, RFC 2579 defines common MIB "Textual Conventions" [RFC2579] 🫧.
- STD 58, RFC 2580 defines Conformance Statements and requirements for defining agent and manager capabilities [RFC2580] 🌷.
- STD 62, RFC 3416 defines the Protocol Operations used in processing [RFC3416] ⚙️.
- STD 62, RFC 3417 defines the Transport Mappings used "on the wire" [RFC3417] 🛰️.
- STD 62, RFC 3418 defines the basic Management Information Base for monitoring and controlling some basic common functions of SNMP entities [RFC3418] 🧁.
Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580) 👑.
The following document augments the definition of SNMPv2:
- RFC 1901 [RFC1901] is an Experimental definition for using SNMPv2 PDUs within a community-based message wrapper. This is referred to throughout this document as SNMPv2c 🧪.
1.3. SNMPv3 🔐
SNMPv3 is defined by these documents:
- STD 62, RFC 3411 defines an Architecture for Describing SNMP Management Frameworks [RFC3411] 🏛️.
- STD 62, RFC 3412 defines Message Processing and Dispatching [RFC3412] 📬.
- STD 62, RFC 3413 defines various SNMP Applications [RFC3413] 🧩.
- STD 62, RFC 3414 defines the User-based Security Model (USM), which provides for both Authenticated and Private (encrypted) SNMP messages [RFC3414] 🔒.
- STD 62, RFC 3415 defines the View-based Access Control Model (VACM), which gives you the ability to limit access to different MIB objects on a per-user basis [RFC3415] 🗝️.
SNMPv3 also uses the SNMPv2 definitions of RFCs 3416 through 3418 and the SMIv2 definitions of 2578 through 2580 described above. Note that text throughout this document that refers to SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3 💕.
2. SMI and Management Information Mappings 🧚
The SMIv2 approach to describing collections of managed objects is nearly a proper superset of the approach defined in SMIv1 🌟. For example, both approaches use an adapted subset of ASN.1 [ASN1] as the basis for a formal descriptive notation 🧠. Honestly, you could argue that SMIv2 mostly codifies the existing practice for defining MIB modules, based on a lot of experience with SMIv1 🙌.
The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements 🎀.
2.1. MIB Modules 🦋
MIB modules defined using SMIv1 may continue to be used with protocol versions which use SNMPv2 PDUs. However, for SMIv1 MIB modules to conform to SMIv2, the following changes SHALL be made:
2.1.1. Object Definitions ✨
okay so, converting a MIB module does NOT automatically mean you have to deprecate the objects in it 🫶 ngl that's a relief. Only if an object's definition is truly inadequate for its intended purpose does the object SHALL be deprecated or obsoleted, otherwise deprecation is not required. 💅
Here's the checklist for the conversion itself 🎀
- First things first: the IMPORTS statement MUST reference SNMPv2-SMI, instead of RFC1155-SMI and RFC-1212. 📦
- The MODULE-IDENTITY macro MUST be invoked immediately after any IMPORTs statement. 🌸
- For any object with a SYNTAX clause value of Counter, the object MUST have the value of its SYNTAX clause changed to Counter32. 🔢
- For any object with a SYNTAX clause value of Gauge, the object MUST have the value of its SYNTAX clause changed to Gauge32, or Unsigned32 where appropriate. 📊
- For all objects, the ACCESS clause MUST be replaced by a MAX-ACCESS clause. The value of the MAX-ACCESS clause SHALL be the same as that of the ACCESS clause unless some other value makes "protocol sense" as the maximal level of access for the object. In particular, object types for which instances can be explicitly created by a protocol set operation, SHALL have a MAX-ACCESS clause of "read-create". If the value of the ACCESS clause is "write-only", then the value of the MAX-ACCESS clause MUST be "read-write", and the DESCRIPTION clause SHALL note that reading this object will result in implementation-specific results. Note that in SMIv1, the ACCESS clause specifies the minimal required access, while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed access. Keep this in mind when converting an ACCESS clause to a MAX-ACCESS clause. 🔐
- For all objects, if the value of the STATUS clause is "mandatory" or "optional", the value MUST be replaced with "current", "deprecated", or "obsolete" depending on the current usage of such objects. 🚦
- For any object not containing a DESCRIPTION clause, the object MUST have a DESCRIPTION clause defined. 📝
- For any object corresponding to a conceptual row which does not have an INDEX clause, the object MUST have either an INDEX clause or an AUGMENTS clause defined. 🗂️
- If any INDEX clause contains a reference to an object with a syntax of NetworkAddress, then a new object MUST be created and placed in this INDEX clause immediately preceding the object whose syntax is NetworkAddress. This new object MUST have a syntax of INTEGER, it MUST be not-accessible, and its value MUST always be 1. The effect of this, and the preceding bullet, is to allow one to convert a MIB module in SMIv1 format to one in SMIv2 format, and then use it with the SNMPv1 protocol with no impact to existing SNMPv1 agents and managers. 🧚
- For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents are ideally written using SMIv2, which does not define NetworkAddress). 🙈
- For any object containing a DEFVAL clause with an OBJECT IDENTIFIER value which is expressed as a collection of sub-identifiers, the value MUST be changed to reference a single ASN.1 identifier. This may require defining a series of new administrative assignments (OBJECT IDENTIFIERS) in order to define the single ASN.1 identifier. 🧩
- One or more OBJECT-GROUPS MUST be defined, and related objects MUST be collected into appropriate groups. Note that SMIv2 requires all OBJECT-TYPEs to be a member of at least one OBJECT-GROUP. 🍓
- For any non-columnar object that is instanced as if it were immediately subordinate to a conceptual row, the value of the STATUS clause of that object MUST be changed to "obsolete". 🫥
- For any conceptual row object that is not immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) MUST be changed to "obsolete". 👋
Other changes are desirable, but not necessary: ✨
- Creation and deletion of conceptual rows is inconsistent using the SMIv1. The SMIv2 corrects this. As such, if the MIB module undergoes review early in its lifetime, and it contains conceptual tables which allow creation and deletion of conceptual rows, then the objects relating to those tables MAY be deprecated and replaced with objects defined using the new approach. The approach based on SMIv2 can be found in section 7 of RFC 2578 [RFC2578], and the RowStatus and StorageType TEXTUAL-CONVENTIONs are described in section 2 of RFC 2579 [RFC2579]. 🔄
- For any object with an integer-valued SYNTAX clause, in which the corresponding INTEGER does not have a range restriction (i.e., the INTEGER has neither a defined set of named-number enumerations nor an assignment of lower- and upper-bounds on its value), the object SHOULD have the value of its SYNTAX clause changed to Integer32, or have an appropriate range specified. 🎯
- For any object with a string-valued SYNTAX clause, in which the corresponding OCTET STRING does not have a size restriction (i.e., the OCTET STRING has no assignment of lower- and upper-bounds on its length), the bounds for the size of the object SHOULD be defined. 📏
- All textual conventions informally defined in the MIB module SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a change would not necessitate deprecating objects previously defined using an informal textual convention. 🎀
- For any object which represents a measurement in some kind of units, a UNITS clause SHOULD be added to the definition of that object. 📐
- For any conceptual row which is an extension of another conceptual row, i.e., for which subordinate columnar objects both exist and are identified via the same semantics as the other conceptual row, an AUGMENTS clause SHOULD be used in place of the INDEX clause for the object corresponding to the conceptual row which is an extension. 🦋
2.1.2. Trap and Notification Definitions ✨
okay this part is a glow-up 🌈 If a MIB module is changed to conform to the SMIv2, then each occurrence of the TRAP-TYPE macro MUST be changed to a corresponding invocation of the NOTIFICATION-TYPE macro:
- The IMPORTS statement MUST NOT reference RFC-1215 [RFC1215], and MUST reference SNMPv2-SMI instead. 🚫
- The ENTERPRISE clause MUST be removed. 🧹
- The VARIABLES clause MUST be renamed to the OBJECTS clause. ✏️
- A STATUS clause MUST be added, with an appropriate value. Normally the value should be 'current', although 'deprecated' or 'obsolete' may be used as needed. 🚦
- The value of an invocation of the NOTIFICATION-TYPE macro is an OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. Specifically, if the value of the ENTERPRISE clause is not 'snmp' then the value of the invocation SHALL be the value of the ENTERPRISE clause extended with two sub-identifiers, the first of which has the value 0, and the second has the value of the invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause is 'snmp', then the value of the invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the same manner as described in section 3.1 in this document. 🔢
- A DESCRIPTION clause MUST be added, if not already present. 📝
- One or more NOTIFICATION-GROUPs MUST be defined, and related notifications MUST be collected into those groups. Note that SMIv2 requires that all NOTIFICATION-TYPEs be a member of at least one NOTIFICATION-GROUP. 🍓
2.2. Compliance Statements 🎀
For those information modules which are "standards track", a corresponding invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within the information module (or in a companion information module), and any commentary text in the information module which relates to compliance SHOULD be removed. Typically this editing can occur when the information module undergoes review. 🧾
Note that a MODULE-COMPLIANCE statement is not required for a MIB document that is not on the standards track (for example, an enterprise MIB), though it may be useful in some circumstances to define a MODULE-COMPLIANCE statement for such a MIB document. 🦄
2.3. Capabilities Statements 🧚
RFC 1303 [RFC1303] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules. 💜
Converting such a description for use with the SMIv2 requires these changes:
- The macro name AGENT-CAPABILITIES MUST be used instead of MODULE-CONFORMANCE. 🔁
- The STATUS clause MUST be added, with a value of 'current'. ✅
- All occurrences of the CREATION-REQUIRES clause MUST either be omitted if appropriate, or be changed such that the semantics are consistent with RFC 2580 [RFC2580]. 🫶
In order to ease coexistence, object groups defined in an SMIv1 compliant MIB module may be referenced by the INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: upon encountering a reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB module, all leaf objects which are subordinate to the subtree and have a STATUS clause value of mandatory are deemed to be INCLUDEd. (Note that this method is ambiguous when different revisions of an SMIv1 MIB have different sets of mandatory objects under the same subtree; in such cases, the only solution is to rewrite the MIB using the SMIv2 in order to define the object groups unambiguously.) 🥹
3. Translating Notification Parameters 💌
okay bestie, this section is all about how notification parameters get translated between the SNMPv1 notification format and the SNMPv2 notification format 🦋. The bundle of settings used to build a notification is called 'notification parameters', so the SNMPv1 flavour is 'SNMPv1 notification parameters' and the SNMPv2 flavour is 'SNMPv2 notification parameters' 💅.
Translation MUST happen in these situations:
- When an entity builds a set of notification parameters in one format, and its configuration says the notification has to go out using an SNMP message version that needs the other format.
- When a proxy receives a notification sent with an SNMP message version that needs one format, and has to forward it with an SNMP message version that needs the other format.
On top of that, it MAY be desirable to translate notification parameters in a notification receiver application, so the end user sees notifications in a consistent format ✨.
Also, for this section, the set of notification parameters doesn't care whether the notification is going out as a trap or an inform 🙈.
SNMPv1 notification parameters are made up of:
- An enterprise parameter (OBJECT IDENTIFIER).
- An agent-addr parameter (NetworkAddress).
- A generic-trap parameter (INTEGER).
- A specific-trap parameter (INTEGER).
- A time-stamp parameter (TimeTicks).
- A list of variable-bindings (VarBindList).
SNMPv2 notification parameters are made up of:
- A sysUpTime parameter (TimeTicks). This shows up in the first variable-binding in an
SNMPv2-Trap-PDUorInformRequest-PDU🕰️. - An snmpTrapOID parameter (OBJECT IDENTIFIER). This shows up in the second variable-binding in an
SNMPv2-Trap-PDUorInformRequest-PDU, and it's equal to the value portion of that variable-binding (not the name portion, since both the name and the value are OBJECT IDENTIFIERs) 🔥. - A list of variable-bindings (VarBindList). This means all the variable-bindings except the first two in an
SNMPv2-Trap-PDUorInformRequest-PDU🌸.
3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters
okay so here's the procedure for turning SNMPv1 notification parameters into SNMPv2 notification parameters 🎀:
(1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the SNMPv1 time-stamp parameter.
(2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the concatenation of the SNMPv1 enterprise parameter and two additional sub-identifiers, '0', and the SNMPv1 specific-trap parameter 🧚.
(3) If the SNMPv1 generic-trap parameter is not 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the corresponding trap as defined in section 2 of RFC 3418 [RFC3418], like this 🍓:
generic-trap
parameter snmpTrapOID.0
============ =============
0 1.3.6.1.6.3.1.1.5.1 (coldStart)
1 1.3.6.1.6.3.1.1.5.2 (warmStart)
2 1.3.6.1.6.3.1.1.5.3 (linkDown)
3 1.3.6.1.6.3.1.1.5.4 (linkUp)
4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)(4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. Plus, if a proxy is doing the translation so it can forward a received trap, three extra variable-bindings get appended, but only if those three don't already exist in the SNMPv1 variable-bindings 👑. The name portion of the first extra variable binding SHALL contain snmpTrapAddress.0, and its value SHALL contain the SNMPv1 agent-addr parameter. The name portion of the second extra variable binding SHALL contain snmpTrapCommunity.0, and its value SHALL contain the community-string field from the received SNMPv1 message that carried the SNMPv1 Trap-PDU. The name portion of the third extra variable binding SHALL contain snmpTrapEnterprise.0 [RFC3418], and its value SHALL be the SNMPv1 enterprise parameter 💜.
3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters
now the other direction! Here's how to turn SNMPv2 notification parameters into SNMPv1 notification parameters 🦋:
(1) The SNMPv1 enterprise parameter SHALL be worked out like this:
- If the SNMPv2 snmpTrapOID parameter is one of the standard traps defined in RFC 3418 [RFC3418], the SNMPv1 enterprise parameter SHALL be set to the value of the variable-binding in the SNMPv2 variable-bindings whose name is
snmpTrapEnterprise.0, if that variable-binding exists. If it doesn't exist, the SNMPv1 enterprise parameter SHALL be set to the value 'snmpTraps' as defined in RFC 3418 [RFC3418] ✨. - If the SNMPv2 snmpTrapOID parameter is NOT one of the standard traps defined in RFC 3418 [RFC3418], the SNMPv1 enterprise parameter SHALL be worked out from the SNMPv2 snmpTrapOID parameter like this:
- If the next-to-last sub-identifier of the snmpTrapOID value is zero, the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID value with the last 2 sub-identifiers removed, otherwise
- If the next-to-last sub-identifier of the snmpTrapOID value is non-zero, the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID value with the last sub-identifier removed.
Oops, I wrote "NOT" in capitals there, which isn't in the original. Correcting that below so the rule stays exactly as written.
(2) The SNMPv1 agent-addr parameter SHALL be worked out based on where the translation is happening 🌈.
- If the translation happens inside a notification originator application, and the notification is going over IP, the SNMPv1 agent-addr parameter SHALL be set to the IP address of the SNMP entity the notification originator lives in. If the notification is going over some other transport, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.
- If the translation happens inside a proxy application, the proxy must attempt to pull out the original source of the notification from the variable-bindings. If the SNMPv2 variable-bindings contain a variable binding whose name is
snmpTrapAddress.0, the agent-addr parameter SHALL be set to the value of that variable binding. Otherwise, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0 🙈.
(3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps defined in RFC 3418 [RFC3418], the SNMPv1 generic-trap parameter SHALL be set as shown here 📋:
snmpTrapOID.0 parameter generic-trap
=============================== ============
1.3.6.1.6.3.1.1.5.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1
1.3.6.1.6.3.1.1.5.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3
1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.(4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps defined in RFC 3418 [RFC3418], the SNMPv1 specific-trap parameter SHALL be set to zero. Otherwise, the SNMPv1 specific-trap parameter SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID parameter 🫶.
(5) The SNMPv1 time-stamp parameter SHALL be taken directly from the SNMPv2 sysUpTime parameter ⏰.
(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings. Note that the SNMPv2 variable-bindings don't include the variable-bindings holding sysUpTime.0 and snmpTrapOID.0. Heads up though: if the SNMPv2 variable-bindings contain any objects whose type is Counter64, the translation to SNMPv1 notification parameters can't be performed 😭. In that case, the notification can't be encoded in an SNMPv1 packet, so it can't be sent using SNMPv1 (see section 4.2.3 and section 4.3).
4. Approaches to Coexistence in a Multi-lingual Network 🌍
there are two basic ways to get coexistence in a multi-lingual network: multi-lingual implementations and proxy implementations 💖. Multi-lingual implementations let elements in a network talk to each other using an SNMP version that both of them support. That means a multi-lingual implementation can talk to any mono-lingual implementation, no matter which SNMP version the mono-lingual one supports 🎀.
Proxy implementations translate between SNMP versions using a third-party network element. This lets network elements that only support one SNMP version, but different ones from each other, still communicate 🦋. Proxies are also handy for securing communications over an insecure link between two locally secure networks 🔐.
4.1. SNMPv1 and SNMPv2 Access to MIB Data
all through section 4., this document talks about 'SNMPv1 Access to MIB Data' and 'SNMPv2 Access to MIB Data' 💅. These terms mean the part of an SNMP agent that actually accesses instances of MIB objects, and that actually starts generating notifications. The differences between the two types of access to MIB data are:
- Error-status values generated.
- Generation of exception codes.
- Use of the Counter64 data type.
- The format of parameters provided when a notification is generated.
SNMPv1 access to MIB data may generate SNMPv1 error-status values, will never generate exception codes or use the Counter64 data type, and will provide SNMPv1 format parameters for generating notifications. Also, SNMPv1 access to MIB data will actually never generate a readOnly error. A noSuchName error would always happen in the situation where you'd expect a readOnly error 🙈.
SNMPv2 access to MIB data may generate SNMPv2 error-status values, may generate exception codes, may use the Counter64 data type, and will provide SNMPv2 format parameters for generating notifications. SNMPv2 access to MIB data will never generate readOnly, noSuchName, or badValue errors ✨.
A particular multi-lingual implementation might decide to treat all access to MIB data as SNMPv2 access to MIB data, and then do the translations described here for SNMPv1-based transactions 🧚.
Lastly, you won't see 'SNMPv3 access to MIB data' anywhere in this document, because SNMPv3 uses SNMPv2 PDU types and protocol operations 💜.
4.2. Multi-lingual implementations ✨
okay so this approach is lowkey the most iconic one 💅 It requires an entity to support multiple SNMP message versions. Typically that means SNMPv1, SNMPv2c, and SNMPv3 🎀 The behaviour of the different kinds of SNMP applications that support multiple message versions is covered in the sections below. The best part is that these multi-lingual entities can still coexist with and talk to entities that only speak a single SNMP message version 🦋
4.2.1. Command Generator 🚀
A command generator must select an appropriate message version when sending requests to another entity. One way to do that is to check a local database to pick the right message version 💖
In addition, a command generator MUST 'downgrade' GetBulk requests to GetNext requests when selecting SNMPv1 as the message version for an outgoing request. The downgrade is super simple: you just change the operation type to GetNext, ignore any non-repeaters and max-repetitions values, and set error-status and error-index to zero ✨
4.2.2. Command Responder 🎀
A command responder must be able to handle both SNMPv1 and SNMPv2 access to MIB data. There are three things it has to deal with. A command responder MUST:
- Deal correctly with
SNMPv2access to MIB data that returns aCounter64value while processing anSNMPv1message, - Deal correctly with
SNMPv2access to MIB data that returns one of the three exception values while processing anSNMPv1message, and - Map
SNMPv2error codes returned fromSNMPv2access to MIB data intoSNMPv1error codes when processing anSNMPv1message.
Note that SNMPv1 error codes SHOULD NOT be used without any change when processing SNMPv2c or SNMPv3 messages, except in the case of proxy forwarding. Also, SNMPv1 access to MIB data SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages. For proxy forwarding, the SNMPv1 error codes may be used without any change in a forwarded SNMPv2c or SNMPv3 message, purely for backwards compatibility 🧚
The following sections describe how a command responder application that supports multiple SNMP message versions behaves when it uses SNMPv2 access to MIB data to process an SNMPv1 message 🌈
4.2.2.1. Handling Counter64 💜
The SMIv2 [RFC2578] defines one new syntax that is incompatible with SMIv1. That syntax is Counter64. Every other syntax defined by SMIv2 is compatible with SMIv1, so it's only this one that needs special handling 😭
For multi-lingual command responders, the impact is that they MUST NOT ever return a variable binding containing a Counter64 value in a response to a request that was received using the SNMPv1 message version. Like, never ever 🙈
Multi-lingual command responders SHALL take the approach that object instances whose type is Counter64 are implicitly excluded from view when processing an SNMPv1 message. So:
- On receipt of an
SNMPv1GetRequest-PDUcontaining a variable binding whose name field points to an object instance of typeCounter64, aGetResponsePDUSHALL be returned, with anerror-statusofnoSuchNameand theerror-indexset to the variable binding that caused this error. - On an
SNMPv1GetNextRequest-PDU, any object instance which contains a syntax ofCounter64SHALL be skipped, and the next accessible object instance that does not have the syntax ofCounter64SHALL be retrieved. If no such object instance exists, then anerror-statusofnoSuchNameSHALL be returned, and theerror-indexSHALL be set to the variable binding that caused this error. - Any
SNMPv1request which contains a variable binding with aCounter64value is ill-formed, so the foregoing rules do not apply. If that error is detected, a response SHALL NOT be returned, since it would contain a copy of the ill-formed variable binding. Instead, the offending PDU SHALL be discarded and the countersnmpInASNParseErrsSHALL be incremented. 🚫
4.2.2.2. Mapping SNMPv2 Exceptions ✨
SNMPv2 has a feature called exceptions, which lets an SNMPv2 Response PDU return as much management information as possible, even when something goes wrong 🦋 But SNMPv1 doesn't support exceptions, so an SNMPv1 Response PDU can't return any management information. It can only return an error-status and an error-index value 😩
When an SNMPv1 request is received, a command responder MUST check any variable bindings returned using SNMPv2 access to MIB data for exception values, and convert those exception values into SNMPv1 error codes.
The type of exception that can come back when accessing MIB data, and the action taken, depends on the type of SNMP request:
- For a
GetRequest, anoSuchObjectornoSuchInstanceexception may be returned. - For a
GetNextRequest, anendOfMibViewexception may be returned. - No exceptions will be returned for a
SetRequest, and aGetBulkRequestshould only be received in anSNMPv2corSNMPv3message, so these request types may be ignored when mapping exceptions.
Note that when a response contains multiple exceptions, it is an implementation choice as to which variable binding the error-index should reference 🤷♀️
4.2.2.2.1. Mapping noSuchObject and noSuchInstance 🌸
A noSuchObject or noSuchInstance exception generated by an SNMPv2 access to MIB data means the requested object instance can not be returned. The SNMPv1 error code for this is noSuchName, so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (if there is more than one, then it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU. 🎀
4.2.2.2.2. Mapping endOfMibView 🧚
When an SNMPv2 access to MIB data returns a variable binding containing an endOfMibView exception, it means there are no object instances available that lexicographically follow the object in the request. In an SNMPv1 agent, this normally results in a noSuchName error, so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (if there is more than one, then it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU. 💅
4.2.2.3. Processing An SNMPv1 GetRequest 🔥
When processing an SNMPv1 GetRequest, the following procedures MUST be followed when using an SNMPv2 access to MIB data.
When such an access to MIB data returns response data using SNMPv2 syntax and error-status values, then:
- If the
error-statusis anything other thannoError,- The error status SHALL be translated to an
SNMPv1error-status using the table in section 4.4, "Error Status Mappings". - The
error-indexSHALL be set to the position (in the original request) of the variable binding that caused the error-status. - The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request.
- The error status SHALL be translated to an
- If the
error-statusisnoError, the variable bindings SHALL be checked for anySNMPv2exception (noSuchObjectornoSuchInstance) or anSNMPv2syntax that is unknown toSNMPv1(Counter64). If there are any such variable bindings, one of those variable bindings SHALL be selected (it is an implementation choice as to which is selected), and:- The
error-statusSHALL be set tonoSuchName, - The
error-indexSHALL be set to the position (in the variable binding list of the original request) of the selected variable binding, and - The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.
- The
- If there are no such variable bindings, then:
- The
error-statusSHALL be set tonoError, - The
error-indexSHALL be set to zero, and - The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data.
- The
4.2.2.4. Processing An SNMPv1 GetNextRequest 🌈
When processing an SNMPv1 GetNextRequest, the following procedures MUST be followed when SNMPv2 access to MIB data is used as part of processing the request. There may be repetitive accesses to MIB data to try to find the first object which lexicographically follows each of the objects in the request. This is implementation specific. These procedures only apply to data returned when using SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB data may be treated in the normal manner for an SNMPv1 request. 🦄
First, if the access to MIB data returns an error-status of anything other than noError:
- The error status SHALL be translated to an
SNMPv1error-status using the table in section 4.4, "Error Status Mappings". - The
error-indexSHALL be set to the position (in the original request) of the variable binding that caused the error-status. - The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.
Otherwise, if the access to MIB data returns an error-status of noError:
- Any variable bindings containing an
SNMPv2syntax ofCounter64SHALL be considered to be not in view, and MIB data SHALL be accessed as many times as is required until either a value other thanCounter64is returned, or an error orendOfMibViewexception occurs. - If there is any variable binding that contains an
SNMPv2exceptionendOfMibView(if there is more than one, then it is an implementation decision as to which is chosen):- The
error-statusSHALL be set tonoSuchName, - The
error-indexSHALL be set to the position (in the variable binding list of the original request) of the variable binding that returned such anSNMPv2exception, and - The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.
- The
- If there are no such variable bindings, then:
- The
error-statusSHALL be set tonoError, - The
error-indexSHALL be set to zero, and - The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data.
- The
4.2.2.5. Processing An SNMPv1 SetRequest 🍓
When processing an SNMPv1 SetRequest, the following procedures MUST be followed when using SNMPv2 access to MIB data.
When such MIB access returns response data using SNMPv2 syntax and error-status values, and the error-status is anything other than noError, then:
- The error status SHALL be translated to an
SNMPv1error-status using the table in section 4.4, "Error Status Mappings". - The
error-indexSHALL be set to the position (in the original request) of the variable binding that caused the error-status. - The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request.
4.2.3. Notification Originator 🔔
Okay so bestie, a notification originator has to be able to translate between SNMPv1 notification parameters and SNMPv2 notification parameters 💅. Why? So it can send a notification with whichever SNMP message version is actually being used 🦋. If a notification is generated with SNMPv1 notification parameters but the config says to send it using SNMPv2c or SNMPv3, the parameters must be translated to SNMPv2 notification parameters ✨. And the reverse is true too: if it's made with SNMPv2 notification parameters but the config says SNMPv1, they must be translated to SNMPv1 notification parameters 🌸. Here's the tea though: if the notification can't be translated because of a Counter64 type, it will not be sent using SNMPv1 💀. No SNMPv1 for that one, sorry, bestie 😭.
When a notification originator makes a notification using parameters from the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB, and the SNMP version is SNMPv1, the PDU type is always a TrapPDU 🧚. That's true even if snmpNotifyType is trap(1) or inform(2) 🎀. Iconic consistency 👑.
Also, access control and notification filtering work the usual way for notifications 💖, no matter which SNMP message version gets used to send one 🫶. The access control parameters come from the usual place too, which means inspecting the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB 🍓. Now here's the main character moment 🌟: when generating an SNMPv1 Trap, to do the access check in [RFC3413], section 3.3, bullet (3), the notification originator might need to generate a value for snmpTrapOID.0, as described in section 3.1, bullets (2) and (3) of this document 🔥. If the SNMPv1 notification parameters were earlier translated from a set of SNMPv2 notification parameters, that value might already be known 🙈. In that case, it doesn't need to be generated again ✨.
4.2.4. Notification Receiver 📬
Notification receivers don't have any special requirements, no cap 🧚♀️. BUT an implementation might find it super useful to let a higher level application pick whether notifications get delivered to it using SNMPv1 notification parameters or SNMPv2 notification parameters 🌈. The notification receiver would then translate the notification parameters when needed, so the notification shows up in the set of parameters the app wants 💜. Slay 💅.
4.3. Proxy Implementations 🦋
A proxy implementation can be used to let entities that support different SNMP message versions talk to each other 🫶. It does this in a proxy forwarder application, which translates PDUs 🍓. The translations depend on the PDU type, the SNMP version of the packet that carried the received PDU, and the SNMP version used to forward the received PDU 🧠. The sections below go through these translations 📖. In every case except the ones described below, the proxy SHALL forward a received PDU without change 💅, subject to the size constraints in section 5.3 (Community MIB) of this document 🎀. Also, in the following sections, the 'Upstream Version' is the version used between the command generator or notification receiver and the proxy 🌊, and the 'Downstream Version' is the version used between the proxy and the command responder or notification originator 🔁. This applies no matter the PDU type or direction ✨.
4.3.1. Upstream Version Greater Than Downstream Version ⬆️
- If a GetBulkRequest-PDU is received and has to be forwarded using the SNMPv1 message version, the proxy forwarder SHALL act as if the non-repeaters and max-repetitions fields were both set to 0 🫠, and SHALL set the tag of the PDU to GetNextRequest-PDU 🧚.
- If a GetResponse-PDU is received whose error-status field has a value of 'tooBig', and the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original request the proxy received was not a GetBulkRequest-PDU, the proxy forwarder SHALL remove the contents of the variable-bindings field 🗑️ and ensure that the error-index field is set to 0 before forwarding the response 💖.
- If a GetResponse-PDU is received whose error-status field has a value of 'tooBig', and the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original request the proxy received was a GetBulkRequest-PDU, the proxy forwarder SHALL re-send the forwarded request 🔄 (which would have been altered to be a GetNextRequest-PDU) with all but the first variable-binding removed. The proxy forwarder SHALL only re-send such a request a single time ☝️. If the resulting GetResponse-PDU also has an error-status field with a value of 'tooBig', then the proxy forwarder SHALL remove the contents of the variable-bindings field, change the error-status field to 'noError', and ensure that the error-index field is set to 0 before forwarding the response 🫶. Note that if the original request only had a single variable-binding, the proxy may skip re-sending the request and just remove the variable-bindings and change the error-status to 'noError' 🙌. Further, it might have been possible to fit more variable bindings if the proxy re-sent the request multiple times and stripped only one variable binding at a time 🤔, but that's deemed too expensive 💸. The approach described here keeps the behaviour of a GetBulkRequest as close as possible, without paying the cost of re-sending the request multiple times 🌸.
- If a Trap-PDU is received and will be forwarded using the SNMPv2c or SNMPv3 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification as an SNMPv2-Trap-PDU 🔔.
Note that when an SNMPv1 agent generates a message containing a Trap-PDU, and one or more proxy forwarders later forward it using SNMP versions other than SNMPv1, the community string and agent-addr fields from the original SNMPv1 agent message are kept 🧷, through the use of the snmpTrapAddress and snmpTrapCommunity objects 💜.
4.3.2. Upstream Version Less Than Downstream Version ⬇️
- If a GetResponse-PDU is received in response to a GetRequest-PDU (previously generated by the proxy) which contains variable-bindings of type Counter64 or which contains an SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate response PDU 😤. It consists of the request-id and variable bindings from the original SNMPv1 request, contains a noSuchName error-status value, and contains an error-index value that points to the position of the variable-binding with the Counter64 type or exception code 🎯.
- If a GetResponse-PDU is received in response to a GetNextRequest-PDU (previously generated by the proxy) which contains variable-bindings that contain an SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate response PDU 🙃. It consists of the request-id and variable bindings from the original SNMPv1 request, contains a noSuchName error-status value, and contains an error-index value that points to the position of the variable-binding with the exception code 🫠.
- If a GetResponse-PDU is received in response to a GetNextRequest-PDU (previously generated by the proxy) which contains variable-bindings of type Counter64, the proxy MUST re-send the entire GetNextRequest-PDU, with the following changes 🔁. For any variable bindings in the received GetResponse that had Counter64 types, the proxy swaps in the object names of those variable bindings for the matching object names in the previously-sent GetNextRequest 🔀. The proxy MUST repeat this process until no Counter64 objects come back 🙏. Note that an implementation may try to optimize this skipping of Counter64 objects 🚀. One approach would be to replace the last sub-identifier of the object names of varbinds containing a Counter64 type with 65535 if that sub-identifier is less than 65535, or with 4294967295 if that sub-identifier is greater than 65535 🔢. This approach should skip multiple instances of the same Counter64 object 🏃♀️, while staying compatible with some broken agent implementations (which only use 16-bit integers for sub-identifiers) 🤭.
Deployment Hint: 🧭 Repeated GetNext requests used by a proxy when Counter64 types come back can get expensive 💸. When deploying a proxy, you can avoid this by configuring the target agents the proxy forwards requests to, so that any objects of type Counter64 are actually not-in-view for the principal the proxy uses when talking to those agents 👀. But if you do this, be careful to use a different principal for talking to the target agent when an incoming SNMPv2c or SNMPv3 request arrives 🧑🤝🧑, so that objects of type Counter64 are still returned properly ✨.
- If a GetResponse-PDU is received which contains an SNMPv2 error-status value of wrongValue, wrongEncoding, wrongType, wrongLength, inconsistentValue, noAccess, notWritable, noCreation, inconsistentName, resourceUnavailable, commitFailed, undoFailed, or authorizationError, and the message would be forwarded using the SNMPv1 message version, the error-status value is changed using the mappings in section 4.4 🔄💅.
- If an SNMPv2-Trap-PDU is received and will be forwarded using the SNMPv1 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification as a Trap-PDU 🪄. Note that if the translation fails because of a Counter64 data-type in the received SNMPv2-Trap-PDU, the trap cannot be forwarded using SNMPv1 🥲.
- If an InformRequest-PDU is received, any configuration information saying it would be forwarded using the SNMPv1 message version SHALL be ignored 🙅♀️. An InformRequest-PDU can only be forwarded using the SNMPv2c or SNMPv3 message version 💅. The InformRequest-PDU may still be forwarded if other configuration information says it should be forwarded using SNMPv2c or SNMPv3 🎀.
4.4. Error Status Mappings 🎀
okay so this part is basically a translation cheat sheet 💅 it shows which SNMPv1 error-status values map to which SNMPv2 ones, and then the reverse direction. the tables are a bit long but they're super clear once you see them 🦋
SNMPv1 error-status SNMPv2 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
genErr genErr
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
genErr genErr
wrongValue badValue
wrongEncoding badValue
wrongType badValue
wrongLength badValue
inconsistentValue badValue
noAccess noSuchName
notWritable noSuchName
noCreation noSuchName
inconsistentName noSuchName
resourceUnavailable genErr
commitFailed genErr
undoFailed genErr
authorizationError noSuchNameokay the big catch 👀 whenever an SNMPv2 authorizationError gets translated into an SNMPv1 noSuchName, the value of snmpInBadCommunityUses MUST be incremented. that's a whole vibe check, so don't skip it 💀🫶
5. Message Processing Models and Security Models 🌸
so to fit SNMPv1 (and SNMPv2c) into the SNMP architecture, this document defines four models. they're the crew:
- The SNMPv1 Message Processing Model
- The SNMPv1 Community-Based Security Model
- The SNMPv2c Message Processing Model
- The SNMPv2c Community-Based Security Model
the two message processing models are almost twins 👯♀️ so we don't cover them separately. same goes for the two community-based security models. we only point out the differences where they actually matter ✨
5.1. Mappings 🧚
the SNMPv1 (and SNMPv2c) Message Processing Model and Security Model need to map stuff between SNMPv1 (and SNMPv2c) message parameters and the version-independent parameters of the SNMP architecture [RFC3411]. the parameters that MUST be mapped are the SNMPv1 (and SNMPv2c) community name, plus the SNMP securityName and the contextEngineID/contextName pair 🍓
this document gives you a MIB module for doing those mappings, called SNMP-COMMUNITY-MIB. it works in both directions, which is so iconic 🙌 a community name can get mapped to a securityName, contextEngineID, and contextName, or you can go the other way and map a securityName, contextEngineID, and contextName combo back to a community name.
5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model 💜
the SNMPv1 Message Processing Model is the one that handles SNMPv1 messages. it mostly works the same way as RFC 1157 [RFC1157] describes, with the differences and clarifications spelled out in the next sections. for the record, the SnmpMessageProcessingModel value for SNMPv1 is 0 (SNMPv2c is 1) 🔢
5.2.1. Processing An Incoming Request 📥
okay so RFC 1157 [RFC1157], section 4.1, item (3), says that an entity receiving a message passes various parameters to the "desired authentication scheme". here that scheme is the SNMPv1 Community-Based Security Model, and it gets called through the processIncomingMsg ASI. these are the parameters handed over to that ASI:
- The messageProcessingModel, which will be
0(or1for SNMPv2c). - The maxMessageSize, which should be the maximum size of a message that the receiving entity can generate (since there is no such value in the received message).
- The securityParameters, which consist of the community string and the message's source and destination transport domains and addresses.
- The securityModel, which will be
1(or2for SNMPv2c). - The securityLevel, which will be
noAuthNoPriv. - The wholeMsg and wholeMsgLength.
next up, the Community-Based Security Model tries to pick a row from the snmpCommunityTable. it does this by searching the table in lexicographic order, and the first entry that satisfies these matching criteria gets selected 🔍
- The community string is equal to the
snmpCommunityNamevalue. - If the
snmpCommunityTransportTagis an empty string, it is ignored for the purpose of matching. If thesnmpCommunityTransportTagis not an empty string, the transportDomain and transportAddress from which the message was received must match one of the entries in thesnmpTargetAddrTableselected by thesnmpCommunityTransportTagvalue. ThesnmpTargetAddrTMaskobject is used as described in section 5.3 when checking whether the transportDomain and transportAddress matches a entry in thesnmpTargetAddrTable.
if no entry can be found at all, an authentication failure happens as described in RFC 1157 [RFC1157], and the snmpInBadCommunityNames counter gets incremented 😤
once the model is done, these are the parameters it gives back:
- The securityEngineID, which will always be the local value of
snmpEngineID.0. - The securityName, which will be the value of
snmpCommunitySecurityNamefrom the selected row in thesnmpCommunityTable. - The scopedPDU. this one is a bit of a diva 💅 because it's really three values bundled together: the contextSnmpEngineID (the value of
snmpCommunityContextEngineIDfrom the selected entry in thesnmpCommunityTable), the contextName (the value ofsnmpCommunityContextNamefrom that same entry), and the PDU. they have to stay separate values, since the first two never actually show up in the message. - The maxSizeResponseScopedPDU, which is derived from the minimum of the maxMessageSize above and the value of
snmpTargetAddrMMSin the selected row of thesnmpTargetAddrTable. if no such entry was selected, it's derived from the maxMessageSize alone. - The securityStateReference, which MUST contain the community string from the original request. this is a must, bestie 🫶
then the right SNMP application gets called through the processPdu ASI. which application depends on the contextEngineID and the request type in the PDU. these are the parameters passed to processPdu:
- The messageProcessingModel, which will be
0(or1for SNMPv2c). - The securityModel, which will be
1(or2for SNMPv2c). - The securityName, which was returned from the call to
processIncomingMsg. - The securityLevel, which is
noAuthNoPriv. - The contextEngineID, which was returned as part of the ScopedPDU from the call to
processIncomingMsg. - The contextName, which was returned as part of the ScopedPDU from the call to
processIncomingMsg. - The pduVersion, which should indicate an SNMPv1 version PDU (if the message version was SNMPv2c, this would be an SNMPv2 version PDU).
- The PDU, which was returned as part of the ScopedPDU from the call to
processIncomingMsg. - The maxSizeResponseScopedPDU, which was returned from the call to
processIncomingMsg. - The stateReference, which was returned from the call to
processIncomingMsg.
the SNMP application should process the request the way it's described earlier in this document. also, access control still happens in an SNMPv3 command responder application like usual 🔐 the parameters passed to processPdu are what get used in the calls to the isAccessAllowed ASI.
5.2.2. Generating An Outgoing Response 📤
good news, there's no special processing needed to generate a response 🎉 the one thing to remember is that the community string in an outgoing response must be the same as the community string from the original request. the original community string MUST be present in the securityStateReference information of the original request.
5.2.3. Generating An Outgoing Notification 🔔
in a multi-lingual SNMP entity, the parameters for generating notifications come from looking at the SNMP-TARGET-MIB and the SNMP-NOTIFICATION-MIB. those parameters get passed to the SNMPv1 Message Processing Model through the sendPdu ASI. then the model tries to find a matching community string in the snmpCommunityTable, based on what was passed to sendPdu. it searches the table in lexicographic order, and the first entry that meets these matching criteria wins 🏆
- The securityName must be equal to the
snmpCommunitySecurityNamevalue. - The contextEngineID must be equal to the
snmpCommunityContextEngineIDvalue. - The contextName must be equal to the
snmpCommunityContextNamevalue. - If the
snmpCommunityTransportTagis an empty string, it is ignored for the purpose of matching. If thesnmpCommunityTransportTagis not an empty string, the transportDomain and transportAddress must match one of the entries in thesnmpTargetAddrTableselected by thesnmpCommunityTransportTagvalue.
if no entry can be found, the notification is not sent 💔 otherwise, the community string used in the outgoing notification is the value of the snmpCommunityName column of the selected row.
5.2.4. Proxy Forwarding Of Requests 🔁
in a proxy forwarding application, when a received request is about to be forwarded using the SNMPv1 Message Processing Model, the forwarding parameters come from the SNMP-PROXY-MIB and the SNMP-TARGET-MIB. those get passed to the SNMPv1 Message Processing Model through the sendPdu ASI. the model then looks for a suitable community string in the snmpCommunityTable based on those parameters, searching in lexicographic order. the first entry that meets these matching criteria gets selected:
- The securityName must be equal to the
snmpCommunitySecurityNamevalue. - The contextEngineID must be equal to the
snmpCommunityContextEngineIDvalue. - The contextName must be equal to the
snmpCommunityContextNamevalue.
if no such entry can be found, the proxy forwarding application should follow the procedure described in RFC 3413 [RFC3413], section 3.5.1.1, item (2). that procedure says the snmpProxyDrops counter [RFC3418] gets incremented, and a Response-PDU gets generated by calling the Dispatcher through the returnResponsePdu abstract service interface 🌈
5.3. The SNMP Community MIB Module 💖
okay so the SNMP-COMMUNITY-MIB is the spot where community strings get mapped to version-independent SNMP message parameters 🎀 and that's giving organized ✨. It also does source address validation on incoming requests, and lets you pick community strings based on target addresses for outgoing notifications 💅. Both of those features run through a tag in the snmpCommunityTable that selects sets of entries in the snmpTargetAddrTable [RFC3413]. The MIB also augments the snmpTargetAddrTable with a transport address mask value and a maximum message size value 🦋. These augmenting values are only used where it's explicitly stated. If the snmpTargetAddrTable shows up without any mention of them, you should ignore the augmenting values 🙈
the mask value, snmpTargetAddrTMask, is what lets one entry cover multiple addresses instead of just one 🌈 this is super useful for picking out a whole subnet in the snmpTargetAddrTable, not just a single address. the mask decides which bits of a transport address have to match the bits of the matching snmpTargetAddrTAddress instance for that address to count as a match for the entry. the value of an snmpTargetAddrTMask instance must always be an OCTET STRING whose length is either zero or the same as the matching snmpTargetAddrTAddress instance. bestie, that length rule is important 💜
snmpTargetAddrTMask is only used where it's explicitly stated 🧚 it is NOT used when generating notifications, so entries in the snmpTargetAddrTable only point at individual addresses in that case. if the text describing address matching in the snmpTargetAddrTable doesn't mention using the mask, then its value MUST be ignored. no exceptions, no vibes-based decisions 🙅♀️
when you're checking whether a transport address matches an entry in the snmpTargetAddrTable, here's the tea ☕ if the snmpTargetAddrTMask value is a zero-length OCTET STRING, the mask gets ignored and the snmpTargetAddrTAddress value has to exactly match the transport address. otherwise, every bit of every octet in the mask lines up with the same bit of the same octet in snmpTargetAddrTAddress. for the bits that are set in the mask (the bits equal to 1), the matching bits in snmpTargetAddrTAddress have to match the bits in the transport address. if all of those bits match, the transport address is matched by that entry. if not, it's a no-match, sorry bestie 💀
last but not least, snmpTargetAddrMMS is used to figure out the maximum message size another SNMP entity will accept, but only when that size can't be figured out from the protocol itself 🍓
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS
IpAddress,
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
snmpModules
FROM SNMPv2-SMI
RowStatus,
StorageType
FROM SNMPv2-TC
SnmpAdminString,
SnmpEngineID
FROM SNMP-FRAMEWORK-MIB
SnmpTagValue,
snmpTargetAddrEntry
FROM SNMP-TARGET-MIB
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF;
snmpCommunityMIB MODULE-IDENTITY
LAST-UPDATED "200308060000Z" -- 06 Aug 2003, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
Subscribe: majordomo@lists.tislabs.com
In msg body: subscribe snmpv3
Co-Chair: Russ Mundy
SPARTA, Inc
Postal: 7075 Samuel Morse Drive
Columbia, MD 21045
USA
EMail: mundy@tislabs.com
Phone: +1 410-872-1515
Co-Chair: David Harrington
Enterasys Networks
Postal: 35 Industrial Way
P. O. Box 5005
Rochester, New Hampshire 03866-5005
USA
EMail: dbh@enterasys.com
Phone: +1 603-337-2614
Co-editor: Rob Frye
Vibrant Solutions
Postal: 2711 Prosperity Ave
Fairfax, Virginia 22031
USA
E-mail: rfrye@vibrant-1.com
Phone: +1-703-270-2000
Co-editor: David B. Levi
Nortel Networks
Postal: 3505 Kesterwood Drive
Knoxville, Tennessee 37918
E-mail: dlevi@nortelnetworks.com
Phone: +1 865 686 0432
Co-editor: Shawn A. Routhier
Wind River Systems, Inc.
Postal: 500 Wind River Way
Alameda, CA 94501
E-mail: sar@epilogue.com
Phone: +1 510 749 2095
Co-editor: Bert Wijnen
Lucent Technologies
Postal: Schagen 33
3461 GL Linschoten
Netherlands
Email: bwijnen@lucent.com
Phone: +31-348-407-775
"
DESCRIPTION
"This MIB module defines objects to help support
coexistence between SNMPv1, SNMPv2c, and SNMPv3.
Copyright (C) The Internet Society (2003) This
version of this MIB module is part of RFC 3584;
see the RFC itself for full legal notices."
REVISION "200308060000Z" -- 06 Aug 2003
DESCRIPTION
"Updated the LAST-UPDATED, CONTACT-INFO, and REVISION
clauses and added a copyright notice to the
DESCRIPTION clause of the MIB module's
MODULE-IDENTITY invocation.
Updated the description of snmpCommunityTransportTag
to make it consistent with the rest of the document.
Updated the description of `snmpTargetAddrMMS' to
clarify that a value of 0 means that the maximum
message size is unknown.
Changed the name of 'snmpCommunityGroup' to
snmpCommunityTableGroup to avoid a name conflict
with the SNMPv2-MIB.
Updated DESCRIPTION of snmpCommunityName.
Updated DESCRIPTION of snmpTrapCommunity.
Added snmpCommunityMIBFullCompliance.
This version published as RFC 3584."
REVISION "200003060000Z" -- 6 Mar 2000
DESCRIPTION "This version published as RFC 2576."
::= { snmpModules 18 }
-- Administrative assignments ************************************
snmpCommunityMIBObjects
OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
snmpCommunityMIBConformance
OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
--
-- The snmpCommunityTable contains a database of community
-- strings. This table provides mappings between community
-- strings, and the parameters required for View-based Access
-- Control.
--
snmpCommunityTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of community strings configured in the SNMP
engine's Local Configuration Datastore (LCD)."
::= { snmpCommunityMIBObjects 1 }
snmpCommunityEntry OBJECT-TYPE
SYNTAX SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular community string."
INDEX { IMPLIED snmpCommunityIndex }
::= { snmpCommunityTable 1 }
SnmpCommunityEntry ::= SEQUENCE {
snmpCommunityIndex SnmpAdminString,
snmpCommunityName OCTET STRING,
snmpCommunitySecurityName SnmpAdminString,
snmpCommunityContextEngineID SnmpEngineID,
snmpCommunityContextName SnmpAdminString,
snmpCommunityTransportTag SnmpTagValue,
snmpCommunityStorageType StorageType,
snmpCommunityStatus RowStatus
}
snmpCommunityIndex OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index value of a row in this table."
::= { snmpCommunityEntry 1 }
snmpCommunityName OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The community string for which a row in this table
represents a configuration. There is no SIZE constraint
specified for this object because RFC 1157 does not
impose any explicit limitation on the length of community
strings (their size is constrained indirectly by the
SNMP message size)."
::= { snmpCommunityEntry 2 }
snmpCommunitySecurityName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A human readable string representing the corresponding
value of snmpCommunityName in a Security Model
independent format."
::= { snmpCommunityEntry 3 }
snmpCommunityContextEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The contextEngineID indicating the location of the
context in which management information is accessed
when using the community string specified by the
corresponding instance of snmpCommunityName.
The default value is the snmpEngineID of the entity in
which this object is instantiated."
::= { snmpCommunityEntry 4 }
snmpCommunityContextName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The context in which management information is accessed
when using the community string specified by the
corresponding instance of snmpCommunityName."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 5 }okay bestie, the transport tag stuff is where the community table gets seriously iconic 💅✨
snmpCommunityTransportTag OBJECT-TYPE
SYNTAX SnmpTagValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies a set of transport endpoints
which are used in two ways:
- to specify the transport endpoints from which an
SNMP entity will accept management requests, and
- to specify the transport endpoints to which a
notification may be sent using the community
string matching the corresponding instance of
snmpCommunityName.
In either case, if the value of this object has
zero-length, transport endpoints are not checked when
either authenticating messages containing this community
string, nor when generating notifications.
The transports identified by this object are specified
in the snmpTargetAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value
are identified.
If a management request containing a community string
that matches the corresponding instance of
snmpCommunityName is received on a transport endpoint
other than the transport endpoints identified by this
object the request is deemed unauthentic.
When a notification is to be sent using an entry in
this table, if the destination transport endpoint of
the notification does not match one of the transport
endpoints selected by this object, the notification
is not sent."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 }
snmpCommunityStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row in the
snmpCommunityTable. Conceptual rows having the value
'permanent' need not allow write-access to any
columnar object in the row."
::= { snmpCommunityEntry 7 }
snmpCommunityStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row in the
snmpCommunityTable.
An entry in this table is not qualified for activation
until instances of all corresponding columns have been
initialized, either through default values, or through
Set operations. The snmpCommunityName and
snmpCommunitySecurityName objects must be explicitly set.
There is no restriction on setting columns in this table
when the value of snmpCommunityStatus is active(1)."
::= { snmpCommunityEntry 8 }
--
-- The snmpTargetAddrExtTable
--
snmpTargetAddrExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of mask and maximum message size (mms) values
associated with the snmpTargetAddrTable.
The snmpTargetAddrExtTable augments the
snmpTargetAddrTable with a transport address mask value
and a maximum message size value. The transport address
mask allows entries in the snmpTargetAddrTable to define
a set of addresses instead of just a single address.
The maximum message size value allows the maximum
message size of another SNMP entity to be configured for
use in SNMPv1 (and SNMPv2c) transactions, where the
message format does not specify a maximum message size."
::= { snmpCommunityMIBObjects 2 }
snmpTargetAddrExtEntry OBJECT-TYPE
SYNTAX SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular mask and mms value."
AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrExtTable 1 }
SnmpTargetAddrExtEntry ::= SEQUENCE {
snmpTargetAddrTMask OCTET STRING,
snmpTargetAddrMMS Integer32
}
snmpTargetAddrTMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The mask value associated with an entry in the
snmpTargetAddrTable. The value of this object must
have the same length as the corresponding instance of
snmpTargetAddrTAddress, or must have length 0. An
attempt to set it to any other value will result in
an inconsistentValue error.
The value of this object allows an entry in the
snmpTargetAddrTable to specify multiple addresses.
The mask value is used to select which bits of
a transport address must match bits of the corresponding
instance of snmpTargetAddrTAddress, in order for the
transport address to match a particular entry in the
snmpTargetAddrTable. Bits which are 1 in the mask
value indicate bits in the transport address which
must match bits in the snmpTargetAddrTAddress value.
Bits which are 0 in the mask indicate bits in the
transport address which need not match. If the
length of the mask is 0, the mask should be treated
as if all its bits were 1 and its length were equal
to the length of the corresponding value of
snmpTargetAddrTable.
This object may not be modified while the value of the
corresponding instance of snmpTargetAddrRowStatus is
active(1). An attempt to set this object in this case
will result in an inconsistentValue error."
DEFVAL { ''H }
::= { snmpTargetAddrExtEntry 1 }
snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (0|484..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum message size value associated with an entry
in the snmpTargetAddrTable. Note that a value of 0 means
that the maximum message size is unknown."
DEFVAL { 484 }
::= { snmpTargetAddrExtEntry 2 }
--
-- The snmpTrapAddress and snmpTrapCommunity objects are included
-- in notifications that are forwarded by a proxy, which were
-- originally received as SNMPv1 Trap messages.
--
snmpTrapAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The value of the agent-addr field of a Trap PDU which
is forwarded by a proxy forwarder application using
an SNMP version other than SNMPv1. The value of this
object SHOULD contain the value of the agent-addr field
from the original Trap PDU as generated by an SNMPv1
agent."
::= { snmpCommunityMIBObjects 3 }
snmpTrapCommunity OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The value of the community string field of an SNMPv1
message containing a Trap PDU which is forwarded by a
a proxy forwarder application using an SNMP version
other than SNMPv1. The value of this object SHOULD
contain the value of the community string field from
the original SNMPv1 message containing a Trap PDU as
generated by an SNMPv1 agent. There is no SIZE
constraint specified for this object because RFC 1157
does not impose any explicit limitation on the length
of community strings (their size is constrained
indirectly by the SNMP message size)."
::= { snmpCommunityMIBObjects 4 }
-- Conformance Information **************************************
snmpCommunityMIBCompliances OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 2 }
-- Compliance statements
snmpCommunityMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
implement the SNMP-COMMUNITY-MIB."
MODULE -- this module
MANDATORY-GROUPS { snmpCommunityTableGroup }
OBJECT snmpCommunityName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunitySecurityName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextEngineID
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityTransportTag
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
::= { snmpCommunityMIBCompliances 1 }
snmpProxyTrapForwardCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
contain a proxy forwarding application which is
capable of forwarding SNMPv1 traps using SNMPv2c
or SNMPv3."
MODULE -- this module
MANDATORY-GROUPS { snmpProxyTrapForwardGroup }
::= { snmpCommunityMIBCompliances 2 }
snmpCommunityMIBFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
implement the SNMP-COMMUNITY-MIB with full read-create
access."
MODULE -- this module
MANDATORY-GROUPS { snmpCommunityTableGroup }
::= { snmpCommunityMIBCompliances 3 }
snmpCommunityTableGroup OBJECT-GROUP
OBJECTS {
snmpCommunityName,
snmpCommunitySecurityName,
snmpCommunityContextEngineID,
snmpCommunityContextName,
snmpCommunityTransportTag,
snmpCommunityStorageType,
snmpCommunityStatus,
snmpTargetAddrTMask,
snmpTargetAddrMMS
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration
of community strings for SNMPv1 (and SNMPv2c) usage."
::= { snmpCommunityMIBGroups 1 }
snmpProxyTrapForwardGroup OBJECT-GROUP
OBJECTS {
snmpTrapAddress,
snmpTrapCommunity
}
STATUS current
DESCRIPTION
"Objects which are used by proxy forwarding applications
when translating traps between SNMP versions. These are
used to preserve SNMPv1-specific information when
translating to SNMPv2c or SNMPv3."
::= { snmpCommunityMIBGroups 3 }
END6. Intellectual Property Statement 💅
okay so the IETF is basically saying it takes no position on whether any IP rights could apply to this tech, how much they matter, or whether any license is even available 🫣 it also hasn't gone hunting for any rights. if you want the IETF's rules on rights for standards-track and standards-related docs, check BCP-11 📜 claims of rights, promised licenses, or the results of an attempt to get a general license or permission for implementers or users can be requested from the IETF Secretariat 📬
the IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to practice this standard ✨ send that info to the IETF Executive Director 💌
7. Acknowledgments 🫶
this doc is the result of the efforts of the SNMPv3 Working Group 💜 the design of the SNMP-COMMUNITY-MIB builds on work done by the authors of SNMPv2*, and they deserve all the flowers 🌸
- Jeff Case (SNMP Research, Inc.)
- David Harrington (Enterasys Networks)
- David Levi (Nortel Networks)
- Brian O'Keefe (Hewlett Packard)
- Jon Saperia (IronBridge Networks, Inc.)
- Steve Waldbusser (International Network Services)
8. Security Considerations 💀
okay bestie, this section is SERIOUS 🚨 even though SNMPv1 and SNMPv2 do not provide any security, mapping community names into securityName/contextName lets you use view-based access control to limit what unsecured SNMPv1 and SNMPv2 operations can reach 🛡️ it's honestly important for network admins to use this, or they risk unauthorized access to MIB data that would otherwise be secure 😭
when a proxy translates messages between SNMPv1 (or SNMPv2c) and SNMPv3, there may be a loss of security 🙈 for example, an SNMPv3 message received using authentication and privacy that then gets forwarded using SNMPv1 loses the security benefits of authentication and privacy (also known as confidentiality) 💔 careful proxy configuration is required to handle situations like this 🧚 one approach might be to use an encrypted tunnel 🔐
there are a bunch of management objects in this MIB module with a MAX-ACCESS clause of read-write and/or read-create 👀 these can be sensitive or vulnerable in some network environments, and SET support in a non-secure environment without proper protection can really mess with network operations 💅 these are the tables and objects, and why they're sensitive:
- The
snmpCommunityTableallows creation and deletion of community strings, which is potentially a serious security hole 🚩 access to this table should be greatly restricted, preferably by only allowing write access using SNMPv3 VACM and USM, with authentication and privacy 🔒 - The
snmpTargetAddrExtTablecontains write-able objects which may also be considered sensitive, so access to it should be restricted as well 🙅♀️
some of the readable objects in this MIB module (aka objects with a MAX-ACCESS other than not-accessible) may be sensitive or vulnerable in some network environments too 👁️ so it's important to control even GET and/or NOTIFY access to these objects, and possibly even encrypt their values when sending them over the network via SNMP 🫣 here's the list:
- The
snmpCommunityTablehas the potential to expose community strings that give access to more information than the usual 'public' community string does 😳 for this reason, a security administrator may wish to limit accessibility to objects in thesnmpCommunityTable, and in particular, make it inaccessible when using the 'public' community string 🙃
SNMP versions prior to SNMPv3 didn't include adequate security 😤 even if the network itself is secure (for example by using IPSec), there's still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module 🫠
it is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy) 🔥 main character energy for security ✨
further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED 🚫 instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security 🔐 then it's a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to principals (users) who have legitimate rights to actually GET or SET (change/create/delete) them 🧚♀️💖
9. References 📚
9.1. Normative References 🎀
- [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
- [RFC1157] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
- [RFC1212] Rose, M. and K. McCloghrie, Eds., "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
- [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
- [RFC1303] McCloghrie, K. and M. Rose, "A Convention for Describing SNMP-based Agents", RFC 1303, February 1992.
- [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
- [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
- [RFC3412] 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.
- [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
- [RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMP)", STD 62, RFC 3414, December 2002.
- [RFC3415] 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.
- [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3416, December 2002.
- [RFC3417] Presuhn, R., Ed., "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3417, December 2002.
- [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for Version 2 of the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
- [ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).
9.2. Informative References 🌈
- [RFC1908] 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.
- [RFC2089] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1 within a bilingual SNMP agent", RFC 2089, January 1997.
- [RFC2576] 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.
- [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
Appendix A. Change Log 🦋
A.1. Changes From RFC 2576 📝
okay so these are all the things that changed from RFC 2576 😭 section numbers below point to the old numbers from RFC 2576, and some of them have moved since then, so keep that in mind 🦋
- Added text to abstract about conversion of MIBs from SMIv1 to SMIv2. 🌸
- Added note at end of section 1.3 that all discussion of SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3. 💅
- Added text at end of section 1.4 to clarify that there is no such thing as 'SNMPv3 access to MIB data', as SNMPv3 just uses SNMPv2 PDU types and protocol operations. 🙈
- Moved section 1.4 to the beginning of section 4. ✨
- Changed "MUST" to "SHOULD" in item (3) of the first list in Section 2.1.1 to since unconstrained INTEGER is not actually illegal in SMIv2. 🍓
- Changed "SHOULD" to "MUST" in item (13) of the first list in Section 2.1.1 to clarify that collecting related objects into groups is required when translating a MIB module from SMIv1 to SMIv2. 👑
- Re-organized bullets in section 2.1.1 to improve clarity. 🧚
- Changed "SHOULD" to "MUST" in items (1) and (2) of Section 2.3 since those updates are indeed required when translating a capabilities statement from the language defined by RFC 1303 into SMIv2. 🔥
- In the second bullet of the last part of Section 3 listing the SNMPv2 notification parameters, clarified that the snmpTrapOID parameter refers to the value portion (not the name portion) of the second variable-binding, and changed the wording in the text under bullet (1) of Section 3.2 from "the snmpTrapOID" to "the snmpTrapOID value" to emphasize this point. 💜
- In bullet (6) of Section 3.2 emphasized that the SNMPv2 variable-bindings do not include sysUpTime.0 an snmpTrapOID.0. 🌈
- In Section 4.2 clarified that the 'Upstream Version' refers to the version used between the command generator or notification receiver and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder or notification originator. RFC 2576 neglected to mention the notification receiver and notification originator. 🫶
- In Section 4.1.2 added text noting that SNMPv1 access to MIB data SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages and re-worded final paragraph to note that the sub-sections that follow are concerned solely with command responders that use SNMPv2 access to MIB data while processing an SNMPv1 request. 🦋
- Re-worded first bullet, section 4.2.1, to make it more readable. 🌸
- In Section 4.2.1 clarified that the error-index field must be set to zero in a translated GetResponse-PDU with an error-status of 'tooBig' and made explicit the rationale for retrying a GetBulkRequest-PDU only once. ⭐
- Added text to the Deployment Hint in Section 4.2.2 to clarify that different principals should be used for SNMPv1 requests and SNMPv2/v3c requests if for SNMPv1 requests a principal for which Counter64 objects are not-in-view is used. 💖
- In Section 5.2.1 clarified that the securityName value and the scopedPDU's contextSnmpEngineID and contextName values come from the selected entry in the snmpCommunityTable. Also clarified how maxSizeResponseScopedPDU is determined and that securityStateReference must contain the community string of the original request. 🎀
- Added Section 5.2.4 on Proxy Forwarding Of Requests. 🧚
- In Section 5.3 clarified that snmpTargetAddrTMask is to be ignored whenever its use is not explicitly called for. 🍓
- Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and added a copyright notice to the DESCRIPTION clause of the MIB module's MODULE-IDENTITY invocation. 💅
- Added text to DESCRIPTION of snmpCommunityName and snmpTrapCommunity to clarify why the object has no size restriction. 🙈
- Updated the description of snmpCommunityTransportTag to make it consistent with the rest of the document. ✨
- Updated the description of 'snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown. 👑
- Changed the name of 'snmpCommunityGroup' to 'snmpCommunityTableGroup' in order to resolve a name conflict with the SNMPv2-MIB. 🔥
- Added compliance statement to SNMP-COMMUNITY-MIB for full read-create compliance. 💜
- Divided references into Normative References and Informative Reference and updated them to point to current documents. 🌈
- Inserted current year into all copyright notices. 🫶
- Corrected various typographical and grammatical errors. 🦋
A.2. Changes Between RFC 1908 and RFC 2576 🌷
okay and this is the glow-up from RFC 1908 to RFC 2576 ✨ it's giving major revamp energy 💅
- Editorial changes to comply with current RFC requirements. 📝
- Added/updated copyright statements. 🎀
- Added Intellectual Property section. 🌸
- Replaced old introduction with complete new introduction/overview. 🦋
- Added content for the Security Considerations Section. 🔥
- Updated References to current documents. 💖
- Updated text to use current SNMP terminology. 🧚
- Added coexistence for/with SNMPv3. 👑
- Added description for SNMPv1 and SNMPv2c Message Processing Models and SNMPv1 and SNMPv2c Community-based Security Models. 🍓
- Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community strings can be mapped into the SNMP Version Independent parameters which can then be used for access control using the standard SNMPv3 View-based Access Control Model and the snmpVacmMIB. 🌈
- Added two MIB objects such that when an SNMPv1 notification (trap) must be converted into an SNMPv2 notification we add those two objects in order to preserve information about the address and community of the originating SNMPv1 agent. ⭐
- Included (and extended) from RFC 2089 the SNMPv2 to SNMPv1 mapping within a multi-lingual SNMP Engine. 🫶
- Use keywords from RFC 2119 to describe requirements for compliance. 💜
- Changed/added some rules for converting a MIB module from SMIv1 to SMIv2. 🙈
- Extended and improved the description of Proxy Forwarder behaviour when multiple SNMP versions are involved. 🎀
Editors' Addresses 📮
Here's where you can find the editors. Slide into their inboxes if you need them 💌
Rob Frye
Vibrant Solutions
2711 Prosperity Ave
Fairfax, Virginia 22031
U.S.A.
Phone: +1 703 270 2000
EMail: rfrye@vibrant-1.comDavid B. Levi
Nortel Networks
3505 Kesterwood Drive
Knoxville, TN 37918
U.S.A.
Phone: +1 865 686 0432
EMail: dlevi@nortelnetworks.comShawn A. Routhier
Wind River Systems, Inc.
500 Wind River Way
Alameda, CA 94501
U.S.A.
Phone: + 1 510 749 2095
EMail: sar@epilogue.comBert Wijnen
Lucent Technologies
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31 348 407 775
EMail: bwijnen@lucent.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2003). All Rights Reserved. 💖
Okay, the legal bit, and it matters 🫶 This document, and translations of it, may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The only exceptions are when it's needed for developing Internet standards, in which case the copyright procedures defined in the Internet Standards process must be followed, or when it's needed to translate it into languages other than English. 🌸
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. 🔒
This document and the information contained herein is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. 🧚
📦 where this page comes from
- ietf: rfc3584 2003-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms