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

Versions: 00 01 02 03 04 05 06 rfc2262                                  
              Message Processing Model for version 3 of the
               Simple Network Management Protocol (SNMPv3)

                            11 July 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


                         <pre-release-version>
                  <draft-ietf-snmpv3-v3mpc-model-02.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 SNMP version 3 Message Processing Model
for use in the SNMP architecture [SNMP-ARCH]. It defines the SNMP
version 3 message format, and the procedures for coordinating the
processing of a message in SNMPv3 format.



Case/Harrington/Wijnen         Expires  December 1997              [Page  1]
\
Draft     SNMPv3 Message Processing Model     July 1997


0. Issues
 . Message ::= instead of snmpV3Message ::= ? is this ok?
 . verify the abstract service primitives once more... names
   of primitives and parameters seem to keep changing.
 . Do we need to expand in section 2.2.2.x
 . Do we want the MIB to be a logical extension of the SNMPv2
   MIB? Instead of having our own snmpV3MIB, we could import
   snmp and snmpMIBObjects from the SNMPv2-MIB (RFC1907)        and
   then start assinging the counter from { snmp 33 } onwards.
   We could then also import snmpMIBCompliances and snmpMIBGroups
   from SNMPv2-MIB and define the snmpV3Compliance and snmpV3Group
   under those existing Registration points. Since we link SNMPv3
   MP with RFC1902-1908 anyways, this actually seems better to me.
 . Someone needs to check elements of procedures.
 . acknowledgements needs expansion
 . snmpUnknownPduHandlers needs to be included in elements of procedure
 . should we have one complete snmpV3AllCompliance that includes the
   snmpCompliance from RFC1907? see MIB below.
   Or we could keep two and have snmpV2andV3Compliance
 . must we return the original Request PDU, so the application can
   determine the request that led to an errorIndication? Conceptually
   the SNMP engine needs to also cache the outgoing requests when it
   caches info about a outgoing Request message. Should we describe
   what processResponsePDU() returns in that circumstance.
 . do we want to define snmpCommunityGroup here or under coexistence?
 . should version-selection and application multiplexing elements of
   procedure be described in MP document or Architecture document?
   This is especially problematic considering snmpInPkts and
   snmpInBadVersions counters.

























Case/Harrington/Wijnen         Expires  December 1997              [Page  2]
\
Draft     SNMPv3 Message Processing Model     July 1997


0.1.  Change Log

[version 3.4]
 . 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 consitent 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]



Case/Harrington/Wijnen         Expires  December 1997              [Page  3]
\
Draft     SNMPv3 Message Processing Model     July 1997


 . published as draft-ietf-snmpv3-mpc-model-01.txt
[version 2.1]
    . ?? not sure if there were any changes
[version 2.0]
    . changes as a result of 1st interim meeting
      . some new wording in introduction
      . rewording 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  December 1997              [Page  4]
\
Draft     SNMPv3 Message Processing Model     July 1997


1.  Introduction

The Architecture for describing Internet Management Frameworks
[SNMP-ARCH] is composed of multiple subsystems:
     1) a Message Processing Subsystem,
     2) a Security Subsystem,
     3) 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 version-specific Message
Processing Model 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 Message Processing Subsystem of an SNMP engine interacts with the
SNMP engine, interacts with the Security Subsystem and interacts with
applications. It uses data elements defined by the SNMPv3 Message
Processing Model, within the constraints of the architecture, and
interacts with other models within the constraints of the architecture.

A Message Processing Model has the responsibility for coordinating the
sending and receiving of SNMP messages via the SNMP engine, and for
coordinating the interaction with other subsystems to acquire the
desired services for the processing of an SNMP message.

It is the purpose of this document to define the specific SNMPv3
Message Processing Model.

Other (future) documents can add specific models for Message Processing
of other SNMP versions (like a v1MP and/or a v2cMP) which then fit
into the overall SNMP architecture.





















Case/Harrington/Wijnen         Expires  December 1997              [Page  5]
\
Draft     SNMPv3 Message Processing Model     July 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 | | |
 | | | Command    |  | Notification | +-----------+ +-------------+ | |
 | | | Responder  |  | Receiver     |                               | |
 | | +------------+  +--------------+                               | |
 | +----------------------------------------------------------------+ |
 |               ^           ^              ^           ^             |
 |               |           |              |           |             |
 |               |           |              |           |             |
 |               v           v              v           v             |
 | +----------------------------------------------------------------+ |
 | | Message    | Message Processing Abstract Service Interface |   | |
 | | Processing +-----------------------------------------------+   | |
 | | Subsystem         ^         ^           ^          ^           | |
 | |                   |         |           |          |           | |
 | +--------------+    |         |           |          |           | |
 | +------------+ |    |         |           |          |           | |
 | | Security   | |    |         |           |          |           | |
 | | Subsystem  | |    |         |           |          |           | |
 | |            | |    v         v           v          v           | |
 | |+----------+| | +------+ +---------+ +--------+  +-----------+  | |
 | ||User-based||<->| v3MP | | v2cMP * | | v1MP * |..| otherMP * |  | |
 | ||Security  || | +------+ +---------+ +--------+  +-----------+  | |
 | ||Model     || |    ^         ^           ^            ^         | |
 | |+----------+| |    |         |           |            |         | |
 | |            | +----|---------|-----------|------------|---------+ |
 | +------------+      |         |           |            |           |
 |                     v         v           v            v           |
 |    +----------------------------------------------------------+    |
 |    |   Message Processing Model selection (incoming only)     |    |
 |    +----------------------------------------------------------+    |
 |                           ^                                        |
 |                           |                                        |
 |                           v                                        |
 |    +-----------------------------------------------------------+   |
 |    |       TRANSPORT MAPPING (for example RFC1906)             |   |
 +--------------------------------------------------------------------+




