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

                            9 May 1997


                               J. Case
                         Snmp Research Inc.
                            case@snmp.com

                              D. Harrington
                          Cabletron Systems, Inc.
                             dbh@cabletron.com


                  <draft-ietf-snmpv3-v3mpc-model-00.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 SNMPng architecture [SNMPng]. 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


0. Issues
    . Interactions with Applications needs clarification and
      simplification following decision of whether agent is an
      application.
    . discussion of application requirements for snmpv3 messaging;
      this is dependent on architecture decisions re: applications
    . discussion of access control applied or not applied for
      messages generated for a local application
    . acknowledgements needs expansion

0.1.  Change Log

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



















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


1. Introduction

The architecture for the Next-Generation of the Simple Network
Management Protocol (SNMPng) is composed of multiple subsystems,
1) a message processing and control subsystem, 2) a security subsystem,
3) a local processing subsystem, and applications.

It is important to understand the SNMPng architecture and the
terminology of the architecture to understand where the model
described in this document fits into the architecture and interacts
with other models within the architecture. The reader is expected to
have read and understood the description of the SNMPng architecture,
as defined in [SNMPng].

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 a specific model of
Message Processing and Control subsystem, designated the SNMP
version 3 Message Processing and Control (v3MPC) model.


























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


2. Overview

2.1. Engine External Interactions

The snmpv3 Message Processing and Control model is part of an SNMP
engine which interacts with the network and with applications. This
document will define the format of the data used during those
interactions.

This document will define the format of SNMP messages which the
v3MPC model is prepared to process, some of the transport mappings
which it supports for sending and receiving messages, some specific
formats of the data transferred between the v3MPC and applications
in abstract data elements, and will define some additional
requirements to be met during interaction with the network and with
applications.

The v3MPC 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. Engine Internal Interactions

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

The v3MPC will be 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 user to cause processing to meet optional
requirements.

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












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


3. Transport Mappings

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

During installation, an SNMPng entity 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 13. The agent listens on each of these
    transport service addresses for messages.







































Harrington/Case         Expires November 1977        [Page  5]
\
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
        version     INTEGER { snmpv3 (3) },
        msgID      INTEGER(0..2147483647),
        mms          SnmpNgMms,

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

        securityModel INTEGER(0..2147483647),

        -- 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  6]
\
Draft              SNMPv3 Message Processing and Control model        May 1997


message by different subsystem models within the architecture.

