An Architecture for Describing SNMP Management Frameworks
obsoleted by
- rfc-3411 — An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
obsoletes
- rfc-2271 — An Architecture for Describing SNMP Management Frameworks
Extracted elements (29)
Abstract service interfaces are defined solely to clarify the externally observable behavior of SNMP entities and MUST NOT be interpreted as APIs or API requirements; they impose no constraints on implementation structure or organization.
Remote configuration of security and access control parameters was a deliberate design requirement because the Security Subsystem requires frequent secret changes and because large operational environments make manual reconfiguration impractical.
The architecture mandates self-contained documents: each document defines the elements of procedure and MIB objects for a specific portion of the SNMP framework, without requiring references to other documents. This modularity allows Security Models, message formats, and authentication mechanisms to be upgraded independently on separate standards-track timelines.
A single SNMP engine can concurrently support multiple Message Processing Models (SNMPv1, SNMPv2c, SNMPv3, and others) and multiple Security Models simultaneously, enabling a single entity to interoperate with peers using different SNMP versions.
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 protect against the principal threats of modification of information and masquerade, and the secondary threats of message stream modification and disclosure.
Security Models within this architecture need not protect against denial-of-service or traffic analysis attacks, as these are deemed of lesser importance in the SNMP management context.
A scopedPDU is a data block containing a contextEngineID, a contextName, and an SNMP PDU. It unambiguously identifies the management information context within an administrative domain.
A securityName is a human-readable, model-independent string representing a principal. Security Models are responsible for transforming their model-dependent security IDs (e.g., community strings, user names) to and from securityNames.
An SNMP context is a collection of management information accessible by an SNMP entity, identified by the combination of contextEngineID and contextName. An item of management information may exist in multiple contexts; to identify it uniquely, both contextEngineID and contextName must be specified in addition to object type and instance.
An SNMP entity consists of an SNMP engine (Dispatcher, Message Processing Subsystem, Security Subsystem, and Access Control Subsystem) plus one or more applications. There is a strict one-to-one association between an SNMP engine and its SNMP entity.
An snmpEngineID is the unique and unambiguous identifier of an SNMP engine within an administrative domain. Because of the one-to-one engine-to-entity binding, it also uniquely identifies the SNMP entity; federation of domains may require reassignment of values.
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).
PDUs are classified by function into seven classes: Read, Write, Response, Notification, and Internal (functional), plus Confirmed (expects a response) and Unconfirmed (not acknowledged). GetRequest, GetNextRequest, GetBulkRequest, SetRequest, and InformRequest are Confirmed; Trapv2 and Report are Unconfirmed.
securityLevel recognizes three ordered values: noAuthNoPriv (no authentication, no privacy), authNoPriv (authentication only), and authPriv (authentication and privacy), where noAuthNoPriv < authNoPriv < authPriv.
The Access Control Subsystem provides authorization services via one or more Access Control Models (e.g., View-Based Access Control Model). Each model defines an access decision function governing access rights to managed objects.
The Local Configuration Datastore (LCD) is the collection of configuration information retained by subsystems, models, and applications within an SNMP entity. Portions of the LCD may be accessible as managed objects.
The maxSizeResponseScopedPDU parameter conveys the maximum size of a scopedPDU that the PDU sender is willing to accept in a response; this size explicitly excludes the SNMP message header.
The Message Processing Subsystem may contain multiple concurrent Message Processing Models (e.g., SNMPv1, SNMPv2c, SNMPv3). Each model defines the format of a particular SNMP message version and coordinates preparation and extraction of that version's messages.
The Security Subsystem provides authentication and privacy services via one or more Security Models (e.g., User-Based Security Model). Each Security Model specifies the threats it protects against, its goals, and the security protocols used.
There is exactly one Dispatcher per SNMP engine. It sends and receives SNMP messages, determines message version and dispatches to the appropriate Message Processing Model, and provides abstract PDU delivery interfaces to applications.
IANA manages the registry of SNMP Message Processing Model values. SNMPv1 is 0; SNMPv2c is 1; SNMPv2u/SNMPv2* is 2; SNMPv3 is 3. The same enterprise/standards split applies as for Security Models.
IANA manages the registry of SNMP Security Model values. Reserved value is 0; SNMPv1 is 1; SNMPv2c is 2; User-Based Security Model (USM) is 3. Values in ranges 1–255 are standards-track; 256–65535 are enterprise-specific.
IANA manages the registry of SnmpEngineID format indicator values (the 5th octet of an SnmpEngineID), as defined in the SNMP-FRAMEWORK-MIB. Different format values specify different encoding conventions for the remaining octets.
Denial-of-service attacks need not be addressed by Security Models because such attacks are often indistinguishable from ordinary network failures that a viable management protocol must tolerate. Traffic analysis need not be addressed because SNMP traffic patterns are predictable and typically involve few management stations.
Secondary threats include message stream modification (malicious reordering, delay, or replay beyond natural network behavior) and disclosure (eavesdropping on SNMP engine exchanges). Protection against disclosure is a matter of local policy.
The principal security threats for SNMP management are modification of information (unauthorized alteration of in-transit messages) and masquerade (assuming an authorized principal's identity to perform unauthorized operations). Security Models SHOULD protect against both.
A scopedPDU encodes a contextEngineID, a contextName, and an SNMP PDU in sequence. The contextEngineID and contextName together unambiguously identify the management context within an administrative domain.