Case/Harrington/Wijnen         Expires  December 1997              [Page  6]
\
Draft     SNMPv3 Message Processing Model     July 1997


2.1. Message Processing Subsystem

The SNMP Message Processing Subsystem is part of an SNMP engine within
an SNMP entity.  It can possibly handle multiple SNMP Message formats
(like the SNMPv1 [RFC1157], SNMPv2c [RFC1901] and SNMPv3 message
formats).  The Message Processing Model selection mechanism receives
and sends messages from/to the network.  For incoming messages, the
SNMP engine determines the specific message format of an incoming SNMP
message and then selects the corresponding version-specific Message
Processing module to further process the SNMP message.  For outgoing
messages, an application specifies which SNMP message format must be
used and based on that the SNMP engine selects the corresponding
version-specific Message Processing module, within the Message
Processing Subsystem, to generate and send the message.
The details of how the SNMP engine selects the proper version-specific
Message Processing module are implementation dependent.

This document defines the SNMP version3 Message Processing (v3MP)
Model and the corresponding SNMPv3 message format.

The SNMP engine and the Message Processing Subsystem, while sending
and receiving SNMP messages, collect statistics about SNMP messages
and the behavior of the SNMP engine.  These statistics are maintained
in managed objects to make them accessible to remote SNMP entities.
For example, the snmpInPkts counter [RFC1907] counts all incoming SNMP
packets regardless of the message format.  The details on how this
is done in a system that supports multiple message formats is outside
the scope of this document.

This document defines the v3MP managed objects, and the MIB module
which contains them.  This document also describes how these managed
objects might be used to provide useful network management.

The v3MP Model is designed to guarantee certain behaviors and to meet
a particular set of requirements.  These goals are met by controlling
the processing of messages, sometimes by defining a fixed behavior
that must be adhered to by a conforming implementation of this model,
sometimes by defining options which can be specified by the user to
cause processing to meet optional requirements.

This document describes how the internal interactions are coordinated
and constrained by the v3MP Model.


2.2.  Message Processing External Interfaces

The SNMPv3 Message Processing Model is a specification of a model of
Message Processing within the Message Processing Subsystem, which
interacts with other subsystems, requesting services from, and
performing services for, those other subsystems.




Case/Harrington/Wijnen         Expires  December 1997              [Page  7]
\
Draft     SNMPv3 Message Processing Model     July 1997



2.2.1.  Message Processing Interface to Security Subsystem

An SNMPv3 Message Processing module interacts with one or more SNMP
Security Models to ensure that the proper security measures
(authentication, timeliness checking, en/decryption) are applied to
the SNMP messages being sent and received.  It uses the abstract
service interface to the Security Model, as defined by the SNMP
architecture, to request services from such a security module.


2.2.2.  Message Processing Abstract Service Interface

When an application wants to send an SNMP PDU, it does so according to
the abstract service interface of the Message Processing Subsystem,
as defined by the SNMP architecture [SNMP-ARCH].

2.2.2.1.  Sending an SNMP Request or Notification

The Message Processing Subsystem provides the following primitive for
an application to send an SNMP Request or Notification to another SNMP
entity:

sendPdu(
    transportDomain             -- transport domain to be used
    transportAddress            -- destination network address
    messageProcessingModel      -- typically, SNMP version
    securityModel               -- Security Model to use
    securityName                -- on behalf of this principal
    LoS                         -- Level of Security requested
    contextEngineID             -- data from/at this entity
    contextName                 -- data from/in this context
    PDU                         -- SNMP Protocol Data Unit
    expectResponse              -- TRUE or FALSE
    )



















Case/Harrington/Wijnen         Expires  December 1997              [Page  8]
\
Draft     SNMPv3 Message Processing Model     July 1997


2.2.2.2.  Registering Responsibility for Handling SNMP PDUs

An application may want to take responsibility for handling a
specific set of SNMP operations, for a specific contextEngineID.
Applications register/unregister responsibility for a specific
contextEngineID, for specific pduTypes, with the Application
Multiplexor according to these primitives:

statusInformation =             -- success or errorIndication
    registerContextEngineID(
        contextEngineID         -- take responsibility for this one
        pduType                 -- the pduType(s) to be registered
        )

unregisterContextEngineID(
        contextEngineID         -- give up responsibility for this one
        pduType                 -- the pduType(s) to be unregistered
        )

2.2.2.3.  Processing an incoming SNMP Request or Notification

Once an incoming message has passed the version-specific Message
Processing (v3MP) and is ready for processing by an application,
then the message is passed to the proper application.  The
Application Multiplexor determines the PDU type and contextEngineID
for the scopedPDU, then determines which application has registered
to handle that PDU type and contextEngineID.

The Application Multiplexor uses the following primitive
to pass an incoming SNMP Response PDU to an application:

