RFC 5590
Transport Subsystem for the Simple Network Management Protocol (SNMP)
RFC 5590 📜✨
Title block, bestie: this is RFC 5590 from the Network Working Group 🎀
- Title: Transport Subsystem for the Simple Network Management Protocol (SNMP)
- Authors: D. Harrington (Huawei Technologies (USA)) and J. Schoenwaelder (Jacobs University Bremen) 🧑💻
- Category: Standards Track
- Date: June 2009
- Updates: 3411, 3412, 3414, 3417 (so it's basically patching older SNMP docs, iconic 🩹)
Status of This Memo
okay so this doc is an Internet standards track protocol for the whole Internet community 🌐 and it's literally asking for discussion and suggestions 🥹 so share your thoughts! For where this protocol stands rn, check the current edition of the "Internet Official Protocol Standards" (STD 1), that's the source of truth 💅. Distribution of this memo is unlimited, so spread the word 🦋
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This doc is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, the version in effect on the publication date (http://trustee.ietf.org/license-info). Please read those carefully, bc they spell out your rights and restrictions for this doc 📖
Heads up 🙈: this doc may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who own the copyright on some of that stuff may not have given the IETF Trust permission to allow changes outside the IETF Standards Process. So without getting a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸
Abstract
This doc defines a Transport Subsystem that extends the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411 🧚 It sets up a subsystem to hold Transport Models, which is comparable to the other subsystems in the RFC 3411 architecture. Secure transports are being worked on, like the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), and using a subsystem will keep the design consistent and modular for those Transport Models ✨ It also identifies and describes some key aspects that any Transport Model for SNMP needs to consider 💜
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Internet-Standard Management Framework . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Where This Extension Fits . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements of a Transport Model . . . . . . . . . . . . . . 7
3.1. Message Security Requirements . . . . . . . . . . . . . . 7
3.1.1. Security Protocol Requirements . . . . . . . . . . . . 7
3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Architectural Modularity Requirements . . . . . . . . 8
3.2.2. Access Control Requirements . . . . . . . . . . . . . 11
3.2.3. Security Parameter Passing Requirements . . . . . . . 12
3.2.4. Separation of Authentication and Authorization . . . . 12
3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 13
3.3.1. No SNMP Sessions . . . . . . . . . . . . . . . . . . . 13
3.3.2. Session Establishment Requirements . . . . . . . . . . 14
3.3.3. Session Maintenance Requirements . . . . . . . . . . . 15
3.3.4. Message Security versus Session Security . . . . . . . 15
4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 16
5. Cached Information and References . . . . . . . . . . . . . . 17
5.1. securityStateReference . . . . . . . . . . . . . . . . . . 17
5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. Transport Information . . . . . . . . . . . . . . . . 18
5.2.2. securityName . . . . . . . . . . . . . . . . . . . . . 19
5.2.3. securityLevel . . . . . . . . . . . . . . . . . . . . 20
5.2.4. Session Information . . . . . . . . . . . . . . . . . 20
6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 21
6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 21
6.2. Changes to RFC 3411 Outgoing ASIs . . . . . . . . . . . . 22
6.2.1. Message Processing Subsystem Primitives . . . . . . . 22
6.2.2. Security Subsystem Primitives . . . . . . . . . . . . 23
6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 24
6.4. Changes to RFC 3411 Incoming ASIs . . . . . . . . . . . . 25
6.4.1. Message Processing Subsystem Primitive . . . . . . . . 25
6.4.2. Security Subsystem Primitive . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Coexistence, Security Parameters, and Access Control . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 32
A.1. Define an Abstract Service Interface . . . . . . . . . . . 32
A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 32
A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 32
A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 331. Introduction ✨
This doc defines a Transport Subsystem that extends the Simple Network Management Protocol (SNMP) architecture defined in [RFC3411]. It identifies and describes some key aspects that any Transport Model for SNMP needs to consider, so this is the big-picture intro bestie 🦋
1.1. The Internet-Standard Management Framework 🗂️
If you want the full tea on the documents that make up the current Internet-Standard Management Framework, go check Section 7 of RFC 3410 [RFC3410] 🫶
1.2. Conventions 📏
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are interpreted as described in RFC 2119 [RFC2119]. These are the capital-letter rules, so they're the ones with real weight 🔥
Lowercase versions of those keywords should be read as normal English 💅 They'll usually, but not always, show up in a context about compatibility with the RFC 3411 architecture or the subsystem defined here, but they might not affect on-the-wire compatibility at all. These terms are guidance for designers of proposed IETF models, to help them stay compatible with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to do their own thing 🌈 and some uses of the lowercase terms are just regular English, no deep meaning.
This doc favors SNMP terminology from STD 62, instead of the different variations used in non-SNMP specs. That's consistent with the IESG decision not to make the SNMPv3 terminology match non-SNMP specs when SNMPv3 was advanced to Full Standard. It's giving consistency 💖
This doc discusses an extension to the modular RFC 3411 architecture. It is not a protocol document 🧚 An architectural "MUST" is a really sharp constraint. To leave room for technology to evolve and to avoid over-constraining future models, a "SHOULD" or a "should" is usually a better fit than a "MUST" in an architecture. Future models MAY express tighter requirements for their own model-specific processing 🍓
1.3. Where This Extension Fits ✨
okay so bestie, you'll want to have read RFCs 3410 and 3411 first 📚 and know the general vibe of what RFCs 3412-3418 do. it's giving foundations 🧱
the "Transport Subsystem" is an extra piece that gets added to the SNMP Engine from RFC 3411, Section 3.1. 🦋 here's the pic of where it lives in the RFC 3411 setup:
+-------------------------------------------------------------------+
| SNMP entity |
| |
| +-------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +------------+ | |
| | | Transport | | |
| | | Subsystem | | |
| | +------------+ | |
| | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| +-------------------------------------------------------------+ |
| |
| +-------------------------------------------------------------+ |
| | Application(s) | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| +-------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+so the transport mappings in RFC 3417 don't bring any lower-layer security stuff, which means they don't come with transport-specific security parameters 🥺 this doc updates RFC 3411 and RFC 3417 🔥 by adding an architectural extension and tweaking the ASIs that transport mappings (we're calling them "Transport Models" from here on 💅) can use to pass transport-specific security parameters over to other subsystems. that includes the ones that get translated into the transport-independent securityName and securityLevel parameters 🫶
the Transport Security Model [RFC5591] and the Secure Shell Transport Model [RFC5592] are both users of the Transport Subsystem 🌸 the Transport Security Model is an alternative to the SNMPv1 Security Model [RFC3584], the SNMPv2c Security Model [RFC3584], and the User-based Security Model [RFC3414] 👑 and the Secure Shell Transport Model is an alternative to the existing transport mappings described in [RFC3417] 🧚
2. Motivation 💖
okay picture this 🏠 there are a bunch of ways to keep your house or business safe, and they sit on a whole spectrum, and the same goes for securing a network management protocol 🔐 let's look at three main approaches 👀
in the first one, you literally just sit on your front porch and wait for intruders 🪑 in the second, you hire an employee, schedule them, station them to guard whatever you care about, then hire a second guard for when the first one calls in sick, and so on 🙃 in the third, you hire a security company, tell them what needs protecting, and let them handle everything else 💅 the hiring and training, positioning and scheduling guards, arranging backup, all of that is the security company's job 🏢 so the homeowner gets the security they want with way less effort, the only stuff left on their plate is figuring out the requirements and checking that the service is actually good ✨
the User-based Security Model (USM) from [RFC3414] mostly goes with the first approach, meaning it provides its own security 🛡️ it uses existing mechanisms (like SHA) but handles all the coordination itself 🧠 USM covers authentication of a principal, message encryption, data integrity checking, timeliness checking, and more 🔥
USM was designed to be independent of other existing security infrastructures 🙅♀️ so it uses its own principal and key management infrastructure 😤 operators have reported that setting up yet another principal and key management system just to use SNMPv3 is a real deterrent to deploying it 😭 it's possible to use external mechanisms to distribute keys for USM, but the bigger issue is that operators wanted to use the existing user management infrastructures that weren't specific to SNMP 💜
a USM-compliant architecture might pair the authentication mechanism with an external mechanism, like RADIUS [RFC2865], to handle authentication 🪪 it could also be possible to use an external protocol to encrypt messages, check timeliness, check data integrity, and so on 🧩 but that's basically the second approach, where you're coordinating a bunch of differently subcontracted services 🙈 building solid security between all those services is hard, and there's a big potential for gaps 🕳️
another option is to lean on one or more lower-layer security mechanisms to provide the message-oriented security services we need 🌈 those would include sender authentication, encryption, timeliness checking, and data integrity checking 💫 this is the third approach from above 🙌 there are a bunch of IETF standards out there, available now or in development, that tackle these problems through security layers at the transport or application layer, including TLS [RFC5246], Simple Authentication and Security Layer (SASL) [RFC4422], and SSH [RFC4251]
from an operations point of view, it's super desirable to use security mechanisms that can unify administrative security management across SNMPv3, command line interfaces (CLIs), and other management interfaces 🎀 the CLI already commonly uses security services from lower layers, and other network management protocols are being proposed to do the same, like syslog [RFC5424] and NETCONF [RFC4741] 🍓
this document defines a Transport Subsystem extension to the RFC 3411 architecture that's based on the third approach 🦋 the extension specifies how other lower-layer protocols with common security infrastructures can be used underneath the SNMP protocol so the goal of unified administrative security can actually be met 🥹
this extension lets security be provided by an external protocol that's connected to the SNMP engine through an SNMP Transport Model [RFC3417] 🔌 that Transport Model then makes it possible to use existing security mechanisms, like TLS [RFC5246] or SSH [RFC4251], inside the RFC 3411 architecture 🫧
there are lots of widely used Internet security protocols and mechanisms out there 🌐 many of them try to provide a generic infrastructure that loads of different application-layer protocols can use 🧃 the whole point of the Transport Subsystem is to leverage those protocols wherever it makes sense 💪
there are also a bunch of challenges to solve in mapping the security a secure transport provides into the SNMP architecture, so that SNMP keeps interoperating with existing implementations 😮💨 this doc walks through those challenges in detail 📝 for some of the key issues, it also describes design choices that could be made to get a workable solution that meets operational requirements and fits into the SNMP architecture defined in [RFC3411] 🎯
3. Requirements of a Transport Model 🧁
3.1. Message Security Requirements 🔒
okay so transport security protocols SHOULD provide protection against these message-oriented threats 🚨
- modification of information
- masquerade
- message stream modification
- disclosure
these threats are described in Section 1.4 of [RFC3411] 📖 the security requirements outlined there don't require protection against denial of service or traffic analysis 🙈 still, transport security protocols should not make those threats significantly worse 😬
3.1.1. Security Protocol Requirements 💅
there are a bunch of standard protocols that could be proposed as possible solutions within the Transport Subsystem 🧰 some factors should be considered when picking one 🤔
using a protocol in a way it wasn't designed for causes lots of problems 💀 the advertised security characteristics of a protocol might depend on it being used as designed, and when it's used in other ways, it might not deliver the security characteristics you were expecting 😱 it is recommended that any proposed model include a description of the applicability of the Transport Model 🫶
a Transport Model SHOULD NOT require modifications to the underlying protocol ✋ modifying the protocol might change its security characteristics in ways that could impact other existing usages 🙅♀️ if a change is necessary, the change SHOULD be an extension that has no impact on the existing usages 🌸 any Transport Model specification should include a description of potential impact on other usages of the protocol 📋
since multiple Transport Models can exist at the same time inside the Transport Subsystem, Transport Models MUST be able to coexist with each other 👯♀️✨
3.2. SNMP Requirements 🦋
3.2.1. Architectural Modularity Requirements ✨
okay so SNMPv3 is built on a modular architecture (defined in Section 3 of [RFC3411]) so the protocol standards can keep evolving over time 🦋 and changes in one part don't cause a bunch of side effects in the other parts 💅
the RFC 3411 architecture has a Message Processing Subsystem, which lets different message versions be handled by a single engine 🫶 it also has a Security Subsystem for different ways of providing security services 🔐, Applications for different types of Application processors 🧚, and an Access Control Subsystem for allowing multiple approaches to access control 👑. but here's the tea: the RFC 3411 architecture doesn't have a Transport Models subsystem 😭, even though there are already multiple transport mappings defined for SNMP [RFC3417]. so this document describes a Transport Subsystem that fits right into the RFC 3411 architecture 🌸. since people are working on using secure transports like SSH and TLS, a subsystem lets those Transport Models be designed consistently and stay modular 💜
the Transport Subsystem respects the goals of the RFC 3411 architecture that are defined in Section 1.5 of [RFC3411] ✨ it uses a modular design so Transport Models (which might or might not be security-aware) can be "plugged into" the RFC 3411 architecture 🎀 those Transport Models should be as independent of the other modular SNMP components as possible 🍓 and this design also lets each Transport Model move through the standards process on its own, separate from the others 🚀
here's the diagram of the SNMPv3 architecture, with the new Transport Subsystem from this document and a new Transport Security Model defined in [RFC5591] 🌈
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-------------------------------------------------------------------+
| +--------------------------------------------------+ |
| | Transport Subsystem | |
| | +-----+ +-----+ +-----+ +-----+ +-------+ | |
| | | UDP | | TCP | | SSH | | TLS | . . . | other | | |
| | +-----+ +-----+ +-----+ +-----+ +-------+ | |
| +--------------------------------------------------+ |
| ^ |
| | |
| Dispatcher v |
| +-------------------+ +---------------------+ +----------------+ |
| | Transport | | Message Processing | | Security | |
| | Dispatch | | Subsystem | | Subsystem | |
| | | | +------------+ | | +------------+ | |
| | | | +->| v1MP |<--->| | USM | | |
| | | | | +------------+ | | +------------+ | |
| | | | | +------------+ | | +------------+ | |
| | | | +->| v2cMP |<--->| | Transport | | |
| | Message | | | +------------+ | | | Security | | |
| | Dispatch <--------->| +------------+ | | | Model | | |
| | | | +->| v3MP |<--->| +------------+ | |
| | | | | +------------+ | | +------------+ | |
| | | | | +------------+ | | | Other | | |
| | PDU Dispatch | | | +------------+ | | | Model(s) | | |
| +-------------------+ | +->| otherMP |<--->| +------------+ | |
| ^ | +------------+ | +----------------+ |
| | +---------------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | Application | | | | Applications | | Application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+3.2.1.1. Changes to the RFC 3411 Architecture 🧩
okay so the RFC 3411 architecture and the Security Subsystem assume that a Security Model gets called by a Message Processing Model and then handles multiple security functions inside the Security Subsystem 💁♀️ a Transport Model that supports a secure transport protocol might do similar security functions inside the Transport Subsystem 🔒 that can include translating transport-security parameters to and from Security-Model-independent parameters ✨
to make that work, an implementation-specific cache of transport-specific information will be described (not shown) 🗂️ and the data flows on this path get extended so they can pass Security-Model-independent values 🦋 this document amends some of the ASIs defined in RFC 3411, and those changes are covered in Section 6 of this document 📝
New Security Models might be defined that know how to work with these modified ASIs and the transport-information cache 🌷 one of them is the Transport Security Model, which is defined in [RFC5591] 💜
3.2.1.2. Changes to RFC 3411 Processing 🔄
the introduction of secure transports changes the responsibilities and the order of processing within the RFC 3411 architecture 😭 the steps are still the same, but they might happen in a different order and might be done by different subsystems 🍓 with the existing RFC 3411 architecture, security processing starts when the Message Processing Model decodes parts of the encoded message to pull out the parameters that identify which Security Model MUST handle the security-related tasks 🔐
a secure transport does those security functions on the message before the message is decoded 🫶 some of those functions might then get repeated by the selected Security Model 🔁
3.2.1.3. Passing Information between SNMP Engines 🚇
a secure Transport Model will set up an authenticated and possibly encrypted tunnel between the Transport Models of two SNMP engines 🛡️ once the transport-layer tunnel is up, SNMP messages can be sent through it from one SNMP engine to the other 💌 the Community Security Models [RFC3584] and the User-based Security Model each set up a security association for every single SNMP message 😵 but newer Transport Models MAY support sending multiple SNMP messages through the same tunnel, which spreads out the cost of setting up a security association 🧠✨
3.2.2. Access Control Requirements 🚪
RFC 3411 made some design decisions about supporting an Access Control Subsystem 👑 these include establishing and passing the securityModel, securityName, and securityLevel parameters in a model-independent way, and keeping message authentication separate from data-access authorization 🫧
3.2.2.1. securityName and securityLevel Mapping 🏷️
SNMP data-access controls are expected to work based on who can do what operations on which subsets of data, and based on the security services that will protect the data in transit 💅 the securityModel and securityLevel parameters set up the protections for transit, meaning whether authentication and privacy services will be (or have been) applied to the message 🔐 the securityName is a model-independent identifier of the security "principal" 🪪
a Security Model has a role in security that goes beyond just protecting the message 💖 it provides a mapping from the Security-Model-specific principal of an incoming message to a Security-Model-independent securityName that can be used for later processing, like access control 🎀 the securityName gets mapped from a mechanism-specific identity, and this mapping must be done for incoming messages by the Security Model before it passes securityName to the Message Processing Model via the processIncoming ASI 🛤️
a Security Model is also responsible for specifying, through the securityLevel parameter, whether incoming messages have been authenticated and encrypted 🕵️ and it makes sure outgoing messages are authenticated and encrypted based on the value of securityLevel 🔒
A Transport Model MAY provide suggested values for securityName and securityLevel 💡 a Security Model might have multiple sources for figuring out the principal and the desired security services, and a particular Security Model might or might not use the values a Transport Model proposes when it decides the value of securityName and securityLevel 🤷♀️
Documents defining a new transport domain MUST define a prefix that MAY be prepended to all securityNames passed by the Security Model 🌈 the prefix MUST include one to four US-ASCII alpha-numeric characters, and it can't include a ":" (US-ASCII 0x3a) character 🚫 if a prefix is used, a securityName is built by concatenating the prefix, a ":" (US-ASCII 0x3a) character, and then a non-empty identity in an snmpAdminString-compatible format 🧵 the prefix is what lets SNMP Applications tell "alice" authenticated by SSH apart from "alice" authenticated by TLS 🫣 transport domains and their matching prefixes are coordinated through the IANA registry "SNMP Transport Domains" 📋
3.2.3. Security Parameter Passing Requirements 📦
a Message Processing Model might unpack SNMP-specific security parameters from an incoming message before it calls a specific Security Model to handle the security-related processing of that message 🎁 when a secure Transport Model is in use, some security parameters might be pulled out of the transport layer by the Transport Model before the message is passed to the Message Processing Subsystem 🚚
this document describes a cache mechanism (see Section 5) where the Transport Model stores information about the transport and security parameters applied to a transport connection or to an incoming message 🗃️ a Security Model might pull that information out of the cache 💫 a tmStateReference gets passed as an extra parameter in the ASIs between the Transport Subsystem and the Message Processing and Security Subsystems, so everyone can find the right cache 🔍 this way of passing a model-independent reference matches the securityStateReference cache that's already passed around in the RFC 3411 ASIs 🥰
3.2.4. Separation of Authentication and Authorization ✨
Okay so the RFC 3411 architecture is built around keeping authentication (proving who you are) totally separate from authorization (what you're allowed to touch in the MIB) 🫶 A set of model-independent parameters (securityModel, securityName, and securityLevel) gets passed between the Security Subsystem, the Applications, and the Access Control Subsystem. Main character separation of concerns, literally 💅
This was a deliberate decision by the SNMPv3 WG 🎀 The goal was to allow authentication protocols that don't provide data-access authorization to still be used, and to support data-access authorization schemes, like the View-based access Control Model (VACM), that don't do their own authentication. Iconic design, no notes 🦋
A Message Processing Model decides which Security Model gets used. That can happen based on the message version (e.g., SNMPv1 and SNMPv2c), or possibly by a value specified in the message (e.g., msgSecurityModel field in SNMPv3) 🧚
The Security Model decides which securityName and securityLevel values get passed as model-independent parameters to an Application. The Application then passes them via the isAccessAllowed ASI to the Access Control Subsystem 🌸
An Access Control Model does the mapping from those model-independent security parameters to a policy inside the Access Control Model. That policy is Access-Control-Model-dependent, so it's its own thing 💜
A Transport Model doesn't know which Security Model will be used for an incoming message, so it can't know how securityName and securityLevel will be determined 🙈 It can propose an authenticated identity (via the tmSecurityName field), but there's no guarantee the Security Model will actually use that value. For example, non-transport-aware Security Models will typically determine the securityName (and securityLevel) based on the contents of the SNMP message itself. Those models will simply not know that the tmStateReference cache exists 💀
Even if the Transport Model can influence the choice of securityName, it can't directly determine the authorization allowed to that identity. If two different Transport Models each authenticate a transport principal, and both of those are mapped to the same securityName, then those two identities will typically be afforded exactly the same authorization by the Access Control Model. Not fair to the Transport Models, but that's how it goes 😭
The only way for the Access Control Model to tell identities apart based on the underlying Transport Model is if those transport-authenticated identities get mapped to distinct securityNames. How and if this is done is Security-Model-dependent 🔥
3.3. Session Requirements 🌈
Some secure transports have a notion of sessions, while others provide channels or other session-like mechanisms. Throughout this document, the term "session" is used in a broad sense to cover transport sessions, transport channels, and other transport-layer, session-like mechanisms. Transport-layer sessions that can secure multiple SNMP messages within the lifetime of the session are considered desirable, because the cost of authentication can be amortized over potentially many transactions. ✨ How a transport session is actually established, opened, closed, or maintained is specific to a particular Transport Model.
To cut down on redundancy, this document describes the aspects that are expected to be common to all Transport Model sessions 🫶
3.3.1. No SNMP Sessions 🙅♀️
The architecture defined in [RFC3411] and the Transport Subsystem defined in this document do not support SNMP sessions, and they don't include a session selector in the Abstract Service Interfaces.
The Transport Subsystem might support transport sessions. However, it doesn't have access to the pduType (i.e., the SNMP operation type), so it can't select a given transport session for particular types of traffic 🧐
Certain parameters of the Abstract Service Interfaces might be used to guide the selection of an appropriate transport session to use for a given request by an Application 🎀
The transportDomain and transportAddress identify the transport connection to a remote network node. Elements of the transport address (such as the port number) might be used by an Application to send a particular PDU type to a particular transport address. For example, the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to configure notification originators with the destination port to which SNMPv2-Trap PDUs or Inform PDUs are to be sent, but the Transport Subsystem never looks inside the PDU 👀
The securityName identifies which security principal to communicate with at that address (e.g., different Network Management System (NMS) applications), and the securityLevel might permit selection of different sets of security properties for different purposes (e.g., encrypted SET vs. non-encrypted GET operations) 🍓
However, because the handling of transport sessions is specific to each Transport Model, some Transport Models MAY restrict selecting a particular transport session. A user application might use a unique combination of transportDomain, transportAddress, securityModel, securityName, and securityLevel to try to force the selection of a given transport session. This usage is NOT RECOMMENDED, because it is not guaranteed to be interoperable across implementations and across models. Not the move 🙅♀️
Implementations SHOULD be able to maintain some reasonable number of concurrent transport sessions, and MAY provide non-standard internal mechanisms to select transport sessions 💖
3.3.2. Session Establishment Requirements 🌷
SNMP Applications provide the transportDomain, transportAddress, securityName, and securityLevel to be used to create a new session 🧚
If the Transport Model cannot provide at least the requested level of security, the Transport Model should discard the message and should notify the Dispatcher that establishing a session and sending the message failed. Similarly, if the session cannot be established, then the message should be discarded and the Dispatcher notified 😤
Transport session establishment might require provisioning authentication credentials at an engine, either statically or dynamically. How this is done depends on the Transport Model and the implementation 🔑
3.3.3. Session Maintenance Requirements 🧹
A Transport Model can tear down sessions as needed. It might be necessary for some implementations to tear down sessions as the result of resource constraints, for example 🫧
The decision to tear down a session is implementation-dependent. How an implementation determines that an operation has completed is also implementation-dependent. While it is possible to tear down each transport session after processing for each message has completed, this is not recommended for performance reasons 🏎️
The elements of procedure describe when cached information can be discarded. The timing of cache cleanup might have security implications, but cache memory management is an implementation issue 🧠
If a Transport Model defines MIB module objects to maintain session state information, then the Transport Model MUST define what happens to those objects when a related session is torn down, since this will impact the interoperability of the MIB module. This one is a must, bestie, no exceptions 🚨
3.3.4. Message Security versus Session Security 🔐
A Transport Model session is associated with state information that is maintained for its lifetime. This state information allows for the application of various security services to multiple messages. Cryptographic keys associated with the transport session SHOULD be used to provide authentication, integrity checking, and encryption services, as needed, for data communicated during the session. The cryptographic protocols used to establish keys for a Transport Model session SHOULD ensure that fresh new session keys are generated for each session. This would ensure that a cross-session replay attack would be unsuccessful; that is, an attacker could not take a message observed on one session and successfully replay it on another session. Fresh keys, fresh start, no cap 🦋
A good security protocol would also protect against replay attacks within a session. That is, an attacker could not take a message observed on a session and successfully replay it later in the same session. One approach would be to use sequence information within the protocol, allowing the participants to detect if messages were replayed or reordered within a session 🔁
If a secure transport session is closed between the time a request message is received and the corresponding response message is sent, then the response message SHOULD be discarded, even if a new session has been established. The SNMPv3 WG decided that this should be a "SHOULD" architecturally, and it is a Security-Model-specific decision whether to REQUIRE this. The architecture does not mandate this requirement, in order to allow for future Security Models where this might make sense. However, not requiring this could lead to added complexity and security vulnerabilities, so most Security Models SHOULD require this 🚫
SNMPv3 was designed to support multiple levels of security, selectable on a per-message basis by an SNMP Application. For example, there is not much value in using encryption for a command generator to poll for potentially non-sensitive performance data on thousands of interfaces every ten minutes, and such encryption might add significant overhead to processing of the messages 🐢
Some Transport Models might support only specific authentication and encryption services, such as requiring all messages to be carried using both authentication and encryption, regardless of the security level requested by an SNMP Application. A Transport Model MAY upgrade the security level requested by a transport-aware Security Model, i.e., noAuthNoPriv and authNoPriv might be sent over an authenticated and encrypted session. A Transport Model MUST NOT downgrade the security level requested by a transport-aware Security Model, and SHOULD discard any message where this would occur. This is a SHOULD rather than a MUST only to permit the potential development of models that can perform error-handling in a manner less severe than discarding the message. However, any model that does not discard the message in this circumstance should have a clear justification for why not discarding will not create a security vulnerability 🛡️✨
4. Scenario Diagrams and the Transport Subsystem 🎬
Sections 4.6.1 and 4.6.2 of RFC 3411 provide scenario diagrams to illustrate how an outgoing message is created and how an incoming message is processed 🖼️ RFC 3411 does not define ASIs for the "Send SNMP Request Message to Network", "Receive SNMP Response Message from Network", "Receive SNMP Message from Network", and "Send SNMP message to Network" arrows in these diagrams. Missing pieces, so this document fills them in 🧩
This document defines two ASIs corresponding to these arrows: a sendMessage ASI to send SNMP messages to the network, and a receiveMessage ASI to receive SNMP messages from the network. These ASIs are used for all SNMP messages, regardless of pduType 🌟
5. Cached Information and References ✨
okay so when an SNMP engine processes a message, there are two levels of state it might need to hang onto 🧠. the first is the short-term state that links a request to its response. the second is longer-term state about the transport and the security 🔐
the RFC 3411 architecture uses caches for that short-term message state, and passes references in the ASIs so the subsystems can find the right info 🦋
this doc defines the requirements for a cache that handles that extra short-term message state and the longer-term transport state too. the way it does that is with a tmStateReference parameter that passes all of this between subsystems 💖
bestie, the release of state isn't always spelled out explicitly, to keep the elements of procedure simple 🙈 but the general rule is: if state exists when a message gets discarded, the state for that message gets discarded too. and if state exists when a relationship between engines is severed (like a transport session closing), the state for that relationship gets discarded as well 🧹
also, a cache only means something inside an implementation, never on the wire, so its format is up to the implementation 🫶
5.1. securityStateReference
the securityStateReference parameter is defined in RFC 3411 🌸 its main job is mapping a request to its matching response. Transport Models can't touch this cache, and an entry usually only sticks around for the life of one request-response pair 💅
5.2. tmStateReference
for every transport session, info about the transport security gets stored in a tmState cache or datastore, and a tmStateReference points to it 🎀 the tmStateReference parameter is how model-specific and mechanism-specific parameters get passed between the Transport Subsystem and transport-aware Security Models 🦋
generally, when it's needed, the Security Model fills in the tmState for outgoing messages and the Transport Model fills it in for incoming ones. BUT in both cases, the model filling it in might only have partial info, and the missing bits can get filled in by the other model once they show up ✨
the tmState can hold long-term AND short-term info 🌈 session info usually stays valid for the whole transport session, can be used for several messages, and might live in a local configuration datastore. some stuff is shorter-lived, like tmSameSecurity and tmRequestedSecurityLevel, which are tied to one specific message 💜
again, this cache only lives inside an implementation, so its exact contents and format are implementation-dependent 🧚 but for architectural modularity between Transport Models and transport-aware Security Models, a fully-defined tmState MUST conceptually include at least these fields:
tmTransportDomaintmTransportAddresstmSecurityNametmRequestedSecurityLeveltmTransportSecurityLeveltmSameSecuritytmSessionID
the details of each one are in the subsections below 👑
5.2.1. Transport Information
info about where an incoming SNMP message came from gets passed up from the Transport Subsystem as far as the Message Processing Subsystem 📬 BUT these parameters aren't part of the processIncomingMsg ASI from RFC 3411, so the Security Model can't see them directly 😭
and a transport-aware Security Model might want to think about the transport protocol and the originating address when it authenticates the request and sets up the authorization parameters 🔍 so the Transport Model needs to stash this info in the tmStateReference cache, so the Security Model can reach it 🫶
tmTransportDomain: the transport protocol (and therefore the Transport Model) that was used to receive the incoming message.tmTransportAddress: the source of the incoming message.
the ASIs for processing an outgoing message all come with explicit transportDomain and transportAddress parameters 💌 and values inside the securityStateReference cache might override those parameters for outgoing messages 🦋
5.2.2. securityName
okay this one is a lot 🥹 there are actually three distinct "identities" that can show up while processing an SNMP request over a secure transport:
- transport principal: the transport-authenticated identity on whose behalf the secure transport connection was (or should be) established. this value is transport-, mechanism-, and implementation-specific, and it's only used within a given Transport Model 🔐
tmSecurityName: a human-readable name (in snmpAdminString format) that stands for this transport identity. this value is transport- and implementation-specific, and only the Transport and Security Models use it (directly) 🎀securityName: a human-readable name (in snmpAdminString format) that stands for the SNMP principal in a model-independent way. this value gets used directly by SNMP Applications, the Access Control Subsystem, the Message Processing Subsystem, and the Security Subsystem 👑
the transport principal might or might not be the same as the tmSecurityName 🌸 and the tmSecurityName might or might not match the securityName that the Application and Access Control Subsystems see. and, in particular, a non-transport-aware Security Model will totally ignore tmSecurityName when figuring out the SNMP securityName 💀
BUT (and this is important, bestie 🫶) the mapping between the transport principal and the SNMP securityName has to be consistent and predictable for transport-aware Security Models. that's what lets you set up suitable access control and get transport connections established 🔥
5.2.3. securityLevel
there are two separate issues about security level when it comes to secure transports 🦋 so for clarity, they get their own fields in the tmStateReference cache:
tmTransportSecurityLevel: the Transport Model tells you what level of security this session is offering. the Security Model can use this to make sure incoming messages were protected properly before it acts on them 🔐tmRequestedSecurityLevel: the Security Model tells you what level of security the transport protocol is required to provide. the Transport Model can use this to make sure outgoing messages don't get sent over a session that's not secure enough 💅
5.2.4. Session Information
for security reasons, if a secure transport session closes between the time a request message comes in and the time its response goes out, then the response message SHOULD be discarded 🚫 even if a brand new session has been set up in the meantime 😤 the SNMPv3 WG decided that this should be a "SHOULD" architecturally, and it's up to each Security Model whether to REQUIRE this 👑
tmSameSecurity: this flag is used by a transport-aware Security Model to say whether the Transport Model MUST enforce this restriction 🔒tmSessionID: to figure out whether the session has changed, the Transport Model has to be able to compare the session used to receive the original request with the one that'll be used to send the response 🔍 this usually needs some kind of session identifier. this value is only ever used by the Transport Model, so its format and interpretation are model-specific and implementation-dependent 🧚
so when processing an outgoing message: if tmSameSecurity is true, then the tmSessionID MUST match the current transport session. otherwise, the message MUST be discarded and the Dispatcher gets notified that sending the message failed 💥
6. Abstract Service Interfaces
abstract service interfaces (ASIs) were defined by RFC 3411 to describe the conceptual data flows between the different subsystems inside an SNMP entity 🌊 they also help keep the subsystems independent of each other, except for the common parameters 🫶
this doc adds a couple of new ASIs to define the interface between the Transport and Dispatcher Subsystems, and it also extends some of the ASIs from RFC 3411 to include transport-related info 🎀
this doc follows RFC 3411's lead on releasing state info and on error indications 💅
- the release of state info isn't always explicitly spelled out in a Transport Model 🙈 as a general rule, if state info exists when a message gets discarded, the message-state info should also be released. and if state info exists when a session is closed, the session-state info should also be released. keeping sensitive security information around longer than necessary might introduce potential vulnerabilities to an implementation 💀
- an error indication in statusInformation will typically include the Object Identifier (OID) and value for an incremented error counter 📊 this might come with values for contextEngineID and contextName for that counter, a value for securityLevel, and the appropriate state reference if that info is available at the point where the error is detected 🔍
6.1. sendMessage ASI
the sendMessage ASI is used to pass a message from the Dispatcher to the right Transport Model so it can be sent 📤 the sendMessage ASI defined in this doc replaces the text "Send SNMP Request Message to Network" that appears in the diagram in Section 4.6.1 of RFC 3411, and the text "Send SNMP Message to Network" that appears in Section 4.6.2 of RFC 3411 ✨
if it's present and valid, the tmStateReference refers to a cache containing Transport-Model-specific parameters for the transport and transport security 🦋 how a tmStateReference is determined to be present and valid is implementation-dependent. how the info in the cache gets used is Transport-Model-dependent and implementation-dependent too 🧚
this might sound a little vague, but a Transport Model could be something like SNMP over UDP over IPv6, where no security is provided 🌸 so it might have no mechanisms for using a tmStateReference cache at all 🙃
statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length
IN tmStateReference -- reference to transport state
)6.2. Changes to RFC 3411 Outgoing ASIs
extra parameters have been added to the ASIs from RFC 3411 that handle communication between the Dispatcher and Message Processing Subsystems, and between the Message Processing and Security Subsystems 💖 more to come, babe 🌈
6.2.1. Message Processing Subsystem Primitives ✨
okay so tmStateReference is the new OUT param on prepareOutgoingMessage and prepareResponseMessage 🎀 it gets passed from the Message Processing Subsystem to the Dispatcher, and then the Dispatcher hands it off to the Transport Subsystem 🚀
whether the Message Processing Subsystem touches or uses the cache contents is up to the Message-Processing-Model, so it's model-specific 🫶
statusInformation = -- success or errorIndication
prepareOutgoingMessage(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the handle for matching
incoming responses
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
OUT tmStateReference -- (NEW) reference to transport state
)
statusInformation = -- success or errorIndication
prepareResponseMessage(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size able to accept
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
OUT tmStateReference -- (NEW) reference to transport state
)6.2.2. Security Subsystem Primitives 🔐
transportDomain and transportAddress are now IN params on generateRequestMsg and generateResponseMsg, and tmStateReference is a new OUT param on both 💅 the transport domain and address come in from the Dispatcher through the Message Processing Subsystem, and then get passed along to the Security Subsystem 🧚 the tmStateReference goes the other way: Security Subsystem → Message Processing Subsystem → Dispatcher → Transport Subsystems 🦋
if a cache already exists for a session that can be identified by tmTransportDomain, tmTransportAddress, tmSecurityName, and the requested securityLevel, then a transport-aware Security Model might make a tmStateReference pointing to that cache and pass it back as an OUT param 🌸
statusInformation =
generateRequestMsg(
IN transportDomain -- (NEW) destination transport domain
IN transportAddress -- (NEW) destination transport address
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- (NEW) reference to transport state
)
statusInformation =
generateResponseMsg(
IN transportDomain -- (NEW) destination transport domain
IN transportAddress -- (NEW) destination transport address
IN messageProcessingModel -- Message Processing Model
IN globalData -- msgGlobalData
IN maxMessageSize -- from msgMaxSize
IN securityModel -- as determined by MPM
IN securityEngineID -- the value of snmpEngineID
IN securityName -- on behalf of this principal
IN securityLevel -- for the outgoing message
IN scopedPDU -- as provided by MPM
IN securityStateReference -- as provided by MPM
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- (NEW) reference to transport state
)6.3. The receiveMessage ASI 📨
the receiveMessage ASI is how a message gets passed from the Transport Subsystem up to the Dispatcher 💌 it takes over from the text "Receive SNMP Response Message from Network" in the diagram in Section 4.6.1 of RFC 3411, and from the text "Receive SNMP Message from Network" in Section 4.6.2 of RFC3411 ✨
when a message comes in on a transport session, the Transport Model might make a cache for that session if one doesn't already exist, and it gets referenced by tmStateReference 🌈 what's inside that cache is covered in Section 5, and how that info gets figured out is up to the implementation and the Transport Model 🫠
"might create one" sounds kinda vague, I know 😭 but a Transport Model could be something like SNMP over UDP over IPv6, where no transport security is provided, so it might not make a cache at all 🙈
the Transport Model doesn't know the securityModel for an incoming message 💀 that gets decided by the Message Processing Model, in a way that depends on the MPM itself 🧠
statusInformation =
receiveMessage(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN incomingMessage -- the message received
IN incomingMessageLength -- its length
IN tmStateReference -- reference to transport state
)6.4. Changes to RFC 3411 Incoming ASIs 📥
tmStateReference also got added to some of the incoming ASIs that were defined in RFC 3411 🎀 whether a Message Processing Model or Security Model uses it, and how, is specific to that model 💅
this might sound underspecified too, but a Message Processing Model can look at everything in the cache and everything in the message 👑 so the MPM might figure out that the USM Security Model is specified in an SNMPv3 message header 🙌 USM doesn't need any of the values in the tmStateReference cache to authenticate and secure the message 🫶 but an Application could have asked for a secure transport, like the one the SSH Transport Model gives, to send the message to its destination 🔥
6.4.1. Message Processing Subsystem Primitive 🧚
the tmStateReference param of prepareDataElements gets passed from the Dispatcher to the Message Processing Subsystem 🦋 whether or not the Message Processing Subsystem touches or uses the cache contents is up to the Message-Processing-Model 🌸
result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network
IN wholeMsgLength -- as received from the network
IN tmStateReference -- (NEW) from the Transport Model
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- the version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- to be used for possible Response
)6.4.2. Security Subsystem Primitive 🛡️
the processIncomingMessage ASI passes tmStateReference from the Message Processing Subsystem over to the Security Subsystem 💖
if tmStateReference is present and valid, an appropriate Security Model might use the info in the cache 🍓 how or if the Security Subsystem uses that info is up to the Security Model 🌈
statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for the received message
IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
IN tmStateReference -- (NEW) from the Transport Model
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
-- information, needed for response
)7. Security Considerations ✨
okay bestie, this section is SERIOUS 😭🔒. This document sets up an architecture that lets SNMP use transport-layer security services 🫶. Every proposed Transport Model should discuss its own security considerations, so each one gets its own homework 💅.
Some industry folks really want SNMP Transport Models to use transport-layer security with perfect forward secrecy, at least for encryption keys 🔐✨. The vibe: even if the long-term secret keys get leaked, past session keys stay safe 🙈. Each proposed Transport Model should talk about whether perfect forward secrecy makes sense for that model 🦋.
The denial-of-service characteristics of different Transport Models and security protocols will vary 💀. They should be evaluated when you're deciding if a Transport Model fits a particular deployment 🌸.
The cache is going to hold security-related parameters, so implementers SHOULD store that info (in memory or in persistent storage) in a way that protects it from unauthorized disclosure and/or modification 🔥💜. Protect that cache like it's your diary 📖💖.
Also, an SNMP engine must make sure it's sending packets over a transport using credentials that are legal for that engine to use on behalf of that user 🎀. Otherwise an engine with several transports open might get "tricked" into sending a message out the wrong transport 🙃.
A Security Model might have multiple sources for defining the securityName and securityLevel 🧚. Using a secure Transport Model does not mean the securityName and securityLevel picked by the Security Model are the transport-authenticated identity or the transport-provided security services 👀. The securityModel, securityName, and securityLevel parameters are a package deal 💅, and an administrator should understand how the specified securityModel picks the matching securityName and securityLevel 🫶.
7.1. Coexistence, Security Parameters, and Access Control
Okay, the RFC 3411 architecture has the Message Processing Model deciding which Security Model to use 👑. This document doesn't change that, so no drama there ✨.
BUT the architecture change here does let SNMP support two different security approaches 🌈: message-driven security and transport-driven security. With message-driven security, SNMP brings its own security and passes security parameters inside the SNMP message 📨. With transport-driven security, SNMP leans on an external entity to provide security during transport by "wrapping" the SNMP message 🎁.
Using a non-transport-aware Security Model with a secure Transport Model is NOT RECOMMENDED. Not me saying no cap 🚫💀.
Why? Security Models defined before the Transport Security Model (SNMPv1, SNMPv2c, and USM) don't support transport-based security 🙅♀️. They only see the security parameters that live inside the SNMP message, and they have no idea about the security parameters tied to a secure transport 🫠. So the Access Control Subsystem makes its decisions based on the parameters pulled out of the SNMP message, NOT the transport-based ones 😭.
Combining older Security Models with Secure Transport Models has known implications 📋. The securityName used for access control comes from the message-driven identity (which might be unauthenticated), not the transport-driven, authenticated identity ⚠️:
- An SNMPv1 message always gets paired with an SNMPv1 Security Model (per RFC 3584), no matter the transport mapping or Transport Model, and access controls are based on the unauthenticated community name 🍓.
- An SNMPv2c message always gets paired with an SNMPv2c Security Model (per RFC 3584), no matter the transport mapping or Transport Model, and access controls are based on the unauthenticated community name 🍓.
- An SNMPv3 message always gets paired with the securityModel listed in the msgSecurityParameters field of the message (per RFC 3412), no matter the transport mapping or Transport Model. If the SNMPv3 message specifies the User-based Security Model (USM) with noAuthNoPriv, then access controls are based on the unauthenticated USM user 🙈.
- For outgoing messages, if a Secure Transport Model is picked along with a Security Model that doesn't populate a tmStateReference, the Secure Transport Model SHOULD detect the missing valid tmStateReference and fail 🛑.
In times of network stress, a Secure Transport Model might not work properly if its underlying security mechanisms (like Network Time Protocol (NTP), Authentication, Authorization, and Accounting (AAA) protocols, or certificate authorities) aren't reachable 🌧️. The User-based Security Model was explicitly designed NOT to depend on external network services, and it provides its own security services 💪. So it is RECOMMENDED that operators provision authPriv USM as a fallback to back up any Security Model or Transport Model with external dependencies 🧷. That way secure SNMP communications can keep going when the external network service is down 🦋✨.
8. IANA Considerations 🧾
IANA has created a brand-new registry in the Simple Network Management Protocol (SNMP) Number Spaces 🎉. It's called "SNMP Transport Domains" 💖. This registry holds US-ASCII alpha-numeric strings of one to four characters that act as prefixes for the matching SNMP transport domains 🔤. Each transport domain MUST have an OID assignment under snmpDomains [RFC2578] 🪪. Values get assigned via [RFC5226] "Specification Required" 📝.
The registry comes pre-loaded with these starter entries 🌸:
Registry Name: SNMP Transport Domains
Reference: [RFC2578] [RFC3417] [RFC5590]
Registration Procedures: Specification Required
Each domain is assigned a MIB-defined OID under snmpDomains
Prefix snmpDomains Reference
------- ----------------------------- ---------
udp snmpUDPDomain [RFC3417] [RFC5590]
clns snmpCLNSDomain [RFC3417] [RFC5590]
cons snmpCONSDomain [RFC3417] [RFC5590]
ddp snmpDDPDomain [RFC3417] [RFC5590]
ipx snmpIPXDomain [RFC3417] [RFC5590]
prxy rfc1157Domain [RFC3417] [RFC5590]9. Acknowledgments 🫶
The Integrated Security for SNMP WG wants to give a shoutout to the people who helped out with the process 📣💕.
The authors of the submitted Security Model proposals were Chris Elliot, Wes Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David Perkins, Joseph Salowey, and Juergen Schoenwaelder 👑🌟.
The members of the Protocol Evaluation Team were Uri Blumenthal, Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla 🧚✨.
The WG members who did detailed reviews were Wes Hardaker, Jeffrey Hutzelman, Tom Petch, Dave Shield, and Bert Wijnen 🔍💜.
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3412,
December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62,
RFC 3413, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417,
December 2002.10.2. Informative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
BCP 74, RFC 3584, August 2003.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
for the Simple Network Management Protocol (SNMP)",
RFC 5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.Appendix A. Why tmStateReference? 🤔🎀
This appendix is about why we went with a cache-based approach for passing parameters 💭.
There are four approaches that could have been used for passing information between the Transport Model and a Security Model 🧩:
- One could define an ASI to supplement the existing ASIs.
- One could add a header to encapsulate the SNMP message.
- One could utilize fields already defined in the existing SNMPv3 message.
- One could pass the information in an implementation-specific cache or via a MIB module.
A.1. Define an Abstract Service Interface
Abstract Service Interfaces (ASIs) are defined by a set of primitives that specify the services provided and the abstract data elements that get passed when the services are invoked 🛠️. Defining extra ASIs to pass the security and transport information from the Transport Subsystem to the Security Subsystem is consistent with existing RFC 3411/3412 practice, which is a big plus 🌟. It also helps make sure any Transport Model proposal passes the data it needs and doesn't cause side effects by creating model-specific dependencies on models or subsystems other than the ones clearly defined by an ASI 🫶✨.
A.2. Using an Encapsulating Header 🎀
okay so an alternative idea is to wrap the SNMP message in a header. ✨ The header would carry the info the Transport Model needs to pass along to the Dispatcher and then to a Message Processing Model. 💖 The header would sit inside the wholeMessage ASI parameter, and a matching Message Processing Model would strip it off again. 🫶
ngl this one has a catch 💀 The one and only Message Dispatcher would have to be changed so it can figure out which SNMP message version it's dealing with. 😭 On top of that, someone would need to build a brand-new Message Processing Model that knows how to pull the header out of the message and hand it to the Security Model. 🔥 Lots of extra work, so it's giving "maybe not, but here's why we considered it." 💅
A.3. Modifying Existing Fields in an SNMP Message 🦋
[RFC3412] defines the SNMPv3 message, and it already has fields for carrying security-related parameters. 🌸 The Transport Subsystem could reuse those fields (or the equivalent fields in other message formats) to pass information between Transport Models in different SNMP engines, and also between a Transport Model and its matching Message Processing Model. 🧚
here's the tea ☕ If the Transport Model changes the fields in an incoming SNMPv3 message before it goes to the Security Model, the Transport Model would have to decode the ASN.1 message, edit the fields, and then re-encode it in ASN.1 before passing it on to the Message Dispatcher or the transport layer. 😬 That means the Transport Model would need to know the message format and every message version really well, just to know which fields it's allowed to touch. 💀 That would seriously wreck the modularity of the architecture, and we really do not want that, bestie. 🙅♀️
A.4. Using a Cache 💜
this is the approach the document actually describes 👑 The Transport Model (TM) stores information about the security that was applied to an incoming message in a cache, and a Security Model can pull that info back out of the cache. 🍓
Now, there might be several TM security caches floating around, so a tmStateReference gets passed as an extra parameter in the ASIs between the Transport Subsystem and the Security Subsystem. 🧚 That's how the Security Model knows which cache to check. iykyk 🌈
Is there a downside? yes, a little 🙈 This approach does create a dependency between one specific Transport Model and its corresponding specific Security Model. 😭 But honestly, passing a model-independent reference to a model-dependent cache is totally consistent with how securityStateReference is already being passed around in the RFC 3411 ASIs. ✨ Same energy, same vibe, slay. 💅
Authors' Addresses 🫶
David Harrington
Huawei Technologies (USA)
1700 Alma Dr. Suite 100
Plano, TX 75075
USA
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Juergen Schoenwaelder
Jacobs University Bremen
Campus Ring 1
28725 Bremen
Germany
Phone: +49 421 200-3587
EMail: j.schoenwaelder@jacobs-university.de📦 where this page comes from
- ietf: rfc5590 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms