Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
obsoleted by
- rfc-2572 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-2262 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
Extracted elements (29)
msgID and PDU request-id are intentionally kept separate: request-id is for SNMP applications to identify PDUs, while msgID is for the engine to identify messages. The engine may need to identify the message even when PDU decryption (and thus request-id) fails, so no equivalence between the two should be assumed.
msgID values should be generated using the low-order bits of snmpEngineBoots as the high-order portion combined with a monotonically increasing integer for the low-order portion, providing replay protection without requiring unpredictable values—non-repetition is sufficient.
The Message Processing Subsystem is designed to support concurrent, independently-described Message Processing Models (v1MP, v2cMP, v3MP, etc.) so that new SNMP versions can be added without changing the Dispatcher architecture.
The msgVersion field occupies the same position in SNMPv3 messages as in SNMPv1 and SNMPv2c messages, enabling a receiver to recognize the SNMP version before applying version-specific parsing.
The pduVersion element is passed from the Message Processing Model to both the Dispatcher and applications so they know whether to apply RFC1905 (SNMPv2) or SNMPv1 PDU semantics; the v3MP always sets pduVersion to SNMPv2-PDU for all decoded messages.
A unique msgID MUST be generated for each outgoing request; the value must not have been used recently and must not duplicate any outstanding request's msgID. This provides replay-attack protection.
For incoming request-type PDUs, the securityEngineID extracted by the Security Model MUST equal the local snmpEngineID; otherwise the message is discarded without further processing.
If privacy is selected (privFlag set), then authentication MUST also be required (authFlag must also be set to one). The combination authFlag=0, privFlag=1 is explicitly invalid.
If the reportableFlag is incorrectly set (e.g. set to one for a Response or Report PDU), the receiver MUST process the message as though the reportableFlag had been set to the correct value.
The reportableFlag MUST always be zero when the message contains a Report PDU, a response-type PDU, or an unacknowledged notification-type PDU (e.g. SNMPv2-Trap). It MUST always be one for request-type PDUs and acknowledged notification-type PDUs (e.g. Inform).
When an incoming message references an unknown or unsupported securityModel, the snmpUnknownSecurityModels counter is incremented, a Report PDU is generated, and the message is discarded without further processing.
When no application has registered for a received contextEngineID/pduType combination, the snmpUnknownPDUHandlers counter is incremented and a Response message containing the snmpUnknownPDUHandlers OID/value pair is sent back to the originator.
When processing an incoming Response-PDU, cached values for snmpEngineID, securityModel, securityName, securityLevel, contextEngineID, and contextName MUST match the corresponding fields extracted from the incoming message; any mismatch causes the message to be discarded.
Applications register with the PDU Dispatcher by supplying a contextEngineID and one or more pduTypes via the registerContextEngineID primitive. Each contextEngineID/pduType combination may be registered by at most one application.
Report PDUs are engine-to-engine communications processed directly by the v3MP and are generally not passed to applications. They carry an OID/value pair from statusInformation in the varBindList with error-status and error-index set to 0.
sendPduHandle is a locally significant handle generated by the Dispatcher to coordinate request/response processing. It must be unique across all Message Processing Models and is used to match incoming responses to outstanding requests.
The Dispatcher is a singleton within an SNMP engine responsible for routing outgoing PDUs to version-specific Message Processing Models and dispatching incoming PDUs to registered applications based on contextEngineID and pduType.
The SNMP-MPD-MIB (snmpModules 11) defines three Counter32 objects: snmpUnknownSecurityModels, snmpInvalidMsgs, and snmpUnknownPDUHandlers, all under snmpMPDStats. Conforming entities must implement the snmpMPDGroup containing all three.
The SNMPv3 message format consists of a SEQUENCE containing msgVersion (INTEGER snmpv3(3)), msgGlobalData (HeaderData), msgSecurityParameters (OCTET STRING), and msgData (ScopedPduData). HeaderData includes msgID, msgMaxSize, msgFlags (1-octet), and msgSecurityModel.
The v3MP caches per-request state (sendPduHandle, msgID, snmpEngineID, securityModel, securityName, securityLevel, contextEngineID, contextName) after sending a request. This cache is keyed by msgID for matching incoming Response or Report PDUs.
The SNMP-MPD-MIB module is assigned OID { snmpModules 11 } (correcting a clerical error in the earlier RFC 2262, which this document obsoletes). The MIB provides managed objects for monitoring Message Processing and Dispatching statistics.
msgID values used in communication between SNMP entities must be chosen to avoid replay attacks. The values do not need to be unpredictable; it is sufficient that they not repeat across outstanding requests.
The level of security provided by the framework is primarily determined by the specific Security Model and SNMP application implementations. Applications have access to unsecured data and should protect it from disclosure, obey the securityLevel, and invoke Access Control Model services.
Incoming PDU dispatching branches on sendPduHandle: if <none>, the PDU is a request or notification and is dispatched to a registered application via processPdu; if not <none>, the PDU is a response, matched to an outstanding request via sendPduHandle, and forwarded via processResponsePdu.
msgFlags is a 1-octet OCTET STRING encoding three bit fields: bit 0 (authFlag), bit 1 (privFlag), and bit 2 (reportableFlag). The combination authFlag=0/privFlag=1 is reserved and must NOT be used; authFlag=0/privFlag=0 means noAuthNoPriv, authFlag=1/privFlag=0 means authNoPriv, authFlag=1/privFlag=1 means authPriv.
msgID is an INTEGER (0..2147483647) used to correlate requests and responses between SNMP entities and to coordinate processing across subsystem models. It is distinct from the PDU request-id and must be findable even if PDU decryption fails.
msgMaxSize is an INTEGER (484..2147483647) conveying the maximum message size the sender can accept in a response. The receiver uses this value to size response messages.
msgSecurityParameters is an OCTET STRING whose content and format are defined entirely by the Security Model indicated by msgSecurityModel; the v3MP passes it opaquely to the security module without interpretation.
scopedPDU is a SEQUENCE of contextEngineID (OCTET STRING), contextName (OCTET STRING), and data (ANY, e.g. PDUs per RFC1905). When privacy is applied, it is transmitted as an encryptedPDU OCTET STRING within ScopedPduData.