An Architecture for Describing SNMP Management Frameworks
obsoleted by
- rfc-2571 — An Architecture for Describing SNMP Management Frameworks
obsoletes
- rfc-2261 — An Architecture for Describing SNMP Management Frameworks
Extracted elements (28)
Abstract service interfaces defined by primitive signatures establish the conceptual boundaries between subsystems and between documents. This allows each piece to be implemented and standardized independently — the boundaries are defined by the abstract interface contract, not by shared internal data structures.
Each portion of the SNMP framework is defined in a self-contained document together with the MIB objects needed for its processing, without cross-document normative references to that content. This allows Security Models, authentication/privacy mechanisms, and message formats to be upgraded independently and progress on different standards-track timelines.
Remote configuration of security and access control parameters is explicitly required because the Security Subsystem demands frequent rotation of secrets across potentially many SNMP entities; purely local configuration would be operationally undeployable at scale.
The architecture supports concurrent operation of SNMPv1, SNMPv2c, SNMPv3, and future SNMP versions by allowing the Message Processing Subsystem and Security Subsystem to each host multiple models simultaneously. The Dispatcher determines the version of an incoming message and routes it to the appropriate Message Processing Model.
The high bit of the first SnmpEngineID octet distinguishes legacy AgentIDs (as defined in RFC 1910, bit=0, 12-octet fixed format) from new-architecture engine IDs (bit=1, variable-length format). This allows SNMPv3 entities to coexist with pre-SNMPv3 implementations without collisions in the engineID space.
All subsystems (Message Processing, Security, Access Control) and applications are required to either supply a securityLevel value or abide by the supplied securityLevel when processing a message and its contents.
Each contextName MUST be unique within an SNMP entity.
Security Models in the Security Subsystem SHOULD protect against the four principal threats (modification of information, masquerade, message stream modification, and disclosure) and need not protect against denial of service or traffic analysis.
The value of an SnmpEngineID may not be all zeros, all 'ff'H, or the empty (zero-length) string.
A scopedPDU is a composite data block containing a contextEngineID, a contextName, and an SNMP PDU. Together, contextEngineID and contextName unambiguously identify the management context within an administrative domain.
A securityName is a human-readable, model-independent string representing a principal. The transformation between model-dependent security IDs (community names, user names, etc.) and securityNames is the responsibility of the relevant Security Model.
An SNMP context is a collection of management information accessible by an SNMP entity. To identify a specific managed object instance within a management domain, four pieces of information are required: contextEngineID, contextName, object type, and instance. The same item of management information may exist in multiple contexts.
An SNMP entity consists of an SNMP engine (comprising a Dispatcher, Message Processing Subsystem, Security Subsystem, and Access Control Subsystem) plus one or more associated applications. There is a one-to-one association between an SNMP engine and the SNMP entity containing it.
Five application types are defined: command generators (monitor and manipulate management data), command responders (provide access to management data), notification originators (initiate asynchronous messages), notification receivers (process asynchronous messages), and proxy forwarders (forward messages between SNMP entities).
The Access Control Subsystem exposes a single isAccessAllowed primitive that accepts securityModel, securityName, securityLevel, viewType (read/write/notify), contextName, and variableName (OID) and returns a statusInformation indicating whether access is permitted.
The architecture defines three ordered security levels: noAuthNoPriv (no authentication, no privacy), authNoPriv (authentication without privacy), and authPriv (authentication with privacy), where noAuthNoPriv < authNoPriv < authPriv. Every message carries an associated securityLevel.
The Dispatcher provides four PDU-level primitives: sendPdu (application sends outgoing request/notification), processPdu (incoming PDU delivered to application), returnResponsePdu (application returns response to dispatcher), and processResponsePdu (incoming response delivered to application). Applications may also call registerContextEngineID/unregisterContextEngineID to claim or release responsibility for specific contextEngineID and pduType combinations.
The Local Configuration Datastore (LCD) is the collection of configuration information retained by subsystems, models, and applications within an SNMP entity. Portions of this information may be accessible as managed objects, supporting remote configuration.
The maxSizeResponseScopedPDU conveys the maximum size of a scopedPDU that may be included in a response message; it excludes the SNMP message header. This value is propagated through Dispatcher and Message Processing primitives to communicate the sender's buffer constraints to the responder.
The Message Processing Subsystem exposes three primitives: prepareOutgoingMessage, prepareResponseMessage, and prepareDataElements. prepareDataElements extracts the messageProcessingModel, securityModel, securityName, securityLevel, contextEngineID, contextName, PDU, pduType, maxSizeResponseScopedPDU, and stateReference from a received raw message.
The Message Processing Subsystem may contain multiple concurrent Message Processing Models (e.g., SNMPv1, SNMPv2c, SNMPv3, or others). Each model defines the format of a specific SNMP message version and coordinates preparation and extraction of that version's messages.
The Security Subsystem exposes three primitives: generateRequestMsg (produces a secured outgoing request or notification, outputting securityParameters and wholeMsg), processIncomingMsg (validates an incoming message and outputs securityEngineID, securityName, scopedPDU, and a securityStateReference for later response), and generateResponseMsg (produces a secured response using the cached securityStateReference).
The Security Subsystem may contain multiple concurrent Security Models. Each Security Model defines the threats it protects against, its goals, and the protocols used. The User-Based Security Model is shown as one example; other models may coexist.
The snmpEngineID is the unique and unambiguous identifier of an SNMP engine within an administrative domain. Because SNMP engines and SNMP entities have a one-to-one relationship, it also uniquely identifies the SNMP entity.
The SNMP-FRAMEWORK-MIB module is assigned OID { snmpModules 10 }, correcting a clerical error in the obsoleted RFC 2261. The MIB defines the SnmpEngineID textual convention and associated managed objects for instrumenting SNMP entities within the architecture.
Denial-of-service and traffic analysis attacks are explicitly out of scope for Security Models in this architecture. DoS attacks are often indistinguishable from normal network failures that a viable management protocol must tolerate; traffic patterns are predictable, so protection against traffic analysis provides little practical advantage.
The four principal threats against which Security Models SHOULD provide protection are: modification of information (unauthorized alteration of in-transit messages), masquerade (assuming another principal's identity to perform unauthorized operations), message stream modification (malicious reordering, delay, or replay beyond normal subnetwork behavior), and disclosure (eavesdropping on exchanges between SNMP engines).
SnmpEngineID encoding: the high bit of the first octet distinguishes legacy format (0, fixed 12-octet: 4-octet IANA enterprise number + 8 enterprise-specific octets) from the new-architecture format (1, variable-length: 4-octet enterprise number with high bit set, 5th octet format indicator — 1=IPv4/4B, 2=IPv6/16B, 3=MAC/6B, 4=text/27B max, 5=octets/27B max, 128–255=enterprise-defined). Values 6–127 for the format indicator are reserved.