Internet Draft
               Message Processing and Control Model for
                           version 3 of the
               Simple Network Management Protocol (SNMPv3)

                            17 June 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-01.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 and
Control Model for use in the SNMP architecture [SNMP-ARCH]. This
model defines the SNMP version 3 message format, and the procedure
for coordinating the processing of a message in SNMPv3 format.




Harrington/Case         Expires November 1977        [Page  1]
\
Draft              SNMPv3 Message Processing and Control model        May 1997
























































Harrington/Case         Expires November 1977        [Page  2]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


0. Issues
 . Interactions with Applications needs more synchronization with
      SNMPv3 applications (orangelets) document
   I am using "applications" instead of "orangelets". DaveL c.s.
       are talking about applications and not about orangelets
 . Interactions with Security Model needs more synchronization with
      SNMPv3 USEC document. Statistics counters have already been
      moved to this MPC document and have now generic names that
      should fit any security model.
 . Do we need to keep the security threats in section 5?
 . Should statistics counters from ACM be moved to MPC ??
      Bert thinks YES.
 . Need to check the SNMP-MPC-MIB with a MIB compiler
 . Need to decide if we want to enumerate Security and Application
      status Codes, so that we can document in which case a specific
      statsCounter gets incremented and a reportPDU gets sent.
      Could decide that such is implementation matter.
 . acknowledgements needs expansion
 . sendRequestPdu() primitive
      should we allow the application to pass stateReference
         which the MPC could save with its state info about an
         outstanding SNMP request message, so that when it returns
         the response message it can pass back a stateReference that
         the application can use to correlate a response to a request.
 . scopedPDU defines contextEngineID as SIZE(0|12). Do we need 0?
 . should the architecture require that all message formats have
    the version number first?
 . should globalData parameters be expanded in primitive?
 . should we use the name primitive, or call them abstract service
   interfaces?
 . when matching a response to the outstanding requests, what
   info must be checked? msgID, contextEngineID? Does the MPC need
   to look at the verb directly?

0.1. Change Log

[version 2.1]
 . spell-check
 . removed references to groupName
 . replaced discussion of threats with reference to [SNMP-ARCH]
 . moved unresolved co-editor questions into Issues list
 . worked on improving consistency internally and with other documents
 . changed errorCode, errorStatus, etc to statusCode.
 . modified 4.7.1. discussion 
 . published as draft-ietf-snmpv3-mpc-model-01.txt

[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



Harrington/Case         Expires November 1977        [Page  3]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


      . 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
      . Bert added as editor ( thank you for the help, bert - dbh )












































Harrington/Case         Expires November 1977        [Page  4]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


1. Introduction

The Architecture for describing Internet Management Frameworks
is composed of multiple subsystems:
     1) a message processing and control subsystem,
     2) a security subsystem,
     3) an access control subsystem, and
     4) orangelets.

It is important to understand the SNMP architecture and the
terminology of the architecture to understand where the 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 and Control subsystem of an SNMP engine
interacts with the network using SNMP messages, interacts with
applications using data elements defined by the Message Processing
and Control model, within the constraints of the Architecture, and
interacts with other models within the constraints of the architecture.

A Message Processing and Control model has the responsibility for
coordinating the sending and receiving of SNMP messages, and for
coordinating the interaction with other subsystems to acquire the
desired services for the processing of a message.

It is the purpose of this document to define:
  - the overall MPC Model, including the MPC Selection and
    the MPC Multiplexing Layer
  - a specific model of Message Processing and Control subsystem,
    designated the SNMP version 3 Message Processing and Control
    (v3MPC) model.

Other (future) documents can add specific models of an MPC for
other SNMP versions (like a v1MPC and/or a v2cMPC) which then
fit into the overall MPC model described in this document.

















Harrington/Case         Expires November 1977        [Page  5]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


2. Overview

The following illustration depicts the MPC:

              MPC External Interface
+----------------------------------------------+
|                 MPC SELECTION                |
+----------------------------------------------+
    ^            ^             ^
    |            |             |
    v            v             v
