Transport Subsystem for the Simple Network Management Protocol (SNMP)
updates
- rfc-3411 — An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
- rfc-3412 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
- rfc-3414 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
- rfc-3417 — Transport Mappings for the Simple Network Management Protocol (SNMP)
also
- std-78
Extracted elements (30)
The cache-based tmStateReference approach was chosen over three alternatives: defining new ASIs (more consistent but adds complexity), using an encapsulating header (would require Message Dispatcher modification and a new Message Processing Model), or modifying existing SNMPv3 message fields (would require Transport Models to decode/re-encode ASN.1, violating modularity). The cache approach is consistent with the existing securityStateReference pattern in RFC 3411.
The requirement to discard responses when a secure transport session closes between request and response is architecturally a SHOULD (not a MUST) to allow future Security Models where this restriction might not make sense. However, not requiring this could lead to added complexity and security vulnerabilities, so most Security Models SHOULD require it.
The separation of authentication and authorization (securityModel, securityName, securityLevel passed as model-independent parameters) was a deliberate RFC 3411 design decision to support authentication protocols lacking authorization capabilities and to support authorization schemes (like VACM) that do not perform their own authentication. The Transport Subsystem preserves this separation.
The Transport Subsystem was motivated by operational experience showing that USM's separate principal and key management infrastructure was a deterrent to SNMPv3 deployment. Operators wanted to leverage existing unified security infrastructures (SSH, TLS) already used for CLI and other management protocols like syslog and NETCONF, rather than maintaining a separate SNMP-specific key management system.
A non-transport-aware Security Model will ignore tmSecurityName completely when determining the SNMP securityName. For outgoing messages, if a Secure Transport Model is selected with a Security Model that does not populate a tmStateReference, the Secure Transport Model SHOULD detect the lack of a valid tmStateReference and fail.
SNMPv1 messages are always paired with the SNMPv1 Security Model (per RFC 3584) regardless of the Transport Model; access control is based on the unauthenticated community name. Similarly, SNMPv2c messages always use the SNMPv2c Security Model. SNMPv3 messages use the Security Model specified in msgSecurityParameters. Transport Models cannot override this binding.
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. A Transport Model MAY upgrade the security level (e.g., sending noAuthNoPriv over an authenticated and encrypted session).
A Transport Model SHOULD NOT require modifications to the underlying transport protocol, as modifying the protocol might change its security characteristics in ways that could impact other existing usages. If a change is necessary, it SHOULD be an extension with no impact on existing usages.
Cryptographic keys associated with a transport session SHOULD be used to provide authentication, integrity, and encryption. The cryptographic protocols SHOULD ensure fresh new session keys are generated for each session to prevent cross-session replay attacks.
Documents defining a new transport domain MUST define a prefix (one to four US-ASCII alpha-numeric characters, excluding ':') that MAY be prepended to all securityNames. A prefixed securityName is formed by concatenating the prefix, a ':' (0x3a), and a non-empty snmpAdminString-compatible identity. This allows distinguishing principals authenticated by different transports (e.g., SSH 'alice' vs. TLS 'alice').
If a secure transport session is closed between the time a request message is received and the corresponding response is sent, the response message SHOULD be discarded even if a new session has been established. This is architecturally a SHOULD; specific Security Models may REQUIRE it.
If a Transport Model defines MIB module objects to maintain session state information, the Transport Model MUST define what happens to those objects when a related session is torn down, as this impacts interoperability of the MIB module.
Since multiple Transport Models can exist simultaneously within the Transport Subsystem, Transport Models MUST be able to coexist with each other.
Transport security protocols SHOULD provide protection against modification of information, masquerade, message stream modification, and disclosure. Transport security protocols should not make denial-of-service or traffic analysis threats significantly worse.
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 notified that sending the message failed.
The prepareDataElements and processIncomingMsg ASIs (RFC 3411) are extended with a new IN parameter tmStateReference, passed from the Dispatcher into the Message Processing Subsystem and then to the Security Subsystem. How or if each model utilizes the tmStateReference is model-specific.
The prepareOutgoingMessage and prepareResponseMessage ASIs (RFC 3411) are extended with a new OUT parameter tmStateReference, passed from the Message Processing Subsystem to the Dispatcher and then to the Transport Subsystem. The generateRequestMsg and generateResponseMsg ASIs (RFC 3411) gain new IN parameters transportDomain and transportAddress, and a new OUT parameter tmStateReference.
The receiveMessage ASI is used to pass a message from the Transport Subsystem to the Dispatcher. Parameters: IN transportDomain, transportAddress, incomingMessage, incomingMessageLength, tmStateReference; OUT statusInformation. It replaces the informal 'Receive SNMP Message from Network' arrows in RFC 3411 scenario diagrams.
The sendMessage ASI is used to pass a message from the Dispatcher to the appropriate Transport Model. Parameters: IN destTransportDomain, destTransportAddress, outgoingMessage, outgoingMessageLength, tmStateReference; OUT statusInformation. It replaces the previously informal 'Send SNMP Message to Network' arrows in RFC 3411 scenario diagrams.
The tmStateReference is a reference to an implementation-specific cache (tmState) containing transport and security parameters for a session. It is passed between the Transport Subsystem and the Message Processing and Security Subsystems via extended ASIs. The tmState MUST conceptually include: tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, tmTransportSecurityLevel, tmSameSecurity, and tmSessionID.
The Transport Subsystem is a new modular component added to the RFC 3411 SNMP engine architecture, sitting alongside the Dispatcher, Message Processing Subsystem, Security Subsystem, and Access Control Subsystem. It contains Transport Models (such as UDP, SSH, TLS) that can be 'plugged in' independently. This enables secure transports to be used beneath SNMP without altering other subsystems.
Three distinct identities are defined for SNMP over secure transport: (1) the transport principal (mechanism-specific, only used within the Transport Model); (2) tmSecurityName (human-readable snmpAdminString, used by Transport and Security Models); (3) securityName (model-independent human-readable name used by Applications, Access Control, Message Processing, and Security Subsystems).
tmSameSecurity is a flag set by a transport-aware Security Model indicating whether the Transport Model MUST enforce same-session semantics for request/response pairs. tmSessionID is a model-specific and implementation-dependent session identifier used by the Transport Model to verify that the session used for the response matches the session used for the original request.
Two distinct security level fields exist in tmState: tmTransportSecurityLevel (the level of security offered by the session, set by the Transport Model for incoming messages) and tmRequestedSecurityLevel (the level required by the Security Model, used to prevent sending outgoing messages over an insufficiently secure session).
IANA created a new registry 'SNMP Transport Domains' in the SNMP Number Spaces. It maps 1-4 character US-ASCII alpha-numeric prefixes to OID assignments under snmpDomains (RFC 2578). Registration procedure is Specification Required. Initial entries include: udp, clns, cons, ddp, ipx, prxy.
Care must be taken to ensure that an SNMP engine sends packets over a transport using credentials that are legal for that engine on behalf of that user. An engine with multiple transports open might otherwise be tricked into sending a message through the wrong transport.
Implementers SHOULD store tmState cache information (in memory or persistent storage) in a manner that protects it from unauthorized disclosure and/or modification, since the cache contains security-related parameters.
It is considered desirable that SNMP Transport Models utilize transport-layer security that addresses perfect forward secrecy at least for encryption keys, guaranteeing that compromise of long-term keys does not result in disclosure of past session keys. Each proposed Transport Model should discuss whether PFS is appropriate.
It is RECOMMENDED that operators provision authPriv USM as a fallback mechanism to supplement any Security Model or Transport Model that has external dependencies (e.g., NTP, AAA, certificate authorities), so that secure SNMP communications can continue when external network services are unavailable.
Using a non-transport-aware Security Model (SNMPv1, SNMPv2c, USM) with a Secure Transport Model is NOT RECOMMENDED. Such models base access control decisions on the unauthenticated message-level identity (community name or USM user), not on the transport-authenticated identity, creating a security gap.