RFC 1445

Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)

📅 published April 1993, from ietf

RFC 1445 is titled Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2). It was published in April 1993 in the Network Working Group by J. Galvin (Trusted Information Systems) and K. McCloghrie (Hughes LAN Systems). It's an IAB standards track document, and its header doesn't list anything it obsoletes or updates. 🎀

Status of this Memo

okay so this RFC specifies an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." And distribution of this memo is unlimited, so share it with everyone 💅

Table of Contents ✨

          1 Introduction ..........................................    2
          1.1 A Note on Terminology ...............................    2
          2 Elements of the Model .................................    3
          2.1 SNMPv2 Party ........................................    3
          2.2 SNMPv2 Entity .......................................    6
          2.3 SNMPv2 Management Station ...........................    7
          2.4 SNMPv2 Agent ........................................    7
          2.5 View Subtree ........................................    7
          2.6 MIB View ............................................    8
          2.7 Proxy Relationship ..................................    8
          2.8 SNMPv2 Context ......................................   10
          2.9 SNMPv2 Management Communication .....................   10
          2.10 SNMPv2 Authenticated Management Communication ......   12
          2.11 SNMPv2 Private Management Communication ............   13
          2.12 SNMPv2 Management Communication Class ..............   14
          2.13 SNMPv2 Access Control Policy .......................   14
          3 Elements of Procedure .................................   17
          3.1 Generating a Request ................................   17
          3.2 Processing a Received Communication .................   18
          3.3 Generating a Response ...............................   21
          4 Application of the Model ..............................   23
          4.1 Non-Secure Minimal Agent Configuration ..............   23
          4.2 Secure Minimal Agent Configuration ..................   26
          4.3 MIB View Configurations .............................   28
          4.4 Proxy Configuration .................................   32
          4.4.1 Foreign Proxy Configuration .......................   33
          4.4.2 Native Proxy Configuration ........................   37
          4.5 Public Key Configuration ............................   41
          5 Security Considerations ...............................   44
          6 Acknowledgements ......................................   45
          7 References ............................................   46
          8 Authors' Addresses ....................................   47

1. Introduction 🦋

so a network management system has a few pieces. You've got several (potentially many) nodes, and each one has a processing entity called an agent that can reach management instrumentation. Then there's at least one management station, plus a management protocol that carries management info between the agents and the stations 🧚 Everything the protocol does runs under an administrative framework, and that framework defines both authentication and authorization policies. Lowkey the whole system is built around who gets to do what 🔐

Network management stations run management applications that monitor and control network elements. Network elements are things like hosts, routers, terminal servers, and so on. You monitor and control them by getting access to their management information 💜

This document, the Administrative Model for SNMPv2, exists to explain how that administrative framework gets applied so network management actually works well across a bunch of different configurations and environments ✨

The model here uses distinct identities for the peers that exchange SNMPv2 messages. So it's a real departure from the community-based administrative model of the original SNMP [1]. By clearly identifying the source and the intended recipient of every SNMPv2 message, this new approach beats the old community scheme in two ways: it supports a more convenient access control model, and it allows effective use of asymmetric (public key) security protocols down the road 🌈 iykyk, it's a big glow-up 😭

1.1. A Note on Terminology 🎀

For clarity, the original Internet-standard Network Management Framework, described in RFCs 1155, 1157, and 1212, is called the SNMP version 1 framework (SNMPv1). The current framework is called the SNMP version 2 framework (SNMPv2) 🍓

2. Elements of the Model 👑

2.1. SNMPv2 Party 💖

okay bestie, an SNMPv2 party is a conceptual, virtual execution environment. Its operation is restricted (for security or other purposes) to an administratively defined subset of all the possible operations of a particular SNMPv2 entity (see Section 2.2). Whenever an SNMPv2 entity processes an SNMPv2 message, it acts as an SNMPv2 party and is restricted to the set of operations defined for that party. The operation sets for different parties may overlap or be disjoint from each other. A party's set can also be a proper or improper subset of all the entity's possible operations 💅

Architecturally, each SNMPv2 party is made up of:

  • a single, unique party identity,
  • a logical network location where the party runs, described by a transport protocol domain and transport addressing information,
  • a single authentication protocol and its associated parameters, which authenticate as to origin and integrity every protocol message the party originates, and
  • a single privacy protocol and its associated parameters, which protect from disclosure every protocol message the party receives.

Conceptually, each SNMPv2 party may be represented by an ASN.1 value with the following syntax:

     SnmpParty ::= SEQUENCE {
       partyIdentity
          OBJECT IDENTIFIER,
       partyTDomain
          OBJECT IDENTIFIER,
       partyTAddress
          OCTET STRING,
       partyMaxMessageSize
          INTEGER,
       partyAuthProtocol
          OBJECT IDENTIFIER,
       partyAuthClock
          INTEGER,
       partyAuthPrivate
          OCTET STRING,
       partyAuthPublic
          OCTET STRING,
       partyAuthLifetime
          INTEGER,
       partyPrivProtocol
          OBJECT IDENTIFIER,
       partyPrivPrivate
          OCTET STRING,
       partyPrivPublic
          OCTET STRING
     }

For each SnmpParty value that represents an SNMPv2 party, these statements are true:

  • Its partyIdentity component is the party identity.
  • Its partyTDomain component is called the transport domain. It tells you the kind of transport service the party uses to receive network management traffic. An example is snmpUDPDomain (SNMPv2 over UDP, using SNMPv2 parties).
  • Its partyTAddress component is called the transport addressing information. It's the transport service address where the party receives network management traffic.
  • Its partyMaxMessageSize component is called the maximum message size. It's the length in octets of the largest SNMPv2 message this party is prepared to accept.
  • Its partyAuthProtocol component is called the authentication protocol. It identifies a protocol and a mechanism that authenticates as to integrity and origin all messages the party generates. Here, the value noAuth means messages generated by the party are not authenticated as to integrity and origin.
  • Its partyAuthClock component is called the authentication clock. It's a notion of the current time specific to the party. What it means depends on the authentication protocol.
  • Its partyAuthPrivate component is called the private authentication key. It's any secret value needed to support the authentication protocol. What it means depends on the authentication protocol.
  • Its partyAuthPublic component is called the public authentication key. It's any public value that may be needed to support the authentication protocol. What it means depends on the authentication protocol.
  • Its partyAuthLifetime component is called the lifetime. It's an administrative upper bound on acceptable delivery delay for protocol messages the party generates. What it means depends on the authentication protocol.
  • Its partyPrivProtocol component is called the privacy protocol. It identifies a protocol and a mechanism that protects from disclosure all protocol messages the party receives. Here, the value noPriv means messages received by the party are not protected from disclosure.
  • Its partyPrivPrivate component is called the private privacy key. It's any secret value needed to support the privacy protocol. What it means depends on the privacy protocol.
  • Its partyPrivPublic component is called the public privacy key. It's any public value that may be needed to support the privacy protocol. What it means depends on the privacy protocol.

and here's the big one 🔥 If, for all SNMPv2 parties realized by an SNMPv2 entity, the authentication protocol is noAuth and the privacy protocol is noPriv, then that entity is called non-secure. 🙈