+-------+    +--------+    +-------+
| v1MPC |    | v2cMPC |    | v3MPC |   .   .   .
+-------+    +--------+    +-------+
    ^            ^             ^
    |            |             |
    v            v             v
+----------------------------------------------+
|             MULTIPLEXING LAYER               |
+----------------------------------------------+
        MPC Abstract Service Interface


2.1. MPC External Interface

The SNMP Message Processing and Control model is part of an SNMP
meesageEngine which interacts with the network. It can possibly handle
multiple SNMP Message formats (like the SNMPv1 [RFC1157], SNMPv2c 
[RFC1901] and SNMPv3 message formats). The MPC Selection mechanism 
receives and sends messages from/to the network. For incoming messages 
it determines the specific message format of an incoming SNMP message 
and then selects the corresponding version-specific MPC module to 
further process the SNMP message.

The transport mappings for sending and receiving messages are defined
in [RFC1906].

This document defines the SNMP version 3 MPC (v3MPC) model and the
corresponding SNMPv3 message format. Other documents may specify
additional version-specific MPC models.

The MPC model, while sending and receiving SNMP messages, collects
statistics about SNMP messages and the behavior of the SNMP engine.
These statistics are maintained in managed objects to make it
accessible to remote SNMP engines. This document will define the
managed objects, and the MIB module which contains them. This
document will also describe how these managed objects might be used
to provide useful network management.

2.2. MPC Abstract Service Interface




Harrington/Case         Expires November 1977        [Page  6]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


The SNMP Message Processing and Control model is a specification
of a subsystem within an SNMP messageEngine which interacts with other
subsystems, requesting services from, and performing services for,
those other subsystems.

The v3MPC module interacts with one or more SNMPv3 Security Models
to ensure that the proper security measures (authentication, timeliness
checking, en/decryption) are applied to the 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.

The v3MPC is designed to guarantee certain behaviors and to
meet a particular set of requirements. It will attempt to achieve
its goals 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 developer or by the user to cause processing 
to meet optional requirements.

This document describes how the internal interactions are
coordinated and constrained by the v3MPC model.

Once an incoming message has passed the version-specific MPC processing
(like the v3MPC processing) and is ready for processing by an
application, the MPC uses a Multiplexing Layer which hides the
differences between the various message formats of the different SNMP
versions. It uses the abstract service interface to the applications,
as defined by the SNMP architecture, to request or provide services
from or to the applications.
























Harrington/Case         Expires November 1977        [Page  7]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


3. Transport Mappings

The MPC model recognizes the transport mappings defined in RFC 1906,
and may support additional transport mappings defined in other
documents.

During installation, an SNMP engine acting in an agent role is
configured with one or more transport service addresses

    These parameters may be specified explicitly, or they may be
    specified implicitly as the same set of network-layer addresses
    configured for other uses by the device together with the well-
    known transport-layer "port" information for the appropriate
    transport domain [RFC1906]. The agent listens on each of these
    transport service addresses for messages.







































Harrington/Case         Expires November 1977        [Page  8]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


4. The SNMPv3 message format

This is the format of a message to be processed by the v3MPC.

DEFINITIONS ::= BEGIN

snmpV3Message ::= SEQUENCE {
        -- administrative parameters (globalData)
        version    INTEGER { snmpv3 (3) },
        msgID      INTEGER (0..2147483647),
        mms        Integer32 (484..2147483647),

        msgFlags OCTET STRING (SIZE(1)),
                   --  .... ..00   noAuth/noPriv
                   --  .... ..01   auth/noPriv
                   --  .... ..10   auth/priv
                   --  .... ..11   reserved
                   --  .... .1..   reportableFlag
                   --  .... 1...   reportFlag

        securityModel SnmpSecurityModel,

        -- security model-specific parameters
        -- format defined by Security Model
        securityParameters OCTET STRING (SIZE(0..2048)),

        -- local-processing model-specific data
        data  ScopedPduData
    }

    ScopedPduData ::= CHOICE {
            plaintext ScopedPDU,
            encrypted OCTET STRING    -- encrypted value
        }

    scopedPDU ::= SEQUENCE {
            contextEngineID  OCTET STRING (SIZE(0|12)),
            contextName OCTET STRING (SIZE(0..32)),
            data
                ANY -- e.g. PDUs as defined in RFC1905
        }