processPdu(                     -- process Request/Notification PDU
    contextEngineID             -- data from/at this SNMP entity
    contextName                 -- data from/in this context
    PDU                         -- SNMP Protocol Data Unit
    maxSizeResponseScopedPDU    -- maximum size of the Response PDU
    securityModel               -- Security Model in use
    securityName                -- on behalf of this principal
    LoS                         -- Level of Security
    stateReference              -- reference to state information
    )                           -- needed when sending a response

2.2.2.4.  Sending an SNMP Response

The Message Processing Subsystem provides the following primitive for
an application to return an SNMP Response PDU to a processed SNMP
Request or Notification:

returnResponsePdu(
    contextEngineID             -- data from/at this SNMP entity
    contextName                 -- data from/in this context



Case/Harrington/Wijnen         Expires  December 1997              [Page  9]
\
Draft     SNMPv3 Message Processing Model     July 1997


    PDU                         -- SNMP Protocol Data Unit
    maxSizeResponseScopedPDU    -- maximum size of the Response PDU
    securityModel               -- same as on incoming request
    securityName                -- same as on incoming request
    LoS                         -- same as on incoming request
    stateReference              -- reference to state information
                                -- as presented with the request
    statusInformation           -- success or errorIndication
    )                           -- error counter OID/value if error

2.2.2.5.  Processing an incoming SNMP Response

The Message Processing Subsystem provides the following primitive to
pass an incoming SNMP Response PDU to an application:

processResponsePdu(             -- process Response PDU
    contextEngineID             -- data from/at this SNMP entity
    contextName                 -- data from/in this context
    PDU                         -- SNMP Protocol Data Unit
    LoS                         -- Level of Security
    statusInformation           -- success or errorIndication
    )
































Case/Harrington/Wijnen         Expires  December 1997              [Page 10]


\
Draft     SNMPv3 Message Processing Model     July 1997


3.  The SNMPv3 Message Format

This is the format of an SNMP message for the SNMPv3 Message
Processing Model.

DEFINITIONS ::= BEGIN


    Message ::= SEQUENCE {
        -- administrative parameters (globalData)
        version    INTEGER { snmpv3 (3) },
        msgID      INTEGER (0..2147483647),
        mms        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

        securityModel INTEGER (0..2147483647),

        -- security model-specific parameters
        -- format defined by Security Model
        securityParameters OCTET STRING

        -- local-processing model-specific data
        data  scopedPduData
    }

    scopedPduData ::= CHOICE {
            plaintext scopedPDU,
            encryptedPDU OCTET STRING  -- encrypted value
        }

    scopedPDU ::= SEQUENCE {
            contextEngineID  OCTET STRING
            contextName OCTET STRING
            data
                ANY -- e.g. PDUs as defined in RFC1905
        }
END






Case/Harrington/Wijnen         Expires  December 1997              [Page 11]


\
Draft     SNMPv3 Message Processing Model     July 1997


3.1.  version

The version field is set to snmpv3(3) and identifies the message as
an SNMP version 3 Message.

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

Note that the request-id in the PDU is used by SNMP applications
to identify the request; the msgID is used by the engine to identify
the message which carries a request. The engine may need to identify
the message even if the decryption of the request (and request-id)
fails. No assumption should be made that the value of the msgID and
the value of the request-id are equivalent.

3.3.  mms

The maximum message size supported by the sender of the message.
That is 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 mms is provided by the
SNMP engine which generates the message.  At the receiving SNMP engine
the mms is used to determine how big the Response to a Request message
can be made.

3.4.  msgFlags

The msgFlags field contains flags to control 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 is a Report PDU, a Response PDU, or an
   SNMPv2-trap PDU.

b) reportFlag

   ReportPDUs are engine-to-engine communications and are processed
   directly by the Message Processing model, and are not passed to
   applications for processing, unlike all other PDU types.     The
   reportFlag is set for a Report PDU so the Message Processing Model
   can easily recognize a Report PDU.



Case/Harrington/Wijnen         Expires  December 1997              [Page 12]


\
Draft     SNMPv3 Message Processing Model     July 1997



The authFlag and privFlag in the msgFlags are used to indicate the
Level of Security (LoS) that has been applied to the message before
sending it on the wire.  The same Level of Security should be applied
when the message is received and when the contents of the message is
being processed.  There are 3 Levels of Security, namely noAuthNoPriv,
which is lower than authNoPriv, which is in turn lower than authPriv.
See the SNMP architecture document [SNMP-ARCH] for details about the
Level of Security.

a) authFlag

   If the authFlag is set, then the securityModel in use, must identify
   the securityName on whose behalf an SNMP message is being processed
   or generated and must authenticate such identification.  In
   addition , the contents of the message must be authenticated to
   ensure that:
   - the message was not modified in transit
   - the message was not replayed
   - the message was not redirected

   If the authFlag is not set, then the securityModel in use must
   identify the securityName on whose behalf a request is being
   processed or generated, but it does not need to authenticate such
   identification.  Also there is no need to authenticate the message
   in this case.

b) privFlag

   If the privFlag is set, then the securityModel in use, 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 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 (LoS) as follows:

   authFlag zero and privFlag one  -> invalid combination
   authFlag zero and privFlag zero -> LoS is noAuthNoPriv
   authFlag one  and privFlag zero -> LoS is authNoPriv
   authFlag one  and privFlag one  -> LoS is authPriv







Case/Harrington/Wijnen         Expires  December 1997              [Page 13]


\
Draft     SNMPv3 Message Processing Model     July 1997