2.2. SNMPv2 Entity 🧚

A SNMPv2 entity is an actual process that gets the network management work done by generating and/or responding to SNMPv2 protocol messages, the way it's described in [2]. 💅 When an entity is acting as a particular SNMPv2 party (see Section 2.1), its operation must be restricted to the subset of all possible operations that's administratively defined for that party. Bestie, that's the boundary line 🚧

By definition, a SNMPv2 entity doesn't need concurrency between processing one protocol message (from a particular SNMPv2 party) and processing another protocol message (from a potentially different party) 🧠 So an implementation supporting more than one party doesn't need to be multi-threaded. ngl, there may be situations where implementors choose multi-threading anyway, and that's totally their call ✨

Architecturally, every SNMPv2 entity keeps a local database of all the SNMPv2 parties it knows about. That includes parties whose operation is realized locally, parties whose operation is realized through proxy interactions with remote parties or devices, and parties whose operation is realized by remote entities 🗂️ It also keeps a local database of all the managed object resources it knows about (see Section 2.8). And finally, it keeps a local database for the access control policy (see Section 2.11) that defines the access privileges given to the known SNMPv2 parties 🔐

2.3. SNMPv2 Management Station ✨

A SNMPv2 management station is the operational role a SNMPv2 party takes on when it starts SNMPv2 management operations by generating the right SNMPv2 protocol messages, or when it receives and processes trap notifications 📣

Sometimes people use the term SNMPv2 management station for partial implementations of SNMPv2 (like on graphics workstations, for example) that focus on just this role 🖥️ These partial versions might give you a convenient, local way to invoke management services, but they might offer little or no support for doing SNMPv2 management operations on behalf of remote protocol users 🙈

2.4. SNMPv2 Agent 🧚

A SNMPv2 agent is the operational role a SNMPv2 party takes on when it performs SNMPv2 management operations in response to received SNMPv2 protocol messages, like the ones a SNMPv2 management station generates (see Section 2.3) 💜

Sometimes the term SNMPv2 agent is used for partial implementations of SNMPv2 (in embedded systems, for example) that focus on this role 🍓 These partial versions carry out SNMPv2 management operations for remote users of management services, but they might offer little or no support for invoking those services locally 🌸

2.5. View Subtree 🌳

A view subtree is the set of all MIB object instances that have a common ASN.1 OBJECT IDENTIFIER prefix in their names. It's identified by the OBJECT IDENTIFIER value that is the longest OBJECT IDENTIFIER prefix shared by all (potential) MIB object instances in that subtree 🦋

When the OBJECT IDENTIFIER prefix that identifies a view subtree is longer than the OBJECT IDENTIFIER of an object type defined according to the SMI [3], then using that view subtree for access control gets granular down to the object instance level. Okay but here's the tea: that level of granularity is considered beyond the scope of a SNMPv2 entity acting in an agent role 🙅‍♀️ So no implementation of a SNMPv2 entity acting in an agent role is required to support values of viewSubtree [6] that have more sub-identifiers than what's needed to identify a particular leaf object type 🌿

BUT, access control information is also used to figure out which SNMPv2 entities acting in a manager role should receive trap notifications (Section 4.2.6 of [2]) 😳 So agent implementors might want to provide instance-level granularity, so a management station can do fine-grain configuration of trap notifications 🎯

2.6. MIB View 👑

A MIB view is a subset of the set of all instances of all object types defined according to the SMI [3] (in other words, of the universal set of all instances of all MIB objects), and it has to follow these constraints:

  • Each element of a MIB view is uniquely named by an ASN.1 OBJECT IDENTIFIER value. So identically named instances of a particular object type (e.g., in different agents) must be contained within different MIB views. Put simply, a particular object instance name resolves within a particular MIB view to at most one object instance 🫶
  • Every MIB view is defined as a collection of view subtrees 🌈

2.7. Proxy Relationship 🎀

A proxy relationship exists when, to process a received management request, a SNMPv2 entity has to communicate with another entity that's logically remote 🔁 A SNMPv2 entity that processes management requests using a proxy relationship is called a SNMPv2 proxy agent.

When communication between a logically remote party and a SNMPv2 entity goes via SNMPv2 (over any transport protocol), the proxy party is called a SNMPv2 native proxy relationship. Deploying SNMPv2 native proxy relationships is a way to amortize or shift the processing or bandwidth costs of management, which makes it easier to build large management systems 💪

When communication between a logically remote party and a SNMPv2 entity party does not go via SNMPv2, the proxy party is called a SNMPv2 foreign proxy relationship. Deploying foreign proxy relationships is a way to manage devices that would otherwise be unmanageable, or portions of an internet, via SNMPv2 🛸

The transparency principle, which defines how a SNMPv2 entity behaves in general, applies in particular to a SNMPv2 proxy relationship. Here's the big rule:

The manner in which one SNMPv2 entity processes SNMPv2 protocol messages received from another SNMPv2 entity is entirely transparent to the latter. 🫣

The transparency principle comes straight from SNMP's long-standing philosophy of separating architecture from implementation 🧩 A lot of the most valuable benefits in both the information and distribution models of the Internet-standard Network Management Framework come from this split, and it's the architectural cornerstone that large management systems get built on 🏗️ Following that philosophy, even though a SNMPv2 proxy agent in some environments might look like a transport-layer bridge, this particular implementation strategy (or any other!) doesn't get special recognition in the SNMPv2 management architecture or in the standard mechanisms for proxy administration 🙃

Implicit in the transparency principle is the requirement that the semantics of SNMPv2 management operations are preserved between any two SNMPv2 peers. Especially, the "as if simultaneous" semantics of a Set operation are extremely difficult to guarantee if its scope reaches management information resident at multiple network locations 😵 For this reason, proxy configurations that allow Set operations applying to information at multiple locations are discouraged. Such operations aren't explicitly precluded by the architecture, though, in those rare cases where they might be supported in a conformant way 🤞

Also implicit in the transparency principle is the requirement that, throughout its interaction with a proxy agent, a management station is given no information about the nature or progress of the proxy mechanisms that realize its requests 🕵️‍♀️ That means it should seem to the management station, except for any difference in the underlying transport address, as if it were interacting via SNMPv2 directly with the proxied device. So a timeout in the communication between a proxy agent and its proxied device should be represented as a timeout in the communication between the management station and the proxy agent ⏱️ Similarly, an error response from a proxied device should, as much as possible, be represented by the corresponding error response in the interaction between the proxy agent and the management station 🚨

2.8. SNMPv2 Context 📚

A SNMPv2 context is a collection of managed object resources accessible by a SNMPv2 entity. The object resources identified by a context are either local or remote 🏠

A SNMPv2 context that refers to local object resources is identified as a MIB view. In this case, a SNMPv2 entity uses local mechanisms to access the management information identified by the SNMPv2 context 🔍

A remote SNMPv2 context that refers to remote object resources is identified as a proxy relationship. In this case, a SNMPv2 entity acts as a proxy agent to access the management information identified by the SNMPv2 context 🛰️