END

4.1. SNMP version

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

4.2. msgID

The msgID is used by the v3MPC to coordinate the processing of the



Harrington/Case         Expires November 1977        [Page  9]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


message by different subsystem models within the architecture.

Note that the request-id [RFC1905] used during local processing
identifies the request, not the message that carried the request,
and therefore might not be equal to the msgID.

4.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 a request message is being generated, the MMS is provided by
the engine which generates the message. When a response message is
being generated, the MMS from the request message is used by the v3MPC
to determine the maximum size that is acceptable to send.

4.4. msgFlags

The msgFlags field contains flags to control the processing of the
message.

If the reportableFlag is set, then reportPDUs are allowed to be
returned to the sender under those conditions which cause the
generation of reportPDUs. If the reportableFlag is zero, then a
reportPDU must not be sent. The reportableFlag should always be zero
when the message is a report, a response, or a trap.

The reportFlag is set for report-PDUs so that the v3MPC can recognize
such a reportPDU and process it internally.

It is the v3MPC module that generates and processes reportPDUs.

If the auth flag is set, then the security implementation is required
to identify the securityIdentity on whose behalf a request is generated
and to authenticate such identification. If the auth flag is zero,
authentication of the securityIdentity is not required.

If the priv flag is set, then the security implementation is required
to protect the data within an SNMP operation from disclosure, i.e. to
encrypt the data. If the priv flag is zero, then the security
implementation does not need to protect the data using encryption.

It is an explicit requirement of the SNMP Architecture that if privacy
is selected, then authentication of the identification is required,
i.e. priv flag can only be set if auth flag is also set.

The combination of the auth flag and the priv flag comprises a Level
of Security (LoS), as defined in [SNMP-ARCH].




Harrington/Case         Expires November 1977        [Page 10]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


4.5. securityModel

The v3MPC supports the concurrent existence of multiple security
models to provide security services for snmpV3Messages. 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 messageEngine is done
in an implementation-dependent manner.

4.6. security parameters

This octet string is not interpreted by the v3MPC. This abstract data
element is used by the v3MPC to transfer security-model-specific data
from the snmpV3Message to the security subsystem model indicated by the
securityModel field in the message. This data is used exclusively by
the security model, and the contents and format of the data is defined
by the security model.

4.7. scopedPDU

A scopedPDU contains a PDU and information to identify an
administratively unique context. The object identifiers
in the PDU refer to managed objects which are expected to be
accessible within the specified context.

4.7.1. contextEngineID

A contextEngineID is the unique identifier of the SNMP contextEngine
that has access to the managed objects referenced in the PDUs.

The v3MPC will compare the contextEngineID to the registered
contextEngineIDs to determine to which application the scopedPDU
should be forwarded.

4.7.2. contextName

This is the name of the locally-unique context, within the engine
specified by the contextEngineID, which realizes the managed objects
referenced within the PDUs.

4.7.3. data

The data contains the PDUs. The v3MPC specifies that the PDUs are
those as specified in RFC1905.










Harrington/Case         Expires November 1977        [Page 11]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


5. Services of the SNMP Message Processing and Control Model

5.1. Services of the MPC Selection process

5.1.1. Receiving an SNMP message from the network

The MPC Selection process when it receives an SNMP message from the
network first increments the snmpInPkts counter [RFC1907]. 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.

The MPC Selection process determines the SNMP version of an incoming
message. If the version is not supported by this SNMP messageEngine
(e.g. there is no version-specific MPC for this version) then the
snmpInBadVersions counter [RFC1907] is incremented, and the message
is discarded without further processing.

Based on the SNMP version of the message, the MPC passes the message
on to the appropriate version-specific MPC. Before doing so, it caches
the origin network address information, so that a possible response
can be sent back to the sender of the message.

5.1.2. Sending an SNMP message onto the network

The MPC Selection process gets called by the version-specific MPC
to send an SNMP message onto the network to a specified destination.

The MPC selection process sends the message to the specified
destination. It then advises the calling version-specific MPC
about the success or failure of the sending of the message.

