SNMP Applications
obsoleted by
- rfc-3413 — Simple Network Management Protocol (SNMP) Applications
obsoletes
- rfc-2273 — SNMPv3 Applications
Extracted elements (30)
A proxy forwarder application is explicitly distinguished from a command responder application: a proxy forwards based on context (contextEngineID/contextName) alone without needing a detailed MIB view definition, whereas a command responder processes requests based on individual managed object types and instances and requires the full MIB view.
The term 'proxy' is defined narrowly in this document to mean only a proxy forwarder application that forwards SNMP messages irrespective of what managed objects are contained within them. This avoids the historical confusion of the term covering version translation, non-SNMP protocol bridging, and managed object aggregation under a single label.
The Management Target MIB is designed as a general-purpose mechanism reusable beyond notification and proxy forwarding. Other documents that use this MIB are responsible for specifying how it is used; for example, [COEX] uses it for source address validation of SNMPv1 messages.
When a proxy forwarder translates between SNMP versions that support different PDU versions, it may need to perform PDU translation; a method for performing such translation is described in [COEX]. For Internal-Class PDUs (e.g., Report PDUs), if the original incoming SNMP version does not support Report PDUs, forwarding of the Internal-Class PDU is halted.
A command responder application MUST always call the returnResponsePdu abstract service interface, even in the event of an error such as a resource allocation error; the PDU passed should contain appropriate errorStatus and errorIndex values.
A proxy forwarder application MUST use the SNMP-PROXY-MIB module defined in this document if it makes the contents of its management target translation table SNMP manageable.
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.
If a notification originator makes the configuration of management targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module defined in this document.
When a command generator receives a response, it MUST discard the response if the received values of messageProcessingModel, securityModel, securityName, contextEngineID, contextName, pduVersion, or request-id are not equal to those used in the original request.
A Management Target is the complete set of information describing where and how to send a message, consisting of 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 with a many-to-many relationship between them.
Command responders use the registerContextEngineID abstract service interface to associate with an SNMP engine before processing messages; the contextEngineID must equal the local snmpEngineID. Only one command responder may be registered per contextEngineID/pduType pair — further registration attempts are denied.
Five SNMP application types 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). Multiple application types may coexist within a single SNMP engine.
Notification filtering uses snmpNotifyFilterProfileTable to associate a filter profile name with a snmpTargetParamsEntry, and snmpNotifyFilterTable to define subtree-based inclusion/exclusion rules. A notification is sent to a target only if the notification's OID and variable-binding OIDs are permitted by the filter profile associated with that target's parameter entry.
Notification originator target selection uses the snmpNotifyTable: entries whose snmpNotifyTag matches a tag in the management target's snmpTargetAddrTagList are selected as recipients, and snmpNotifyType determines whether to send an unconfirmed trap (SNMPv2-Trap) or a confirmed inform (Inform PDU) to each selected target.
Notification receivers register with the Dispatcher using registerContextEngineID with a wildcard contextEngineID, so notifications are delivered regardless of the contextEngineID in the message. For Confirmed-Class PDUs received, the receiver must construct a Response-Class PDU (preserving request-id and variable-bindings, setting error-status and error-index to 0) and call returnResponsePdu.
SnmpTagValue and SnmpTagList are textual conventions (OCTET STRING, SIZE 0..255, UTF-8 encoded per ISO/IEC IS 10646-1) for grouping management target entries. Delimiter characters (space 0x20, TAB 0x09, CR 0x0D, LF 0x0B) separate tag values in a list; no leading/trailing delimiters and no adjacent delimiters are allowed; individual tag values must have non-zero length.
snmpTargetSpinLock (TestAndIncr) provides a serialization mechanism for concurrent modification of snmpTargetAddrTagList by multiple managers: retrieve spinlock and tag list, generate new tag list, then set both atomically — if the spinlock set fails, restart from step 1.
The sendPdu abstract service interface is used by command generators and notification originators to dispatch PDUs. Parameters include transportDomain, transportAddress, messageProcessingModel, securityModel, securityName, securityLevel, contextEngineID, contextName, pduVersion, PDU, and expectResponse. On success it returns a sendPduHandle used to correlate subsequent responses.
The SNMP-NOTIFY-MIB defines the snmpNotifyTable (with snmpNotifyTag for target selection, snmpNotifyType for trap vs. inform), the snmpNotifyFilterProfileTable (mapping target parameter entries to filter profiles), and the snmpNotifyFilterTable (specifying subtree inclusion/exclusion filters for notification content).
The SNMP-PROXY-MIB defines the snmpProxyTable, which maps incoming management target parameters (contextEngineID, contextName, target address, SNMP version) to outgoing management target parameters for forwarding. The table uses snmpProxyType to distinguish request forwarding from notification forwarding entries.
The snmpTargetAddrTable stores transport endpoint information for management targets: snmpTargetAddrTDomain (transport type), snmpTargetAddrTAddress (transport address), snmpTargetAddrTimeout (expected round-trip time, default 1500 centiseconds), snmpTargetAddrRetryCount (default 3), snmpTargetAddrTagList (tag values for grouping), and snmpTargetAddrParams (pointer to snmpTargetParamsTable entry).
The snmpTargetParamsTable stores SNMP message parameters for management targets: snmpTargetParamsMPModel (message processing model), snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel. Security-sensitive fields (MPModel, SecurityModel, SecurityName, SecurityLevel) may not be modified while the row is active.
Two error counters track context problems: snmpUnknownContexts (Counter32) counts packets dropped because the context was unknown to the SNMP entity; snmpUnavailableContexts (Counter32) counts packets dropped because the context was known but currently unavailable. Determining context unavailability is implementation-specific.
This document defines three MIB modules registered under snmpModules: SNMP-TARGET-MIB (snmpModules 12), SNMP-NOTIFY-MIB (snmpModules 13), and SNMP-PROXY-MIB (snmpModules 14). These modules provide standardized objects for management target configuration, notification configuration/filtering, and proxy forwarding configuration respectively.
Access control is applied by notification originators before sending notifications: the isAccessAllowed abstract service interface is called to verify that both the variable-bindings and the NOTIFICATION-TYPE OID are within the authorized MIB view for each management target. If access is denied, the notification is not sent to that target. In proxy notification forwarding, no access control is applied to the forwarded variable-bindings.
The security of operations depends on the security parameters configured in the SNMP-TARGET-MIB and SNMP-NOTIFY-MIB. Misconfiguration of these MIBs (e.g., using noAuthNoPriv security level for notifications) could result in disclosure of sensitive management information. Access to MIB objects controlling target and notification configuration should itself be protected by appropriate access control.
Command responder processing: (1) extract operation type; (2) extract request-id; (3) extract PDU-type-specific parameters; (4) extract variable-bindings; (5) call isAccessAllowed for each object instance — on noSuchView/noAccessEntry/noGroupName return authorizationError, on otherError return genError, on noSuchContext increment snmpUnknownContexts, on unavailable context increment snmpUnavailableContexts; (6) call returnResponsePdu.
Notification originator procedure per management target: (1) apply filtering; (2) retrieve variable-bindings using isAccessAllowed; (3) check NOTIFICATION-TYPE OID via isAccessAllowed; (4) construct PDU; (5) for Unconfirmed-Class call sendPdu with expectResponse=FALSE; (6) for Confirmed-Class call sendPdu with expectResponse=TRUE, cache target info, retry up to retry count on timeout or report indication.
Proxy request forwarding: (1) receive via processPdu and translate management target; (2) if no outgoing target found, increment snmpProxyDrops and return error via returnResponsePdu; (3) construct new PDU with unique request-id; (4) call sendPdu; (5) cache sendPduHandle, original request-id, contextEngineID, contextName, stateReference, and management target info; (6) wait for response or timeout.
Proxy response forwarding: (1) receive via processResponsePdu and locate cache entry by matching sendPduHandle, contextEngineID, contextName, outgoing target, and request-id from received PDU; (2) extract and remove cache entry; (3) construct new Response PDU with original request-id from cache; (4) call returnResponsePdu with original incoming management target parameters.