2.9. SNMPv2 Management Communication 💌

A SNMPv2 management communication is a communication from one specified SNMPv2 party to a second specified SNMPv2 party about management information contained in a SNMPv2 context that's accessible by the appropriate SNMPv2 entity. A management communication can be any of these:

  • a query by the originating party about information accessible to the addressed party (e.g., getRequest, getNextRequest, or getBulkRequest) 🔎
  • an indicative assertion to the addressed party about information accessible to the originating party (e.g., Response, InformRequest, or SNMPv2-Trap) 📢
  • an imperative assertion by the originating party about information accessible to the addressed party (e.g., setRequest) 👉
  • a confirmation to the addressed party about information received by the originating party (e.g., a Response confirming an InformRequest) ✅

A management communication is represented by an ASN.1 value with the following syntax:

SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE {
  dstParty
     OBJECT IDENTIFIER,
  srcParty
     OBJECT IDENTIFIER,
  context
     OBJECT IDENTIFIER,
  pdu
     PDUs
}

Okay so, for every SnmpMgmtCom value that's a SNMPv2 management communication, these are the facts 💅:

  • Its dstParty component is called the destination, and it tells you which SNMPv2 party the communication is aimed at 🎯
  • Its srcParty component is called the source, and it's the SNMPv2 party that actually sent it 📤
  • Its context component tells you which SNMPv2 context holds the management information the communication is talking about 🗂️
  • Its pdu component has the form and meaning described in [2] 🧃

2.10. SNMPv2 Authenticated Management Communication

Okay, so an SNMPv2 authenticated management communication is basically a SNMPv2 management communication (see Section 2.9) where the sender is (possibly) reliably identified, and the integrity of the message is (possibly) protected too 🔐. The whole thing is represented as an ASN.1 value that looks like this:

     SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE {
       authInfo
          ANY, -- defined by authentication protocol
       authData
          SnmpMgmtCom
     }

For every SnmpAuthMsg value that stands for an SNMPv2 authenticated management communication, these are the facts:

  • Its authInfo component is called the authentication information. It holds whatever the authentication protocol needs from the SNMPv2 party that sent the message 🪪. What's inside is totally specific to whichever authentication protocol is in use. It doesn't change what the communication means at the application level. Its only job is helping the authentication protocol decide whether the communication is legit or not 🕵️‍♀️
  • Its authData component is called the authentication data, and it's an SNMPv2 management communication inside a trench coat 🧥

2.11. SNMPv2 Private Management Communication

An SNMPv2 private management communication is an SNMPv2 authenticated management communication (see Section 2.10) that's (possibly) protected from being disclosed 🤫. It's also an ASN.1 value, shaped like this:

     SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE {
       privDst
          OBJECT IDENTIFIER,
       privData
          [1] IMPLICIT OCTET STRING
     }

For every SnmpPrivMsg value that represents an SNMPv2 private management communication, these are the facts:

  • Its privDst component is called the privacy destination, and it identifies the SNMPv2 party the communication is headed to 📬
  • Its privData component is called the privacy data. It holds the serialization of an SNMPv2 authenticated management communication (see Section 2.10), following the conventions of [5]. That serialization may be encrypted 🔒✨

2.12. SNMPv2 Management Communication Class

An SNMPv2 management communication class lines up with one specific SNMPv2 PDU type defined in [2] 🧩. Each class is represented by an ASN.1 INTEGER value that depends on which PDU identifies it. Check out Table 1 for the whole lineup:

                              Get              1
                              GetNext          2
                              Response         4
                              Set              8
                              -- unused       16
                              GetBulk         32
                              Inform          64
                              SNMPv2-Trap    128


                    Table 1: Management Communication Classes

So the value for a communication class is computed as 2 raised to the value of the ASN.1 context-specific tag for the matching SNMPv2 PDU. Math is giving pow 🧮💖

A set of management communication classes is represented by the ASN.1 INTEGER value that's the sum of the representations of the classes in that set. And the null set? It's represented by the value zero 0️⃣🫧

2.13. SNMPv2 Access Control Policy

Okay, the bestie of this section is the SNMPv2 access control policy 👑. It's a specification of a local access policy, written in terms of an SNMPv2 context and the management communication classes that are authorized between a pair of SNMPv2 parties. Architecturally, that specification has four parts:

  • the targets of SNMPv2 access control, which are the SNMPv2 parties that may perform management operations when they get management communications from other parties 🎯
  • the subjects of SNMPv2 access control, which are the SNMPv2 parties that may ask, by sending management communications to other parties, for management operations to be performed 🙋‍♀️
  • the managed object resources of SNMPv2 access control, which are the SNMPv2 contexts that identify the management information the requested operations act on 🗃️
  • the policy itself, which spells out the classes of SNMPv2 management communications about a particular SNMPv2 context that a particular target is allowed to accept from a particular subject 📜

Conceptually, an SNMPv2 access policy is represented by a collection of ASN.1 values with this syntax:

     AclEntry ::= SEQUENCE {
       aclTarget
          OBJECT IDENTIFIER,
       aclSubject
          OBJECT IDENTIFIER,
       aclResources
          OBJECT IDENTIFIER,
       aclPrivileges
          INTEGER
     }

For each such value that represents one part of an SNMPv2 access policy, these are the facts:

  • Its aclTarget component is called the target, and it identifies the SNMPv2 party the partial policy grants access to 🚪
  • Its aclSubject component is called the subject, and it identifies the SNMPv2 party the partial policy grants privileges to 🎀
  • Its aclResources component is called the managed object resources, and it identifies the SNMPv2 context the partial policy refers to 🌸
  • Its aclPrivileges component is called the privileges. It represents a set of SNMPv2 management communication classes which, when they reference the specified SNMPv2 context, are authorized to be processed by the specified target party when received from the specified subject party 🫶

Access control policy only kicks in when management communications are received. It doesn't get applied when they're sent 📭. But here's the tea: AclEntry values are also used when figuring out where a SNMPv2-Trap [2] should go 🦋💅

3. Elements of Procedure ⚙️

okay so this section is where the procedures live 🫶 these are the steps a SNMPv2 entity follows when it's handling messages, and the best part is they don't care which authentication or privacy protocols you're running. mix and match all you want 💅

3.1. Generating a Request 📤

this is the playbook a SNMPv2 entity follows whenever it's sending a management request or a trap notification to another party 🦋

  1. first, build a SnmpMgmtCom value. its srcParty component names the originating party, its dstParty component names the receiving party, its context component names the SNMPv2 context you want, and its pdu component holds the management operation you're after ✨
  2. next, check the local database of party information to find out the authentication protocol and other useful info for both the originating and receiving SNMPv2 parties 🔍
  3. now build a SnmpAuthMsg value with these properties:
    • its authInfo component is built according to the authentication protocol set for the originating party. 🔐
      • in particular, if the originating party's authentication protocol is noAuth, then this component is the OCTET STRING value of zero length 🌸
    • its authData component is the SnmpMgmtCom value you just made 💖
  4. check the local database of party information again, this time for the privacy protocol and other relevant info for the receiving SNMPv2 party 🕵️‍♀️
  5. build a SnmpPrivMsg value with these properties:
    • its privDst component names the receiving SNMPv2 party 🎯
    • its privData component is the serialization of the SnmpAuthMsg value, possibly encrypted, following the conventions of [5] 🍓
      • in particular, if the receiving party's privacy protocol is noPriv, then privData stays unencrypted 🙈
      • otherwise, privData gets processed according to the privacy protocol ✨
  6. serialize the SnmpPrivMsg value you built, following the conventions of [5] 🧚
  7. transmit the serialized SnmpPrivMsg value using the transport address and transport domain for the receiving SNMPv2 party 🚀