5.2. Services of the v3MPC Model

5.2.1. Interacting with a Security Model to Protect against Threats

Several of the classical threats to network protocols are applicable
to the network management problem and therefore would be applicable
to any SNMP security model. These are described in [SNMP-ARCH].

5.2.1.1. Receive SNMPv3 messages from the network

Upon receipt of an SNMPv3 message from the network (passed to the
v3MPC by the MPC Selection process), this SNMPv3 Message Processing
and Control model extracts and caches the version, msgID, MMS,
and the msgFlags, determines the LoS, and determines where the block
of security parameters start in the message.

The v3MPC, in an implementation-defined manner, establishes a
mechanism for coordinating processing regarding this received



Harrington/Case         Expires November 1977        [Page 12]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


message, e.g. it may assign a "handle" to the message and it's
cached data.

The SNMPv3 Message Processing and Control model passes the various
header fields. the LoS, the whole message and it's length, and the
block of security parameters to the implementation of the Security
Model specified in the message header. The abstract service interface
for this is:

      processMsg(version, msgID, mms, msgFlags,
                 securityModel, securityParameters,
                 LoS, wholeMsg, wholeMsgLen)

The Security Model, after completion of its processing, returns to
the Message Processing and Control implementation a status code and,
if the message passed all security checks, a MIID, 
a cachedSecurityDataReference, a scopedPDUmms, and the scopedPDU
itself. The abstract service interface for this is:

      returnMsg(MIID, cachedSecurityDataReference,
                scopedPDUmms, scopedPDU, statusCode)

In the event of an error in security processing (as indicated by the
statusCode), the v3MPC module updates the proper error counter,
generates a reportPDU and discards the message without further
processing.

If successful, the v3MPC adds the cachedSecurityDataReference
to it's set of cached information.

If the reportFlag is set, then the v3MPC assumes that this is an 
SNMPv3 error report and parses the reportPDU. It then takes 
appropriate action (like resending the request in case of a 
notInTimeWindows report or advising the original application about 
a failed request).

If the reportFlag is not set, then the v3MPC determines if this 
message is a response to an outstanding request. To do so it checks 
if there is an outstanding request message for the msgID and
contextEngineID contained in the message.

The v3MPC passes this message, together with an indication if this
is a response message or not, to the MPC Multiplexing layer,
which will determine what to do with the payload of the message.
If this is a response message, then any cached data for this msgID
is discarded, the message processing part of the transaction
is complete.

If the Multiplexing layer returns an error in the statusCode, then
an appropriate reportPDU is generated and the message (including
any cached data) is discarded without further processing.



Harrington/Case         Expires November 1977        [Page 13]
\
Draft              SNMPv3 Message Processing and Control model        May 1997



5.2.1.2. Send SNMPv3 messages to the network

The MPC Multiplexing Layer passes a request to the v3MPC to be sent
out as an SNMPv3 message. The v3MPC interacts with the SNMPv3
Security Model to secure the outgoing message. There are 2 types
of SNMPv3 messages to consider:

  a. An SNMP request or notification. In this case, the abstract
     service interface is:

          generateRequestMsg(version, msgID, mms, msgFlags,
                             securityModel, securityParameters,
                             LoS, MIID, engineID, scopedPDU)

     The v3MPC module fills out the globalData of the SNMPv3 message
     before calling upon the generateRequestMsg service. It does so
     as follows:
          - the version is set to snmpv3 (3).
          - a unique msgID is generated. It is best to use random
            numbers for the msgID.
          - the mms is set to the value of snmpEngineMaxMessageSize.0
          - the msgFlags are set:
            - the auth and priv flags are set according to the LoS
              requested.
            - the reportableFlag is set to 1
            - the other bits of the msgFlags octet are set to zero.
          - the securityModel is set to SnmpV3UsecModel

  b. An SNMP response. In this case, the abstract service interface is:

          generateResponseMsg(version, msgID, mms, msgFlags,
                              securityModel, securityParameters,
                              scopedPDU, cachedSecurityDataReference)

     The v3MPC module fills out the global data based on the cached
     information it saved from the incoming request to which this is
     a response. The cachedSecurityDataReference is also picked up
     from that cache.

