rfc-2262

Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

J. Case, D. Harrington, R. Presuhn, B. Wijnen
date1998-01 streamIETF areaops wgsnmpv3 statusPROPOSED STANDARD pages39 canonicalhttps://www.rfc-editor.org/rfc/rfc2262 doi10.17487/RFC2262
This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

obsoleted by

Extracted elements (28)

design-rationale §6.2

A recommended msgID generation strategy uses the low-order bits of snmpEngineBoots as the high-order portion and a monotonically increasing integer for the low-order portion. This avoids reuse of outstanding values and provides replay protection without requiring unpredictable values.

snmp, security

design-rationale §6.2

msgID and the PDU's request-id are intentionally distinct. The msgID identifies the message and must be accessible even if PDU decryption fails; the request-id in the PDU is used by SNMP applications to identify the PDU. No assumption should be made that their values are equivalent.

snmp

design-rationale §2.2

The v3MP is defined in a separate section of the document to demonstrate that multiple independent Message Processing Models (v1MP, v2cMP, v3MP, and others) can coexist simultaneously within the architecture and can be described in separate documents.

snmp

interoperability-note §2.2

The Message Processing Subsystem is designed to support multiple concurrent version-specific MP models. SNMPv1 (RFC 1157) and SNMPv2c (RFC 1901) message formats are identified as future models; the architecture does not restrict the number or types of models that can coexist.

snmp

normative-requirement §7.1 MUST NOT

A unique msgID MUST be generated for each outgoing request; the value MUST NOT be the same as any outstanding request. Values should not have been used recently to provide protection against some replay attacks.

snmp, security

normative-requirement §4.3 REQUIRED

Each combination of contextEngineID and pduType can be registered with the PDU Dispatcher only once; a second registration attempt for the same combination returns an errorIndication of alreadyRegistered.

snmp

normative-requirement §7.2 MUST

For an incoming Response-PDU, the v3MP MUST compare the message's securityEngineID, securityModel, securityName, securityLevel, contextEngineID, and contextName against cached values from the original request; if any differ, the message MUST be discarded without further processing.

snmp, security

normative-requirement §7.2 MUST

For incoming GetRequest, GetNextRequest, GetBulkRequest, SetRequest, or InformRequest PDUs, if the value of securityEngineID is not equal to the local snmpEngineID, the message MUST be discarded without further processing and a FAILURE result returned.

snmp, security

normative-requirement §4.2.1 MUST

If an incoming message cannot be parsed to determine the SNMP version, snmpInASNParseErrs MUST be incremented and the message discarded. If the version is not supported, snmpInBadVersions MUST be incremented and the message discarded.

snmp

normative-requirement §6.4 MUST

If the privFlag is set in msgFlags, the authFlag MUST also be set to one. The SNMP architecture explicitly requires that if privacy is selected, authentication is also required; the combination authFlag=0/privFlag=1 is invalid.

snmp, security

normative-requirement §6.4 MUST

The reportableFlag MUST be zero for messages containing a Report PDU, a Response PDU, or an SNMPv2-Trap PDU; it MUST be one for Request-type PDUs and InformRequest PDUs. If the flag is incorrectly set, the receiver MUST process the message as if it were set correctly.

snmp

normative-requirement §7.2 MUST

Upon receiving a message where authFlag=0 and privFlag=1, the v3MP MUST increment snmpInvalidMsgs, generate a Report PDU, discard the message without further processing, and return FAILURE.

snmp, security

normative-requirement §4.2.2.1 MUST

When no application has registered for the contextEngineID/pduType combination of an incoming request or notification, snmpUnknownPDUHandlers MUST be incremented and a Response containing the snmpUnknownPDUHandlers OID/value pair MUST be sent back to the originator.

snmp

protocol-element §4.2.2

PDU dispatch after message processing is determined by sendPduHandle: a value of <none> indicates an incoming request or notification (dispatched via processPdu), while a non-<none> value indicates a response matched to an outstanding request (dispatched via processResponsePdu).

snmp

protocol-element §6.4

Report PDUs are engine-to-engine communications processed directly by the SNMPv3 Message Processing Model and are generally not passed to applications, unlike all other PDU types. They carry OID/value pairs from statusInformation (e.g., error counters).

snmp

protocol-element §3.4

sendPduHandle is a locally significant handle generated by the Dispatcher to coordinate the processing of requests and responses between the SNMP engine and an application. It must be unique across all version-specific Message Processing Models.

snmp

protocol-element §2.1

The Dispatcher is the sole dispatch component in an SNMP engine. It routes outgoing PDUs to version-specific Message Processing Models for message preparation, and routes incoming messages to the appropriate MP Model for extraction, then forwards extracted PDUs to registered applications.

snmp

protocol-element §6

The SNMPv3Message wire structure is a SEQUENCE containing msgVersion (snmpv3(3)), msgGlobalData (HeaderData with msgID, msgMaxSize, msgFlags, msgSecurityModel), msgSecurityParameters (OCTET STRING), and msgData (ScopedPduData, either plaintext ScopedPDU or encryptedPDU OCTET STRING).

snmp

registry §5.1

This document defines the SNMP-MPD-MIB (OID snmpModules 3) containing the snmpMPDStats group with three mandatory Counter32 objects: snmpUnknownSecurityModels, snmpInvalidMsgs, and snmpUnknownPDUHandlers, used for remote monitoring of the message processing subsystem.

snmp, registry

security-consideration §10

Applications have access to data that is not secured by the messaging layer. Applications should take reasonable steps to protect data from disclosure, and when sending data across the network they should obey the securityLevel and invoke Access Control Model services.

snmp, security

security-consideration §10

The actual level of security provided by the framework is primarily determined by the specific Security Model and SNMP application implementations incorporated. The Dispatcher and v3MP interact with Security Models via abstract service interface primitives but do not themselves implement security algorithms.

snmp, security

security-consideration §10

Values for msgID 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.

snmp, security

wire-format §6.4

msgFlags is an OCTET STRING of SIZE(1) with three defined bits: authFlag (bit 0), privFlag (bit 1), and reportableFlag (bit 2). The combination authFlag=0/privFlag=1 is reserved and must NOT be used; the three valid combinations map to noAuthNoPriv, authNoPriv, and authPriv.

snmp, security

wire-format §6.2

msgID is an INTEGER (0..2147483647) used between two SNMP entities to coordinate request messages and responses, and by the v3MP to coordinate processing across subsystem models. It is distinct from the PDU's request-id field.

snmp

wire-format §6.3

msgMaxSize is an INTEGER (484..2147483647) that conveys the maximum message size the sender can accept when another SNMP engine sends it a message; used by the receiver to bound the size of any generated Response.

snmp

wire-format §6.5

msgSecurityModel is an INTEGER (0..2147483647) that identifies which Security Model was used by the sender; the receiver MUST apply the same Security Model when processing the message.

snmp, security

wire-format §6.6

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 appropriate Security Model implementation without interpretation.

snmp, security

wire-format §6.8

ScopedPDU is a SEQUENCE of contextEngineID (OCTET STRING), contextName (OCTET STRING), and data (ANY, e.g., PDUs per RFC 1905). It is either carried as plaintext in scopedPduData or as an encryptedPDU OCTET STRING when privacy is applied.

snmp