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 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]