The Security Model will construct the message, and return the completed
message to the Message Processing and Control model. The abstract
service interface is:

     returnGeneratedMsg(wholeMsg, wholeMsgLen, statusCode)

If the statusCode indicates success, then the v3MPC passes the
completed message to the MPC Selection process for sending it to
the destination. If the sending of the message succeeds, then the
MPC Multiplexing Layer is advised that the sending of the SNMP
message was successful.



Harrington/Case         Expires November 1977        [Page 14]
\
Draft              SNMPv3 Message Processing and Control model        May 1997



If the statusCode indicates an error, or if the actual sending of the
message failed, then the MPC Multiplexing Layer is advised that the
sending of the SNMP message failed.

If the message is a request, then the msgID, the target snmpEngineID
and the target contextEngineID are saved in a cache, so that when a
response is received, it can be matched up to an outstanding
request.

5.3. Services of the MPC Multiplexing Layer

5.3.1. Application Registration for handling payloads (PDUs)

Applications must register, with the MPC multilexing layer, the 
contextEngineIDs for which they wish to receive PDUs delivered
in asynchronous messages.
The abstract interfaces for this are:

       boolean register_contextEngineID(contextEngineID)

       unregister_contextEngineID(contextEngineID)

Only one application can register to provide asynchronous support
for a contextEngineID. If a second one tries to register
then a FAILED error code is returned. Otherwise a SUCCESS code is
returned.

The unregister primitive does not return an error code. If unregister
primitive is called for a non-registered contextEngineID, then the
request is ignored.

5.3.2. Sending the payload of an SNMP Message to an application

The MPC Model determines by which application a scopedPDU should 
be processed.

If the message is a response to an outstanding request, then the
response is passed to the application that issued the request.
The abstract service interface for that is:

   processResponsePdu(contextEngineID, contextName, PDU, LoS,
                      status_code)

If the message is not a response to an outstanding request,
the MPC checks, in an implementation-dependent manner,
which application registered for the contextEngineID contained
in the scoped PDU. If no application registered for it, then
the snmpMPCUnknownContextEngineIDs counter is incremented and an
statusCode is returned to the calling version-specific MPC.




Harrington/Case         Expires November 1977        [Page 15]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


Otherwise the registered application is called to handle the
scopedPDU. The abstract service interface is:

   processPdu(contextEngineID, contextName, PDU, PDU-MMS,
              LoS, securityModel, MIID, stateReference)

When such an application finishes processing the PDU they must return
a statusCode and possibly a response. The abstract service interface 
is:

   returnPdu(contextEngineID, contextName, PDU, LoS,
             stateReference, statusCode)

If the statusCode indicates an error, then the stateReference data
is discarded, a possible error counter is incremented and the error
code is passed on to the version-specific MPC for further processing.

5.3.3. Applications sending SNMP requests

When an application wants to send an SNMP request to another SNMP
engine, it can call upon the services of the MPC Multiplexing Layer.
The abstract service interface is:

   sendRequestPdu(TDomain, TAddress, snmpVersion,
                  LoS, securityModel, MIID, contextEngineID,
                  contextName, PDU)


The MPC keeps state information about where the request came from and
then passes the message up to the version-specific MPC for further
processing.

When an application wants to send an SNMP message that will not 
result in an SNMP response message (like a trap), it can call upon 
the services of the MPC Multiplexing Layer. The abstract service 
interface is:

   sendPdu(TDomain, TAddress, snmpVersion,
           LoS, securityModel, MIID, contextEngineID,
           contextName, PDU)

The MPC passes the message on to the version-specific MPC and then
discards the information.











Harrington/Case         Expires November 1977        [Page 16]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


6. Definitions

6.1. Definitions for the SNMP Message Processing and Control Model

SNMP-MPC-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, snmpModules,
    Counter32                                  FROM SNMPv2-SMI;
    TEXTUAL-CONVENTION, 
    TDomain, TAddress                          FROM SNMPv2-TC;
    MODULE-COMPLIANCE, OBJECT-GROUP            FROM SNMPv2-CONF;
    snmpEngineID, SnmpSecurityModel, 
    SnmpAdminString                            FROM IMF-MIB;


