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]