3.5.  securityModel

The v3MP supports the concurrent existence of multiple security models
to provide security services for SNMPv3 messages.  The securityModel
identifies which security model should be used to provide security
processing for the message.  The mapping to the appropriate
implementation within an SNMP engine is done in an implementation
dependent manner.

3.6.  securityParameters

The securityParameters filed is used for communication between the
Security Model modules in the sending and receiving SNMP engines.
This data 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
securityModel field in the message.

3.7.  scopedPduData

The scopedPduData 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.





























Case/Harrington/Wijnen         Expires  December 1997              [Page 14]


\
Draft     SNMPv3 Message Processing Model     July 1997


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

3.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 cpontextID is used to determine to which
application the scopedPDU should be sent for processing.

For outgoing messages, the v3MP just sets the contextEngineID as
provided by the application that requests for a message to be sent.

3.8.2. contextName

This is a locally unique name for a context, within the SNMP entity
specified by the contextEngineID, which may realize the managed
objects referenced within the PDU.  An application uses the
contextName during processing.

The v3MP, for outgoing messages, just set the contextName as provided
by the application that requests for a message to be sent.

3.8.3. data

The data contains the PDU.  The PDU contains the PDU type that is also
used by the v3MP to determine the type of incoming SNMP message.
The v3MP specifies that the PDU must be one of those specified in
[RFC1905].



















Case/Harrington/Wijnen         Expires  December 1997              [Page 15]


\
Draft     SNMPv3 Message Processing Model     July 1997


4. Elements of Procedure

This section describes the procedures followed by an SNMP engine when
processing SNMP messages according to the SNMPv3 Message Processing
Model.

4.1.  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 some steps
might be done in the SNMP engine itself, specifically if the
implementations supports multiple Message Processing Models.  Yet
the complete procedure is described here, so that for a single-version
implementation, the complete elements of procedure are in one place.

Please note, that in order to not make the procedures too complicated,
we do not always explicitly say when state information needs to be
released.  The general rule is, that if state information is available
when a message gets discarded for further processing, that at that
time the state information must also be released.

1)  The snmpInPkts counter [RFC1907] is incremented.  That is if
    such has not been done yet by a possible Message Processing
    Model selection process in the SNMP engine.

2)  If the received message is not the serialization (according to
    the conventions of [RFC1906]) of a Message value, then the
    snmpInASNParseErrs counter [RFC1907] is incremented, and the
    message is discarded without further processing.

3)  The values for the various message components are extracted
    from the message.

4)  If the value of the version component has a value other than 3
    then the message is either processed according to some other
    version-specific Message Processing Model, or the
    snmpInBadVersions counter [RFC1907] is incremented (that is if
    not yet done by a possible Message Processing Model selection
    process in the SNMP engine), and the message is discarded without
    further processing.

5)  If the value of the securityModel component does not match a
    supported securityModel, then the snmpUnknownSecurityModels
    counter is incremented, a Report PDU is generated and the
    message is discarded without further processing.

6)  The Level of Security (LoS) is determined from the msgFlags
    component as follows:
    a) if neither the authFlag nor the privFlag is set, then the LoS
       is set to noAuthNoPriv.




Case/Harrington/Wijnen         Expires  December 1997              [Page 16]


\
Draft     SNMPv3 Message Processing Model     July 1997


       Otherwise,

    b) If the authFlag is set and the privFlag is zero, then the LoS
       is set to authNoPriv.

       Otherwise,

    c) If the authFlag is set and the privFlag is set, then the LoS
       is set to authPriv.

       Otherwise,

    d) The snmpInvalidMsgFlags counter is incremented, a Report PDU
       is generated and the message is discarded without further
       processing.

7)  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:

     processMsg(
         messageProcessingModel     -- typically, SNMP version
         msgID                      -- of the received message
         mms                        -- of the sending SNMP entity
         msgFlags                   -- for the received message
         securityParameters         -- for the received message
         securityModel              -- for the received message
         LoS                        -- Level of Security
         wholeMsg                   -- as received on the wire
         wholeMsgLength             -- length as received on the wire
         )

    The security module returns the results according to the abstract
    service interface primitive:

     returnProcessedMsg(
         securityName               -- identification of the principal
         scopedPDU,                 -- message (plaintext) payload
         maxSizeResponseScopedPDU   -- maximum size of a Response PDU
         securityStateReference     -- reference to security state
                                    -- information, needed for response
         statusInformation          -- errorIndication or success
         )                          -- error counter OID/value if error

    If an errorIndication is returned by the security module, then
    a Report PDU is generated with the returned errorCounter in the
    varBindList, and the message is discarded without further
    processing.





Case/Harrington/Wijnen         Expires  December 1997              [Page 17]


\
Draft     SNMPv3 Message Processing Model     July 1997


8)  If the reportFlag in the msgFlags component is set, then the
    scopedPDU is parsed.

    a) If the PDU is not a Report PDU, then the message is discarded
       without further processing.  This also means that any possible
       security state information is discarded.

       Otherwise,

    b) The errorCounter is inspected to determine the cause for the
       Report PDU.  The value of the msgID component is used to
       determine from the list of outstanding SNMP messages, which
       application is to be posted with an errorIndication.  If no
       such outstanding SNMP message is found, then the message is
       discarded without further processing.  This also means that
       any possible security state information is discarded.

       Otherwise,

    c) The application is informed according to the abstract service
       primitive:

        processResponsePdu(            -- process Response PDU
            contextEngineID            -- data from/at this SNMP entity
            contextName                -- data from/in this context
            PDU                        -- SNMP Protocol Data Unit
            LoS                        -- Level of Security
            statusInformation          -- success or errorIndication
            )

       Any cached information about the message, generated by this SNMP
       engine, with the same msgID as the value of the msgID component
       is discarded.  This includes any possible security state
       information.  Processing of the message is complete as far as
       the Message Processing module is concerned.