note: this procedure does NOT apply any SNMPv2 access control policy. that's a whole separate thing (see section 2.13) 🙅‍♀️

3.2. Processing a Received Communication 📥

this is what the entity does when a management communication shows up. it's giving careful gatekeeper energy, and a bunch of counters get updated along the way 📊

  1. first, the snmpStatsPackets counter [7] goes up by one. if the received message isn't the serialization of an SnmpPrivMsg value (following the conventions of [5]), then it gets discarded right away, no further processing 🗑️
    • (if the first octet of the packet is hexadecimal 30, then the snmpStats30Something counter [7] gets incremented before the discard. otherwise, the snmpStatsEncodingErrors counter [7] gets incremented.)
  2. check the local database of party information for the receiving SNMPv2 party identified by the privDst component of the SnmpPrivMsg value 👀
  3. if there's no info about the receiving SNMPv2 party in the local database of party information, or the info says the receiving party's operation isn't realized by the local SNMPv2 entity, then the message is discarded with no further processing, after the snmpStatsUnknownDstParties counter [7] goes up 🚫
  4. construct an ASN.1 OCTET STRING value from the privData component of that SnmpPrivMsg value. this might involve decryption, depending on the privacy protocol in use 🔓
    • in particular, if the privacy protocol recorded for the party is noPriv, then the OCTET STRING value matches the privData component of the SnmpPrivMsg value exactly ✨
  5. if that OCTET STRING value isn't the serialization of an SnmpAuthMsg value (following the conventions of [5]), then the message is discarded with no further processing, after the snmpStatsEncodingErrors counter [7] goes up 💀
  6. if the dstParty component of the authData component of the obtained SnmpAuthMsg value doesn't match the privDst component of the SnmpPrivMsg value, then the message is discarded with no further processing, after the snmpStatsDstPartyMismatches counter [7] goes up 😭
  7. check the local database of party information for the originating SNMPv2 party, identified by the srcParty component of the authData component of the SnmpAuthMsg value 🔎
  8. if there's no info about the originating SNMPv2 party in the local database of party information, then the message is discarded with no further processing, after the snmpStatsUnknownSrcParties counter [7] goes up 🙅‍♀️
  9. evaluate the obtained SnmpAuthMsg value using the authentication protocol and other relevant info linked to the originating and receiving SNMPv2 parties in the local database of party information ⚖️
    • in particular, if the authentication protocol is noAuth, then the SnmpAuthMsg value is always evaluated as authentic 🫶
  10. if the SnmpAuthMsg value is evaluated as unauthentic, then the message is discarded with no further processing. and if the snmpV2EnableAuthenTraps object [7] is enabled, the SNMPv2 entity sends authorizationFailure traps [7] according to its configuration (Section 4.2.6 of[2]) 🚨
  11. extract the SnmpMgmtCom value from the authData component of the SnmpAuthMsg value 🎀
  12. check the local database of context information for the SNMPv2 context identified by the context component of the SnmpMgmtCom value 🗺️
  13. if there's no info about the SNMPv2 context in the local database of context information, then the message is discarded with no further processing, after the snmpStatsUnknownContexts counter [7] goes up 🥲
  14. check the local database of access policy information for the access privileges that the local access policy permits to the originating SNMPv2 party, with respect to the receiving SNMPv2 party and the indicated SNMPv2 context 🔐
  15. figure out the management communication class from the ASN.1 tag value tied to the PDUs component of the SnmpMgmtCom value. if the management information class of the received message is 32, 8, 2, or 1 (i.e., GetBulk, Set, GetNext or Get) and the SNMPv2 context isn't realized by the local SNMPv2 entity, then the message is discarded with no further processing, after the snmpStatsUnknownContexts counter [7] goes up 🌈
  16. if the management communication class is 128, 64 or 4 (i.e., SNMPv2-Trap, Inform, or Response) and this class isn't among the access privileges, then the message is discarded with no further processing, after the snmpStatsBadOperations counter [7] goes up 🙈
  17. if the management communication class of the received message isn't among the access privileges, then the message is discarded with no further processing, but only after a response message is generated and sent. that response is directed to the originating SNMPv2 party on behalf of the receiving SNMPv2 party. its context, var-bind-list and request-id components are identical to the received request's. its error-index component is zero and its error-status component is authorizationError [2] 📨
  18. if the SNMPv2 context refers to local object resources, then the receiving SNMPv2 entity performs the management operation represented by the SnmpMgmtCom value with respect to the MIB view identified by the SNMPv2 context, following the procedures in [2] 🏆
  19. if the SNMPv2 context refers to remote object resources, then the management operation represented by the SnmpMgmtCom value gets performed through the appropriate proxy relationship 🦋

3.3. Generating a Response 📬

generating a response to a SNMPv2 management request is basically the same as sending a request (see Section 3.1), with a couple of plot twists 💖

  1. in Step 1, the dstParty component of the responding SnmpMgmtCom value is taken from the srcParty component of the original SnmpMgmtCom value. the srcParty component of the responding SnmpMgmtCom value is taken from the dstParty component of the original one. the context component of the responding value is taken from the original context component. and the pdu component of the responding value is the response that comes from applying the operation in the original SnmpMgmtCom value 🔁
  2. in Step 7, the serialized SnmpPrivMsg value gets transmitted using the transport address and transport domain the corresponding request came from, even if that's different from the transport info recorded in the local database of party information 🧚‍♀️

4. Application of the Model 🌷

this section is all about how the administrative model we just went through gets used to make network management actually work in all kinds of setups and environments 🌍 it walks through several types of administrative configurations, and gives an example of each one 🫶

4.1. Non-Secure Minimal Agent Configuration 💖

okay so this section gives us an example setup for a minimal, non-secure SNMPv2 agent that chats with one or more SNMPv2 management stations 🧚. Table 2 lists the party info that both the minimal agent and the manager know about, and Table 3 lists the similarly shared local access policy info 💅.