snmpMPCMIB MODULE-IDENTITY
    LAST-UPDATED "9706170000Z"     -- 17 June 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
                  email:      mundy@tis.com
                  phone:      301-854-6889

                  Co-editor:  Dr. Jeffrey Case
                              Snmp Research International, Inc.
                  postal:
                  phone:

                  Co-editor   Dave Harrington
                              Cabletron Systems, Inc
                  postal:     Post Office Box 5005
                              MailStop: Durham
                              35 Industrial Way
                              Rochester NH 03867-5005
                  email:      dbh@cabletron.com
                  phone:      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



Harrington/Case         Expires November 1977        [Page 17]
\
Draft              SNMPv3 Message Processing and Control model        May 1997



                 "
    DESCRIPTION  "The snmp MPC MIB"
    ::= { snmpModules xx }

-- Administrative assignments

snmpMPCMIBObjects      OBJECT IDENTIFIER ::= { snmpMPCMIB 1 }
snmpMPCMIBConformance  OBJECT IDENTIFIER ::= { snmpMPCMIB 2 }

-- Statistics for MPC Model ******************************************

snmpMPCStats           OBJECT IDENTIFIER ::= { snmpMPCMIBObjects 1 }

snmpMPCStatsUnknownContextEngineIDs 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 engine
                 (e.g. was not registered by any application).
                "
    ::= { snmpMPCStats 1 }

snmpMPCStatsUnsupportedLoS 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 requested a
                 Level of Security that was unknown to the engine or
                 otherwise unavailable.
                "
    ::= { snmpMPCStats 2 }

snmpMPCStatsNotInTimeWindows 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 appeared
                 outside of the engine's window.
                "
    ::= { snmpMPCStats 3 }

snmpMPCStatsUnknownSecurityIdentities OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMP



Harrington/Case         Expires November 1977        [Page 18]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


                 engine which were dropped because they referenced a
                 security model specific securityIdentity that was
                 not known to the engine.
                "
    ::= { snmpMPCStats 4 }


snmpMPCStatsAuthenticationErrors 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 could not be
                 authenticated (i.e. the MAC did not match).
                "
    ::= { snmpMPCStats 5 }

snmpMPCStatsPrivacyErrors 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 could not be
                 decrypted.
                "
    ::= { snmpMPCStats 6 }

-- Conformance information

snmpMPCMIBCompliances  OBJECT IDENTIFIER ::=
                                 { snmpMPCMIBConformance 1 }
snmpMPCMIBGroups       OBJECT IDENTIFIER ::=
                                 { snmpMPCMIBConformance 2 }


-- Compliance statements

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

    MODULE    -- this module
        MANDATORY-GROUPS { snmpMPCBasicGroup }

    ::= { snmpMPCMIBCompliances 1 }

snmpMPCBasicGroup OBJECT-GROUP
    OBJECTS {
              snmpMPCStatsUnknownContextEngineIDs,



Harrington/Case         Expires November 1977        [Page 19]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


              snmpMPCStatsUnsupportedLoS,
              snmpMPCStatsNotInTimeWindows,
              snmpMPCStatsUnknownSecurityIdentities,
              snmpMPCStatsAuthenticationErrors,
              snmpMPCStatsPrivacyErrors
            }
    STATUS       current
    DESCRIPTION "A collection of objects providing for remote monitoring
                 of an implementation of an SNMP Message Processing and
                 Control model.
                "
    ::= { snmpMPCMIBGroups 1 }

END








































Harrington/Case         Expires November 1977        [Page 20]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


7. Security Consideration

The SNMP Message Processing and Control 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.

The level of security actually provided is primarily determined by
the specific Security Model implementations and the specific
SNMP application implementations 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 the Access Control Model services to apply access control.








































Harrington/Case         Expires November 1977        [Page 21]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


8. Glossary