9)  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, a report PDU
    is generated, and the message is discarded without further
    processing.  This also means that any possible security state
    information is discarded.











Case/Harrington/Wijnen         Expires  December 1997              [Page 18]


\
Draft     SNMPv3 Message Processing Model     July 1997


10) The message type is determined (how is an implementation issue)
    to be either a Response message or a Request or Notification
    message.

    a) If this is a Response message, then the value of the msgID
       component is used to determine from the list of outstanding
       SNMP messages, which application is to process the Response PDU.

       1) If no such outstanding SNMP message is found, then the
          message is discarded without further processing.  This also
          means that any possible  security state information is
          discarded.

          Otherwise,

       2) The Response PDU is passed to the application according to
          the abstract service primitive:

           processResponsePdu(         -- process Response PDU
               contextEngineID         -- data from/at this SNMP entity
               contextName             -- data from/in this context
               PDU                     -- SNMP Protocol Data Unit
               LoS                     -- Level of Security
               statusInformation       -- success or errorIndication
               )

          Any cached information about the message, generated by this
          SNMP engine, with the same msgID as the value of the msgID
          component is discarded.  This includes any possible security
          state information.  Processing of the message is complete as
          far as the Message Processing module is concerned.

       Otherwise,

    b) If this is a Request message or a Notification message, then
       it is determined which application should process the message.
       This is based on the PDU type and the list of applications and
       their registered contextEngineIDs.

       1) If no such application can be found because none registered
          for the contextEngineID, then the snmpUnknownContextEngineIDs
          counter is incremented, a Report PDU is generated, and the
          message is discarded without further processing.  This also
          means that any possible security state information is
          discarded.

          Otherwise,

       2) If no such application can be found for other reasons,
          then the snmpUnknownApplications counter is incremented,
          a Report PDU is generated, and the message is discarded



Case/Harrington/Wijnen         Expires  December 1997              [Page 19]


\
Draft     SNMPv3 Message Processing Model     July 1997


          without further processing.  This also means that any
          possible security state information is discarded.


          Otherwise,

       3) Information about the message is cached and a stateReference
          is created (implementation specific).  Information to be
          cached includes:

             value version component,
             value msgID component,
             value of LoS,
             value of msgFlags component,
             value of mms component,
             value of securityModel component,
             value of maxSizeResponseScopedPDU,
             securityStateReference

11) The SNMP PDU is passed to the selected application according to
    the abstract service interface primitive:

     processPdu(                   -- process Request/Notification PDU
         contextEngineID           -- data from/at this SNMP entity
         contextName               -- data from/in this context
         PDU                       -- SNMP Protocol Data Unit
         maxSizeResponseScopedPDU  -- maximum size of the Response PDU
         securityModel             -- Security Model in use
         securityName              -- on behalf of this principal
         LoS                       -- Level of Security
         stateReference            -- reference to state information
         )                         -- needed when sending a response

    Processing of the message is complete.  The application processes
    the PDU and when done will return a Response PDU using the
    abstract service interface primitive:


     returnResponsePdu(
         contextEngineID           -- data from/at this SNMP entity
         contextName               -- data from/in this context
         PDU                       -- SNMP Protocol Data Unit
         maxSizeResponseScopedPDU  -- maximum size of the Response PDU
         securityModel             -- same as on incoming request
         securityName              -- same as on incoming request
         LoS                       -- same as on incoming request
         stateReference            -- reference to state information
                                   -- as presented with the request
         statusInformation         -- success or errorIndication
         )                         -- error counter OID/value if error




Case/Harrington/Wijnen         Expires  December 1997              [Page 20]


\
Draft     SNMPv3 Message Processing Model     July 1997


    The v3MP procedures for this returned Response PDU are described
    in section 4.2.


4.2.  Sending an SNMP Message to the Network

This section describes the procedure followed by an SNMP engine
whenever it must send an SNMP message.  There are three ways that can
cause a message to be sent:

  - An application wants an SNMP PDU to be sent to another (remote)
    application. The application can request this according to the
    abstract service primitive:

     sendPdu(
         transportDomain             -- transport domain to be used
         transportAddress            -- destination network address
         messageProcessingModel      -- typically, SNMP version
         securityModel               -- Security Model to use
         securityName                -- on behalf of this principal
         LoS                         -- Level of Security requested
         contextEngineID             -- data from/at this entity
         contextName                 -- data from/in this context
         PDU                         -- SNMP Protocol Data Unit
         expectResponse              -- TRUE or FALSE
         )

  - An application wants a response to be sent back to the originator
    of an SNMP Request.  This means that this is the resulting
    response of step 11) of section 4.1.

  - A Report PDU needs to be send as the result of a v3MP internal
    detection of a problem, or as the result of a security module or
    an application returning statusInformation which contains an
    errorIndication and the OID and value of an (incremented) error
    counter.

