RFC 1351

RFC 1351: SNMP Administrative Model 🎀

okay bestie, here's the lineup. This is RFC 1351, and the title is SNMP Administrative Model 💅

• Written by: J. Davin (MIT Laboratory for Computer Science), J. Galvin (Trusted Information Systems, Inc.), and K. McCloghrie (Hughes LAN Systems, Inc.) 🫶
• Working group: Network Working Group
• Category: IAB standards track protocol (more on that in the Status section, it's giving official 📜)
• Date: July 1992
• Obsoletes / Updates: this one doesn't list either in its header, so there's nothing to obsolete or update here 🙈

Here's the table of contents, copied exactly as it's written:

   1.    Abstract  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.    Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
   3.    Elements of the Model . . . . . . . . . . . . . . . . . . .  2
   3.1   SNMP Party  . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.2   SNMP Protocol Entity  . . . . . . . . . . . . . . . . . . .  6
   3.3   SNMP Management Station . . . . . . . . . . . . . . . . . .  6
   3.4   SNMP Agent  . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.5   View Subtree  . . . . . . . . . . . . . . . . . . . . . . .  7
   3.6   MIB View  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.7   SNMP Management Communication . . . . . . . . . . . . . . .  8
   3.8   SNMP Authenticated Management Communication . . . . . . . .  9
   3.9   SNMP Private Management Communication   . . . . . . . . . .  9
   3.10  SNMP Management Communication Class . . . . . . . . . . . . 10
   3.11  SNMP Access Control Policy  . . . . . . . . . . . . . . . . 11
   3.12  SNMP Proxy Party  . . . . . . . . . . . . . . . . . . . . . 12
   3.13  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . 13
   3.13.1  Generating a Request  . . . . . . . . . . . . . . . . . . 13
   3.13.2  Processing a Received Communication . . . . . . . . . . . 15
   3.13.3  Generating a Response . . . . . . . . . . . . . . . . . . 17
   4.    Application of the Model  . . . . . . . . . . . . . . . . . 17
   4.1   Non-Secure Minimal Agent Configuration  . . . . . . . . . . 17
   4.2   Secure Minimal Agent Configuration  . . . . . . . . . . . . 20
   4.3   Proxy Configuration   . . . . . . . . . . . . . . . . . . . 21
   4.3.1   Foreign Proxy Configuration . . . . . . . . . . . . . . . 22
   4.3.2   Native Proxy Configuration  . . . . . . . . . . . . . . . 25
   4.4   Public Key Configuration  . . . . . . . . . . . . . . . . . 27
   4.5   MIB View Configurations . . . . . . . . . . . . . . . . . . 29
   5.    Compatibility . . . . . . . . . . . . . . . . . . . . . . . 33
   6.    Security Considerations . . . . . . . . . . . . . . . . . . 33
   7.    References  . . . . . . . . . . . . . . . . . . . . . . . .
   8.    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . 34

---

Status of this Memo 📌

okay so this doc specifies an IAB standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🌸 For where the protocol stands in standardization and its status, go check the current edition of the "IAB Official Protocol Standards." And distribution of this memo is unlimited, so share it with whoever 💌

1. Abstract ☁️

This memo elaborates on the SNMP administrative model set out in [1]. The model gives us a unified conceptual basis for administering SNMP protocol entities so they can support:

• authentication and integrity,
• privacy,
• access control, and
• the cooperation of multiple protocol entities.

Please send comments to the SNMP Security Developers mailing list (snmp-sec-dev@tis.com) 💖

2. Introduction 🦋

This memo also elaborates on the SNMP administrative model set out in [1], so yes, same model, it's the main character 👑 It describes how the elaborated model gets applied to realize effective network management across a variety of configurations and environments.

The model described here uses distinct identities for peers that exchange SNMP messages. That makes it a departure from the community-based administrative model in [1], and honestly it's a glow-up 💅 By unambiguously identifying the source and intended recipient of each SNMP message, this new strategy improves on the historical community scheme in two ways. It supports a more convenient access control model, and it allows for effective use of asymmetric (public key) security protocols in the future ✨

3. Elements of the Model ✨

3.1 SNMP Party 🎀

okay so a SNMP party is a conceptual, virtual execution context. Its operation is restricted (for security or other purposes) to an administratively defined subset of all possible operations of a particular SNMP protocol entity (see Section 3.2). Whenever a SNMP protocol entity processes a SNMP message, it does so by acting as a SNMP party, and that means it's restricted to the set of operations defined for that party 🧚 The set of possible operations for one SNMP party may be overlapping or disjoint with the sets for other SNMP parties. It may also be a proper or improper subset of all possible operations of the SNMP protocol entity.

Architecturally, each SNMP party comprises:

• a single, unique party identity,
• a single authentication protocol and its associated parameters, which are used to authenticate all protocol messages originated by the party as to origin and integrity,
• a single privacy protocol and its associated parameters, which protect all protocol messages received by the party from disclosure,
• a single MIB view (see Section 3.6) that all management operations performed by the party are applied to, and
• a logical network location where the party executes, described by a transport protocol domain and transport addressing information.

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

      SnmpParty ::= SEQUENCE {
        partyIdentity
           OBJECT IDENTIFIER,
        partyTDomain
           OBJECT IDENTIFIER,
        partyTAddr
           OCTET STRING,
        partyProxyFor
           OBJECT IDENTIFIER,
        partyMaxMessageSize
           INTEGER,
        partyAuthProtocol
           OBJECT IDENTIFIER,
        partyAuthClock
           INTEGER,
        partyAuthLastMsg
           INTEGER,
        partyAuthNonce
           INTEGER,

        partyAuthPrivate
           OCTET STRING,
        partyAuthPublic
           OCTET STRING,
        partyAuthLifetime
           INTEGER,
        partyPrivProtocol
           OBJECT IDENTIFIER,
        partyPrivPrivate
           OCTET STRING,
        partyPrivPublic
           OCTET STRING
      }

For each SnmpParty value that represents a SNMP party, the following 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 of a transport domain is rfc1351Domain (SNMP over UDP, using SNMP parties).
• Its partyTAddr component is called the transport addressing information. It's the transport service address where the party receives network management traffic.
• Its partyProxyFor component is called the proxied party. It's the identity of a second SNMP party or other management entity that might need to be involved in order to satisfy received management requests. Here, the value noProxy means the party responds to received management requests by entirely local mechanisms 🍓
• Its partyMaxMessageSize component is called the maximum message size. It's the length in octets of the largest SNMP message this party is prepared to accept.
• Its partyAuthProtocol component is called the authentication protocol. It identifies a protocol and a mechanism that authenticate all messages generated by the party as to integrity and origin. 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 that's specific to the party. What it means depends on the authentication protocol.
• Its partyAuthLastMsg component is called the last-timestamp. It's a notion of time tied to the most recent, authentic protocol message generated by the party. What it means depends on the authentication protocol.
• Its partyAuthNonce component is called the nonce. It's a monotonically increasing integer tied to the most recent, authentic protocol message generated by 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 generated by the party. What it means depends on the authentication protocol.
• Its partyPrivProtocol component is called the privacy protocol. It identifies a protocol and a mechanism that protect all protocol messages received by the party from disclosure. 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.

If, for all SNMP parties realized by a SNMP protocol entity, the authentication protocol is noAuth and the privacy protocol is noPriv, then that protocol entity is called non-secure. Yikes, but it's a real category 😭

3.2 SNMP Protocol Entity 🧚

A SNMP protocol entity is an actual process that performs network management operations by generating and/or responding to SNMP protocol messages in the manner specified in [1]. When a protocol entity is acting as a particular SNMP party (see Section 3.1), its operation must be restricted to the subset of all possible operations that is administratively defined for that party 🫶

By definition, a SNMP protocol entity's operation needs no concurrency between processing any single protocol message (by a particular SNMP party) and processing any other protocol message (by a potentially different SNMP party). So an implementation of a SNMP protocol entity that supports more than one party need not be multi-threaded. However, there may be situations where implementors choose to use multi-threading 🌈

Architecturally, every SNMP entity keeps its own local database 💅 of all the SNMP parties it knows about. That includes the ones it runs itself, the ones it handles by proxy for remote parties or devices, and the ones that get run by remote entities 🧚. On top of that, every SNMP protocol entity keeps a local database for its access control policy (see Section 3.11) 🔐, which spells out the access privileges given to each known SNMP party 🎀.

3.3. SNMP Management Station ✨

Okay bestie, a SNMP management station is the role a SNMP party plays when it kicks off SNMP management operations by generating the right SNMP protocol messages, or when it receives and processes trap notifications 📣.

Sometimes people use the term SNMP management station for partial implementations of SNMP (think graphics workstations 🖥️) that focus on just this role. These partials can offer convenient local invocation of management services, but they may give you little or no support for doing SNMP management operations on behalf of remote protocol users 🥺.

3.4. SNMP Agent 🤖

A SNMP agent is the role a SNMP party plays when it carries out SNMP management operations in response to received SNMP protocol messages, like the ones a SNMP management station sends (see Section 3.3) 📨.

Sometimes the term SNMP agent gets used for partial implementations (in embedded systems, for example 🔌) that focus on this role. These partials provide for carrying out SNMP management operations on behalf of remote users of management services, but they may provide little or no support for invoking those services locally 💤.

3.5. View Subtree 🌳

A view subtree is the set of all MIB object instances that share 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 common to all of the (potential) MIB object instances in that subtree 🔎.

3.6. MIB View 🗺️

A MIB view is a subset of all instances of all object types defined under the Internet-standard SMI [2] (so, basically the whole universal set of MIB object instances 🌍), subject to 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 (say, in different agents) must be contained within different MIB views. In other words, 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 🌲.

3.7. SNMP Management Communication 💌

A SNMP management communication is a message from one specified SNMP party to a second specified SNMP party, about management information that lives in the MIB view of the appropriate party. A management communication can be:

• a query by the originating party about information in the MIB view of the addressed party (for example getRequest and getNextRequest) 🔍,
• an indicative assertion to the addressed party about information in the MIB view of the originating party (for example getResponse or trapNotification) 📢, or
• an imperative assertion by the originating party about information in the MIB view of the addressed party (for example setRequest) 👑.

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

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

For each SnmpMgmtCom value that represents a SNMP management communication, the following statements are true:

• Its dstParty component is called the destination, and it identifies the SNMP party the communication is aimed at 🎯.
• Its srcParty component is called the source, and it identifies the SNMP party the communication came from 📤.
• Its pdu component has the form and significance that [1] gives it 📦.

3.8. SNMP Authenticated Management Communication 🫶

A SNMP authenticated management communication is a SNMP management communication (see Section 3.7) where the originating SNMP party is (possibly) reliably identified, and the integrity of the transmission of the communication is (possibly) protected 🔐. It's represented by an ASN.1 value with this syntax:

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

For each SnmpAuthMsg value that represents a SNMP authenticated management communication, the following statements are true:

• Its authInfo component is called the authentication information. It holds whatever the authentication protocol in use needs from the SNMP party that originated the message. What it means is totally specific to that protocol, and it has no effect on the application semantics of the communication other than being used by the authentication protocol to decide whether the communication is authentic or not 🕵️‍♀️.
• Its authData component is called the authentication data, and it represents a SNMP management communication.

3.9. SNMP Private Management Communication 🤫

A SNMP private management communication is a SNMP authenticated management communication (see Section 3.8) that is (possibly) protected from disclosure. It's represented by an ASN.1 value with this syntax:

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

For each SnmpPrivMsg value that represents a SNMP private management communication, the following statements are true:

• Its privDst component is called the privacy destination, and it identifies the SNMP party the communication is directed to 🎯.
• Its privData component is called the privacy data. It represents the (possibly encrypted) serialization (following the conventions of [3] and [1]) of a SNMP authenticated management communication (see Section 3.8) 🔒.

3.10. SNMP Management Communication Class 🧩

A SNMP management communication class corresponds to a specific SNMP PDU type defined in [1]. A management communication class is represented by an ASN.1 INTEGER value according to the type of the identifying PDU (see Table 1) 🏷️.

              Get             1
              GetNext         2
              GetResponse     4
              Set             8
              Trap           16

    Table 1: Management Communication Classes

The value by which a communication class is represented is computed as 2 raised to the value of the ASN.1 context-specific tag for the appropriate SNMP PDU 🧮.

A set of management communication classes is represented by the ASN.1 INTEGER value that is the sum of the representations of the communication classes in that set. The null set is represented by the value zero 0️⃣.

3.11. SNMP Access Control Policy 🚪

A SNMP access control policy is a specification of a local access policy in terms of the network management communication classes that are authorized between pairs of SNMP parties. Architecturally, such a specification comprises three parts:

• the targets of SNMP access control: the SNMP parties that may perform management operations as requested by management communications received from other parties,
• the subjects of SNMP access control: the SNMP parties that may request, by sending management communications to other parties, that management operations be performed, and
• the policy that specifies the classes of SNMP management communications that a particular target is authorized to accept from a particular subject.

Access to individual MIB object instances is determined implicitly, since by definition each (target) SNMP party performs operations on exactly one MIB view 👀. So defining the permitted access of a (reliably) identified subject party to a particular target party effectively defines the access that subject has to that target's MIB view and, accordingly, to particular MIB object instances.

Conceptually, a SNMP access policy is represented by a collection of ASN.1 values with the following syntax:

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

For each such value that represents one part of a SNMP access policy, the following statements are true:

• Its aclTarget component is called the target, and it identifies the SNMP party to which the partial policy permits access 🎯.
• Its aclSubject component is called the subject, and it identifies the SNMP party to which the partial policy grants privileges 🎀.
• Its aclPrivileges component is called the privileges. It represents a set of SNMP management communication classes that are authorized to be processed by the specified target party when received from the specified subject party 💅.

3.12. SNMP Proxy Party 🪞

A SNMP proxy party is a SNMP party that performs management operations by communicating with another, logically remote party.

When communication between a logically remote party and a SNMP proxy party is via the SNMP (over any transport protocol), then the proxy party is called a SNMP native proxy party 🌐. Deploying SNMP native proxy parties 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 SNMP proxy party is not via the SNMP, then the proxy party is called a SNMP foreign proxy party 👽. Deploying foreign proxy parties lets otherwise unmanageable devices or portions of an internet be managed via the SNMP 🛸.

The transparency principle that defines the behavior of a SNMP party in general applies in particular to a SNMP proxy party:

The manner in which one SNMP party processes SNMP protocol messages received from another SNMP party is entirely transparent to the latter. 🫧

The transparency principle comes straight from the historical SNMP philosophy of divorcing architecture from implementation. Lots of the most valuable benefits in both the information and distribution models of the management framework are down to this split, and it's the architectural cornerstone that large management systems may be built on 🌈. Consistent with this philosophy, even though SNMP proxy agents in certain environments may look a lot like a transport-layer bridge, this particular implementation strategy (or any other!) does not merit special recognition either in the SNMP management architecture or in standard mechanisms for proxy administration 💖.

Okay so the transparency principle comes with a sneaky little implication, bestie 👀 The semantics of SNMP management operations have to be preserved between any two SNMP peers, no changes allowed 💅 And a Set operation's "as if simultaneous" vibe is genuinely hard to guarantee if its scope reaches management information living at multiple network locations 😭 So proxy setups that let Set operations hit information at several locations are discouraged 🙅‍♀️. The architecture doesn't outright ban them, though, in those rare cases where they could be supported in a conformant way ✨

Also implicit in transparency is that a management station gets zero info about how a proxy agent is making its requests happen 🫣 From the station's point of view, it should seem (except for the transport address, obviously) like it's talking straight to the proxied device over SNMP 🦋 So a timeout between the proxy agent and its proxied device should show up as a timeout between the management station and the proxy agent. Same energy here: an error response from a proxied device should, as much as possible, be represented by the matching error response between the proxy agent and the management station 💖

---

3.13 Procedures ✨

This section is the step-by-step for how an SNMP protocol entity processes SNMP messages 📋 Lowkey the best part: none of it depends on which authentication and privacy protocols are in use 🧚

3.13.1 Generating a Request 🎀

This section covers the procedure an SNMP protocol entity follows whenever a management request or a trap notification is about to be transmitted by an SNMP party 📤

1. Construct an ASN.1 SnmpMgmtCom value. Its srcParty component identifies the originating party, its dstParty component identifies the receiving party, and its other component represents the desired management operation 💅
2. Consult the local database to determine the authentication protocol and other relevant information for the originating SNMP party 🔍
3. Construct an ASN.1 SnmpAuthMsg value with the following properties 🫶
   • Its authInfo component is constructed according to the authentication protocol specified for the originating party. In particular, if the authentication protocol for the originating SNMP party is identified as noAuth, then this component corresponds to the OCTET STRING value of zero length.
   • Its authData component is the constructed SnmpMgmtCom value.
4. Consult the local database to determine the privacy protocol and other relevant information for the receiving SNMP party 🔐
5. Construct an ASN.1 SnmpPrivMsg value with the following properties 🌸
   • Its privDst component identifies the receiving SNMP party.
   • Its privData component is the (possibly encrypted) serialization of the SnmpAuthMsg value, following the conventions of [3] and [1]. In particular, if the privacy protocol for the receiving SNMP party is identified as noPriv, then the privData component is unencrypted. Otherwise, the privData component is processed according to the privacy protocol.
6. Serialize the constructed SnmpPrivMsg value according to the conventions of [3] and [1] 🧃
7. Transmit the serialized SnmpPrivMsg value using the transport address and transport domain for the receiving SNMP party 🚀

3.13.2 Processing a Received Communication 📥

This section covers the procedure an SNMP protocol entity follows whenever a management communication is received. This is where the bouncer energy lives 🚪💀

1. If the received message is not the serialization (following the conventions of [3] and [1]) of an ASN.1 SnmpPrivMsg value, then that message is discarded without further processing 🗑️
2. Consult the local database for information about the receiving SNMP party identified by the privDst component of the SnmpPrivMsg value 🔎
3. If information about the receiving SNMP party is absent from the local database, or specifies a transport domain and address which indicates that the receiving party's operation is not realized by the local SNMP protocol entity, then the received message is discarded without further processing 🙅‍♀️
4. Construct an ASN.1 OCTET STRING value (possibly by decryption, according to the privacy protocol in use) from the privData component of said SnmpPrivMsg value. In particular, if the privacy protocol recorded for the party is noPriv, then the OCTET STRING value corresponds exactly to the privData component of the SnmpPrivMsg value 🧩
5. If the OCTET STRING value is not the serialization (following the conventions of [3] and [1]) of an ASN.1 SnmpAuthMsg value, then the received message is discarded without further processing 🫠
6. If the dstParty component of the authData component of the obtained SnmpAuthMsg value is not the same as the privDst component of the SnmpPrivMsg value, then the received message is discarded without further processing 🚫
7. Consult the local database for information about the originating SNMP party identified by the srcParty component of the authData component of the SnmpAuthMsg value 📖
8. If information about the originating SNMP party is absent from the local database, then the received message is discarded without further processing 👋
9. Evaluate the obtained SnmpAuthMsg value according to the authentication protocol and other relevant information associated with the originating SNMP party in the local database. In particular, if the authentication protocol is identified as noAuth, then the SnmpAuthMsg value is always evaluated as authentic ✅
10. If the SnmpAuthMsg value is evaluated as unauthentic, then the received message is discarded without further processing, and an authentication failure is noted 🚨
11. Extract the ASN.1 SnmpMgmtCom value from the authData component of the SnmpAuthMsg value 📦
12. Consult the local database for the access privileges permitted by the local access policy to the originating SNMP party with respect to the receiving SNMP party 🗝️
13. Determine the management communication class from the ASN.1 tag value associated with the SnmpMgmtCom value 🏷️
14. If the management communication class of the received message is either 16 or 4 (i.e., Trap or GetResponse) and this class is not among the access privileges, then the received message is discarded without further processing 🙈
15. If the management communication class of the received message is not among the access privileges, then the received message is discarded without further processing after generation and transmission of a response message. This response message is directed to the originating SNMP party on behalf of the receiving SNMP party. Its var-bind-list and request-id components are identical to those of the received request. Its error-index component is zero and its error-status component is readOnly 📖🍓
16. If the proxied party associated with the receiving SNMP party in the local database is identified as noProxy, then the management operation represented by the SnmpMgmtCom value is performed by the receiving SNMP protocol entity with respect to the MIB view identified with the receiving SNMP party, according to the procedures set forth in [1] 🏠
17. If the proxied party associated with the receiving SNMP party in the local database is not identified as noProxy, then the management operation represented by the SnmpMgmtCom value is performed through appropriate cooperation between the receiving SNMP party and the identified proxied party. In particular, if the transport domain associated with the identified proxied party in the local database is rfc1351Domain, then the operation requested by the received message is performed by generating a corresponding request to the proxied party on behalf of the receiving party. If the received message requires a response from the local SNMP protocol entity, then that response is subsequently generated from the response (if any) received from the proxied party corresponding to the newly generated request. 🤝✨

3.13.3 Generating a Response 💌

This section covers the procedure an SNMP protocol entity follows whenever a response to a management request is generated.

The procedure for generating a response is identical to the procedure for transmitting a request (see Section 3.13.1), except for how the transport domain and address information is derived. Here, the response is sent using the transport domain and address from which the corresponding request originated, even if that's different from the transport information recorded in the local database 🦋

---

4. Application of the Model 🌈

This section describes how the administrative model set forth above is applied to realize effective network management in a variety of configurations and environments. Several types of administrative configurations are identified, and an example of each is presented 🧁

4.1 Non-Secure Minimal Agent Configuration 🌱

This section presents an example configuration for a minimal, non-secure SNMP agent that interacts with one or more SNMP management stations. Table 2 presents information about SNMP parties that is known both to the minimal agent and to the manager, while Table 3 presents similarly common information about the local access policy 📋

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

Suppose that the managing party george wishes to interrogate the agent named gracie by issuing a SNMP GetNext request message. The manager consults its local database of party information. Because the authentication protocol for the party george is recorded as noAuth, the GetNext request message generated by the manager is not

Okay, the party list for our minimal agent is up first 💅

    Identity          gracie                george
                      (agent)               (manager)
    Domain            rfc1351Domain         rfc1351Domain
    Address           1.2.3.4, 161          1.2.3.5, 2001
    Proxied Party     noProxy               noProxy
    Auth Prot         noAuth                noAuth
    Auth Priv Key     ""                    ""
    Auth Pub Key      ""                    ""
    Auth Clock        0                     0
    Auth Last Msg     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   Privileges
              gracie    george    3
              george    gracie    20

        Table 3: Access Information for Minimal Agent

So picking up right where we left off 🦋 the request is authenticated as to origin and integrity. Because, according to the manager's database, the privacy protocol for the party gracie is noPriv, the GetNext request message is not protected from disclosure.

Nothing fancy happens here 🎀 the message 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 the party gracie.

When the GetNext request lands at the agent, the agent pulls out the identity of the party it's aimed at (gracie) and checks its local database of party information. Because the privacy protocol for gracie is recorded as noPriv, the message is assumed not to be protected from disclosure. Then it grabs the identity of the originating party (george) and checks the local party database again. Because the authentication protocol for george is recorded as noAuth, the message is immediately accepted as authentic 🫶

The received message only gets fully processed if the access policy database local to the agent authorizes GetNext request communications by the party george with respect to the agent party gracie. The access policy database in Table 3 authorizes that (as well as Get operations) ✨

Once the request is processed, a GetResponse message is generated, with gracie as the source party and george, the party the request came from, as the destination party. Because the authentication protocol for gracie is recorded in the local party database as noAuth, the GetResponse message is not authenticated as to origin or integrity. Because, according to the local database, the privacy protocol for george is noPriv, the response is not protected from disclosure. The response goes out to the transport address the original request came from -- without regard for the transport address associated with george in the local database 🌸

When the response reaches the manager, it pulls out the identity it's directed at (george) and checks the local database of party information. Because the privacy protocol for george is recorded as noPriv, the response is assumed not to be protected from disclosure. Then it grabs the originating party's identity (gracie) and checks the database again. Because the authentication protocol for gracie is recorded as noAuth, the response is immediately accepted as authentic 💖

The received message only gets fully processed if the access policy database local to the manager authorizes GetResponse communications by the party gracie with respect to the manager party george. The access policy database in Table 3 authorizes those response messages (as well as Trap messages) 👑

---

4.2 Secure Minimal Agent Configuration

This section shows an example configuration for a secure, minimal SNMP agent that talks to a single SNMP management station 🔐 Table 4 lists SNMP party info that's known to both the minimal agent and the manager, and Table 5 lists similarly shared info about the local access policy.

The manager and agent interact in this setup a lot like the non-secure minimal agent we just looked at -- except now every protocol message is authenticated as to origin and integrity and protected from disclosure 🧚 This example needs encryption so that secret keys can be distributed over SNMP itself. A more elaborate example, with one more pair of SNMP parties, could swap non-secret info in authenticated messages without paying the cost of encryption.

An actual secure agent setup may need SNMP parties whose authentication and privacy protocols are noAuth and noPriv, respectively, so clock synchronization can happen (see [4]). We're leaving those extra parties out of this example for clarity 🙈

     Identity          ollie                stan
                       (agent)              (manager)
     Domain            rfc1351Domain        rfc1351Domain
     Address           1.2.3.4, 161         1.2.3.5, 2001
     Proxied Party     noProxy              noProxy
     Auth Prot         md5AuthProtocol      md5AuthProtocol
     Auth Priv Key     "0123456789ABCDEF"   "GHIJKL0123456789"
     Auth Pub Key      ""                   ""
     Auth Clock        0                    0
     Auth Last Msg     0                    0
     Auth Lifetime     500                  500
     Priv Prot         desPrivProtocol      desPrivProtocol
     Priv Priv Key     "MNOPQR0123456789"   "STUVWX0123456789"
     Priv Pub Key      ""                   ""

      Table 4: Party Information for Secure Minimal Agent

               Target   Subject   Privileges
               ollie    stan      3
               stan     ollie     20

      Table 5: Access Information for Secure Minimal Agent

As Table 4 shows, the example agent party runs at UDP port 161 at IP address 1.2.3.4 under the identity ollie, and the example manager runs at UDP port 2001 at IP address 1.2.3.5 under the identity stan. At minimum, a secure SNMP agent implementation must provide for administrative configuration (and non-volatile storage) of relevant information about two SNMP parties: itself and a remote peer. Both ollie and stan authenticate every message they generate using the SNMP authentication protocol md5AuthProtocol and their own distinct, private authentication keys. Those private authentication key values ("0123456789ABCDEF" and "GHIJKL0123456789") are shown here just for expository purposes 🎀 In real life, private authentication keys aren't normally visible to humans. They stay confined to the parts of the protocol implementation that need them 🔒

When using md5AuthProtocol, the public authentication key for each SNMP party is never used in authentication and verification of SNMP exchanges 🙅‍♀️ Also, because md5AuthProtocol is symmetric in character, the private authentication key for each party must be known to another SNMP party that it wants to have authenticated communication with. Asymmetric (public key) authentication protocols, on the other hand, wouldn't depend on sharing a private key to work 🦋

All protocol messages originated by stan are encrypted on transmission using the desPrivProtocol privacy protocol and the private key "STUVWX0123456789", and they're decrypted on reception using that same protocol and key. Likewise, every message originated by ollie is encrypted on transmission using the desPrivProtocol protocol and the private privacy key "MNOPQR0123456789", and it's decrypted correspondingly on reception. Just like with the authentication keys, private privacy keys aren't normally afforded to humans and stay confined to the parts of the implementation that require them 🫶

---

4.3 Proxy Configuration

This section shows examples of SNMP proxy configurations 🌈 Foreign proxy configurations let you manage non-SNMP devices, while native proxy configurations let an administrator shift the heavy computational lifting of rich management functions away from network devices whose main job isn't management 💅 To the extent that SNMP proxy agents act as points of aggregation for management information, proxy configurations may also cut down on the bandwidth needed for large-scale management activities ✨

The example configurations in this section are simplified for clarity: real configurations may need additional parties to support clock synchronization and distribution of secrets 🧚

4.3.1 Foreign Proxy Configuration

This section shows an example configuration where a SNMP management station can manage network elements that don't support SNMP themselves 💖 The setup centers on a SNMP proxy agent that carries out SNMP management operations by talking to a non-SNMP device over a proprietary protocol 🔥

Table 6 lists the SNMP party info stored in the local database of the SNMP proxy agent. Table 7 lists the party info stored in the local database of the SNMP management station. Table 8 lists the access policy set by the local administration 📖

As Table 6 shows, the proxy agent party runs at UDP port 161 at IP address 1.2.3.5 under the identity moe, and the example manager runs at UDP port 2002 at IP address 1.2.3.4 under the identity larry. Both larry and moe authenticate every message they generate using the protocol md5AuthProtocol and their own distinct, private authentication keys. Although these private authentication key values ("0123456789ABCDEF" and

   Identity        larry               moe                 curly
                   (manager)           (proxy)             (proxied)
   Domain          rfc1351Domain       rfc1351Domain       acmeMgmtPrtcl
   Address         1.2.3.4, 2002       1.2.3.5, 161        0x98765432
   Proxied Party   noProxy             curly               noProxy
   Auth Prot       md5AuthProtocol     md5AuthProtocol     noAuth
   Auth Priv Key   "0123456789ABCDEF"  "GHIJKL0123456789"  ""
   Auth Pub Key    ""                  ""                  ""
   Auth Clock      0                   0                   0
   Auth Last Msg   0                   0                   0
   Auth Lifetime   500                 500                 0
   Priv Prot       noPriv              noPriv              noPriv
   Priv Priv Key   ""                  ""                  ""
   Priv Pub Key    ""                  ""                  ""

         Table 6: Party Information for Proxy Agent

     Identity        larry               moe
                     (manager)           (proxy)
     Domain          rfc1351Domain       rfc1351Domain
     Address         1.2.3.4, 2002       1.2.3.5, 161
     Proxied Party   noProxy             noProxy
     Auth Prot       md5AuthProtocol     md5AuthProtocol
     Auth Priv Key   "0123456789ABCDEF"  "GHIJKL0123456789"
     Auth Pub Key    ""                  ""
     Auth Clock      0                   0
     Auth Last Msg   0                   0
     Auth Lifetime   500                 500
     Priv Prot       noPriv              noPriv
     Priv Priv Key   ""                  ""
     Priv Pub Key    ""                  ""

Okay so, quick reminder: these keys ("GHIJKL0123456789" and friends) are only shown here so the example is easy to follow 🔑. Real private keys aren't something humans normally get to see. They stay locked inside the parts of the protocol implementation that actually need them 🔒

Here's the thing, though. Every SNMP agent that uses crypto keys will almost certainly do private SNMP exchanges to hand those keys out 🫶. To keep this example simple, neither the management station nor the proxy agent sends or receives private SNMP communications. So the privacy protocol for each of them is recorded as noPriv 💅

The party curly doesn't send or receive SNMP protocol messages at all. Everything with that party goes through a hypothetical proprietary protocol identified by the value acmeMgmtPrtcl 🧚 Since curly isn't in SNMP, a bunch of the attributes recorded for it in a local database just get ignored. Main character energy, but make it invisible 🙈

Now, to interrogate the proprietary device behind curly, the management station larry builds an SNMP GetNext request and sends it to the party moe (see Table 7) at UDP port 161 and IP address 1.2.3.5 🎀 The request is authenticated with the private authentication key "0123456789ABCDEF".

When moe gets that request, it checks that the sender really is larry by using its local knowledge (see Table 6) of that same key 🔍 larry is allowed to issue GetNext requests to moe under the access control policy (Table 8), so the request gets accepted ✅ Because moe's local database says its proxied party is curly, the request gets translated into the right acmeMgmtPrtcl operations aimed at curly. Those new operations go to curly at address 0x98765432 in the acmeMgmtPrtcl domain 🦋

When and if the proprietary exchange between the proxy agent and the device wraps up, the party moe builds an SNMP GetResponse to relay the results to larry 💜 This response is authenticated for origin and integrity with the authentication protocol md5AuthProtocol and the private authentication key "GHIJKL0123456789", which is the one specified for transmissions from moe. It goes to the party larry at the management station, IP address 1.2.3.4 and UDP port 2002, which is the source address from the original request 🌸

When larry receives this response, it verifies that the sender is moe by using its local knowledge (see Table 7) of "GHIJKL0123456789" 🔑 moe is authorized to issue GetResponse communications to larry under the access control policy (Table 8), so the response is accepted and the interrogation of the proprietary device is complete 🎉

It's especially useful to notice that the database of SNMP parties kept at the proxy agent (Table 6) doesn't have to be static, and it doesn't have to be configured only by the management station 🧠 Say that in this example, acmeMgmtPrtcl was a proprietary MAC-layer mechanism for managing stations on a local area network. In that setup, the party moe would live at an SNMP proxy agent attached to that LAN, and by taking part in the LAN protocols it could spot stations connecting and disconnecting 👀 The proxy agent could then keep updating its local database of SNMP parties so it can indirectly manage those LAN stations from the SNMP management station. For every new LAN station it detects, it would add two things to its database: an entry like the one for curly (representing the new station itself), and an entry like the one for moe (a proxy for that new station in the SNMP domain) 💖

Because of all that, an SNMP management station can use SNMP to poke around the database of parties held by the SNMP proxy agent, and discover and interact with new stations as they show up on the LAN 🦋✨

---

4.3.2. Native Proxy Configuration ✨

This section shows an example configuration that supports SNMP native proxy operations, which is indirect interaction between an SNMP agent and a management station, mediated by a second SNMP (proxy) agent 💅

This example is pretty similar to the foreign proxy one above, with one big difference 👀 Here, the party associated with the identity curly receives messages over SNMP, so it talks to the SNMP proxy agent moe using authenticated SNMP communications 🔐

Table 9 has info about the SNMP parties recorded in the local database of the SNMP proxy agent 📋 Table 7 has info about SNMP parties recorded in the local database of the SNMP management station 📋 And Table 10 has info about the access policy set by local administration 🎀

As you can see in Table 9, the proxy party runs at UDP port 161 at IP address 1.2.3.5 using the party identity moe:

  Identity       larry              moe                curly
                 (manager)          (proxy)            (proxied)
  Domain         rfc1351Domain      rfc1351Domain      rfc1351Domain
  Address        1.2.3.4, 2002      1.2.3.5, 161       1.2.3.6, 16
  Proxied Party  noProxy            curly              noProxy
  Auth Prot      md5AuthProtocol    md5AuthProtocol    md5AuthProtocol
  Auth Priv Key  "0123456789ABCDEF" "GHIJKL0123456789" "MNOPQR0123456789"
  Auth Pub Key   ""                 ""                 ""
  Auth Clock     0                  0                  0
  Auth Last Msg  0                  0                  0
  Auth Lifetime  500                500                500
  Priv Prot      noPriv             noPriv             noPriv
  Priv Priv Key  ""                 ""                 ""
  Priv Pub Key   ""                 ""                 ""

         Table 9: Party Information for Proxy Agent

               Target   Subject   Privileges
               moe      larry     3
               larry    moe       20
               curly    moe       3
               moe      curly     20

         Table 10: Access Information for Native Proxy

Meanwhile, the example manager runs at UDP port 2002 at IP address 1.2.3.4 using the identity larry, and the proxied party runs at UDP port 161 at IP address 1.2.3.6 using the party identity curly 🫶 Every message from all three SNMP parties is authenticated for origin and integrity using the authentication protocol md5AuthProtocol and its own distinct private authentication key 🔑 Those keys ("0123456789ABCDEF", "GHIJKL0123456789", and "MNOPQR0123456789") are shown just for expository purposes, and once again, humans don't normally get to know private keys. That stuff is confined to the protocol implementation parts that need it 🙈

To interrogate the proxied device behind curly, the management station larry builds a SNMP GetNext request and sends it to the party moe (see Table 7) at UDP port 161 and IP address 1.2.3.5 📡 This request is authenticated using the private authentication key "0123456789ABCDEF".

When moe receives that request, it verifies that the originator is larry by using its local knowledge (see Table 9) of "0123456789ABCDEF" ✅ larry is authorized to issue GetNext (and Get) requests to moe under the access control policy (Table 10), so the request is accepted. Because moe's local database records its proxied party as curly, the request gets translated into a corresponding SNMP GetNext request going from moe to curly. This new communication is authenticated with the private authentication key "GHIJKL0123456789" and sent to curly at IP address 1.2.3.6 🦋

When curly gets this new request, it verifies that the originator is moe by using its local knowledge (see Table 9) of "GHIJKL0123456789" 🔍 moe is authorized to issue GetNext (and Get) requests to curly under the access control policy (Table 10), so the request is accepted. Since curly's local database records its proxied party as noProxy, the GetNext request is handled by local mechanisms. curly then generates an SNMP GetResponse message with the results of the query. This response is authenticated for origin and integrity using the private authentication key "MNOPQR0123456789" and sent to moe at IP address 1.2.3.5, which is the source address from the corresponding request 💜

When moe receives this response, it verifies that the originator is curly by using its local knowledge (see Table 9) of "MNOPQR0123456789" 🔐 curly is authorized to issue GetResponse communications to moe under the access control policy (Table 10), so the response is not rejected. Instead, it gets translated into a response to the original GetNext request from larry. This response is authenticated for origin and integrity using the private authentication key "GHIJKL0123456789" and sent to larry at IP address 1.2.3.4, which is the source address from the original request 🌈

When larry receives this response, it verifies that the originator is moe by using its local knowledge (see Table 7) of "GHIJKL0123456789" 🎀 moe is authorized to issue GetResponse communications to larry under the access control policy (Table 10), so the response is accepted, and the interrogation is complete 🎉

4.4. Public Key Configuration 🔑

This section presents an example configuration built on a hypothetical security protocol 🧚 That hypothetical protocol would be based on asymmetric (public key) cryptography, used as a way to provide data origin authentication (but not protection against disclosure). This example shows that the administrative model fits with public key technology, and the extension of the example to support protection against disclosure should be apparent 💖

Okay so the example setup is giving simple but make it secure 💖 There's one SNMP agent talking to one SNMP management station, and it's honestly so clean. Table 11 shows what the agent party looks like 🎀

    Identity          ollie                      stan
                      (agent)                    (manager)
    Domain            rfc1351Domain              rfc1351Domain
    Address           1.2.3.4, 161               1.2.3.5, 2004
    Proxied Party     noProxy                    noProxy
    Auth Prot         pkAuthProtocol             pkAuthProtocol
    Auth Priv Key     "0123456789ABCDEF"         ""
    Auth Pub Key      ""                         "ghijkl0123456789"
    Auth Clock        0                          0
    Auth Last Msg     0                          0
    Auth Lifetime     500                        500
    Priv Prot         noPriv                     noPriv
    Priv Priv Key     ""                         ""
    Priv Pub Key      ""                         ""

       Table 11: Party Information for Public Key Agent

The agent and manager info lives in Tables 11 and 12, and Table 5 is the local access policy that both of them know about 🧚

So ollie is the agent party, chilling at UDP port 161 on IP 1.2.3.4. stan is the manager party, at UDP port 2004 on IP 1.2.3.5. Both of them authenticate every message they send, for origin and integrity, using the hypothetical SNMP authentication protocol pkAuthProtocol. Each one uses its own private authentication key 🔐 Here's the manager's side, Table 12:

    Identity          ollie                  stan
                      (agent)                (manager)
    Domain            rfc1351Domain          rfc1351Domain
    Address           1.2.3.4, 161           1.2.3.5, 2004
    Proxied Party     noProxy                noProxy
    Auth Prot         pkAuthProtocol         pkAuthProtocol
    Auth Priv Key     ""                     "GHIJKL0123456789"
    Auth Pub Key      "0123456789abcdef"     ""
    Auth Clock        0                      0
    Auth Last Msg     0                      0
    Auth Lifetime     500                    500
    Priv Prot         noPriv                 noPriv
    Priv Priv Key     ""                     ""
    Priv Pub Key      ""                     ""

   Table 12:  Party Information for Public Key Management
              Station

Real talk, those private authentication key values ("0123456789ABCDEF" and "GHIJKL0123456789") are only shown here for expository purposes 👀 In real life, humans don't get to see private keys. They stay locked inside the parts of the protocol implementation that actually need them 🔒

In most respects, the manager and agent interact in this setup almost exactly like they do in the minimal, secure SNMP agent example from earlier. The big difference is that neither SNMP party knows the private key the other one uses to authenticate its transmissions. Instead, every time an authenticated SNMP message comes in, the originator's identity gets verified by running an asymmetric cryptographic algorithm on the received message together with the originating party's public authentication key. So the agent knows the manager's public key ("ghijkl0123456789") but not its private key ("GHIJKL0123456789"). And the manager knows the agent's public key ("0123456789abcdef") but not its private key ("0123456789ABCDEF") 🦋

Privacy protocols are not covered in this example, to keep things simple 🙈 Just know they'd be needed for the secure, automated distribution of secret keys, which is a whole other slay.

---

4.5. MIB View Configurations ✨

This section is all about a convention for defining MIB views, and then using that convention to show example MIB view configurations for SNMP parties 💅

A MIB view is made up of a collection of view subtrees (see Section 3.6), and any MIB view can be represented this way. Sometimes a MIB view definition has a huge number of view subtrees, so a convention for abbreviating these definitions is honestly desirable 😭

The convention adopted in [5] lets you abbreviate MIB view definitions using families of view subtrees. Each family is either included in or excluded from the definition of a MIB view. A table that every SNMP entity keeps locally defines the MIB view for each SNMP party that entity realizes. Each entry in that table is a family of view subtrees that is either included or excluded, depending on the entry's status, from the MIB view of some SNMP party. Each table entry represents a subtree family as a pairing of two things: an OBJECT IDENTIFIER value (called the family name) and a bitstring value (called the family mask). The family mask tells you which subidentifiers of the family name actually matter for defining that subtree family. 🌸

Here's how a MIB object instance decides whether it belongs to the subtree family for a particular table entry. It belongs if:

• its OBJECT IDENTIFIER name has at least as many subidentifiers as the family name for that table entry, and
• each subidentifier in its name matches the corresponding subidentifier of the family name whenever the matching bit in the family mask is non-zero.

Now, whether an instance shows up in a particular SNMP party's MIB view depends on which of that party's family memberships it has:

• If a MIB object instance belongs to none of the relevant subtree families, it is not in the MIB view for that SNMP party.
• If a MIB object instance belongs to exactly one of the relevant subtree families, it gets included in, or excluded from, the MIB view depending on the status of that one entry.
• If a MIB object instance belongs to more than one of the relevant subtree families, the status of one single entry decides it. That entry is the one whose family name has the greatest number of subidentifiers and, if there's a tie there, whose family name is lexicographically greatest. Its status then sets whether the instance is included or excluded. 🧠

A subtree family whose family mask is all ones is just the single view subtree named by that entry's family name. And since the convention of [5] lets family mask values be implicitly extended with ones, a table entry with a family mask of zero length always corresponds to a single view subtree too 🎀

Here's the simplest possible one, Table 13:

     Party Identity  Status     Family Name    Family Mask
     lucy            include    internet       ""h

         Table 13: View Definition for Minimal Agent

This is the kind of MIB view definition you see a lot, and it's clean. Table 13 shows the MIB view definitions needed for a minimal SNMP entity that realizes just one SNMP party. The party's MIB view covers every instance of every MIB object defined within the internet network management framework 🌈 The table has one entry: the party lucy is in the first column, and the status "include" means any MIB object instance in that entry's subtree family can show up in lucy's 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, Table 14. This one has a single SNMP protocol entity realizing multiple SNMP parties, each with its own distinct MIB view 💜 The MIB view for lucy covers all instances of all MIB objects in the internet network management framework, except the ones about administering SNMP parties. Meanwhile, ricky's MIB view has only MIB object instances from the system group of the internet-standard MIB, plus the object instances used to administer SNMP parties 🫶

     Party Identity  Status     Family Name    Family Mask
     lucy            include    internet       ""h
     lucy            exclude    snmpParties    ""h
     ricky           include    system         ""h
     ricky           include    snmpParties    ""h

         Table 14: View Definition for Multiple Parties

Now a more complicated one, Table 15, which shows how related collections of view subtrees can be grouped together into view subtree families. In this example, lucy's MIB view includes all object instances in the system group of the internet-standard MIB, along with some info about the second network interface on the managed device. There's a catch, though: that interface info doesn't include the interface's speed 😭 The family mask "FFA0"h in the second table entry means a MIB object instance belongs to that subtree family if its name starts with the ifEntry portion of the registration hierarchy and its eleventh subidentifier is 2 ✨

The speed of the second network interface belongs to the subtree families from both the second and third entries. But it still gets excluded from lucy's MIB view, because the lexicographically greater family name is in the entry with status exclude. Plot twist, but it makes sense 💀

ricky's MIB view is defined here too. It includes all object instances in the icmp group of the internet-standard MIB, plus all information 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 🍓

As the examples above suggest, the abbreviated representation of [5] handles a wide range of MIB view configurations really efficiently. Still, careful MIB design can sometimes shrink the size and complexity of the most elaborate ones even more 🌸

    Party Identity  Status     Family Name        Family Mask
    lucy            include    system             ""h
    lucy            include    { ifEntry 0 2 }    "FFA0"h
    lucy            exclude    { ifSpeed 2 }      ""h
    ricky           include    icmp               ""h
    ricky           include    { ifEntry 0 5 }    "FFA0"h
    ricky           include    { ifInOctets 4 }   ""h

          Table 15: More Elaborate View Definitions

Okay so the last bit of section 4 is lowkey about configuration cost 💅. MIB view configuration can't slam hard limits on how local administrations set their access policies, or on how MIB namespaces are shaped 🙅‍♀️. It has to stay flexible, no cap. BUT, and this is the iconic part ✨, when the most common access policies are already known, you can cut the setup cost by grouping the MIB objects that local policies usually want treated differently into their own portions of the registration hierarchy. The move [5] makes to relegate certain objects to a distinct arc in the MIB namespace is literally an example of this optimization 🧚

5. Compatibility 🎀

Ideally, every SNMP management station and agent would talk exclusively through the secure facilities in this memo 🫶. Realistically though, lots of SNMP agents may only implement the insecure SNMP mechanisms from [1] for a while yet 😭.

New SNMP agent implementations should never implement both the insecure mechanisms of [1] and the facilities described here 🙅‍♀️. Instead, staying true to the SNMP philosophy, the burden of supporting both sorts of communication should fall entirely upon managers 👑. The best way to get both old and new modes working is probably a SNMP proxy agent deployed locally on the same system as a management station implementation 🌸. The management station operates exclusively in the newer, secure modes, and the local proxy agent translates the manager's requests into older, insecure modes as needed 🔥.

Heads up 👀: proxy agent implementations may need extra information beyond what this memo describes in order to pull off the translation work that's implicit in the proxy function. The good news is that this information could easily be retrieved from a filestore 📂.

---

6. Security Considerations 🚨

🚨 Important, bestie: in the example configuration for native proxy operations presented in this memo, using symmetric cryptography does not securely prevent direct communication between the SNMP management station and the proxied SNMP agent. Symmetric crypto is not a shield here. 💀

Plot twist 🌈: according to the administrative model set forth in this memo, secure isolation of the management station and the proxied agent can be realized using symmetric cryptography. However, the required configuration is way more complex and is not described in this memo 🙈. So the recommendation is that native proxy configurations requiring secure isolation of the management station from the proxied agent be implemented using security protocols based on asymmetric (or "public key") cryptography. The tea though: no SNMP security protocols based on asymmetric cryptography are currently defined 😭.

To take part in the administrative model set forth in this memo, SNMP implementations must support local, non-volatile storage of the local party database 💾. So the authors went all out to minimize the amount of non-volatile storage required 🥹.

---

7. References 📚

Here's the reading list, bestie 📚

   [1] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
       Network Management Protocol", RFC 1157, University of Tennessee
       at Knoxville, Performance Systems International, Performance
       Systems International, and the MIT Laboratory for Computer
       Science, May 1990.  (Obsoletes RFC 1098.)

   [2] Rose, M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP based internets", RFC 1155,
       Performance Systems International, Hughes LAN Systems, May 1990.
       (Obsoletes RFC 1065.)

   [3] Information Processing -- Open Systems Interconnection --
       Specification of Basic Encoding Rules for Abstract Syntax
       Notation One (ASN.1), International Organization for
       Standardization/International Electrotechnical Institute, 1987,
       International Standard 8825.

   [4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
       Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
       LAN Systems, Inc., MIT Laboratory for Computer Science, July
       1992.

   [5] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed
       Objects for Administration of SNMP Parties", RFC 1353, Hughes LAN
       Systems, Inc., MIT Laboratory for Computer Science, Trusted
       Information Systems, Inc., July 1992.

8. Authors' Addresses 🦋

       James R. Davin
       MIT Laboratory for Computer Science
       545 Technology Square
       Cambridge, MA 02139

       Phone:  (617) 253-6020
       EMail:  jrd@ptt.lcs.mit.edu


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

       Phone:  (301) 854-6889
       EMail:  galvin@tis.com
       Keith McCloghrie
       Hughes LAN Systems, Inc.
       1225 Charleston Road
       Mountain View, CA 94043

       Phone:  (415) 966-7934
       EMail:  kzm@hls.com