An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
obsoletes
- rfc-2571 — An Architecture for Describing SNMP Management Frameworks
updated by
- rfc-5343 — Simple Network Management Protocol (SNMP) Context EngineID Discovery
- rfc-5590 — Transport Subsystem for the Simple Network Management Protocol (SNMP)
also
- std-62
Extracted elements (30)
Remote configuration of Security and Access Control parameters is a design requirement because the new subsystems introduce a large set of configuration parameters and require frequent key rotation. Large operational deployments make out-of-band configuration impractical.
The architecture explicitly addresses 'controlled complexity': simple managed devices must be able to implement a minimal conforming SNMP entity cheaply, while complex environments can spend more resources for additional functionality. The design keeps these competing requirements in balance.
The architecture is modular: each subsystem (Message Processing, Security, Access Control) is specified in self-contained documents that can evolve and advance the standards track independently. This allows Security Models, authentication/privacy mechanisms, and message formats to be upgraded without directly impacting other portions of the framework.
The architecture accommodates simultaneous support for SNMPv1, SNMPv2c, and SNMPv3 within a single SNMP engine via multiple Message Processing Models in the Dispatcher. Coexistence between these versions and transition guidance are addressed in separate coexistence documents such as RFC 2576.
All subsystems (Message Processing, Security, Access Control) and applications are REQUIRED to either supply a value of securityLevel or to abide by the supplied value of securityLevel while processing a message and its contents.
Each contextName MUST be unique within an SNMP entity.
Security Models used within this architecture SHOULD provide protection against the principal threats of modification of information and masquerade, and against the secondary threats of message stream modification and disclosure.
A contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName within an administrative domain. The combination of contextEngineID and contextName unambiguously identifies a context within an administrative domain.
A scopedPDU is a data block containing a contextEngineID, a contextName, and a PDU. It forms the payload of a secured SNMP message, binding the protocol operation to a specific management context.
A securityName is a human-readable string representing a principal (the 'who' on whose behalf services are provided). It has a model-independent format and can be used outside a specific Security Model. Model-dependent security IDs (e.g., community names, usernames) are transformed to/from securityNames by the relevant Security Model.
An SNMP context is a collection of management information accessible by an SNMP entity. A context is always a subset of a single SNMP entity. To identify a specific item of management information, its contextName, contextEngineID, object type, and instance must all be specified.
An SNMP engine is the core of an SNMP entity, consisting of a Dispatcher, a Message Processing Subsystem, a Security Subsystem, and an Access Control Subsystem. There is a one-to-one association between an SNMP engine and the SNMP entity that contains it. The engine is uniquely identified within an administrative domain by its snmpEngineID.
Five application types are defined: command generators (monitor/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 entities).
Seven PDU classes are defined: Read (GetRequest, GetNextRequest, GetBulkRequest), Write (SetRequest), Response (Response-PDU), Notification (Trapv2, InformRequest), Internal (Report-PDU), Confirmed (operations expecting a response), and Unconfirmed (operations not acknowledged).
The Access Control Subsystem provides a single primitive, isAccessAllowed, which takes securityModel, securityName, securityLevel, viewType (read/write/notify), contextName, and variableName (OID) as inputs and returns success or an error indication.
The Access Control Subsystem provides authorization services through one or more Access Control Models (e.g., View-Based Access Control Model). An Access Control Model defines the access decision function for determining whether access to a managed object is permitted.
The Dispatcher is a single component within an SNMP engine that sends and receives SNMP messages, determines the SNMP version of incoming messages, dispatches to the appropriate Message Processing Model, and provides an abstract interface for applications to send and receive PDUs.
The Dispatcher provides abstract service primitives: sendPdu (application sends a request/notification), processPdu (dispatcher delivers incoming PDU to application), returnResponsePdu (application returns response), processResponsePdu (dispatcher delivers response to originating application), registerContextEngineID, and unregisterContextEngineID.
The Message Processing Subsystem prepares messages for sending and extracts data from received messages. It may contain multiple Message Processing Models (e.g., SNMPv1, SNMPv2c, SNMPv3) concurrently, each defining a specific SNMP message format identified by a version field.
The Message Processing Subsystem provides three primitives: prepareOutgoingMessage (prepares outgoing request/notification), prepareResponseMessage (prepares outgoing response), and prepareDataElements (extracts abstract data elements from an incoming SNMP message).
The Security Subsystem provides authentication and privacy services and may support multiple Security Models concurrently (e.g., User-Based Security Model). Each Security Model specifies the threats it addresses, its goals, and the security protocols used.
The Security Subsystem provides three primitives: generateRequestMsg (generates a secured outgoing request/notification), processIncomingMsg (authenticates and decrypts an incoming message, returning the plaintext scopedPDU), and generateResponseMsg (generates a secured response using cached security state from the original request).
The securityLevel defines three ordered levels of security: noAuthNoPriv (no authentication, no privacy), authNoPriv (authentication, no privacy), and authPriv (authentication and privacy), where noAuthNoPriv < authNoPriv < authPriv.
The snmpEngineID is the unique and unambiguous identifier of an SNMP engine within an administrative domain. It also uniquely identifies the containing SNMP entity. Different administrative domains may have SNMP entities with the same snmpEngineID value; federation may require reassignment.
IANA maintains a registry of Message Processing Model numbers for use in SNMP. Values 0 (SNMPv1), 1 (SNMPv2c), 2 (SNMPv2u/SNMPv2*), and 3 (SNMPv3) are assigned. Values 0–255 are standards-track; 256–65535 are enterprise-specific.
IANA maintains a registry of Security Model numbers for use in SNMP. The values 0 (reserved), 1 (SNMPv1), 2 (SNMPv2c), and 3 (USM) are assigned. Values 1–255 are standards-track; 256–65535 are enterprise-specific.
IANA maintains a registry of SnmpEngineID format values (the first octet of an snmpEngineID when the high bit is set to 1) that indicate the format of the remaining octets. Formats include IPv4 address, IPv6 address, MAC address, text, octets, and enterprise-specific formats.
Denial of service and traffic analysis are explicitly excluded as threats requiring protection. DoS attacks are often indistinguishable from normal network failures that management protocols must tolerate; SNMP traffic patterns are predictable enough that traffic analysis yields little advantage to attackers.
Secondary threats include message stream modification (malicious reordering, delay, or replay of messages beyond natural network behavior) and disclosure (eavesdropping on SNMP engine exchanges). Protection against disclosure may be a matter of local policy.
The principal threats against which Security Models SHOULD protect are modification of information (unauthorized alteration of in-transit SNMP messages) and masquerade (performing operations by assuming the identity of an authorized principal). These require integrity and authentication services.