Note that the requestID [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.

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. 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 the agent is done in an
implementation-dependent manner.

4.5. 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 reportPDU, a responsePDU, or a trapPDU.

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 SNMPng Framework 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 [SNMPng-ARCH].




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


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 engine
that realizes the managed objects referenced in the PDUs.

The v3MPC will compare the contextEngineID to its own snmpV3EngineID
to determine whether the scopedPDU should be processed by the snmpv3
Local Processing model, or should be forwarded to an application
for processing.

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 Local Processing Model defines the
content and format of the PDUs.


















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


5. Services of the SNMPv3 Message Processing and Control Model

5.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 SNMPng security model.  Other threats are not applicable to
the network management problem.  This section discusses principal
threats, secondary threats, and threats which are of lesser
importance.

The principal threats against which any security model used with
the snmpv3 Message Processing and Control model must provide
protection are:

Modification of Information
     The modification threat is the danger that some unauthorized
     entity may alter in-transit SNMPv3 messages generated on behalf
     of an authorized securityIdentity in such a way as to effect
     unauthorized management operations, including falsifying the
     value of an object.

Masquerade
     The masquerade threat is the danger that management operations not
     authorized for some securityIdentity may be attempted by assuming
     the identity of another securityIdentity that has the appropriate
     authorizations.

Two secondary threats are also identified, for which a security
model used by the snmpv3 Message Processing and Control model should
provide protection:

Message Stream Modification
     The SNMPv3 protocol is typically based upon a connectionless
     transport service which may operate over any subnetwork service.
     The re-ordering, delay or replay of messages can and does occur
     through the natural operation of many such subnetwork services.
     The message stream modification threat is the danger that messages
     may be maliciously re-ordered, delayed or replayed to an extent
     which is greater than can occur through the natural operation of a
     subnetwork service, in order to effect unauthorized management
     operations.

Disclosure
     The disclosure threat is the danger of eavesdropping on the
     exchanges between SNMP engines. Protecting against this threat
     may be required as a matter of local policy.

There are at least two threats that a security model used by an
snmpv3 Message Processing and Control model need not protect against.




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


Denial of Service
     A security model need not attempt to address the broad range of
     attacks by which service on behalf of authorized users is denied.
     Indeed, such denial-of-service attacks are in many cases
     indistinguishable from the type of network failures with which any
     viable network management protocol must cope as a matter of
     course.

Traffic Analysis
     A security model need not attempt to address traffic analysis
     attacks.  Many traffic patterns are predictable - agents may be
     managed on a regular basis by a relatively small number of
     management stations - and therefore there is no significant
     advantage afforded by protecting against traffic analysis.

5.1.1. Receive SNMP messages from the network

Upon receipt of an SNMPv3 message from the network, this Message
Processing and Control model will extract the MMS, and the msgFlags,
determine the LoS, and will determine where the block of security
parameters start in the message.

The v3MPC will, in an implementation-defined manner, establish a
mechanism for coordinating all processing regarding this received
message, e.g. it may assign a "handle" to the message.

The Message Processing and Control model will pass the MMS, the LoS,
the message, and the block of security parameters to the implementation
of the Security Model specified in the message header.

The Security Model, after completion of its processing, will return to
the Message Processing and Control implementation the GroupName, the
securityCookie, the scopedPDU-MMS, and the scopedPDU.

In the event of an error in security processing, an errorCode may be
returned instead.

5.1.2. Send SNMP messages to the network

The Message Processing and Control model will pass to the Security
Model a scopedPDU, the securityCookie, and the administrative
parameters to be included in the message.

The Security Model will construct the message, and return the completed
message to the Message Processing and Control model, which will send
the message to the desired address using the appropriate transport.

5.2. Determination of How to Direct a ScopedPDU

The v3MPC Model determines whether a scopedPDU should be processed
by the current engine or by an application. If a received message



Harrington/Case         Expires November 1977        [Page 10]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


contains a scopedPDU with a contextEngineID matching the engineID of
the current engine, then the scopedPDU should be passed to the Local
Processing Model implementation for processing.

If the MPC Model determines that the contextEngineID does not match the
engineID of the current engine, then the message parts are passed to
an application for processing, using the application-interface defined
by the architecture.

The v3MPC Model always passes a complete scopedPDU between subsystems,
i.e. it never passes less than the complete list of varbinds.

5.3. Interacting with a Local Processing Model to Access MIB Data

5.3.1. Access Control

For security reasons, it is often valuable to be able to restrict the
access rights of some management applications to only a subset of the
management information in the management domain.
In addition to restricting access rights by identifying (sub-)sets of
management information, it is also valuable to restrict the requests
allowed on the management information within a particular context.

An administration's access policy determines the access rights of
groups of securityIdentities.

The enforcement of access rights requires the means to identify the
securityIdentity on whose behalf a request has been generated, and
the GroupName of the group to which the securityIdentity is assigned
for purposes of applying access control during the processing of the
received request.

Local Processing models used by the snmpv3 Message Processing and
Control model must include the provision of access control
mechanism(s) which include the ability to restrict access to a subset
of the management domain, to restrict the requests allowed on the
management information within a particular context, and to allow
the use of groups to specify access policy.

5.3.2. Coordinate the Local Processing of a Received Request Message

The MPC will receive the SNMP message according to the process
described in 5.1.1.

The Message Processing and Control implementation will compare the
contextEngineID in the scopedPDU with its snmpV3EngineID. If they m
atch, the MPC will forward the scopedPDU to the Local Processing
implementation. The MPC will pass the scopedPDU, the GroupName, and
the scopedPDU-MMS provided by the Security Model implementation, plus
the LoS, to the Local Processing implementation.




Harrington/Case         Expires November 1977        [Page 11]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


It will accept a completed scopedPDU containing the responsePDU
from the LP-I, and generate a response message according to the
process described in 5.1.2.

5.4. Interacting with Local Applications

5.4.1. Forward Received Request Message to an Application

The MPC will receive the SNMP message according to the process
described in 5.1.1.

The MPC will determine whether a scopedPDU in a received message
contains a contextEngineID which differs from its snmpV3EngineID.
If it does differ, the MPC will assign an implementation-defined
handle to the message. The MPC will determine the SNMP
version, the securityModel, the MMS, and the LoS. It will pass to the
application the handle, the SNMP version, MMS, LoS, plus the
securityCookie provided by the Security Model implementation.

An Application, using the securityCookie, can determine the
securityIdentity on whose behalf the response should be processed.

5.4.2. Forward Received Response Message to an Application

The MPC will receive the SNMP message according to the process
described in 5.1.1.

The MPC will pass to the application the LoS, the MMS,
the securityCookie, the scopedPDU-MMS, and the scopedPDU.

An Application, using the securityCookie, can determine the
securityIdentity on whose behalf the response should be processed.

5.4.3. Forward Received Notification Message to an Application

The MPC will receive the SNMP message according to the process
described in 5.1.1.

The MPC will pass to the application the LoS, the MMS, the
securityCookie, the scopedPDU-MMS, and the scopedPDU.

An Application, using the securityCookie, can determine the
securityIdentity on whose behalf the notification should be processed.

5.4.4. Send a Request Message for an Application

The MPC will receive a request for the generation of a request message
from an application. The application has the responsibility for
providing the Destination Address, the SNMP version, the LoS desired,
the securityCookie to use, a scopedPDU containing the desired
operation, and a handle used for matching up an incoming response to



Harrington/Case         Expires November 1977        [Page 12]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


the application making the request.

The MPC skips local processing of the scopedPDU.

The MPC sends the message according to the process described
in 5.1.2.

5.4.5. Send a Response Message for an Application

The MPC will receive a request for the generation of a response message
from an application. The application has the responsibility for
providing the Destination Address, the SNMP version, the LoS desired,
the securityCookie to use, and a scopedPDU containing the desired
operation.

The MPC skips local processing of the scopedPDU.

The MPC sends the SNMP message according to the process
described in 5.1.2.

5.4.6. Send a Notification Message for an Application

The MPC will receive a request for the generation of a notification
message from an application. The application has the responsibility for
providing the Destination Address, the SNMP version, the LoS desired,
the securityCookie to use, a scopedPDU containing the desired
operation, and, for an inform, a handle used for matching up an
incoming response to the application making the request.

The MPC skips local processing of the scopedPDU.

The MPC sends the SNMP message according to the process
described in 5.1.2.





















Harrington/Case         Expires November 1977        [Page 13]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


6. Definitions

6.1. Definitions for the SNMPv3 Message Processing and Control Model

snmpV3MPC-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, snmpModules  FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, TestAndIncr,
    RowStatus, AutonomousType, StorageType,
    TDomain, TAddress                          FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP            FROM SNMPv2-CONF;
    SnmpNgEngineID, SnmpNgMms,
    SnmpNgSecurityModel, SnmpNgLoS,
    SnmpNgGroupName, SnmpNgContextName            FROM SNMPng-ARCH;


snmpV3MPCMIB MODULE-IDENTITY
    LAST-UPDATED "9704260000Z"     -- 26 Apr 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
                 "
    DESCRIPTION  "The snmpV3 MPC MIB"
    ::= { snmpModules xx }

-- Administrative assignments

snmpV3MPCMIBObjects      OBJECT IDENTIFIER ::= { snmpV3MPCMIB 1 }



Harrington/Case         Expires November 1977        [Page 14]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


snmpV3MPCMIBConformance  OBJECT IDENTIFIER ::= { snmpV3MPCMIB 2 }



-- MIB objects implemented by the SNMPv3 MPC ******************

snmpV3EngineID   OBJECT-TYPE
    SYNTAX       SnmpNgEngineID
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The SNMPv3 engine's administratively-unique
                 identifier.
                "
    ::= { snmpV3MPCMIBObjects 1 }

snmpV3EngineMms   OBJECT-TYPE
    SYNTAX       SnmpNgMms
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The maximum length in octets of an SNMPv3 message
                 which this engine will accept using any
                 transport mapping.
                "
    ::= { snmpV3MPCMIBObjects 2 }


-- Conformance information

snmpV3MPCMIBCompliances  OBJECT IDENTIFIER ::=
                                 { snmpV3MPCMIBConformance 1 }
snmpV3MPCMIBGroups       OBJECT IDENTIFIER ::=
                                 { snmpV3MPCMIBConformance 2 }


-- Compliance statements

snmpV3MPCMIBCompliance MODULE-COMPLIANCE
    STATUS current
    DESCRIPTION
          "The compliance statement for SNMPng entities which
           implement the SNMPv3 MPC MIB.
          "

    MODULE  -- this module
        MANDATORY-GROUPS { snmpV3MPCBasicGroup }

    ::= { snmpV3MPCMIBCompliances 1 }

snmpV3MPCBasicGroup OBJECT-GROUP
    OBJECTS { snmpV3EngineID,
              snmpV3EngineMms



Harrington/Case         Expires November 1977        [Page 15]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


            }
    STATUS  current
    DESCRIPTION
          "A collection of objects providing for remote configuration
           of an implementation of an SNMPv3 Message Processing and
           Control model.
          "
    ::= { snmpV3MPCMIBGroups 1 }

END












































Harrington/Case         Expires November 1977        [Page 16]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


7. Security Consideration

The SNMPv3 Message Processing and Control model coordinates the
processing of messages to provide a level of security for network
management messages and controlled access to data.

The level of security actually provided is primarily determined by
the specific Security Model implementation(s) and the specific Local
Processing Model 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.











































Harrington/Case         Expires November 1977        [Page 17]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


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


[SNMPng-ARCH] The SNMPng Working Group, Harrington, D., Wijnen, B.,
     "Architectural Model for the Next Generation Simple Network
     Management Protocol (SNMPng)", draft-ietf-snmpng-arch-00.txt,
     March 1997.

[SNMPng-LPM] The SNMPng Working Group, Wijnen, B., Harrington, D.,
     "Local Processing Model for the Next Generation Simple Network
     Management Protocol (SNMPng)", draft-ietf-snmpng-lpm-00.txt,
     March 1997.

[SNMPng-USEC] To be written
     The SNMPng Working Group, Editors...Names,
     "The User-Based Security Model for the Next Generation Simple
     Network Management Protocol (SNMPng)",
     draft-ietf-snmpng-usec-00.txt, April 1997.







Harrington/Case         Expires November 1977        [Page 18]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


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






































Harrington/Case         Expires November 1977        [Page 19]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


10. 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 20]