The following elements of procedures are followed to generate the
SNMP message according to the SNMPv3 message format.

1)  a) If the request to send a message is caused by the sendPdu
       primitive, then:

       1) If the messageProcessingModel has a value other than 3, then
          the request is either processed according to some other
          version-specific Message Processing Model, or an error
          (implementation specific) is returned to the calling
          application.

          Otherwise,




Case/Harrington/Wijnen         Expires  December 1997              [Page 21]


\
Draft     SNMPv3 Message Processing Model     July 1997


       2) The parameters are verified to be valid and supported by the
          SNMPv3 Message Processing module.  If not, then an error
          (implementation specific) is returned to the calling
          application.

          Otherwise,

       3) All parameters are valid; use these values in the process:
          - expectResponse switch as passed by application.
          - a unique msgID is generated.  It is best to use
            unpredictable numbers for the msgID.
          - msgFlags are set as follows:
            - if LoS specifies noAuthNoPriv, then authFlag and
              privFlag are both set to zero.
            - if LoS specifies authNoPriv, then authFlag is set
              to one and privFlag is set to zero.
            - If LoS specifies authPriv, then authFlag is set to
              one and privFlag is set to one.
            - If expectResponse is TRUE, then the reportableFlag is
              set to one otherwise it is set to zero.
            - All other msgFlags bits are set to zero.
          - the transportDomain and transportAddress as passed by the
            application.

       Otherwise,

    b) If the request to send a message is caused by the
       returnResponsePdu primitive, then:

       1) The parameters are verified to be valid and are in accordance
          with the cached state information pointed to by the
          stateReference parameter.  If not, then an (implementation
          specific) error is returned to the calling application.

          Otherwise:

       2) If the statusInformation indicates an error that should
          cause a Report PDU, then a Report PDU is constructed with
          a varBindList that contains the OID and value of the
          increment error counter that was returned; continue with
          step 1.c.

          Otherwise,

       3) If the statusInformation indicates noError then this is a
          Response PDU and all parameters are valid; then use these
          values in the process:
          - expectResponse switch is FALSE.
          - msgID as is obtained via stateReference
          - msgFlags are set as follows:
            - if LoS specifies noAuthNoPriv, then authFlag and



Case/Harrington/Wijnen         Expires  December 1997              [Page 22]


\
Draft     SNMPv3 Message Processing Model     July 1997


              privFlag are both set to zero.
            - if LoS specifies authNoPriv, then authFlag is set
              to one and privFlag is set to zero.
            - If LoS specifies authPriv, then authFlag is set to
              one and privFlag is set to one.
            - All other msgFlags bits are set to zero.
          - the transportDomain and transportAddress as saved in the
            state information.


    c) If the request to send a message is caused by a Report PDU, then
       the internal v3MP process passes the proper parameters that are
       needed in the following steps:
          - expectResponse switch is FALSE.
          - msgID as in the received message or from the state
            information
          - msgFlags are set as follows:
            - If the Report PDU is cause by a notInTimeWindow error
              then the authFlag is set to one, otherwise it is set
              to zero.
            - The reportFlag is set to one.
            - all other msgFlags bits are set to zero.
          - the transportDomain and transportAddress as in the
            received message or as saved in the state information.

2)  The version component of the message is set to snmpv3 (3).

3)  The mms is set to an implementation defined value within the range
    allowed by the definition of mms in section 3.

4)  The msgFlags are set as specified in step 1.

5)  The securityModel is set to the securityModel as specified or as
    obtained from the state information.

6)  An SNMP message is to be generated by the security module. The
    securityModel is used to determine which Security Model to use.

    a) If the expectResponse switch is TRUE, then an SNMP Response
       message is to be generated. The security module is called
       according to the abstract service interface primitive:

        generateResponseMsg(
            messageProcessingModel      -- typically, SNMP version
            msgID                       -- for the outgoing message
            mms                         -- of the sending SNMP entity
            msgFlags                    -- for the outgoing message
            securityParameters          -- filled in by Security Module
            securityModel               -- for the outgoing message
            scopedPDU                   -- message (plaintext) payload
            securityStateReference      -- reference to security state



Case/Harrington/Wijnen         Expires  December 1997              [Page 23]


\
Draft     SNMPv3 Message Processing Model     July 1997


                                        -- information, as received in
            )                           -- processPdu primitive

       Otherwise,

    b) If the expectResponse switch is FALSE, then an SNMP Response
       message is to be generated. The security module is called
       according to the abstract service interface primitive:

        generateRequestMsg(
            messageProcessingModel      -- typically, SNMP version
            msgID                       -- for the outgoing message
            mms                         -- of the sending SNMP entity
            msgFlags                    -- for the outgoing message
            securityParameters          -- filled in by Security Module
            securityModel               -- for the outgoing message
            securityName                -- on behalf of this principal
            LoS                         -- Level of Security requested
            snmpEngineID                -- authoritative SNMP entity
            scopedPDU                   -- message (plaintext) payload
            )

7)  Upon completion of the security processing, the security module
    returns a completed message according to the abstract service
    interface primitive:

      returnGeneratedMsg(
          wholeMsg                  -- complete generated message
          wholeMsgLength            -- length of the generated message
          statusInformation         -- errorIndication or success
          )

    a) If the statusInformation returns an errorIndication, then an
       errorIndication is returned to the calling application or
       v3MP internal function.

       Otherwise,

    b) The generated message is sent over the transport specified by
       the transportDomain to the address specified by the
       transportAddress.

    Processing is complete as far as the Message Processing module
    is concerned.


