An Architecture for Describing SNMP Management Frameworks
obsoleted by
- rfc-2271 — An Architecture for Describing SNMP Management Frameworks
Extracted elements (27)
Remote configuration of security and access control parameters is a design requirement because the Security and Access Control Subsystems introduce a large set of configuration parameters, including secrets that must be changed frequently. Without remote configuration capability, deployment in large operational environments would be impractical.
The architecture mandates self-contained documents: elements of procedure and MIB objects needed for a specific portion of the SNMP framework should be defined in the same document and not referenced across documents. This modularity allows Security Models, authentication/privacy mechanisms, and message formats to be upgraded independently and to progress on the standards track at different paces.
The architecture separates 'security' (message-level: authentication, encryption, timeliness) from 'access control' (operation-level: controlling access to managed objects). This separation allows each concern to be addressed by independent, pluggable models that can evolve separately.
The high bit of the snmpEngineID first octet distinguishes pre-SNMPv3 engineID formats (bit=0, uses former enterprise methods, 12-octet fixed length) from the new SNMPv3 architecture format (bit=1, variable-length with structured format indicator in the fifth octet). This allows existing uses of engineID (also known as AgentID per RFC 1910) to co-exist with SNMPv3.
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 the message and its contents.
Each contextName MUST be unique within an SNMP entity.
Security Models within this architecture SHOULD provide protection against the four principal threats: modification of information, masquerade, message stream modification, and disclosure.
A scopedPDU is a data block containing a contextEngineID, a contextName, and a PDU. It groups the PDU with the context information necessary to unambiguously identify the management information within an administrative domain.
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 particular Security Model. A model-dependent security ID is the model-specific representation of a securityName within a particular Security Model (e.g., community names, user names).
An SNMP context is a collection of management information accessible by an SNMP entity. A context is identified by the combination of a contextEngineID and a contextName, which together unambiguously identify a context within an administrative domain. A contextEngineID uniquely identifies the SNMP entity that may realize an instance of a context with a particular contextName.
An SNMP engine consists of four components: 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 containing it. The engine provides services for sending/receiving messages, authenticating/encrypting messages, and controlling access to managed objects.
Applications register responsibility for specific contextEngineID and pduType combinations with the PDU Dispatcher using the registerContextEngineID primitive. This allows multiple applications to coexist and receive only the PDUs for which they have registered.
Applications within an SNMP entity are categorized as: 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).
The Access Control Subsystem provides authorization services via one or more Access Control Models. An Access Control Model defines a particular access decision function to support decisions about access rights for managed objects.
The Access Control Subsystem provides the isAccessAllowed primitive, which accepts securityModel, securityName, securityLevel, viewType (read/write/notify), contextName, and variableName (OID) to determine whether access should be granted, returning statusInformation indicating success or errorIndication.
The Dispatcher is a single component within an SNMP engine that enables concurrent support of multiple SNMP message versions. It sends and receives SNMP messages from the network, determines the SNMP version of each message, interacts with the corresponding Message Processing Model, and provides abstract interfaces for SNMP applications to send and receive PDUs.
The Dispatcher's sendPdu primitive is used by applications to send an SNMP Request or Notification. Parameters include transportDomain, transportAddress, messageProcessingModel, securityModel, securityName, securityLevel, contextEngineID, contextName, pduVersion, PDU, and expectResponse. It returns a sendPduHandle on success or errorIndication on failure.
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, enabling remote configuration.
The Message Processing Subsystem is responsible for preparing outgoing messages and extracting data from received messages. It may contain multiple Message Processing Models simultaneously (e.g., SNMPv1, SNMPv2c, SNMPv3, and others), enabling an SNMP engine to send and receive multiple versions of SNMP messages.
The Security Subsystem provides authentication and privacy services and may contain multiple Security Models concurrently. A Security Model defines the threats it protects against, the goals of its services, and the security protocols used. A Security Protocol defines the mechanisms, procedures, and MIB data used to provide a specific security service.
The Security Subsystem's generateRequestMsg primitive takes messageProcessingModel, globalData, maxMessageSize, securityModel, securityEngineID, securityName, securityLevel, and scopedPDU as inputs and outputs securityParameters, wholeMsg, and wholeMsgLength. A corresponding processIncomingMsg primitive validates incoming messages and extracts the scopedPDU payload.
The securityLevel construct defines three ordered levels of security: noAuthNoPriv (no authentication, no privacy), authNoPriv (authentication but no privacy), and authPriv (authentication and privacy). Every message has an associated securityLevel that all subsystems and applications must honor.
The snmpEngineID is the unique and unambiguous identifier of an SNMP engine within an administrative domain. Because there is a one-to-one association between SNMP engines and SNMP entities, it also uniquely identifies the SNMP entity.
This document defines the SNMP-FRAMEWORK-MIB (OID snmpModules 2), which includes the SnmpEngineID and SnmpSecurityModel textual conventions, and managed objects for instrumenting SNMP engines within the architecture. The MIB provides objects including snmpEngineID, snmpEngineBoots, snmpEngineTime, and snmpEngineMaxMessageSize.
Security Models within this architecture need not protect against Denial of Service or Traffic Analysis. DoS attacks are often indistinguishable from network failures that any viable management protocol must handle. Traffic patterns in SNMP management are typically predictable, offering no significant advantage to protecting against traffic analysis.
The four principal threats against which Security Models SHOULD protect are: (1) Modification of Information — unauthorized alteration of in-transit SNMP messages; (2) Masquerade — assuming the identity of an authorized principal; (3) Message Stream Modification — malicious re-ordering, delay, or replay of messages beyond natural network effects; (4) Disclosure — eavesdropping on exchanges between SNMP engines.
SnmpEngineID is an OCTET STRING of SIZE(1..32). The standard format sets the high bit of the first octet to 1, uses the next 3 octets for the IANA-assigned enterprise number, and uses the fifth octet as a format indicator (1=IPv4, 2=IPv6, 3=MAC, 4=text, 5=octets, 127-255=enterprise-defined). The value MUST NOT be all zeros, all 0xFF, or zero-length.