\
Draft              SNMPv3 Message Processing and Control model        May 1997


Table of Contents

0. Issues                                                              2
0.1.  Change Log                                                       2
1. Introduction                                                        3
2. Overview                                                            4
2.1. Engine External Interactions                                      4
2.2. Engine Internal Interactions                                      4
3. Transport Mappings                                                  5
4. The SNMPv3 message format                                           6
4.1. SNMP version                                                      6
4.2. msgID                                                             6
4.3. MMS                                                               7
4.4. securityModel                                                     7
4.5. msgFlags                                                          7
4.6. security parameters                                               8
4.7. scopedPDU                                                         8
4.7.1. contextEngineID                                                 8
4.7.2. contextName                                                     8
4.7.3. data                                                            8
5. Services of the SNMPv3 Message Processing and Control Model         9
5.1 Interacting with a Security Model to Protect against Threats       9
5.1.1. Receive SNMP messages from the network                         10
5.1.2. Send SNMP messages to the network                              10
5.2. Determination of How to Direct a ScopedPDU                       10
5.3. Interacting with a Local Processing Model to Access MIB Data     11
5.3.1. Access Control                                                 11
5.3.2. Coordinate the Local Processing of a Received Request Message  11
5.4. Interacting with Local Applications                              12
5.4.1. Forward Received Request Message to an Application             12
5.4.2. Forward Received Response Message to an Application            12
5.4.3. Forward Received Notification Message to an Application        12
5.4.4. Send a Request Message for an Application                      12
5.4.5. Send a Response Message for an Application                     13
5.4.6. Send a Notification Message for an Application                 13
6. Definitions                                                        14
6.1. Definitions for the SNMPv3 Message Processing and Control Model  14
7. Security Consideration                                             17
8. References                                                         18
9. Editor's Addresses                                                 19
10. Acknowledgements                                                  20















Harrington/Case         Expires November 1977        [Page 21]