As Table 2 shows, the example agent party is at UDP port 161 on IP address 1.2.3.4 and goes by the identity gracie. The example manager is at UDP port 2001 on IP address 1.2.3.5 and goes by george. At minimum, a non-secure SNMPv2 agent implementation must provide admin configuration (and non-volatile storage) for the identities and transport addresses of two SNMPv2 parties: itself and a remote peer. Strictly speaking, other info about these two parties (including access policy info) need not be configurable 🫶.

    Identity          gracie                george
                      (agent)               (manager)
    Domain            snmpUDPDomain         snmpUDPDomain
    Address           1.2.3.4, 161          1.2.3.5, 2001
    Auth Prot         noAuth                noAuth
    Auth Priv Key     ""                    ""
    Auth Pub Key      ""                    ""
    Auth Clock        0                     0
    Auth Lifetime     0                     0
    Priv Prot         noPriv                noPriv
    Priv Priv Key     ""                    ""
    Priv Pub Key      ""                    ""


        Table 2: Party Information for Minimal Agent
    Target    Subject    Context    Privileges
    gracie    george     local       35 (Get, GetNext & GetBulk)
    george    gracie     local      132 (Response & SNMPv2-Trap)


        Table 3: Access Information for Minimal Agent

Say the managing party george wants to look at the management info in the SNMPv2 context named "local" held by the agent gracie, so george sends a SNMPv2 GetNext request message 👀. The manager checks its local party database first. Since george's authentication protocol is recorded as noAuth, the GetNext request is not authenticated as to origin and integrity. Since gracie's privacy protocol is recorded as noPriv in the manager's database, the request is not protected from disclosure either. It just gets assembled, serialized, and sent off to the transport address (IP address 1.2.3.4, UDP port 161) that the manager's database links to gracie. no frills, no drama 🦋.

When the GetNext request shows up at the agent, the agent pulls out the party it's addressed to (gracie) and checks its own database. Since gracie's privacy protocol is noPriv, the agent assumes the message isn't protected from disclosure. It also pulls out the originating party (george) and checks that entry too. Since george's authentication protocol is noAuth, the message is accepted as authentic right away 🌸.

The agent only fully processes the request if its local access policy database authorizes GetNext requests from george to the agent party gracie for the SNMPv2 context "local". Table 3 does authorize that, along with Get and GetBulk operations ✨.

Once the request is processed, the agent generates a Response message. This message references the SNMPv2 context "local", names gracie as the source party, and names george (the party the request came from) as the destination party. Since gracie's authentication protocol is recorded as noAuth in the local party database, the Response is not authenticated as to origin or integrity. Since george's privacy protocol is noPriv in that same database, the Response is not protected from disclosure. The Response goes back to the transport address the request came from, and the agent doesn't care what transport address george has in its local party database 🙈.

When the manager gets that Response, it pulls out the destination party (george) and checks its database. Since george's privacy protocol is noPriv, the Response is assumed not to be protected from disclosure. The manager also pulls out the originating party (gracie) and checks it. Since gracie's authentication protocol is noAuth, the Response is accepted as authentic immediately 💁‍♀️.

The manager only fully processes the Response if its local access policy database authorizes Response messages from gracie to the manager party george that reference the SNMPv2 context "local". Table 3 authorizes those Responses, plus SNMPv2-Trap messages 🎀.

4.2. Secure Minimal Agent Configuration 🔐

this section is the secure glow-up 💅. It gives an example setup for a secure, minimal SNMPv2 agent that talks to a single SNMPv2 management station. Table 4 lists the party info that both the minimal agent and the manager know about, and Table 5 lists the similarly shared local access policy info 🦋.

The way manager and agent work together here is basically the same as the non-secure version above, except now every protocol message is authenticated as to origin and integrity AND protected from disclosure 🛡️. This example needs encryption so the secret keys can be distributed over SNMPv2 itself. A fancier example with one more pair of SNMPv2 parties could pass non-secret info in authenticated messages without paying the encryption cost 💜.

A real secure agent setup may need SNMPv2 parties whose authentication and privacy protocols are noAuth and noPriv, respectively, so that clock synchronization can happen (see [6]). Those extra parties aren't shown here, just to keep things clear 🫶.

    Identity          ollie                stan
                      (agent)              (manager)
    Domain            snmpUDPDomain        snmpUDPDomain
    Address           1.2.3.4, 161         1.2.3.5, 2001
    Auth Prot         v2md5AuthProtocol    v2md5AuthProtocol
    Auth Priv Key     "0123456789ABCDEF"   "GHIJKL0123456789"
    Auth Pub Key      ""                   ""
    Auth Clock        0                    0
    Auth Lifetime     300                  300
    Priv Prot         desPrivProtocol     desPrivProtocol
    Priv Priv Key     "MNOPQR0123456789"   "STUVWX0123456789"
    Priv Pub Key      ""                   ""


        Table 4: Party Information for Secure Minimal Agent
    Target    Subject    Context    Privileges
    ollie     stan       local       35 (Get, GetNext & GetBulk)
    stan      ollie      local      132 (Response & SNMPv2-Trap)


        Table 5: Access Information for Secure Minimal Agent

As Table 4 shows, the example agent party is at UDP port 161 on IP address 1.2.3.4 and goes by ollie. The example manager is at UDP port 2001 on IP address 1.2.3.5 and goes by stan. At minimum, a secure SNMPv2 agent implementation must provide admin configuration (and non-volatile storage) for the relevant info about two SNMPv2 parties: itself and a remote peer. Both ollie and stan authenticate every message they generate using the SNMPv2 authentication protocol v2md5AuthProtocol and their own distinct, private authentication keys 🔑. The private authentication key values ("0123456789ABCDEF" and "GHIJKL0123456789") are shown here just for explaining things. In real life, humans don't usually get to see private authentication keys. Those keys stay inside the parts of the protocol implementation that actually need them 🤫.

When v2md5AuthProtocol is in use, the public authentication key for each SNMPv2 party is never used for authenticating and verifying SNMPv2 exchanges. Also, since v2md5AuthProtocol is symmetric, the private authentication key for each party has to be known by any other SNMPv2 party it wants authenticated communication with. Asymmetric (public key) authentication protocols, by contrast, wouldn't rely on sharing a private key to work 🧠.

Every protocol message generated for stan is encrypted with the desPrivProtocol privacy protocol and the private key "STUVWX0123456789", and gets decrypted on arrival using that same protocol and key. In the same way, every message generated for ollie is encrypted with the desPrivProtocol protocol and the private privacy key "MNOPQR0123456789", then decrypted on reception. Just like the authentication keys, private privacy keys aren't normally shown to humans. They stay inside the parts of the implementation that need them 🔒.

4.3. MIB View Configurations 🌈

this section explains a convention for defining MIB views ✨. Using that convention, it then shows example MIB view configurations for SNMPv2 contexts that point at local object resources 🧚.

A MIB view is defined by a collection of view subtrees (see Section 2.6), and any MIB view can be represented this way 💅. Since MIB view definitions can get huge in some cases, a convention for abbreviating them is super desirable 🎀.

The convention adopted in [4] lets you abbreviate MIB view definitions using families of view subtrees that are either included in or excluded from the definition of the relevant MIB view ✨. So here's the vibe: each SNMPv2 entity keeps a local table that defines the MIB view for each SNMPv2 context that refers to local object resources 🦋. Each entry in that table is a family of view subtrees that, depending on the entry's type, is either included in or excluded from the MIB view of some SNMPv2 context 🌸.