4.3.  Application Registration for Handling PDU types

Applications that want to process certain PDUs must register with the
Message Processing Subsystem and specify which contextEngineID and
which PDU types they want to take responsibility for.



Case/Harrington/Wijnen         Expires  December 1997              [Page 24]


\
Draft     SNMPv3 Message Processing Model     July 1997



The following procedures are followed for this registration process.

1)  An application registers according to the abstract interface
    primitive:

     statusInformation =          -- success or errorIndication
         registerContextEngineID(
             contextEngineID      -- take responsibility for this one
             pduType              -- the pduType(s) to be registered
             )


2)  The parameters are checked to be valid; if not an errorIndication
    (invalidParameter) is returned to the application.

3)  a) If the contextEngineID is equal to the snmpEngineID of the
       processing SNMP engine, then only one application can register
       for each pduType.

       1) If another application already registered, then an
          errorIndication (alreadyRegistered) is returned to the
          application.

          Otherwise,

       2) The registration is saved so that SNMP messages with a
          payload that matches the registered contextEngineID and
          pduType(s) can be dispatched to this application.

    b) If the contextEngineID is not equal to the snmpEngineID of the
       processing SNMP engine, then the registration is saved so that
       SNMP messages with a payload that matches the registered
       contextEngineID and pduType(s) can be dispatched to this
       application.


4.3.  Application Unregistration for Handling Payloads (PDUs)

Applications that no longer want to process certain PDUs must
unregister with the Message Processing Subsystem and specify which
contextEngineID and which PDU types they no longer want to take
responsibility for.

The following procedures are followed for this unregistration process.

1)  An application unregisters according to the abstract interface
    primitive:

     unregisterContextEngineID(
             contextEngineID    -- give up responsibility for this one



Case/Harrington/Wijnen         Expires  December 1997              [Page 25]


\
Draft     SNMPv3 Message Processing Model     July 1997


             pduType            -- the pduType(s) to be unregistered
             )

2)  The parameters are checked to be valid; if not the request is
    ignored.

3)  a) If the contextEngineID and pduType combination have indeed
       been registered, then the registration is deleted.

    b) If nu such registration exists, then the request is ignored.












































Case/Harrington/Wijnen         Expires  December 1997              [Page 26]


\
Draft     SNMPv3 Message Processing Model     July 1997


5.  Definitions

5.1.  Definitions for the SNMPv3 Message Processing Model

SNMPv3-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-COMPLIANCE, OBJECT-GROUP         FROM SNMPv2-CONF
    MODULE-IDENTITY, OBJECT-TYPE,
    snmpModules, Counter32                  FROM SNMPv2-SMI;

snmpV3MIB MODULE-IDENTITY
    LAST-UPDATED "9707110000Z"              -- 11 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 Rd
                              Glenwood MD 21738
                              USA
                  email:      mundy@tis.com
                  phone:      +1-301-854-6889

                  Co-editor:  Dr. Jeffrey Case
                              SNMP Research, Inc.
                  postal:     3001 Kimberlain Heights Rd
                              Knoxville, TN 37920-9716
                              USA
                  email:      case@snmp.com
                  phone:      +1-615-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  December 1997              [Page 27]


\
Draft     SNMPv3 Message Processing Model     July 1997



                 "
    DESCRIPTION  "The MIB for the SNMPv3 Message Processing Model"
    ::= { snmpModules 8 }  -- check if assignment is OK

-- Administrative assignments ****************************************

snmpV3Admin           OBJECT IDENTIFIER ::= { snmpV3MIB 1 }
snmpV3MIBObjects      OBJECT IDENTIFIER ::= { snmpV3MIB 2 }
snmpV3MIBConformance  OBJECT IDENTIFIER ::= { snmpV3MIB 3 }

-- Statistics for SNMPv3 Message Processing Model ********************

