SNMPv3 Applications
obsoleted by
- rfc-2273 — SNMPv3 Applications
Extracted elements (28)
A proxy forwarder forwarding Inform requests acts as a true intermediary: it does not generate a response to the original Inform immediately upon receipt, but waits until a response is received from the downstream target before forwarding the acknowledgment back. This preserves end-to-end Inform reliability semantics.
Proxy notification forwarding explicitly bypasses access control on variable-bindings: the variable-bindings from the original received notification are forwarded as-is, rather than being retrieved from local MIB instrumentation. This is intentional because the proxy forwarder is an intermediary without knowledge of the managed object definitions.
The document deliberately narrows the definition of 'proxy' to mean only a proxy forwarder that forwards messages irrespective of managed object types, distinguishing it from MIB aggregation proxies or non-SNMP protocol translators. This avoids confusion caused by the historically loose use of the term 'proxy' in SNMP, which encompassed at least three distinct scenarios.
A notification receiver registers with the Dispatcher using an undefined 'wildcard' value for contextEngineID, so it receives notifications regardless of the contextEngineID in the notification message. For Inform PDUs, the receiver must send a Response PDU with error-status and error-index both set to 0.
When a proxy forwarder forwards a request from SNMPv2/SNMPv3 to an SNMPv1 target, it must apply the translation rules documented in RFC 1908. Conversely, when forwarding a response from SNMPv1 to an SNMPv2/SNMPv3 originator, the same RFC 1908 translation rules apply.
When forwarding notifications, if the incoming SNMP version is SNMPv2 or SNMPv3 and the outgoing version is SNMPv1, that outgoing management target is silently skipped (not used) for the forwarded notification. This prevents lossy downgrade of SNMPv2-Trap PDU types that have no SNMPv1 equivalent.
A command responder application should always call the returnResponsePdu abstract service interface, even in the event of an error such as a resource allocation error. In the event of such an error, the PDU value passed to returnResponsePdu must contain appropriate values for errorStatus and errorIndex.
A proxy forwarder application should never attempt to register a contextEngineID value equal to the snmpEngineID of the SNMP engine to which the proxy forwarder is associated, to prevent routing loops.
If a notification originator application makes the configuration of management targets SNMP-manageable, it MUST use the SNMP-TARGET-MIB module defined 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.
When a newly created row in snmpTargetAddrTable or snmpTargetParamsTable cannot be made active, its RowStatus remains 'notReady'. The columns snmpTargetAddrTDomain, snmpTargetAddrTAddress (for the addr table) and snmpTargetParamsMPModel, snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, snmpTargetParamsSecurityLevel (for the params table) may not be modified while RowStatus is active(1).
A 'Management Target' specifies where and how to send an SNMP message. It consists of two components: destination information (transport domain and transport address, i.e., a transport endpoint) and SNMP parameters (message processing model, security model, security level, and security name). The SNMP-TARGET-MIB provides two tables for these two kinds of information.
RFC 2263 defines five SNMPv3 application types: Command Generators (initiate Get/Set requests), Command Responders (process incoming requests), Notification Originators (generate Trap/Inform messages), Notification Receivers (receive notifications), and Proxy Forwarders (forward requests and notifications between SNMP engines). Multiple application types may coexist in a single SNMP engine.
The SNMP-NOTIFICATION-MIB defines three tables: snmpNotifyTable (selects target addresses for notification generation and specifies trap vs. inform type), snmpNotifyFilterProfileTable (sparsely augments snmpTargetAddrTable to associate filter profiles with management targets), and snmpNotifyFilterTable (defines subtree-based filters controlling which notifications are sent to particular targets).
The SNMP-PROXY-MIB defines a snmpProxyTable whose entries map incoming contextEngineID/contextName pairs to outgoing management target information. Each entry specifies the incoming SNMPv2 PDU type, incoming context, outgoing target parameters name, and optionally a single or multiple target address tags for request or notification forwarding respectively.
The SnmpTagValue and SnmpTagList textual conventions (OCTET STRING, SIZE 0–255, UTF-8 encoded) provide a mechanism for grouping management target addresses. A tag value may not contain delimiter characters (space 0x20, TAB 0x09, CR 0x0D, LF 0x0B) and may not have zero length. A tag list separates tag values with exactly one delimiter character and may not have leading, trailing, or adjacent delimiters.
The snmpTargetAddrTable stores transport addresses used for generating SNMP messages. Each entry (SnmpTargetAddrEntry) contains snmpTargetAddrName (index, 1–32 octets), snmpTargetAddrTDomain, snmpTargetAddrTAddress, snmpTargetAddrTimeout (default 1500), snmpTargetAddrRetryCount (default 3, range 0–255), snmpTargetAddrTagList, snmpTargetAddrParams (pointer to snmpTargetParamsTable), snmpTargetAddrStorageType, and snmpTargetAddrRowStatus.
The snmpTargetParamsTable stores SNMP security and message-processing parameters for use when sending messages to a management target. Each SnmpTargetParamsEntry contains snmpTargetParamsMPModel, snmpTargetParamsSecurityModel (constrained to 0–254 or 256–2147483647, excluding 255), snmpTargetParamsSecurityName, snmpTargetParamsSecurityLevel, snmpTargetParamsStorageType, and snmpTargetParamsRowStatus.
The snmpTargetSpinLock object (TestAndIncr syntax) serializes concurrent modification of snmpTargetAddrTagList by multiple managers. The procedure is: (1) read snmpTargetSpinLock and snmpTargetAddrTagList, (2) compute new tag list, (3) set snmpTargetSpinLock to the retrieved value atomically with the new tag list; retry from step 1 if the set fails.
Two counters in SNMP-TARGET-MIB track context errors: snmpUnavailableContexts counts packets dropped because the context in the received message was unavailable, and snmpUnknownContexts counts packets dropped because the context was unknown. These are mandatory objects for command responder compliance.
SNMP-NOTIFICATION-MIB is defined at snmpModules 13. It provides the snmpNotifyTable, snmpNotifyFilterProfileTable, and snmpNotifyFilterTable for remotely configuring notification generation parameters and notification filtering in SNMP entities.
SNMP-PROXY-MIB is defined at snmpModules 14. It provides the snmpProxyTable for remotely configuring the management target translation table used by proxy forwarder applications to route incoming requests and notifications to appropriate outgoing SNMP targets.
SNMP-TARGET-MIB is defined at snmpModules 7. It provides the snmpTargetAddrTable and snmpTargetParamsTable for remotely configuring SNMP management targets, along with SnmpTagValue and SnmpTagList textual conventions and the snmpTargetSpinLock coordination object.
Command responder applications enforce access control using the isAccessAllowed abstract service interface for every variable in an SNMP request. Access is determined by securityModel, securityName, securityLevel, viewType (read or write), contextName, and the specific variableName OID. Failures map to authorizationError or genError in the response.
Notification originators apply access control (isAccessAllowed) to each variable-binding before including it in an outgoing notification. If isAccessAllowed does not return accessAllowed for a variable, the notification is not sent to that management target. Proxy forwarders, by contrast, do not apply access control to forwarded notification variable-bindings.
Command responder request processing: (1) extract operation type; (2) extract request-id; (3) for GetBulk, extract non-repeaters/max-repetitions; (4) extract variable-bindings; (5) perform management operation using isAccessAllowed for each variable, halting on noSuchView/noAccessEntry/noGroupName (authorizationError), otherError (genError), noSuchContext (increment snmpUnknownContexts), or unavailable context (increment snmpUnavailableContexts); (6) call returnResponsePdu.
Notification originator Inform retry loop: (a) send Inform via sendPdu with expectResponse=TRUE, (b) cache management target info, (c) if response received within timeout from target endpoint, consider acknowledged and delete cache, (d) else if timeout or report received, retrieve cache and repeat steps (a)–(d) up to the configured retry count; if retry count exceeded, consider acknowledgement failed.
Proxy forwarder request forwarding cache: upon forwarding a request, the proxy caches sendPduHandle, original request-id, contextEngineID, contextName, stateReference, incoming and outgoing management target info. A response is matched to the cache using sendPduHandle, contextEngineID, contextName, outgoing management target info, and the request-id in the received PDU. If no cache entry is found, the response is discarded. Entries are removed on match or timeout.