LoS 
MIID
MMS
MPC
PDU
SNMP
ScopedPDU
ScopedPduData
SnmpAdminString
SnmpSecurityModel
SnmpV3UsecModel
TAddress
TDomain
USEC
auth
cachedSecurityDataReference
contextEngine
contextEngineID
contextName
engineID
generateRequestMsg
generateResponseMsg
globalData
meesageEngine
messageEngine
MIID
mms
msgFlags
msgID
noAuth
noPriv
notInTimeWindows
orangelets
plaintext
priv
processMsg
processPdu
processResponsePdu
reportFlag
reportPDU
reportPDUs
reportableFlag
responsePDU
returnGeneratedMsg
returnMsg
returnPdu
scopedPDU
scopedPDUmms
securityIdentity



Harrington/Case         Expires November 1977        [Page 22]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


securityModel
securityParameters
sendPdu
sendRequestPdu
snmpEngineID
snmpEngineMaxMessageSize.0
snmpModules
snmpV3Message
snmpV3Messages
snmpVersion
snmpv3
stateReference
statsCounter
statusCode
v1MPC - an MPC model designed to be compatible with RFC1157 
v2cMPC - an MPC model designed to be compatible with RFC1901 
v3MPC - the MPC model described in this document
wholeMsg - a complete message 
wholeMsgLen - the length of a complete message



































Harrington/Case         Expires November 1977        [Page 23]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


9. 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 Internet Management Frameworks",
     draft-ietf-snmpv3-next-gen-arch-02.txt, June 1997.

[SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D.,
     "Message Processing and Control Model for version 3 of the Simple
     Network Management Protocol (SNMPv3)",
     draft-ietf-snmpv3-mpc-01.txt, June 1997.

[SNMPv3-ACM] The SNMPv3 Working Group, Wijnen, B., Harrington, D.,
     "Access Control Model for Version 3 of the Simple Network
     Management Protocol (SNMPv3)", draft-ietf-snmpv3-acm-00.txt,
     June 1997.

[SNMPv3-USEC] 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-usec-01.txt, June 1997.





Harrington/Case         Expires November 1977        [Page 24]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


10. Editor's Addresses

   Co-editor:  Dr. Jeffrey Case
               Snmp Research International, Inc.
   postal:
   email:      case@snmp.com
               phone:

   Co-editor   Dave Harrington
               Cabletron Systems, Inc
   postal:     Post Office Box 5005
               MailStop: Durham
               35 Industrial Way
               Rochester NH 03867-5005
   email:      dbh@cabletron.com
   phone:      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






























Harrington/Case         Expires November 1977        [Page 25]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


11. 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)









































Harrington/Case         Expires November 1977        [Page 26]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


Table of Contents

0. Issues                                                              3
0.1. Change Log                                                        3
1. Introduction                                                        5
2. Overview                                                            6
2.1. MPC External Interface                                            6
2.2. MPC Abstract Service Interface                                    6
3. Transport Mappings                                                  8
4. The SNMPv3 message format                                           9
4.1. SNMP version                                                      9
4.2. msgID                                                             9
4.3. MMS                                                              10
4.4. msgFlags                                                         10
4.5. securityModel                                                    11
4.6. security parameters                                              11
4.7. scopedPDU                                                        11
4.7.1. contextEngineID                                                11
4.7.2. contextName                                                    11
4.7.3. data                                                           11
5. Services of the SNMP Message Processing and Control Model          12
5.1. Services of the MPC Selection process                            12
5.1.1. Receiving an SNMP message from the network                     12
5.1.2. Sending an SNMP message onto the network                       12
5.2. Services of the v3MPC Model                                      12
5.2.1. Interacting with a Security Model to Protect against Threats   12
5.2.1.1. Receive SNMPv3 messages from the network                     12
5.2.1.2. Send SNMPv3 messages to the network                          14
5.3. Services of the MPC Multiplexing Layer                           15
5.3.1. Application Registration for handling payloads (PDUs)          15
5.3.2. Sending the payload of an SNMP Message to an application       15
5.3.3. Applications sending SNMP requests                             16
6. Definitions                                                        17
6.1. Definitions for the SNMP Message Processing and Control Model    17
7. Security Consideration                                             21
8. Glossary                                                           22
9. References                                                         24
10. Editor's Addresses                                                25
11. Acknowledgements                                                  26

















Harrington/Case         Expires November 1977        [Page 27]