snmpV3Stats           OBJECT IDENTIFIER ::= { snmpV3MIBObjects 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.
                "
    ::= { snmpV3Stats 1 }

snmpInvalidMsgFlags 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 msgFlags
                 component of the message specified invalid flags.
                "
    ::= { snmpV3Stats 2 }

snmpUnknownContextEngineIDs 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
                 contextEngineID that was not known to the SNMP engine
                 e.g. was not registered by any application.
                "
    ::= { snmpV3Stats 3 }

snmpUnknownApplications OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only



Case/Harrington/Wijnen         Expires  December 1997              [Page 28]


\
Draft     SNMPv3 Message Processing Model     July 1997


    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMP
                 engine which were dropped because they could not be
                 passed to an application for undefined reasons.
                "
    ::= { snmpV3Stats 4 }

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 they referenced a
                 contextEngineID that was known, but no application
                 has registered for the received pduType (yet).
                "
    ::= { snmpV3Stats 5 }

-- Conformance information *******************************************

snmpV3MIBCompliances OBJECT IDENTIFIER ::= { snmpV3MIBConformance 1 }
snmpV3MIBGroups      OBJECT IDENTIFIER ::= { snmpV3MIBConformance 2 }

-- Compliance statements

snmpV3Compliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP entities which
                 implement the SNMPv3-MIB.
                "

    MODULE    -- this module
        MANDATORY-GROUPS { snmpV3Group }

    ::= { snmpV3MIBCompliances 1 }


snmpV3AllCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP entities which
                 implement the SNMPv2-MIB and the SNMPv3-MIB.
                "

    MODULE    -- this module
        MANDATORY-GROUPS {
-- must import following before we can reference them
--                         snmpGroup, snmpSetGroup, systemGroup,
--                         snmpBasicNotificationsGroup,
                           snmpV3Group
                         }




Case/Harrington/Wijnen         Expires  December 1997              [Page 29]


\
Draft     SNMPv3 Message Processing Model     July 1997


    ::= { snmpV3MIBCompliances 2 }


snmpV2cAndV3Compliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP entities which
                 implement the SNMPv2-MIB and the SNMPv3-MIB.
                "

    MODULE    -- this module
        MANDATORY-GROUPS {
-- must import following before we can reference them
--                         snmpGroup, snmpSetGroup, systemGroup,
--                         snmpBasicNotificationsGroup,
                           snmpV3Group
                         }

--      GROUP    snmpCommunityGroup
--      DESCRIPTION "This group is mandatory for SNMP entities that
--                   support Community-based authentication.
--                  "

    ::= { snmpV3MIBCompliances 3 }

snmpV3Group OBJECT-GROUP
    OBJECTS {
              snmpUnknownSecurityModels,
              snmpUnknownContextEngineIDs,
              snmpInvalidMsgFlags,
              snmpUnknownApplications,
              snmpUnknownPduHandlers
            }
    STATUS       current
    DESCRIPTION "A collection of objects providing for remote
                 monitoring of an implementation of the SNMPv3
                 Message Processing Model.
                "
    ::= { snmpV3MIBGroups 1 }

END














Case/Harrington/Wijnen         Expires  December 1997              [Page 30]


\
Draft     SNMPv3 Message Processing Model     July 1997


6. Security Consideration

The SNMPv3 Message Processing Model coordinates the processing of
messages to provide a level of security for network management
messages and to direct the SNMP Message payload 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 LoS and
call upon an Access Control Model services to apply access control.








































Case/Harrington/Wijnen         Expires  December 1997              [Page 31]


\
Draft     SNMPv3 Message Processing Model     July 1997


7. 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 1905, 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 Internet Management Frameworks",
     draft-ietf-snmpv3-next-gen-arch-03.txt, July 1997.

[SNMPv3-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-01.txt, July 1997.

[SNMPv3-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B.
     "User-Based Security Model for version 3 of the Simple Network
     Management Protocol (SNMPv3)",
     draft-ietf-snmpv3-usm-00.txt, July 1997.










Case/Harrington/Wijnen         Expires  December 1997              [Page 32]


\
Draft     SNMPv3 Message Processing Model     July 1997


8. Editor's Addresses

   Co-editor:  Dr. Jeffrey Case
               SNMP Research, Inc.
   postal:     3001 Kimberlain Heights Rd
               Knoxville, TN 37920-9716
               USA
   email:      case@snmp.com
   phone:      +1-615-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  December 1997              [Page 33]


\
Draft     SNMPv3 Message Processing Model     July 1997


9. Acknowledgements

This document builds on the work of the SNMP Security and
Administrative Framework Evolution team, comprised of

    David Harrington (Cabletron Systems Inc.)
    Jeff Johnson (Cisco)
    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)









































Case/Harrington/Wijnen         Expires  December 1997              [Page 34]


\
Draft     SNMPv3 Message Processing Model     July 1997


Table of Contents

0. Issues                                                             2
0.1.  Change Log                                                      3
1.  Introduction                                                      5
2. Overview                                                           6
2.1. Message Processing Subsystem                                     7
2.2.  Message Processing External Interfaces                          7
2.2.1.  Message Processing Interface to Security Subsystem            8
2.2.2.  Message Processing Abstract Service Interface                 8
2.2.2.1.  Sending an SNMP Request or Notification                     8
2.2.2.2.  Registering Responsibility for Handling SNMP PDUs           9
2.2.2.3.  Processing an incoming SNMP Request or Notification         9
2.2.2.4.  Sending an SNMP Response                                    9
2.2.2.5.  Processing an incoming SNMP Response                       10
3.  The SNMPv3 Message Format                                        11
3.1.  version                                                        12
3.2.  msgID                                                          12
3.3.  mms                                                            12
3.4.  msgFlags                                                       12
3.5.  securityModel                                                  14
3.6.  securityParameters                                             14
3.7.  scopedPduData                                                  14
3.8.  scopedPDU                                                      15
3.8.1. contextEngineID                                               15
3.8.2. contextName                                                   15
3.8.3. data                                                          15
4. Elements of Procedure                                             16
4.1.  Receiving an SNMP Message from the Network                     16
10) The message type is determined (how is an implementation issue)  19
11) The SNMP PDU is passed to the selected application according to  20
4.2.  Sending an SNMP Message to the Network                         21
4.3.  Application Registration for Handling PDU types                24
4.3.  Application Unregistration for Handling Payloads (PDUs)        25
5.  Definitions                                                      27
5.1.  Definitions for the SNMPv3 Message Processing Model            27
6. Security Consideration                                            31
7. References                                                        32
8. Editor's Addresses                                                33
9. Acknowledgements                                                  34
















Case/Harrington/Wijnen         Expires  December 1997              [Page 35]