Each table entry represents a subtree family as a pairing of an OBJECT IDENTIFIER value (called the family name) and a bitstring value (called the family mask) 💜. The family mask shows which sub-identifiers of the family name actually matter for defining the subtree family 🧚. For any possible MIB object instance, that instance belongs to the view subtree family represented by a particular table entry if:

  • the OBJECT IDENTIFIER name of that MIB object instance has at least as many sub-identifiers as the family name for that table entry, and
  • each sub-identifier in the name of that MIB object instance matches the corresponding sub-identifier of the family name whenever the corresponding bit of the family mask is non-zero 🫶.

Now, how does an instance end up in a MIB view for a given SNMPv2 context? It all depends on which subtree families the instance belongs to, from the local table entries tied to that context 👑:

  • If a MIB object instance belongs to none of the relevant subtree families, then it is not in the MIB view for that SNMPv2 context 🙈.
  • If a MIB object instance belongs to the subtree family represented by exactly one of the relevant table entries, then it is included in, or excluded from, the relevant MIB view based on the type of that entry ✨.
  • If a MIB object instance belongs to the subtree families represented by more than one of the relevant table entries, then the type of the single winning entry decides. That winner is the one whose family name has, first, the greatest number of sub-identifiers, and, second, the lexicographically greatest family name 🔥.

A table entry whose family mask is all ones maps to exactly one view subtree: the one identified by its family name 🍓. And because the convention of [4] implicitly extends family mask values with ones, a table entry with a zero-length family mask always corresponds to a single view subtree 💖.

Here's the simplest possible setup, Table 6 🌈:

  Context    Type        Family Name    Family Mask
  lucy       included    internet       ''H

Table 6: View Definition for Minimal Agent

This one's for a minimal SNMPv2 entity with a single SNMPv2 context, where the MIB view covers all instances of all MIB objects defined within the SNMPv2 Network Management Framework 😭. The table has a single entry. The SNMPv2 context lucy is listed in the first column, and the entry type included means any MIB object instance in that subtree family can show up in lucy's MIB view 🎀. The family name is internet, and the zero-length family mask means the subtree family is just the single view subtree rooted at that node 💅.

Next up is Table 7, where one entity has multiple SNMPv2 contexts with different MIB views 🦋. The view for lucy has everything in the SNMPv2 Network Management Framework except the stuff about administering SNMPv2 parties 💀. Meanwhile, the view for ricky only has MIB object instances from the system group of the Internet-standard MIB, plus the ones used to administer SNMPv2 parties 🧚‍♀️:

   Context    Type        Family Name    Family Mask
   lucy       included    internet       ''H
   lucy       excluded    snmpParties    ''H
   ricky      included    system         ''H
   ricky      included    snmpParties    ''H

Table 7: View Definition for Multiple Contexts

Now for the more complicated example, which shows how related groups of view subtrees can be abbreviated as view subtree families (see Table 8) 🌸. Here, the MIB view for lucy includes every object instance in the system group of the Internet-standard MIB, plus some info about the second network interface on the managed device 🍓. But the interface info doesn't include the interface's speed 😤.

The family mask 'FFA0'H in the second entry means a MIB object instance belongs to that subtree family if its name starts with a prefix that puts it inside the ifEntry part of the registration hierarchy, and the eleventh sub-identifier of its name is 2 ✨. The object instance for the speed of the second network interface belongs to the subtree families from both the second and third entries. But it gets excluded from lucy's view, because the lexicographically greater of those family names is in the entry with type excluded 🔥.

The MIB view for ricky is also defined here 👑. It includes every object instance in the icmp group of the Internet-standard MIB, along with all info relevant to the fifth network interface on the managed device 🫶. On top of that, ricky's view also includes the number of octets received on the fourth attached network interface 💜.

     Context    Type        Family Name        Family Mask
     lucy       included    system             ''H
     lucy       included    { ifEntry 0 2 }    'FFA0'H
     lucy       excluded    { ifSpeed 2 }      ''H
     ricky      included    icmp               ''H
     ricky      included    { ifEntry 0 5 }    'FFA0'H
     ricky      included    { ifInOctets 4 }   ''H

Table 8: More Elaborate View Definitions

So, as the examples show, the abbreviated representation from [4] handles a wide range of MIB view setups really efficiently 🦋. Still, smart MIB design can shrink the size and complexity of the most common MIB view definitions even further 💅. On one hand, the mechanisms for configuring MIB views must impose no absolute constraints on local administrations' access policies or on the structure of MIB namespaces 🙅‍♀️. On the other hand, when the most common access policies are known, you can cut the configuration cost a bit by assigning to separate parts of the registration hierarchy the MIB objects that local policies most often need to treat differently 🧠✨.

4.4. Proxy Configuration 🧚

This section shows some examples of SNMPv2 proxy configurations 🎀. On one hand, foreign proxy configurations let you manage non-SNMP devices 🛸. On the other hand, native proxy configurations let an administrator move the heavy lifting of rich management functions off network devices whose main job isn't management 💪. And to the extent that SNMPv2 proxy agents act as points of aggregation for management information, proxy configurations can also cut down the bandwidth needed for large-scale management activities 🌈.

The example configurations in this section are simplified for clarity. Real-life configurations may need extra parties to handle clock synchronization and distribution of secrets 🔐.

4.4.1. Foreign Proxy Configuration

This section walks through an example where a SNMPv2 management station can manage network elements that don't support SNMPv2 themselves 🥺. The whole setup centers on a SNMPv2 proxy agent, which carries out SNMPv2 management operations by talking to a non-SNMPv2 device over a proprietary protocol 💖.

Table 9 shows the SNMPv2 party information stored in the SNMPv2 proxy agent's local party database 📚. Table 10 shows the proxy relationship information stored in the SNMPv2 proxy agent's local context database 🦋. Table 11 shows the SNMPv2 party information stored in the SNMPv2 management station's local party database 🌸. And Table 12 shows the access policy information in the database set up by the local administration 👑.

   Identity        groucho             chico               harpo
                   (manager)           (proxy agent)       (proxy dst)
   Domain          snmpUDPDomain       snmpUDPDomain       acmeMgmtPrtcl
   Address         1.2.3.4, 2002       1.2.3.5, 161        0x98765432
   Auth Prot       v2md5AuthProtocol   v2md5AuthProtocol   noAuth
   Auth Priv Key   "0123456789ABCDEF"  "GHIJKL0123456789"  ""
   Auth Pub Key    ""                  ""                  ""
   Auth Clock      0                   0                   0
   Auth Lifetime   300                 300                 0
   Priv Prot       noPriv              noPriv              noPriv
   Priv Priv Key   ""                  ""                  ""
   Priv Pub Key    ""                  ""                  ""

Table 9: Party Information for Proxy Agent 🎀

Context     Proxy Destination    Proxy Source    Proxy Context
ducksoup    harpo                n/a             n/a

Table 10: Proxy Relationships for Proxy Agent 💅

