[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc2262                                  
               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



                  <draft-ietf-snmpv3-v3mpc-model-03.txt>


                           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 <none>, 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 <none>, 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 <none>, 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 <none>

    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 <none>.

    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",
     <draft-ietf-snmpv3-appl-01.txt>, 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]