Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
obsoleted by
- rfc-3412 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-2272 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
Extracted elements (30)
The msgID is kept separate from the PDU request-id because the engine must be able to identify the message even if decryption of the PDU (and thus the request-id) fails. No assumption should be made that msgID and request-id are equivalent.
The msgVersion field is placed in the same position as in SNMPv1 and SNMPv2c messages, allowing a receiver to recognize the SNMP version before full parsing. The value 3 identifies an SNMPv3 message.
The SNMPv3 Message Processing Model does not interpret msgSecurityParameters; this OCTET STRING is passed opaquely to the Security Model indicated by msgSecurityModel, allowing Security Models to define their own parameter formats independently of the MP layer.
The Dispatcher supports concurrent multiple Message Processing Models (v1MP, v2cMP, v3MP, and others) identified by the messageProcessingModel value. An incoming message's SNMP version is determined before dispatching to the correct version-specific model.
When an incoming SNMPv3 message has authFlag=0 and privFlag=1, the snmpInvalidMsgs counter is incremented and the message is discarded without further processing; this invalid security level combination must not be processed.
Each combination of contextEngineID and pduType can be registered by an application only once; if another application has already registered for that combination, an errorIndication (alreadyRegistered) is returned.
If a receiver encounters reportableFlag=1 for an Unconfirmed Class PDU, it MUST process the message as though reportableFlag were zero; similarly, if reportableFlag=0 for a Confirmed Class PDU, it must be treated as though set to one.
If the privFlag is set, the authFlag MUST also be set to one; privacy without authentication is an invalid combination.
The receiver of an SNMP message MUST apply the same securityLevel (as indicated by authFlag and privFlag in msgFlags) when processing the message as was applied by the sender.
The remaining (reserved) bits in msgFlags MUST be set to zero when sending a message and SHOULD be ignored when receiving a message.
The reportableFlag MUST always be zero when the message contains a PDU from the Unconfirmed Class (Report, Response, or unacknowledged Notification). It MUST always be one for Confirmed Class PDUs (request-type or Inform PDUs).
Values for msgID SHOULD be generated in a manner that avoids re-use of any outstanding values, providing protection against some replay attacks. A new msgID value SHOULD be used for each retransmission.
Applications register with the PDU Dispatcher by specifying a contextEngineID and one or more pduTypes they will handle via registerContextEngineID. They unregister via unregisterContextEngineID when they no longer wish to handle those PDU types.
msgFlags is a one-octet field whose authFlag (bit 0), privFlag (bit 1), and reportableFlag (bit 2) control security processing and Report PDU generation. The combinations authFlag=0/privFlag=1 and authFlag=1/privFlag=0 yield noAuthNoPriv and authNoPriv respectively; authFlag=1/privFlag=1 yields authPriv; authFlag=0/privFlag=1 is invalid.
msgID is used between two SNMP entities to correlate request messages and responses and to coordinate processing across subsystem models. The msgID is distinct from the PDU request-id; the engine needs msgID even if PDU decryption fails.
msgMaxSize conveys the maximum message size the sender can accept when another SNMP engine sends it a message on the current transport; minimum value is 484 octets.
The Dispatcher is the single component in an SNMP engine responsible for sending and receiving SNMP messages, dispatching PDUs to applications, and delegating version-specific message preparation to Message Processing Models. There is exactly one Dispatcher per SNMP engine.
The Message Processing Subsystem contains one or more Message Processing Models, each responsible for processing a version-specific SNMP message and coordinating security services. This document defines the SNMPv3 Message Processing Model (v3MP) as one such model.
The sendPduHandle is a locally significant handle generated by the Dispatcher to coordinate request/response processing between the SNMP engine and an application. It must be unique across all version-specific Message Processing Models.
When no application has registered for an incoming contextEngineID/pduType combination, the Dispatcher increments snmpUnknownPDUHandlers, generates a Response containing the snmpUnknownPDUHandlers OID/value pair, and discards the incoming message.
The SNMP-MPD-MIB (snmpModules 11) defines the snmpMPDStats group with three Counter32 objects: snmpUnknownSecurityModels, snmpInvalidMsgs, and snmpUnknownPDUHandlers, for remote monitoring of the Message Processing and Dispatching process.
Applications have access to data that is not secured and should take reasonable steps to protect it from disclosure. When sending data across the network, applications should obey the securityLevel and invoke an Access Control Model.
For incoming Response Class PDUs, if the securityModel, securityName, securityLevel, contextEngineID, or contextName values differ from the cached values for the outstanding request, the message is discarded. An implementation may optionally retain cached state to handle the case where the response might be illegitimate.
The values for msgID must be chosen to avoid replay attacks; they need not be unpredictable but must not repeat across outstanding requests. Internal Class PDUs delivered at noAuthNoPriv security level open a window for spoofing or replay attacks, though receivers aware of these risks may accept them for engine ID discovery or misconfiguration detection.
For incoming SNMPv3 messages, v3MP determines securityLevel from msgFlags bits, calls the Security Model's processIncomingMsg, then classifies the pduType as Response Class (validate cached state, discard on mismatch), Internal Class (Report PDU handling with optional cached state retention), Confirmed Class (cache state), or Unconfirmed Class (return SUCCESS immediately).
For outgoing SNMPv3 messages, v3MP generates a unique msgID, constructs msgGlobalData (msgVersion=3, msgFlags per securityLevel and PDU class, msgSecurityModel), wraps the PDU in a scopedPDU, then calls generateResponseMsg (for Response/Internal class) or generateRequestMsg (for Confirmed/Notification class) on the Security Model.
Incoming message processing follows a two-phase dispatch: (1) the Dispatcher passes the message to the version-specific MP Model via prepareDataElements; (2) if sendPduHandle is <none> the PDU is dispatched as a request/notification via processPdu, otherwise it is dispatched as a response via processResponsePdu using the cached sendPduHandle.
HeaderData contains msgID (INTEGER 0..2147483647), msgMaxSize (INTEGER 484..2147483647), msgFlags (OCTET STRING SIZE(1) with authFlag bit 0, privFlag bit 1, reportableFlag bit 2), and msgSecurityModel (INTEGER 1..2147483647).
The ScopedPDU is an ASN.1 SEQUENCE containing contextEngineID (OCTET STRING), contextName (OCTET STRING), and data (ANY, e.g., PDUs per RFC 1905). When privacy is applied, it is encoded as an encrypted OCTET STRING in the ScopedPduData field.
The SNMPv3Message is an ASN.1 SEQUENCE containing: msgVersion (INTEGER 0..2147483647), msgGlobalData (HeaderData SEQUENCE), msgSecurityParameters (OCTET STRING), and msgData (ScopedPduData CHOICE of plaintext ScopedPDU or encrypted OCTET STRING).