Okay so, Table 9 is the proxy agent's little black book of parties 📖. The proxy agent party is chico, chilling at UDP port 161 on IP address 1.2.3.5, and the manager is groucho, at UDP port 2002 on IP address 1.2.3.4. Both of them sign every message they send with v2md5AuthProtocol and their own private authentication keys, which are totally separate, bestie 🔐. Yes, those keys are shown here only for expository purposes! In real life, nobody human is supposed to see private keys. They stay locked inside the parts of the protocol implementation that actually need them 🙈.

Now harpo is a different vibe entirely 🧚. Harpo never sends or receives SNMPv2 protocol messages. Everything with harpo goes through a hypothetical proprietary protocol called acmeMgmtPrtcl 🛸. Since harpo isn't even in the SNMPv2 game, a bunch of the attributes recorded for it in the local party database just get ignored. Not me being shady, just the spec being like "not relevant here" 💀.

Table 10 lists the proxy relationships the proxy agent knows about. The big one is the SNMPv2 context ducksoup, which is basically a relationship that gets satisfied by harpo 🦋. Here's the tea: the transport domain of the proxy destination party decides how the proxy source and proxy context identities get interpreted. In this case, acmeMgmtPrtcl means the proxy source and context identities are ignored. Iconic behaviour, honestly 👑.

So how does groucho actually poke the proprietary device behind harpo? Groucho builds an SNMPv2 GetNext request, wraps it in a SnmpMgmtCom value that references the context ducksoup, and sends it off to chico at UDP port 161, IP address 1.2.3.5 📨 (see Table 11 for the party details). This request gets authenticated with the private authentication key "0123456789ABCDEF". Main character energy for sure ✨.

When chico gets that request, it checks who sent it by using its local knowledge of the key "0123456789ABCDEF" (see Table 9), and confirms the originator is groucho 🔍. Next up is the access check. Groucho is allowed to issue GetNext (as well as Get and GetBulk) requests toward chico and the context ducksoup, according to the relevant access control policy in Table 12 🗝️. So the request is accepted, yay 🎉. Then, because the local context database says ducksoup is a proxy relationship, the request gets translated into the right acmeMgmtPrtcl operations aimed at harpo. Those new operations get sent to harpo at the address 0x98765432 in the acmeMgmtPrtcl domain 🚀.

Once the proprietary exchange between the proxy agent and the device wraps up (and only when it does, bestie ⏳), chico builds an SNMPv2 Response to relay the results back to groucho, again referring to the context ducksoup 💌. This response gets authenticated for origin and integrity using v2md5AuthProtocol and the private authentication key "GHIJKL0123456789", which is the one specified for transmissions from chico 🔏. It's then sent to groucho at IP address 1.2.3.4 and UDP port 2002, which is the source address of the original request. Send it back to where it came from, periodt 📬.

When groucho receives that response, it verifies that the sender is chico by using its local knowledge (see Table 11) of the key "GHIJKL0123456789" 🕵️‍♀️. Then it checks the access policy (Table 12). Because chico is authorized to send Response communications to groucho with respect to ducksoup, the response gets accepted, and the interrogation of the proprietary device is complete 🥳✅.

Here's the part that's honestly so cool 😭. The local database of party information at the proxy agent (Table 9) doesn't have to be static, and it doesn't have to be configured exclusively by the management station either 🌈. Imagine acmeMgmtPrtcl was a proprietary, MAC-layer mechanism for managing stations attached to a local area network. In that world, the SNMPv2 party chico would live at an SNMPv2 proxy agent plugged into that LAN, and by joining in on the LAN protocols, it could notice when stations attach to and detach from the network 👀. The proxy agent could then keep its local party database up to date. For every new LAN station it detects, it adds an entry to its party database that's analogous to the one for harpo (representing the new station itself), and it also adds an entry to its context database that's analogous to the one for ducksoup (representing a proxy relationship for that new station in the SNMPv2 domain) 🧩.

And the payoff? A SNMPv2 management station can poke at the proxy agent's party database over SNMPv2 and discover and interact with new stations as they show up on the LAN 🎀💖.

4.4.2. Native Proxy Configuration

Let's glow up to native proxies ✨. This example configuration supports SNMPv2 native proxy operations, which means indirect interaction between an SNMPv2 agent and a management station, mediated by a second SNMPv2 (proxy) agent 🔁.

This setup is pretty similar to the foreign proxy one we just did. The twist is that the party associated with the identity harpo now receives messages via the SNMPv2, so it talks to the SNMPv2 proxy agent chico using authenticated SNMPv2 communications 🫶.

Table 13 shows the SNMPv2 party info recorded in the SNMPv2 proxy agent's local party database. Table 14 shows the proxy relationship info recorded in the proxy agent's local context database. Table 11 shows the SNMPv2 party info recorded in the SNMPv2 management station's local party database (we already met it, so no need to re-read it). And Table 15 shows the access policy info specified by the local administration 📋.

Identity          groucho              chico
                  (manager)            (proxy agent)
Domain            snmpUDPDomain        snmpUDPDomain
Address           1.2.3.4, 2002        1.2.3.5, 161
Auth Prot         v2md5AuthProtocol    v2md5AuthProtocol
Auth Priv Key    "0123456789ABCDEF"   "GHIJKL0123456789"
Auth Pub Key      ""                   ""
Auth Clock        0                    0
Auth Lifetime     300                  300
Priv Prot         noPriv               noPriv
Priv Priv Key     ""                   ""
Priv Pub Key      ""                   ""


Identity          harpo                   zeppo
                  (proxy dst)          (proxy src)
Domain            snmpUDPDomain        snmpUDPDomain
Address           1.2.3.6, 161         1.2.3.5, 161
Auth Prot         v2md5AuthProtocol    v2md5AuthProtocol
Auth Priv Key    "MNOPQR0123456789"   "STUVWX0123456789"
Auth Pub Key      ""                   ""
Auth Clock        0                    0
Auth Lifetime     300                  300
Priv Prot         noPriv               noPriv
Priv Priv Key     ""                   ""
Priv Pub Key      ""                   ""

Table 13: Party Information for Proxy Agent 🍓

Context     Proxy Destination    Proxy Source    Proxy Context
ducksoup    harpo                zeppo           bigstore
bigstore    groucho              chico           ducksoup

Table 14: Proxy Relationships for Proxy Agent 🌸

Target     Subject    Context     Privileges
chico      groucho    ducksoup     35 (Get, GetNext & GetBulk)
groucho    chico      ducksoup    132 (Response & SNMPv2-Trap)
harpo      zeppo      bigstore     35 (Get, GetNext & GetBulk)
zeppo      harpo      bigstore    132 (Response & SNMPv2-Trap)

Table 15: Access Information for Native Proxy 👑

As you can see in Table 13, the proxy agent party lives at UDP port 161, IP address 1.2.3.5, and goes by the party identity chico 💖. The example manager is at UDP port 2002, IP address 1.2.3.4, identity groucho 🎀. The proxy source party is at UDP port 161, IP address 1.2.3.5, identity zeppo ✨. And the proxy destination party is at UDP port 161, IP address 1.2.3.6, identity harpo 🦋. All four SNMPv2 parties authenticate their messages, for origin and integrity, with the authentication protocol v2md5AuthProtocol, and each one has its own private authentication key 🔐. The key values are "0123456789ABCDEF", "GHIJKL0123456789", "MNOPQR0123456789", and "STUVWX0123456789". They're only shown here so the example makes sense 🙈. In real life, humans aren't supposed to see private keys at all. They stay locked inside the parts of the implementation that need them 💅.

