Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) 1 August 1997 J. Case SNMP Research Inc. case@snmp.com D. Harrington Cabletron Systems, Inc. dbh@cabletron.com B. Wijnen IBM T. J. Watson Research wijnen@vnet.ibm.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [SNMP-ARCH]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. Case/Harrington/Wijnen Expires February 1998 [Page 1] Draft Message Processing and Dispatching for SNMP August 1997 0. Issues 0.1. Resolved Issues . contextEngineID in reportPDU = snmpEngineID of report generator . returnResponsePDU - are all parameters needed? overrides allowed? all parameters kept for future flexibility overrides not supported by SNMPv3 . use of IN/OUT indicators in primitives accepted . NT/Unix-like access control - can be defined as future model . user-friendly names? yes, but with limits . SnmpAdminString as index? yes, but restrict sizes . need both MMS and maxSizeResponseScopedPDU? yes. . synchronous vs. asynchronous primitives? synchronous preferred . should we change MIB naming? no, it is acceptable . is it ok that USM is bound to SNMPv3? while undesirable, it is acceptable. A cleaner model may be defined in the future. . should securityModel "any" be supported? for ACM use, not SNMPv3 . what defines SNMPv3? a document will be published after Munich . Is an application-level handle needed for request/response matching? yes. create sendPduhandle . Is wildcard conextEngineID/pduType registration needed? No. This is an internal interface, and wildcarding can be supported by an implementation, but is not required in the standard. . Should indices be integers or SnmpAdminStrings? SnmpAdminStrings is the consensus. . Should protocols be identified as OIDs or Integers? OIDs . terminology: securityLevel rather than LoS msgXXXX to identify message fields in SNMPv3 Case/Harrington/Wijnen Expires February 1998 [Page 2] Draft Message Processing and Dispatching for SNMP August 1997 0.2. Change Log [version 4.12] . formatting . pagination [version 4.11] . moved Issues to resolved following consensus, as listed above . remove expectResponse from processIncomingMsg (it doesn't work) . add securityEngineID . acknowldgements . references . ordered security, editors, acknowledgements, references sections . checked line lengths [version 4.10] . deTab . checked MIB using SMICng [version 4.9] . editorial changes . rename processMsg to processIncomingMsg . returnResponsePDU - to allow application to override cache (futures) . generateResponseMsg passes globalData to reduce binding between MP and SEC . generateRequestMsg passes globalData to reduce binding between MP and SEC . expectResponse in processIncomingMessage to address Levi concern . acknowledgements . posted to snmpv3 mailing list [version 4.8] . spell checking . corrected SNMPv3 Message Processing Model [version 4.7] . editorial changes (dbh) [version 4.4] . editorial changes (bert) . renamed document to Message Processing and Dispatching for SNMP . reworked Multi-Lingual Model into Dispatcher and Message Processing . Adapted Primitives to latest set defined in ARCH [version 4.3] . removed tabs [version 4.2] . modified elements of procedure for Multi-Lingual Model [version 4.0] . Multi-Lingual Message Processing Model initial version [version 3.6] . editorial fixups by jdc . corrected overview diagram . changed Message definition to SNMPv3Message [version 3.5] . change LoS to securityLevel [version 3.4] Case/Harrington/Wijnen Expires February 1998 [Page 3] Draft Message Processing and Dispatching for SNMP August 1997 . engine, not Message Processing, interacts with network . editorial changes . registration is per PDU type . fields in MsgFlags modified and discussed . Changes as to address comments by dbh . Changes to get Primitives inline with latest list . ran MIB through SMICng . updated picture in Overview . update primitives to match editors' discussions . updates addresses to international format . removed editors' notes as appropriate . converted editors' notes into Issues as appropriate . modified text as per editors' discussions . posted to snmpv3 mailing list [version 3.3] . spelling changes . elements of procedure expanded . changes snmpMPCxxxx to snmpV3xxxx in MIB [version 3.2] . updated change log [version 3.1] . changes as a result of 2nd interim meeting . adopt to new abstract service interface primitives . use new agreed upon names for things . add a new overview of Message Processing Subsystem . Remove MP Model selection descriptions . Remove Multiplexing layer descriptions . Rewrite all the elements of procedure . Redo the SNMPv3-MIB . Removed security threats section. . Did a quick spell check on AIX . Message Processing and Control changed to Message Processing . change orangelets to applications . stats counters should be in the module where they make sense . statistics counters moved between documents on a case-by-case basic, according to where they make the most sense . modified to match consistent terminology . improved pictures . added elements of procedure . changed snmpv3Message to Message . modified naming of msgFlags . securityParameters size limitation removed . removed limits on lengths of contextEngineID and contextName . new names for the application types . more bullets to make it easier to read . primitives have consistent format with expanded comments . glossary (not filled in) removed [version 3.0] . published as draft-ietf-snmpv3-mpc-model-01.txt [version 2.1] . ?? not sure if there were any changes Case/Harrington/Wijnen Expires February 1998 [Page 4] Draft Message Processing and Dispatching for SNMP August 1997 [version 2.0] . changes as a result of 1st interim meeting . some new wording in introduction . reword in overview with a drawing . added reportFlag to msgFlags . describe overall MPC model: MPC Selection mechanism . describe overall MPC model: MPC Multiplexing Layer . describe v3MPC model. . added the abstract interface definitions for interacting with SNMPv3 USEC Model . added the abstract interface definitions for interacting with applications . added MIB definitions for error Counters (statistics) . removed references to LPM and Access Control [version 1.2] . add text regarding security threats . add text regarding access control . remove text regarding agent installation of views . removed Naming-Scope . removed discussion of MPC determining to which application a message/request should be forwarded. . added Issues section . added sending a notification for an application . spell-check, renumber, paginate [version 1.1] . separated architecture from Message Processing and Control Model for SNMPv3 . clarified snmpV3Message definition . rewrote introduction and overviews . wrote transport mappings . documented snmpV3Message format . changed Quality of Service (QoS) to Level of Security (LoS) . changed end-user to security entity . Tried to clarify MMS of engine versus MMS of message. . change security entity to securityIdentity [version 1.0] . Initial document, with SNMPng architecture and MPCv3 merged. Case/Harrington/Wijnen Expires February 1998 [Page 5] Draft Message Processing and Dispatching for SNMP August 1997 1. Introduction The Architecture for describing Internet Management Frameworks [SNMP-ARCH] describes that an SNMP engine is composed of: 1) a Dispatcher 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem. Applications make use of the services of these subsystems. It is important to understand the SNMP architecture and its terminology to understand where the Message Processing and Dispatching described in this document fits into the architecture and interacts with other subsystems within the architecture. The reader is expected to have read and understood the description of the SNMP architecture, as defined in [SNMP-ARCH]. The Dispatcher in the SNMP engine sends and receives SNMP messages. It also dispatches SNMP PDUs to SNMP applications. When an SNMP message needs to be prepared or when data needs to be extracted from an SNMP message, then the Dispatcher delegates these tasks to a message version specific Message Processing Model. A Message Processing Model has the responsibility for processing a SNMP version specific message and for coordinating the interaction with the Security Subsystem to ensure proper security is applied to the SNMP message being handled. The interactions between the Dispatcher, the Message Processing Subsystem and applications are performed using abstract data elements and abstract service interface primitives as defined by the SNMP architecture. Similarly, the interactions between the Message Processing Subsystem and the Security Subsystem are performed using abstract data elements and abstract service interface primitives as defined by the SNMP architecture. Case/Harrington/Wijnen Expires February 1998 [Page 6] Draft Message Processing and Dispatching for SNMP August 1997 2. Overview The following illustration depicts the Message Processing in relation to SNMP applications, the Security Subsystem and Transport Mappings. +--------------------------------------------------------------------+ | SNMP Entity | | | | +----------------------------------------------------------------+ | | | Applications | | | | +------------+ +--------------+ | | | | | Command | | Notification | | | | | | Generator | | Originator | +-----------+ +--------------+| | | | +------------+ +--------------+ | Proxy | | Other | | | | +------------+ +--------------+ | Forwarder | |Application(s)|| | | | | Command | | Notification | +-----------+ +--------------+| | | | | Responder | | Receiver | | | | | +------------+ +--------------+ | | | +----------------------------------------------------------------+ | | ^ ^ ^ ^ | | | | | | | | v v v v | | +--------+--------+---------------+-----------+ | | ^ | | | +---------------------+ +-----------------+ | | | | Message Processing | | Security | | | Dispatcher v | Subsystem | | Subsystem | | | +-------------------+ | +------------+ | | | | | | PDU Dispatcher | | +->| v1MP * |<--->| +-------------+ | | | | | | | +------------+ | | | Other | | | | | | | | +------------+ | | | Security | | | | | | | +->| v2cMP * |<--->| | Model | | | | | Message | | | +------------+ | | +-------------+ | | | | Dispatcher <--------->+ | | | | | | | | | +------------+ | | +-------------+ | | | | | | +->| v3MP * |<--->| | User-based | | | | | Transport | | | +------------+ | | | Security | | | | | Mapping | | | +------------+ | | | Model | | | | | (e.g RFC1906) | | +->| otherMP * |<--->| +-------------+ | | | +-------------------+ | +------------+ | | | | | ^ +---------------------+ +-----------------+ | | | | +----------|---------------------------------------------------------+ v +-------------------+ | Network | +-------------------+ Case/Harrington/Wijnen Expires February 1998 [Page 7] Draft Message Processing and Dispatching for SNMP August 1997 2.1. The Dispatcher. The Dispatcher is a key piece of an SNMP engine. There is only one in an SNMP engine, and its job is to dispatch tasks to the multiple version-specific Message Processing Models, and to dispatch PDUs to various applications. For incoming messages, the Dispatcher determines the SNMP version of the incoming message and passes the message to the version-specific Message Processing Model to extract the components of the message and to coordinate the processing of security services for the message. After version-specific processing, the PDU Dispatcher determines to which application the PDU should be sent for processing. For outgoing messages, an application provides a PDU to be sent, plus the data needed to prepare and send the message, and the application specifies which version-specific Message Processing Model should be used to prepare the message with the desired security processing. Once the message is prepared, the Dispatcher sends the message. The Dispatcher, while sending and receiving SNMP messages, collects statistics about SNMP messages and the behavior of the SNMP engine in managed objects to make them accessible to remote SNMP entities. This document defines these managed objects, the MIB module which contains them, and how these managed objects might be used to provide useful management. 2.2. Message Processing Subsystem The SNMP Message Processing Subsystem is the part of an SNMP engine which interacts with the Dispatcher to handle the version specific SNMP messages. It contains one or more Message Processing Models. This document describes one Message Processing Model, the SNMPv3 Message Processing Model, in section 6. The SNMPv3 Message Processing Model is defined in a separate section to show that multiple (independent) Message Processing Models can exist at the same time and that such Models can be described in different documents. The SNMPv3 Message Processing Model can be replaced or supplemented with other Message Processing Models in the future. Two Message Processing Models which are expected to be developed in the future are the SNMPv1 message format [RFC1157] and the SNMPv2c message format [RFC1901]. Others may be developed as needed. Case/Harrington/Wijnen Expires February 1998 [Page 8] Draft Message Processing and Dispatching for SNMP August 1997 3. Elements of Message Processing See [SNMP-ARCH] for the definitions of contextEngineID contextName scopedPDU maxSizeResponseScopedPDU securityModel securityName securityLevel snmpVersion For incoming messages, a version-specific message processing module provides these values to the Dispatcher. For outgoing messages, an application provides these values to the Dispatcher. For some version-specific processing, the values may be extracted from received messages; for other versions, the values may be determined by algorithm, or by an implementation-defined mechanism. How the value is determined is irrelevant to the Dispatcher The following additional or expanded definitions are for use within the Dispatcher. 3.1. messageProcessingModel The messageProcessingModel identifies a Message Processing Model. A Model describes the version-specific procedures for extracting data from messages, generating messages, calling upon a securityModel to use its security services for a message, and for converting data from a version-specific message format into a generic format usable by the Dispatcher, and for converting data from Dispatcher format into a version-specific message format. 3.2. pduVersion A value which represents a specific version of protocol operation and its associated PDU formats. The values of pduVersion are specific to the version of the PDU contained in a message, and the PDUs processed by applications. The Dispatcher does not use the values of pduVersion directly. An application can specify the pduVersion when it requests the PDU Dispatcher to send a PDU to another SNMP engine. The Dispatcher passes the pduVersion to a Message Processing Model, so it knows how to handle the PDU properly. For incoming messages, pduVersion is provided to the Dispatcher by a version-specific Message Processing module. The PDU Dispatcher passes the pduVersion to the application so it knows how to handle the PDU properly. Case/Harrington/Wijnen Expires February 1998 [Page 9] Draft Message Processing and Dispatching for SNMP August 1997 3.3. pduType A value which represents a specific type of protocol operation. The values of pduType are specific to the version of the PDU contained in a message. Applications register to support particular pduTypes for particular contextEngineIDs. For incoming messages, pduType is provided to the Dispatcher by a version-specific Message Processing module. It is subsequently used to dispatch the PDU to the application which registered for the pduType for the contextEngineID of the associated scopedPDU. 3.4. sendPduHandle This handle is generated for coordinating the processing of requests and responses between the SNMP engine and an application. The handle must be unique across all version-specific Message Processing Models. Implementation Hint: If sendPduhandle is implemented as a 32-bit integer, its value could be used as a generic unique ID. For example, the values of an SNMPv3 msgID or an SNMPv1 request-id could be taken from the sendPduhandle. Case/Harrington/Wijnen Expires February 1998 [Page 10] Draft Message Processing and Dispatching for SNMP August 1997 4. Elements of Procedure This section describes the procedures followed by the Dispatcher when generating and processing SNMP messages. 4.1. Sending an SNMP Message to the Network This section describes the procedure followed by an SNMP engine whenever it must send an SNMP message. 4.1.1. Sending a Request or Notification An application wants an SNMP PDU to be sent to another (remote) application. 1) The application requests this using the abstract service primitive: statusInformation = -- sendPduHandle if success -- errorIndication if failure sendPdu( IN transportDomain -- transport domain to be used IN transportAddress -- destination network address IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE ) 2) If the messageProcessingModel value does not represent a Message Processing Model known to the Dispatcher, then an errorIndication (implementation-dependent) is returned to the calling application. No further processing is done. 3) The Dispatcher generates a sendPduHandle to coordinate subsequent processing. 4) The Message Dispatcher sends the request to the version-specific Message Processing module identified by messageProcessingModel using the abstract service primitive: statusInformation = - success or error indication prepareOutgoingMessage( IN transportDomain -- as specified by application IN transportAddress -- as specified by application IN messageProcessingModel -- as specified by application IN securityModel -- as specified by application Case/Harrington/Wijnen Expires February 1998 [Page 11] Draft Message Processing and Dispatching for SNMP August 1997 IN securityName -- as specified by application IN securityLevel -- as specified by application IN contextEngineID -- as specified by application IN contextName -- as specified by application IN pduVersion -- the version of the PDU IN PDU -- as specified by application IN expectResponse -- as specified by application IN sendPduHandle -- as determined in step 3. OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- the message length ) 5) If the statusInformation indicates an error, the errorIndication is returned to the calling application. 6) If the statusInformation indicates success, the sendPduHandle is returned to the application, and the outgoingMessage is sent over the transport specified by the transportDomain to the address specified by the transportAddress. Outgoing Message Processing is complete. 4.1.2. Sending a Response to the Network An application wants a response to be sent back to the originator of an SNMP Request. 1) An application can request this using the abstract service primitive: returnResponsePdu( IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- same as on incoming request IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size of the Response PDU IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication ) -- error counter OID/value if error 2) The Message Dispatcher sends the request to the version-specific protocol specified by messageProcessingModel using the abstract service primitive: Case/Harrington/Wijnen Expires February 1998 [Page 12] Draft Message Processing and Dispatching for SNMP August 1997 result = -- SUCCESS or errorIndication prepareResponseMessage( IN messageProcessingModel -- as specified by application IN securityModel -- as specified by application IN securityName -- as specified by application IN securityLevel -- as specified by application IN contextEngineID -- as specified by application IN contextName -- as specified by application IN pduVersion -- as specified by application IN PDU -- as specified by application IN maxSizeResponseScopedPDU -- as specified by application IN stateReference -- as specified by application IN statusInformation -- as specified by application OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- the message length ) 3) If the result is an errorIndication, the errorIndication is returned to the calling application. 4) If the result is success, the outgoingMessage is sent over the transport specified by the transportDomain to the address specified by the transportAddress. Message Processing is complete. 4.2. Receiving an SNMP Message from the Network This section describes the procedure followed by an SNMP engine whenever it receives an SNMP message. Please note, that for the sake of clarity and to prevent the text from being even longer and more complicated, some details were omitted from the steps below. a) The elements of procedure do not always explicitly indicate when state information needs to be released. The general rule is that if state information is available when a message is to be "discarded without further processing", then the state information must also be released at that same time. 4.2.1. Message Dispatching 1) The snmpInPkts counter [RFC1907] is incremented. 2) The version of the SNMP message is determined in an implementation dependent manner. If the version cannot be determined, or the version is not supported, then the snmpInBadVersions [RFC1907] counter is incremented, and the message is discarded without Case/Harrington/Wijnen Expires February 1998 [Page 13] Draft Message Processing and Dispatching for SNMP August 1997 further processing. 3) The origin transportDomain and origin transportAddress are determined. 4) The message is passed to the version-specific Message Processing Model which returns the abstract data elements required by the Dispatcher. This is done using the abstract service primitive: result = -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin as determined in step 3. IN transportAddress -- origin as determined in step 3. IN wholeMsg -- as received from the network IN wholeMsglength -- as received from the network OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model to use OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security requested OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- the version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for a matched request OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU OUT statusInformation -- success or errorIndication -- error counter OID/value if error OUT stateReference -- reference to state information -- to be used for a possible ) -- Response 5) If the result is a FAILURE errorIndication, the message is discarded without further processing. 6) The abstract data elements have been prepared now. Continue with the section that describes the PDU Dispatching. 4.2.2. PDU Dispatching for Incoming Messages If the value of sendPduhandle is , then this is a request or notification. 1) The combination of contextEngineID, and pduType are used to determine which application has registered for this request or notification. 2) If no application has registered for the combination, then a) The snmpUnknownPDUHandlers counter is incremented. Case/Harrington/Wijnen Expires February 1998 [Page 14] Draft Message Processing and Dispatching for SNMP August 1997 b) A Response message is generated using the abstract service primitive: result = -- SUCCESS or FAILURE prepareResponseMessage( IN messageProcessingModel -- as provided by MP module IN securityModel -- as provided by MP module IN securityName -- as provided by MP module IN securityLevel -- as provided by MP module IN contextEngineID -- as provided by MP module IN contextName -- as provided by MP module IN pduVersion -- as provided by MP module IN PDU -- as provided by MP module IN maxSizeResponseScopedPDU -- as provided by MP module IN stateReference -- as provided by MP module IN statusInformation -- errorIndication plus -- snmpUnknownPDUHandlers OID -- value pair. OUT transportDomain -- destination transportDomain OUT transportAddress -- destination transportAddress OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length ) c) If the result is SUCCESS, then the prepared message is sent to the originator of the request as identified by the transportDomain and transportAddress. d) The incoming message is discarded without further processing. Message Processing for this message is complete. 3) The PDU is dispatched to the application, using the abstract service interface: processPdu( -- process Request/Notification IN messageProcessingModel -- as provided by MP module IN securityModel -- as provided by MP module IN securityName -- as provided by MP module IN securityLevel -- as provided by MP module IN contextEngineID -- as provided by MP module IN contextName -- as provided by MP module IN pduVersion -- as provided by MP module IN PDU -- as provided by MP module IN maxSizeResponseScopedPDU -- as provided by MP module IN stateReference -- as provided by MP module ) -- needed when sending a response Message processing for this message is complete. If the value of sendPduHandle is not , then this is a response. Case/Harrington/Wijnen Expires February 1998 [Page 15] Draft Message Processing and Dispatching for SNMP August 1997 1) The value of sendPduHandle is used to determine, in an implementation-defined manner, which application is waiting for a response PDU associated with this sendPduHandle. 2) If no waiting application is found, the message is discarded without further processing, and the stateReference is released. Message Processing is complete for this message. 3) Any cached information, including stateReference, about the message is discarded. 4) The response is dispatched to the application using the abstract service primitive: processResponsePdu( -- process Response PDU IN messageProcessingModel -- as provided by the MP module IN securityModel -- as provided by the MP module IN securityName -- as provided by the MP module IN securityLevel -- as provided by the MP module IN contextEngineID -- as provided by the MP module IN contextName -- as provided by the MP module IN pduVersion -- as provided by the MP module IN PDU -- as provided by the MP module IN statusInformation -- as provided by the MP module IN sendPduHandle -- as provided by the MP module ) Message Processing is complete for this message. 4.3. Application Registration for Handling PDU types Applications that want to process certain PDUs must register with the PDU Dispatcher. Applications specify for which combination of contextEngineID, and pduType(s) they want to take responsibility. 1) An application registers according to the abstract interface primitive: statusInformation = -- success or errorIndication registerContextEngineID( IN contextEngineID -- take responsibility for this one IN pduType -- the pduType(s) to be registered ) 2) The parameters may be checked to be valid; if they are not, then an errorIndication (invalidParameter) is returned to the application. 3) Each combination of contextEngineID and pduType can be registered only once. If another application has already registered for the specified combination, then an errorIndication (alreadyRegistered) is returned to the application. Case/Harrington/Wijnen Expires February 1998 [Page 16] Draft Message Processing and Dispatching for SNMP August 1997 4) Otherwise, the registration is saved so that SNMP PDUs can be dispatched to this application. 4.3. Application Unregistration for Handling PDU Types Applications that no longer want to process certain PDUs must unregister with the PDU Dispatcher. 1) An application unregisters using the abstract service primitive: unregisterContextEngineID( IN contextEngineID -- give up responsibility for this IN pduType -- the pduType(s) to be unregistered ) 2) If the contextEngineID and pduType combination has been registered, then the registration is deleted. If no such registration exists, then the request is ignored. Case/Harrington/Wijnen Expires February 1998 [Page 17] Draft Message Processing and Dispatching for SNMP August 1997 5. Definitions 5.1. Definitions for SNMP Message Processing and Dispatching SNMP-MPD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, snmpModules, Counter32 FROM SNMPv2-SMI; snmpMPDMIB MODULE-IDENTITY LAST-UPDATED "9707270000Z" -- 27 July 1997, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@tis.com Subscribe: majordomo@tis.com In message body: subscribe snmpv3 Chair: Russ Mundy Trusted Information Systems postal: 3060 Washington Road Glenwood MD 21738 USA email: mundy@tis.com phone: +1-301-854-6889 Co-editor: Jeffrey Case SNMP Research, Inc. postal: 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA email: case@snmp.com phone: +1-423-573-1434 Co-editor Dave Harrington Cabletron Systems, Inc postal: Post Office Box 5005 MailStop: Durham 35 Industrial Way Rochester NH 03867-5005 USA email: dbh@cabletron.com phone: +1- 603-337-7357 Co-editor: Bert Wijnen IBM T. J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-432-794 Case/Harrington/Wijnen Expires February 1998 [Page 18] Draft Message Processing and Dispatching for SNMP August 1997 " DESCRIPTION "The MIB for Message Processing and Dispatching" ::= { snmpModules 8 } -- check if assignment is OK -- Administrative assignments **************************************** snmpMPDAdmin OBJECT IDENTIFIER ::= { snmpMPDMIB 1 } snmpMPDMIBObjects OBJECT IDENTIFIER ::= { snmpMPDMIB 2 } snmpMPDMIBConformance OBJECT IDENTIFIER ::= { snmpMPDMIB 3 } -- Statistics for SNMP Messages ************************************** snmpMPDStats OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 } snmpUnknownSecurityModels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they referenced a securityModel that was not known to or supported by the SNMP engine, e.g., was not registered by any application. " ::= { snmpMPDStats 1 } snmpInvalidMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because there were invalid or inconsistent components in the SNMP message. " ::= { snmpMPDStats 2 } snmpUnknownPDUHandlers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because the PDU contained in the packet could not be passed to an application responsible for handling the pduType, i.e. no SNMP application had registered for the proper combination of the messageProcessingModel, the contextEngineID and the pduType. " ::= { snmpMPDStats 3 } Case/Harrington/Wijnen Expires February 1998 [Page 19] Draft Message Processing and Dispatching for SNMP August 1997 -- Conformance information ******************************************* snmpMPDMIBCompliances OBJECT IDENTIFIER ::= { snmpMPDMIBConformance 1 } snmpMPDMIBGroups OBJECT IDENTIFIER ::= { snmpMPDMIBConformance 2 } -- Compliance statements snmpMPDCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the SNMP-MPD-MIB. " MODULE -- this module MANDATORY-GROUPS { snmpMPDGroup } ::= { snmpMPDMIBCompliances 1 } snmpMPDGroup OBJECT-GROUP OBJECTS { snmpUnknownSecurityModels, snmpInvalidMsgs, snmpUnknownPDUHandlers } STATUS current DESCRIPTION "A collection of objects providing for remote monitoring of the SNMP Message Processing and Dispatching process. " ::= { snmpMPDMIBGroups 1 } END Case/Harrington/Wijnen Expires February 1998 [Page 20] Draft Message Processing and Dispatching for SNMP August 1997 6. The SNMPv3 Message Format This section defines the SNMPv3 message format and the corresponding SNMP version 3 Message Processing Model (v3MP). DEFINITIONS ::= BEGIN SNMPv3Message ::= SEQUENCE { -- administrative parameters msgGlobalData headerData -- security model-specific parameters -- format defined by Security Model msgSecurityParameters OCTET STRING msgData scopedPduData } headerData ::= SEQUENCE { msgVersion INTEGER { snmpv3 (3) }, msgID INTEGER (0..2147483647), msgMaxSize INTEGER (484..2147483647), msgFlags OCTET STRING (SIZE(1)), -- .... ...1 authFlag -- .... ..1. privFlag -- .... .1.. reportableFlag -- .... 1... reportFlag -- -- Please observe: -- .... ..00 is OK, means noAuthNoPriv -- .... ..01 is OK, means authNoPriv -- .... ..10 reserved, must NOT be used. -- .... ..11 is OK, means authPriv msgSecurityModel INTEGER (0..2147483647) } scopedPduData ::= CHOICE { plaintext scopedPDU, encryptedPDU OCTET STRING -- encrypted scopedPDU value } scopedPDU ::= SEQUENCE { contextEngineID OCTET STRING contextName OCTET STRING data ANY -- e.g. PDUs as defined in RFC1905 } END Case/Harrington/Wijnen Expires February 1998 [Page 21] Draft Message Processing and Dispatching for SNMP August 1997 6.1. msgVersion The msgVersion field is set to snmpv3(3) and identifies the message as an SNMP version 3 Message. 6.2. msgID The msgID is used between two SNMP entities to coordinate request messages and responses, and by the v3MP to coordinate the processing of the message by different subsystem models within the architecture. Another purpose of msgID is to provide protection against message replays. This requires that msgID generated must vary from one message to another, and it should be initialized to an unpredictable value. A good method would be to initialize msgID when the SNMP engine is started and then increase its value monotonically with each subsequent message. Note that the request-id in a PDU is used by SNMP applications to identify the PDU; the msgID is used by the engine to identify the message which carries a PDU. The engine may need to identify the message even if decrypting of the PDU (and request-id) fails. No assumption should be made that the value of the msgID and the value of the request-id are equivalent. 6.3. msgMaxSize The msgMaxSize field of the message conveys the maximum message size supported by the sender of the message, i.e., the maximum message size that the sender can accept when another SNMP engine sends an SNMP message (be it a response or any other message) to the sender of this message. When an SNMP message is being generated, the msgMaxSize is provided by the SNMP engine which generates the message. At the receiving SNMP engine the msgMaxSize is used to determine how big the Response to a Request message can be. 6.4. msgFlags The msgFlags field of the message contains several bit fields which assist with the processing of the message. a) reportableFlag If the reportableFlag is set, then Report PDUs are allowed to be returned to the sender under those conditions which cause the generation of Report PDUs. If the reportableFlag is zero, then a Report PDU must not be sent. The reportableFlag should always be zero when the message contains a Report PDU, a Response PDU, or an Case/Harrington/Wijnen Expires February 1998 [Page 22] Draft Message Processing and Dispatching for SNMP August 1997 SNMPv2-trap PDU. The reportableFlag should always be set for a Request PDU. b) reportFlag The reportFlag indicates whether or not the message contains a Report PDU. Report PDUs are engine-to-engine communications and are processed directly by the SNMPv3 Message Processing Model, and are not passed to applications for processing, unlike all other PDU types. The reportFlag is set for a message containing a Report PDU so the SNMPv3 Message Processing Model can easily recognize such messages. The authFlag and privFlag portions of the msgFlags field are set by the sender to indicate the securityLevel that was applied to the message before it was sent on the wire. The receiver of the message should apply the same securityLevel when the message is received and the contents are being processed. There are 3 securityLevels, namely noAuthNoPriv, which is less than authNoPriv, which is in turn less than authPriv. See the SNMP architecture document [SNMP-ARCH] for details about the securityLevel. a) authFlag If the authFlag is set, then the securityModel used by the SNMP engine which sent the message must identify the securityName on whose behalf the SNMP message was generated and must provide, in a securityModel-specific manner, sufficient data for the receiver of the message to be able to authenticate that identification. In general, this authentication will allow the receiver to determine with reasonable certainty that the message was: - sent on behalf of the principal associated with the securityName, - was not redirected, - was not modified in transit, and - was not replayed. If the authFlag is not set, then the securityModel used by the SNMP engine which sent the message must identify the securityName on whose behalf the SNMP message was generated but it does not need to provide sufficient data for the receiver of the message to authenticate the identification, as there is no need to authenticate the message in this case. b) privFlag If the privFlag is set, then the securityModel used by the SNMP engine which sent the message must also protect the scopedPDU in an SNMP message from disclosure, i.e. must encrypt/decrypt the scopedPDU. If the privFlag is zero, then the securityModel in use Case/Harrington/Wijnen Expires February 1998 [Page 23] Draft Message Processing and Dispatching for SNMP August 1997 does not need to protect the data from disclosure. It is an explicit requirement of the SNMP architecture that if privacy is selected, then authentication is also required. That means that if the privFlag is set, then the authFlag should also be set. The combination of the authFlag and the privFlag comprises a Level of Security as follows: authFlag zero and privFlag zero -> securityLevel is noAuthNoPriv authFlag zero and privFlag one -> invalid combination authFlag one and privFlag zero -> securityLevel is authNoPriv authFlag one and privFlag one -> securityLevel is authPriv 6.5. msgSecurityModel The v3MP supports the concurrent existence of multiple Security Models to provide security services for SNMPv3 messages. The msgSecurityModel field in an SNMPv3 Message identifies which Security Model was used by the sender to generate the message and therefore which securityModel should be used by the receiver to perform security processing for the message. The mapping to the appropriate securityModel implementation within an SNMP engine is accomplished in an implementation-dependent manner. 6.6. msgSecurityParameters The msgSecurityParameters field of the SNMPv3 Message is used for communication between the Security Model modules in the sending and receiving SNMP engines. The data in the msgSecurityParameters field is used exclusively by the Security Model, and the contents and format of the data is defined by the Security Model. This OCTET STRING is not interpreted by the v3MP, but is passed to the local implementation of the Security Model indicated by the msgSecurityModel field in the message. 6.7. scopedPduData The scopedPduData field represents either the plain text scopedPDU if the privFlag in the msgFlags is zero, or it represents an encryptedPDU which must be decrypted by the securityModel in use to produce a plaintext scopedPDU. 6.8. scopedPDU The scopedPDU contains information to identify an administratively unique context and a PDU. The object identifiers in the PDU refer to managed objects which are (expected to be) accessible within the specified context. Case/Harrington/Wijnen Expires February 1998 [Page 24] Draft Message Processing and Dispatching for SNMP August 1997 6.8.1. contextEngineID The contextEngineID in the SNMPv3 message, uniquely identifies, within an administrative domain, an SNMP entity that may realize an instance of a context with a particular contextName. For incoming messages, the contextEngineID is used to determine to which application the scopedPDU should be sent for processing. For outgoing messages, the v3MP sets the contextEngineID to the value provided by the application in the request for a message to be sent. 6.8.2. contextName The contextName field in an SNMPv3 message, in conjunction with the contextEngineID field, identifies the particular context associated with the management information contained in the PDU portion of the message. The contextName is unique within the SNMP entity specified by the contextEngineID, which may realize the managed objects referenced within the PDU. An application which originates a message provides the value for the contextName field and this value may be used during processing by an application at the receiving SNMP Engine. 6.8.3. data The data field of the SNMPv3 Message contains the PDU. Among other things, the PDU contains the PDU type that is used by the v3MP to determine the type of the incoming SNMP message. The v3MP specifies that the PDU must be one of those specified in [RFC1905]. Case/Harrington/Wijnen Expires February 1998 [Page 25] Draft Message Processing and Dispatching for SNMP August 1997 7. Elements of Procedure This section describes the procedures followed by an SNMP engine when generating and processing SNMP messages according to the SNMPv3 Message Processing Model. Please note, that for the sake of clarity and to prevent the text from being even longer and more complicated, some details were omitted from the steps below. a) Some steps specify that when some error conditions are encountered when processing a received message, a message containing a Report PDU is generated and the received message is discarded without further processing. However, a Report-PDU must not be generated unless the reportableFlag is set in the received message. b) The elements of procedure do not always explicitly indicate when state information needs to be released. The general rule is that if state information is available when a message is to be "discarded without further processing", then the state information must also be released at that same time. 7.1. Prepare an Outgoing SNMP Message This section describes the procedure followed to prepare an SNMPv3 message from the data elements passed by the Message Dispatcher. 1) The Message Dispatcher may request that an SNMPv3 message containing a GetRequest-PDU, a GetNextRequest-PDU, a GetBulkRequest-PDU, a SetRequest-PDU, an InformRequest-PDU, or an SNMPv2-Trap-PDU be prepared for sending. a) It makes such a request according to the abstract service primitive: statusInformation = -- success or errorIndication prepareOutgoingMessage( IN transportDomain -- requested transport domain IN transportAddress -- requested destination address IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE IN sendPduHandle -- the handle for matching -- incoming responses OUT destTransportDomain -- destination transport domain Case/Harrington/Wijnen Expires February 1998 [Page 26] Draft Message Processing and Dispatching for SNMP August 1997 OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- the length of the message ) b) A unique msgID is generated. It is best to use unpredictable numbers for the msgID. * SNMPv3 does not use the values of expectResponse or pduVersion. 2) The Message Dispatcher may request that an SNMPv3 message containing a Response-PDU or a Report-PDU be prepared for sending. a) It makes such a request according to the abstract service primitive: result = -- SUCCESS or FAILURE prepareResponseMessage( IN messageProcessingModel -- typically, SNMP version IN securityModel -- same as on incoming request IN securityName -- same as on incoming request IN securityLevel -- same as on incoming request IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size of the Response PDU IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication -- error counter OID/value if error OUT transportDomain -- destination transport domain OUT transportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- the length of the message ) b) The cached information for the original request, pointed to by the stateReference, is retrieved, including - msgID, - contextEngineID, - contextName, - securityModel, - securityName, - securityLevel, - securityStateReference, - reportableFlag, - transportDomain, and - transportAddress. Case/Harrington/Wijnen Expires February 1998 [Page 27] Draft Message Processing and Dispatching for SNMP August 1997 The SNMPv3 Message Processing Model does not allow cached data to be overidden by specified parameters. 3) If statusInformation contains values for an OID/value combination, then a) If reportableFlag is zero, then the original message is discarded, and no further processing is done. A result of FAILURE is returned. SNMPv3 Message Processing is complete. b) If a PDU is provided, it is the PDU from the original request. If possible, extract the request-id. c) A Report PDU is prepared: 1) the varBindList is set to contain the OID and value from the statusInformation 2) error-status is set to 0 3) error-index is set to 0. 4) request-id is set to the value extracted in step b) Otherwise, request-id is set to 0 d) If the errorIndication is NotInTimeWindow, then securityLevel is set to authNoPriv, otherwise securityLevel is set to noAuthNoPriv. e) PDU is set to refer to the new Report-PDU. The old PDU is discarded. f) contextEngineID is set to the value of snmpEngineID g) contextName is set to the default contextName 4) If contextEngineID is not yet determined, then the contextEngineID is determined, in an implementation-dependent manner, possibly using the transportDomain and transportAddress. 5) If the contextName is not yet determined, the contextName is set to the default context. 6) A scopedPDU is prepared from the contextEngineID, contextName, and PDU. 7) msgGlobalData is constructed as follows a) The msgVersion field is set to snmpv3(3). b) msgID is set as determined in step 1 or 2. c) msgMaxSize is set to an implementation dependent value. d) msgFlags are set as follows: - If securityLevel specifies noAuthNoPriv, then authFlag Case/Harrington/Wijnen Expires February 1998 [Page 28] Draft Message Processing and Dispatching for SNMP August 1997 and privFlag are both set to zero. - If securityLevel specifies authNoPriv, then authFlag is set to one and privFlag is set to zero. - If securityLevel specifies authPriv, then authFlag is set to one and privFlag is set to one. - If the PDU is a Response-PDU, a Report-PDU or an SNMPv2-Trap-PDU, then the reportableFlag is set to zero; - If the PDU is a GetRequest-PDU, a GetNextRequest-PDU, a GetBulkRequest-PDU, a SetRequest-PDU, or an InformRequest-PDU then the reportableFlag is set to one. - If the PDU is a Report-PDU, the reportFlag is set to one; otherwise it is set to zero. - All other msgFlags bits are set to zero. e) msgSecurityModel is set to the value of securityModel 8) If the PDU is a Response-PDU or a Report-PDU, then a) The specified Security Model is called to generate the message according to the primitive: statusInformation = generateResponseMsg( IN messageProcessingModel -- SNMPv3 Message Processing Model IN globalData -- msgGlobalData from step 7 IN maxMessageSize -- from msgMaxSize in step 7 c) IN securityModel -- as determined in step 7 e) IN securityEngineID -- the value of snmpEngineID IN securityName -- on behalf of this principal IN securityLevel -- for the outgoing message IN scopedPDU -- as prepared in step 6) IN securityStateReference -- as determined in step 2 OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of the generated message ) If, upon return from the Security Model, the statusInformation includes an errorIndication, then any cached information about the outstanding request message is discarded, and an errorIndication is returned, so it can be returned to the calling application. SNMPv3 Message Processing is complete. b) A SUCCESS result is returned. SNMPv3 Message Processing is complete. 9) If the PDU is a GetRequest-PDU, a GetNextRequest-PDU, a GetBulkRequest-PDU, a SetRequest-PDU, an InformRequest-PDU, or or an SNMPv2-Trap-PDU, then a) If the PDU is an SNMPv2-Trap-PDU, then securityEngineID Case/Harrington/Wijnen Expires February 1998 [Page 29] Draft Message Processing and Dispatching for SNMP August 1997 is set to the value of this entity's snmpEngineID, Otherwise, the snmpEngineID of the target entity is determined, in an implementation-dependent manner, possibly using transportDomain and transportAddress. securityEngineID is set to the value of the target entity's snmpEngineID. b) The specified Security Model is called to generate the message according to the primitive: statusInformation = generateRequestMsg( IN messageProcessingModel -- SNMPv3 Message Processing Model IN globalData -- msgGlobalData, from step 7 IN maxMessageSize -- from msgMaxSize in step 7 c) IN securityModel -- as provided by caller IN securityEngineID -- authoritative SNMP entity IN securityName -- as provided by caller IN securityLevel -- as provided by caller IN snmpEngineID -- as determined in step 9 a) IN scopedPDU -- as prepared in step 6 OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of the generated message ) If, upon return from the Security Model, the statusInformation includes an errorIndication, then the message is discarded, and the errorIndication is returned, so it can be returned to the calling application, and no further processing is done. SNMPv3 Message Processing is complete. c) Information about the outgoing message is cached, and a stateReference is created (implementation specific). Information to be cached includes the values of: - sendPduHandle - msgID - snmpEngineID - securityModel - securityName - securityLevel - contextEngineID - contextName d) A SUCCESS result is returned. SNMPv3 Message Processing is complete. Case/Harrington/Wijnen Expires February 1998 [Page 30] Draft Message Processing and Dispatching for SNMP August 1997 7.2. Prepare Data Elements from an Incoming SNMP Message This section describes the procedure followed to extract data from an SNMPv3 message, and to prepare the data elements required for further processing of the message by the Message Dispatcher. 1) The message is passed in from the Message Dispatcher according to the abstract service primitive: result = -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN wholeMsg -- as received from the network IN wholeMsglength -- as received from the network OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model to use OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security requested OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for matched request OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU OUT statusInformation -- success or errorIndication -- error counter OID/value if error OUT stateReference -- reference to state information -- to be used for a possible ) -- Response 2) If the received message is not the serialization (according to the conventions of [RFC1906]) of an SNMPv3Message value, then the snmpInASNParseErrs counter [RFC1907] is incremented, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. 3) The values for msgVersion, msgID, msgMaxSize, msgFlags, msgSecurityModel, msgSecurityParameters, and msgData are extracted from the message. 4) If the value of the msgSecurityModel component does not match a supported securityModel, then the snmpUnknownSecurityModels counter is incremented, a Report PDU is generated, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. 5) The securityLevel is determined from the authFlag and the privFlag bits of the msgFlags component as follows: Case/Harrington/Wijnen Expires February 1998 [Page 31] Draft Message Processing and Dispatching for SNMP August 1997 a) If the authFlag is not set and the privFlag is not set, then securityLevel is set to noAuthNoPriv. b) If the authFlag is set and the privFlag is not set, then securityLevel is set to authNoPriv. c) If the authFlag is set and the privFlag is set, then securityLevel is set to authPriv. d) If the authFlag is not set and privFlag is set, then the snmpInvalidMessages counter is incremented, a Report PDU is generated, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. 6) The security module implementing the Security Model as specified by the securityModel component is called for authentication and privacy services. This is done according to the abstract service primitive: statusInformation = -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- SNMPv3 Message Processing Model IN expectResponse -- TRUE or FALSE IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU OUT securityStateReference -- reference to security state ) -- information, needed for response If an errorIndication is returned by the security module, then a) If statusInformation contains values for an OID/value pair, then a Report PDU is generated. 1) If the scopedPDU has been returned from ProcessIncomingMessage then determine contextEngineID, contextName, and PDU. 2) Information about the message is cached and a stateReference is created (implementation specific). Information to be cached includes the values of: msgVersion, Case/Harrington/Wijnen Expires February 1998 [Page 32] Draft Message Processing and Dispatching for SNMP August 1997 msgID, securityLevel, msgFlags, msgMaxSize, securityModel, maxSizeResponseScopedPDU, securityStateReference 3) Request that a Report-PDU be prepared and sent, according to the abstract service primitive: result = -- SUCCESS or FAILURE returnResponsePDU( IN messageProcessingModel -- SNMPv3(3) IN securityModel -- same as on incoming request IN securityName -- from ProcessIncomingMessage IN securityLevel -- same as on incoming request IN contextEngineID -- from step 6 a) 1) IN contextName -- from step 6 a) 1) IN pduVersion -- SNMPv2-PDU IN PDU -- from step 6 a) 1) IN maxSizeResponseScopedPDU -- from ProcessIncomingMessage IN stateReference -- from step 6 a) 2) IN statusInformation -- from ProcessIncomingMsg OUT transportDomain -- destination transport domain OUT transportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- the length of the message ) b) The incoming message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. 7) The scopedPDU is parsed to extract the contextEngineID, the contextName and the PDU. If any parse error occurs, then the snmpInASNParseErrs counter [RFC1907] is incremented, the security state information is discarded, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. 8) The pduVersion is set to an SNMPv2-PDU. 9) The pduType is determined, in an implementation-dependent manner, to be: - a GetRequest-PDU, - a GetNextRequest-PDU, - a GetBulkRequest-PDU, - a SetRequest-PDU, - an InformRequest-PDU, Case/Harrington/Wijnen Expires February 1998 [Page 33] Draft Message Processing and Dispatching for SNMP August 1997 - an SNMPv2-Trap-PDU, - a Response-PDU, or - a Report-PDU. 10) If the pduType is a Response-PDU or a Report-PDU, then a) The value of the msgID component is used to find the cached information for a corresponding outstanding Request message. If no such outstanding Request message is found, then the security state information is discarded, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. b) sendPduhandle is retrieved from the cached information. Otherwise, sendPduhandle is set to , an implementation defined value. 11) If the pduType is a Report-PDU, then a) statusInformation is created using the contents of the Report-PDU, in an implementation-dependent manner. This statusInformation will be forwarded to the application associated with the sendPduHandle. b) Any cached information about the outstanding Request message message is discarded. c) The security state information for this incoming message is discarded. d) stateReference is set to e) A SUCCESS result is returned. SNMPv3 Message Processing is complete. 12) If the pduType is a Response-PDU, then a) The cached data for the outstanding request, referred to by stateReference, is retrieved, including - snmpEngineID - securityModel - securityName - securityLevel - contextEngineID - contextName b) If the values extracted from the incoming message differ from the cached data, then the security state information is discarded, any cached information about the outstanding Case/Harrington/Wijnen Expires February 1998 [Page 34] Draft Message Processing and Dispatching for SNMP August 1997 Request message is discarded, the incoming message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. c) Otherwise, any cached information about the outstanding Request message is discarded, and stateReference is set to . d) A SUCCESS result is returned. SNMPv3 Message Processing is complete. 13) If the pduType is a GetRequest-PDU, a GetNextRequest-PDU, a GetBulkRequest-PDU, a SetRequest-PDU, an InformRequest-PDU, then a) If the value of securityEngineID is not equal to the value of snmpEngineID, then the security state information is discarded, any cached information about the outstanding Request message is discarded, the incoming message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. b) Information about the message is cached and a stateReference is created (implementation specific). Information to be cached includes the values of: msgVersion, msgID, securityLevel, msgFlags, msgMaxSize, securityModel, maxSizeResponseScopedPDU, securityStateReference c) A SUCCESS result is returned. SNMPv3 Message Processing is complete. 14) If the pduType is an SNMPv2-Trap-PDU, then A SUCCESS result is returned. SNMPv3 Message Processing is complete. Case/Harrington/Wijnen Expires February 1998 [Page 35] Draft Message Processing and Dispatching for SNMP August 1997 8. Security Considerations The Multi-Lingual Message Processing Model coordinates the processing of messages to provide a level of security for management messages and to direct the SNMP PDUs to the proper SNMP application(s). The level of security actually provided is primarily determined by the specific Security Model implementation(s) and the specific SNMP application implementation(s) incorporated into this framework. Applications have access to data which is not secured. Applications should take reasonable steps to protect the data from disclosure, and when they send data across the network, they should obey the securityLevel and call upon the services of an Access Control Model to apply access control. Case/Harrington/Wijnen Expires February 1998 [Page 36] Draft Message Processing and Dispatching for SNMP August 1997 9. Editor's Addresses Co-editor: Jeffrey Case SNMP Research, Inc. postal: 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA email: case@snmp.com phone: +1-423-573-1434 Co-editor Dave Harrington Cabletron Systems, Inc postal: Post Office Box 5005 MailStop: Durham 35 Industrial Way Rochester NH 03867-5005 USA email: dbh@cabletron.com phone: +1-603-337-7357 Co-editor: Bert Wijnen IBM T. J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-432-794 Case/Harrington/Wijnen Expires February 1998 [Page 37] Draft Message Processing and Dispatching for SNMP August 1997 10. Acknowledgements This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members: Dave Battle (SNMP Research, Inc.) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) T. Max Devlin (Hi-TECH Connections) John Flick (Hewlett Packard) David Harrington (Cabletron Systems Inc.) N.C. Hien (IBM T.J. Watson Research Center) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Russ Mundy (Trusted Information Systems, Inc.) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reid (SNMP Research, Inc.) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Bert Wijnen (IBM T.J. Watson Research Center) The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were: David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center) As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*: Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.) Keith McCloghrie (Cisco Systems) Case/Harrington/Wijnen Expires February 1998 [Page 38] Draft Message Processing and Dispatching for SNMP August 1997 Brian O'Keefe (Hewlett Packard) Marshall T. Rose (Dover Beach Consulting) Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.) Case/Harrington/Wijnen Expires February 1998 [Page 39] Draft Message Processing and Dispatching for SNMP August 1997 11. References [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 January 1996. [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An Architecture for describing SNMP Management Frameworks", draft-ietf-snmpv3-next-gen-arch-04.txt, August 1997. [SNMP-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", draft-ietf-snmpv3-usm-01.txt, August 1997. [SNMP-ACM] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", draft-ietf-snmpv3-acm-02.txt, August 1997. [SNMP-APPL] The SNMPv3 Working Group, Levi, D. B., Meyer, P., Stewart, B., "SNMPv3 Applications", , August 1997 Case/Harrington/Wijnen Expires February 1998 [Page 40] Draft Message Processing and Dispatching for SNMP August 1997 Table of Contents 0. Issues 2 0.1. Resolved Issues 2 0.2. Change Log 3 1. Introduction 6 2. Overview 7 2.1. The Dispatcher. 8 2.2. Message Processing Subsystem 8 3. Elements of Message Processing 9 3.1. messageProcessingModel 9 3.2. pduVersion 9 3.3. pduType 10 3.4. sendPduHandle 10 4. Elements of Procedure 11 4.1. Sending an SNMP Message to the Network 11 4.1.1. Sending a Request or Notification 11 4.1.2. Sending a Response to the Network 12 4.2. Receiving an SNMP Message from the Network 13 4.2.1. Message Dispatching 13 4.2.2. PDU Dispatching for Incoming Messages 14 4.3. Application Registration for Handling PDU types 16 4.3. Application Unregistration for Handling PDU Types 17 5. Definitions 18 5.1. Definitions for SNMP Message Processing and Dispatching 18 6. The SNMPv3 Message Format 21 6.1. msgVersion 22 6.2. msgID 22 6.3. msgMaxSize 22 6.4. msgFlags 22 6.5. msgSecurityModel 24 6.6. msgSecurityParameters 24 6.7. scopedPduData 24 6.8. scopedPDU 24 6.8.1. contextEngineID 25 6.8.2. contextName 25 6.8.3. data 25 7. Elements of Procedure 26 7.1. Prepare an Outgoing SNMP Message 26 7.2. Prepare Data Elements from an Incoming SNMP Message 31 8. Security Considerations 36 9. Editor's Addresses 37 10. Acknowledgements 38 11. References 40 Case/Harrington/Wijnen Expires February 1998 [Page 41]