Simple Network Management Protocol (SNMP) Applications
Extracted elements (29)
Although the architecture permits separate command responder applications to register for different PDU types on the same engine, only a single command responder should be registered at any given time because multiple registrations for the same contextEngineID and pduType are explicitly denied.
The document defines 'proxy' narrowly as a forwarder that forwards SNMP messages based solely on context information, irrespective of individual managed object types. This avoids historical confusion where 'proxy' covered at least three distinct scenarios: cross-domain/version forwarding, non-SNMP protocol translation, and managed-object aggregation.
The Management Target MIB uses two separate tables (snmpTargetAddrTable for transport endpoints, snmpTargetParamsTable for SNMP parameters) with a many-to-many relationship, allowing multiple transport endpoints to share one set of security parameters or one endpoint to be used with multiple security parameter sets.
When a proxy forwarder forwards between SNMP versions that support different PDU versions, the PDU may need to be translated. RFC 2576 describes a method for performing such translation between SNMPv1 and SNMPv2 PDU types.
When an Internal-Class PDU (e.g., Report PDU) is received by a proxy forwarder in response to a previously forwarded request, if the original incoming management target indicated an SNMP version that does not support Report PDUs, processing of the Internal-Class PDU is halted and it is not forwarded back.
When forwarding a Confirmed-Class notification, any outgoing management target for which the outgoing SNMP version does not support PDU types that are both Notification-Class and Confirmed-Class must not be used for the forwarded notification.
A command generator receiving a response must discard it if messageProcessingModel, securityModel, securityName, contextEngineID, contextName, or pduVersion do not all equal the values used in the original request, or if the request-id does not match.
A command responder application should always call the returnResponsePdu abstract service interface, even in the event of an error such as resource allocation failure. The PDU passed must contain appropriate errorStatus and errorIndex values.
A notification receiver must register with the Dispatcher using a wildcard (undefined) contextEngineID so that notifications are delivered regardless of the contextEngineID in the received message.
A proxy forwarder application should never attempt to register a contextEngineID value equal to the snmpEngineID of its associated SNMP engine, to prevent routing loops.
A row in snmpTargetAddrTable cannot be made active until snmpTargetAddrTDomain, snmpTargetAddrTAddress, and snmpTargetAddrParams are all configured. While active(1), snmpTargetAddrTDomain and snmpTargetAddrTAddress may not be modified (attempt returns inconsistentValue).
A row in snmpTargetParamsTable cannot be made active until snmpTargetParamsMPModel, snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel are all set. While active(1), all four objects may not be modified.
If a notification originator application makes the configuration of management targets SNMP-manageable, it MUST use the SNMP-TARGET-MIB module described in this document.
If a proxy forwarder application makes the contents of its management target translation table SNMP-manageable, it MUST use the SNMP-PROXY-MIB module defined in this document.
A 'Management Target' is the complete set of information describing where and how to send an SNMP message. It consists of destination information (transport domain and transport address) and SNMP parameters (message processing model, security model, security level, security name).
Five types of SNMP applications are defined: Command Generators (initiate Read/Write-Class requests), Command Responders (respond to Read/Write-Class requests), Notification Originators (generate Notification-Class PDUs), Notification Receivers (receive Notification-Class PDUs), and Proxy Forwarders (forward SNMP messages irrespective of managed object types).
SnmpTagValue and SnmpTagList are TEXTUAL-CONVENTIONs (OCTET STRING, SIZE 0..255) encoded in UTF-8 (ISO/IEC IS 10646-1). A tag value must not contain delimiter characters (space 0x20, TAB 0x09, CR 0x0D, LF 0x0A). Within a tag list, values are separated by a single delimiter; leading/trailing delimiters and adjacent delimiters are prohibited.
snmpTargetSpinLock (SYNTAX TestAndIncr) is used to facilitate concurrent modification of snmpTargetAddrTagList by multiple managers. The safe procedure is: (1) retrieve lock and current tag list, (2) compute new value, (3) set both atomically; if the lock set fails, restart from step 1.
The snmpTargetAddrTable stores transport endpoint information for management targets. Its columnar objects are: snmpTargetAddrName (index, 1..32 octets), snmpTargetAddrTDomain, snmpTargetAddrTAddress, snmpTargetAddrTimeout (default 1500), snmpTargetAddrRetryCount (0..255, default 3), snmpTargetAddrTagList, snmpTargetAddrParams, snmpTargetAddrStorageType, and snmpTargetAddrRowStatus.
The snmpTargetParamsTable stores SNMP security parameters for message generation. Its columnar objects are: snmpTargetParamsName (index, 1..32 octets), snmpTargetParamsMPModel, snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, snmpTargetParamsSecurityLevel, snmpTargetParamsStorageType, and snmpTargetParamsRowStatus.
Two counters track context errors: snmpUnavailableContexts (incremented when the named context is known but currently unavailable) and snmpUnknownContexts (incremented when the named context is completely unknown). Both trigger generation of a report message rather than a normal response.
SNMP-NOTIFICATION-MIB (Section 4.2) defines MIB objects for notification filtering in notification originator applications. SNMP-PROXY-MIB (Section 4.3) defines objects for configuring the management target translation table used by proxy forwarder applications.
SNMP-TARGET-MIB is registered at snmpModules 12, providing the snmpTargetAddrTable and snmpTargetParamsTable for remotely configuring SNMP message generation parameters. It also defines the SnmpTagValue and SnmpTagList textual conventions and the snmpTargetSpinLock object.
Command responder applications must apply access control via the isAccessAllowed abstract service interface for each variable binding, using securityModel, securityName, securityLevel, viewType (read or write), and contextName. Access violations return authorizationError for noSuchView/noAccessEntry/noGroupName, genError for otherError, and a report for noSuchContext or unavailable context.
Notification originators must apply access control (via isAccessAllowed with viewType=notify) to both the full set of variable-bindings and to the snmpTrapOID.0 value before sending to each management target. If access is denied for either check, the notification is not sent to that target.
Proxy forwarders do not apply access control when forwarding notifications; variable-bindings and snmpTrapOID.0 are passed through without checking. The security context (securityModel, securityLevel, securityName) from the outgoing management target governs the forwarded message.
Notification Originator confirmed-PDU retry machine: (a) send PDU with expectResponse=TRUE and cache target info; (b) if response received within timeout, notification acknowledged and cache deleted; (c) if no response or a failing report indication arrives, retry steps (a)-(c) up to the configured retry count; (d) if retry count exceeded, acknowledgement fails.
Proxy forwarder notification forwarding for Confirmed-Class PDUs: forward to all outgoing targets; if at least one target acknowledges, construct Response-Class PDU using original request-id and variable-bindings (error-status=0, error-index=0) and call returnResponsePdu; if none acknowledges within the longest timeout, halt processing of the original notification.
Proxy forwarder request forwarding: receive via processPdu → translate management target; if no target found, increment snmpProxyDrops and return error response; construct new PDU with unique request-id; call sendPdu; cache (sendPduHandle, request-id, contextEngineID, contextName, stateReference, management target info); await response or timeout (on timeout, remove cached entry).