Table 14 lists the proxy relationships the proxy agent knows about 🌸. The big one is the SNMPv2 context ducksoup, which is a relationship that gets satisfied when zeppo talks to harpo and points at the SNMPv2 context bigstore. Very neat 👑.

So, groucho wants to interrogate the device behind harpo 👀. Groucho builds a SNMPv2 GetNext request, wraps it in a SnmpMgmtCom value that references the SNMPv2 context ducksoup, and sends it to chico at UDP port 161 and IP address 1.2.3.5 (see Table 11) 📨. The request is authenticated with the private key "0123456789ABCDEF".

When chico gets that request, it checks the sender is really groucho by using its local copy (see Table 13) of "0123456789ABCDEF" 🔍. Groucho is allowed to send GetNext (plus Get and GetBulk) to chico for the context ducksoup under the relevant access control policy (Table 15), so the request gets accepted 🙌. The local database says ducksoup is a proxy relationship, so chico translates the request into a fresh SNMPv2 GetNext from zeppo to harpo, referencing the context bigstore 🔄. That new message is authenticated with "STUVWX0123456789" and sent to harpo at 1.2.3.6 🚀.

When harpo gets this new request, it verifies that the sender is zeppo using its local knowledge of "STUVWX0123456789" ✅. Zeppo is authorized to send GetNext (plus Get and GetBulk) to harpo for the context bigstore under Table 15, so harpo accepts it 💜. Harpo then builds a SNMPv2 Response for zeppo, referencing bigstore, with the query results 📦. That response is authenticated, for origin and integrity, with "MNOPQR0123456789" and sent back to zeppo at IP address 1.2.3.5, which is where the corresponding request came from 💌.

When zeppo gets the response, it confirms the sender is harpo using its local knowledge (see Table 13) of "MNOPQR0123456789" 🧐. Harpo is allowed to send Response messages to zeppo for bigstore under Table 15, so the response is accepted. Zeppo uses it to build a response to the original GetNext, this time indicating the SNMPv2 context ducksoup 🎁. That response goes from chico to groucho, is authenticated with "GHIJKL0123456789", and is sent to groucho at IP address 1.2.3.4, which was the source of the original request 🥰.

Last step: groucho checks the response came from chico using its local knowledge (see Table 13) of "GHIJKL0123456789" 🕵️‍♀️. Chico is allowed to send Response messages to groucho for ducksoup under Table 15, so the response is accepted, and the whole interrogation is complete 🎉✨.

4.5. Public Key Configuration

This section gives an example setup built on a hypothetical security protocol 🧪. The protocol would use asymmetric (public key) cryptography to provide data origin authentication, but not protection against disclosure 🙅‍♀️. The example shows the administrative model working fine with public key technology, and it's pretty easy to see how you'd extend it to protect against disclosure too 💡.

     Identity          ollie                stan
                       (agent)              (manager)
     Domain            snmpUDPDomain        snmpUDPDomain
     Address           1.2.3.4, 161         1.2.3.5, 2004
     Auth Prot         pkAuthProtocol       pkAuthProtocol
     Auth Priv Key     "0123456789ABCDEF"   ""
     Auth Pub Key      "0123456789abcdef"   "ghijkl0123456789"
     Auth Clock        0                    0
     Auth Lifetime     300                  300
     Priv Prot         noPriv               noPriv
     Priv Priv Key     ""                   ""
     Priv Pub Key      ""                   ""

Table 16: Party Information for Public Key Agent

The example has one SNMPv2 agent talking to one SNMPv2 management station 🤝. Tables 16 and 17 hold the party information for the agent and the manager, respectively, and Table 5 has the local access policy that both the manager and the agent know 📋.

     Identity          ollie                stan
                       (agent)              (manager)
     Domain            snmpUDPDomain        snmpUDPDomain
     Address           1.2.3.4, 161         1.2.3.5, 2004
     Auth Prot         pkAuthProtocol       pkAuthProtocol
     Auth Priv Key     ""                   "GHIJKL0123456789"
     Auth Pub Key      "0123456789abcdef"   "ghijkl0123456789"
     Auth Clock        0                    0
     Auth Lifetime     300                  300
     Priv Prot         noPriv               noPriv
     Priv Priv Key     ""                   ""
     Priv Pub Key      ""                   ""

Table 17: Party Information for Public Key Management Station

As Table 16 shows, the example agent party is at UDP port 161, IP address 1.2.3.4, with the identity ollie 🐣. The example manager is at UDP port 2004, IP address 1.2.3.5, with the identity stan 🌟. Both ollie and stan authenticate every message they generate, for origin and integrity, using the hypothetical SNMPv2 authentication protocol pkAuthProtocol and their own distinct private authentication keys 🔑. The private key values "0123456789ABCDEF" and "GHIJKL0123456789" are shown here just for the example 🙈. As before, humans don't normally get to see private keys. They stay inside the parts of the implementation that need them 💅.

Honestly, this setup is almost identical to the minimal, secure SNMPv2 agent we looked at earlier 😌. The biggest difference is that neither party knows the private key the other one uses to authenticate its messages 🫣. Instead, every time an authenticated SNMPv2 message comes in, the receiver checks who sent it by running an asymmetric cryptographic algorithm on the message together with the sender's public authentication key 🧩. So in this setup, the agent knows the manager's public key "ghijkl0123456789" but not its private key "GHIJKL0123456789" 🗝️. Likewise, the manager knows the agent's public key "0123456789abcdef" but not its private key "0123456789ABCDEF" 💜.

5. Security Considerations 🚨

To take part in the administrative model described in this memo, SNMPv2 implementations must support local, non-volatile storage of the local database of party information 💾. That's a big deal, so the authors made every attempt to keep the amount of non-volatile storage needed as small as possible 🥺.

6. Acknowledgements 🫶

This document is based, almost entirely, on RFC 1351 🌷.

7. References 📚

Okay so bestie, the references section is where the RFC lists every doc it leans on, and this one has seven of them, all about SNMPv2 and its whole family of pieces. Let's go through them, no cap. 💅

  • [1] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. 🌸
  • [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 🦋
  • [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 🎀
  • [4] McCloghrie, K., and Galvin, J., "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN Systems, Trusted Information Systems, April 1993. 🧚
  • [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1449, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 🌈
  • [6] Galvin, J., and McCloghrie, K., "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April 1993. 🔐
  • [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1450, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 💜

8. Authors' Addresses 💖

Okay and last but not least, here's where you can find the two authors who wrote this one. Iconic. ✨

James M. Galvin 🫶 Trusted Information Systems, Inc. 3060 Washington Road, Route 97 Glenwood, MD 21738

Phone: +1 301 854-6889 EMail: galvin@tis.com

Keith McCloghrie 👑 Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043 US

Phone: +1 415 966 7934 Email: kzm@hls.com

📦 where this page comes from