Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-2572 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
updated by
- rfc-5590 — Transport Subsystem for the Simple Network Management Protocol (SNMP)
also
- std-62
Extracted elements (29)
The msgID and the PDU request-id serve distinct purposes: the request-id identifies the PDU for applications, while the msgID identifies the message for the engine. The engine needs msgID to identify messages even when PDU decryption (and thus request-id extraction) fails, so no assumption should be made that msgID and request-id are equivalent.
The reportableFlag is a secondary aid for determining whether a Report PDU must be sent, used only when the PDU portion cannot be decoded (e.g., incorrect encryption key). When the PDU can be decoded, the pduType alone governs Report PDU generation decisions.
The SNMPv3 Message Processing Model is defined in a separate section to demonstrate that multiple independent Message Processing Models can coexist simultaneously and be described in separate documents. The v3MP can be replaced or supplemented by other models in the future.
For Response Class incoming PDUs, the v3MP implementation may retain cached information about the outstanding request even when securityModel or securityLevel values differ from the cached ones, in anticipation that the received Response Class PDU might be illegitimate rather than a legitimate superseding response.
The msgVersion field occupies the same position in SNMPv3 messages as in SNMPv1 and SNMPv2c, allowing an SNMP engine to recognize the message version before invoking version-specific parsing. The value 3 denotes SNMPv3.
A Report PDU MUST NOT be generated unless the PDU causing the Report can be determined to be a member of the Confirmed Class, or the reportableFlag is set to one and the PDU class cannot be determined.
For incoming Confirmed Class PDUs (step 7.2.13), if the value of securityEngineID is not equal to the value of snmpEngineID, the message MUST be discarded without further processing.
For incoming Response Class PDUs, if the values of securityEngineID, securityModel, securityName, securityLevel, contextEngineID, or contextName extracted from the incoming message differ from the cached data for the outstanding request, the message MUST be discarded.
If the privFlag is set in msgFlags, the authFlag MUST also be set to one, as the SNMP architecture requires authentication when privacy is selected. A message with authFlag=0 and privFlag=1 is invalid; the snmpInvalidMsgs counter is incremented and the message discarded.
The msgID field MUST NOT be the same as the msgID used for any currently outstanding request. Values must be chosen to avoid replay attacks; they do not need to be unpredictable but must not repeat across outstanding requests.
The msgSecurityModel field identifies which Security Model was used by the sender; the receiver MUST use that same Security Model for security processing of the message.
The reportableFlag MUST always be zero for PDUs from the Unconfirmed Class (Report PDU, response-type PDUs, unacknowledged notifications) and MUST always be one for PDUs from the Confirmed Class (request-type PDUs, Inform PDU). If misset, receivers MUST treat the flag as if correctly set.
Values for msgID SHOULD be generated in a manner that avoids re-use of any outstanding values to provide protection against replay attacks. A new msgID value SHOULD be used for each retransmission of a request.
When no application has registered for an incoming request's contextEngineID/pduType combination, the snmpUnknownPDUHandlers counter MUST be incremented, a Response message with that error counter OID/value pair MUST be generated and sent, and the message discarded.
Application registration uses the registerContextEngineID() primitive, binding a contextEngineID and pduType combination to an application. Each combination can be registered only once; duplicate registration returns errorIndication (alreadyRegistered).
The abstract sendPdu() service primitive is used by applications to request the Dispatcher to send a PDU. It accepts transportDomain, transportAddress, messageProcessingModel, securityModel, securityName, securityLevel, contextEngineID, contextName, pduVersion, PDU, and expectResponse as inputs.
The Dispatcher is the single component in an SNMP engine responsible for dispatching tasks to version-specific Message Processing Models and dispatching PDUs to applications. There is only one Dispatcher per SNMP engine. It also collects statistics about SNMP messages in managed objects.
The messageProcessingModel identifies a Message Processing Model, which handles version-specific procedures for extracting/generating messages, calling security models, and converting between version-specific and generic Dispatcher formats.
The msgVersion field is set to snmpv3(3) for SNMPv3 messages. Its position in the message is the same as in SNMPv1 and SNMPv2c, enabling version identification before version-specific parsing.
The sendPduHandle is a locally significant handle generated by the Dispatcher to coordinate processing of requests and responses between the SNMP engine and applications. It must be unique across all version-specific Message Processing Models.
The SNMP-MPD-MIB (OID snmpModules 11) defines the snmpMPDStats group with three read-only Counter32 objects: snmpUnknownSecurityModels (packets dropped for unknown securityModel), snmpInvalidMsgs (packets dropped for invalid/inconsistent components), and snmpUnknownPDUHandlers (packets dropped for unregistered contextEngineID/pduType).
Internal Class PDUs (Report PDUs) may be delivered at noAuthNoPriv security level independent of the preceding exchange's security level, opening a window for spoofing or replay attacks. Receivers aware of these risks may still accept such messages for discovering engine IDs or detecting misconfiguration.
The msgID values used in SNMP entity communication MUST be chosen to avoid replay attacks. They need not be unpredictable, but must not repeat across outstanding requests. Applications must obey securityLevel and call upon Access Control Model services when sending data across the network.
Incoming message PDU dispatching branches on sendPduHandle: if <none>, the PDU is a request or notification dispatched via processPdu() to the registered application; if not <none>, it is a response matched by sendPduHandle and dispatched via processResponsePdu(). Unmatched responses increment snmpUnknownPDUHandlers.
The v3MP classifies incoming PDUs into Response Class, Internal Class (Report PDU), Confirmed Class, and Unconfirmed Class, each triggering distinct processing paths: response matching via msgID, Report PDU forwarding with spoofing caveats, Confirmed Class caching with stateReference, or immediate SUCCESS for Unconfirmed.
HeaderData is an ASN.1 SEQUENCE containing msgID (INTEGER 0..2147483647), msgMaxSize (INTEGER 484..2147483647), msgFlags (OCTET STRING SIZE(1)), and msgSecurityModel (INTEGER 1..2147483647).
ScopedPduData is an ASN.1 CHOICE between a plaintext ScopedPDU SEQUENCE (contextEngineID OCTET STRING, contextName OCTET STRING, data ANY) and an encryptedPDU OCTET STRING. The choice is determined by the privFlag in msgFlags.
The msgFlags field is a single octet with three defined bits: bit 0 (authFlag), bit 1 (privFlag), and bit 2 (reportableFlag). The combination authFlag=0, privFlag=1 is reserved and MUST NOT be used. All other bits are reserved and MUST be zero on send.
The SNMPv3Message is an ASN.1 SEQUENCE containing msgVersion (INTEGER 0..2147483647), msgGlobalData (HeaderData SEQUENCE), msgSecurityParameters (OCTET STRING), and msgData (ScopedPduData CHOICE). The msgVersion field is in the same position as in SNMPv1 and SNMPv2c to allow version recognition.