Message Processing and Dispatching for the
Simple Network Management Protocol (SNMP)
1 August 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-03.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 Message Processing and Dispatching for
SNMP messages within the SNMP architecture [SNMP-ARCH]. It defines the
procedures for dispatching potentially multiple versions of SNMP
messages to the proper SNMP Message Processing Models, and for
dispatching PDUs to SNMP applications. This document also describes
one Message Processing Model - the SNMPv3 Message Processing Model.
Case/Harrington/Wijnen Expires February 1998 [Page 1]
Draft Message Processing and Dispatching for SNMP August 1997
0. Issues
0.1. Resolved Issues
. contextEngineID in reportPDU = snmpEngineID of report generator
. returnResponsePDU - are all parameters needed? overrides allowed?
all parameters kept for future flexibility
overrides not supported by SNMPv3
. use of IN/OUT indicators in primitives accepted
. NT/Unix-like access control - can be defined as future model
. user-friendly names? yes, but with limits
. SnmpAdminString as index? yes, but restrict sizes
. need both MMS and maxSizeResponseScopedPDU? yes.
. synchronous vs. asynchronous primitives? synchronous preferred
. should we change MIB naming? no, it is acceptable
. is it ok that USM is bound to SNMPv3? while undesirable, it is
acceptable. A cleaner model may be defined in the future.
. should securityModel "any" be supported? for ACM use, not SNMPv3
. what defines SNMPv3? a document will be published after Munich
. Is an application-level handle needed for request/response matching?
yes. create sendPduhandle
. Is wildcard conextEngineID/pduType registration needed? No. This is
an internal interface, and wildcarding can be supported by an
implementation, but is not required in the standard.
. Should indices be integers or SnmpAdminStrings? SnmpAdminStrings
is the consensus.
. Should protocols be identified as OIDs or Integers? OIDs
. terminology:
securityLevel rather than LoS
msgXXXX to identify message fields in SNMPv3
Case/Harrington/Wijnen Expires February 1998 [Page 2]
Draft Message Processing and Dispatching for SNMP August 1997
0.2. Change Log
[version 4.12]
. formatting
. pagination
[version 4.11]
. moved Issues to resolved following consensus, as listed above
. remove expectResponse from processIncomingMsg (it doesn't work)
. add securityEngineID
. acknowldgements
. references
. ordered security, editors, acknowledgements, references sections
. checked line lengths
[version 4.10]
. deTab
. checked MIB using SMICng
[version 4.9]
. editorial changes
. rename processMsg to processIncomingMsg
. returnResponsePDU - to allow application to override cache (futures)
. generateResponseMsg passes globalData to reduce binding between MP
and SEC
. generateRequestMsg passes globalData to reduce binding between MP
and SEC
. expectResponse in processIncomingMessage to address Levi concern
. acknowledgements
. posted to snmpv3 mailing list
[version 4.8]
. spell checking
. corrected SNMPv3 Message Processing Model
[version 4.7]
. editorial changes (dbh)
[version 4.4]
. editorial changes (bert)
. renamed document to Message Processing and Dispatching for SNMP
. reworked Multi-Lingual Model into Dispatcher and Message Processing
. Adapted Primitives to latest set defined in ARCH
[version 4.3]
. removed tabs
[version 4.2]
. modified elements of procedure for Multi-Lingual Model
[version 4.0]
. Multi-Lingual Message Processing Model initial version
[version 3.6]
. editorial fixups by jdc
. corrected overview diagram
. changed Message definition to SNMPv3Message
[version 3.5]
. change LoS to securityLevel
[version 3.4]
Case/Harrington/Wijnen Expires February 1998 [Page 3]
Draft Message Processing and Dispatching for SNMP August 1997
. engine, not Message Processing, interacts with network
. editorial changes
. registration is per PDU type
. fields in MsgFlags modified and discussed
. Changes as to address comments by dbh
. Changes to get Primitives inline with latest list
. ran MIB through SMICng
. updated picture in Overview
. update primitives to match editors' discussions
. updates addresses to international format
. removed editors' notes as appropriate
. converted editors' notes into Issues as appropriate
. modified text as per editors' discussions
. posted to snmpv3 mailing list
[version 3.3]
. spelling changes
. elements of procedure expanded
. changes snmpMPCxxxx to snmpV3xxxx in MIB
[version 3.2]
. updated change log
[version 3.1]
. changes as a result of 2nd interim meeting
. adopt to new abstract service interface primitives
. use new agreed upon names for things
. add a new overview of Message Processing Subsystem
. Remove MP Model selection descriptions
. Remove Multiplexing layer descriptions
. Rewrite all the elements of procedure
. Redo the SNMPv3-MIB
. Removed security threats section.
. Did a quick spell check on AIX
. Message Processing and Control changed to Message Processing
. change orangelets to applications
. stats counters should be in the module where they make sense
. statistics counters moved between documents on a case-by-case
basic, according to where they make the most sense
. modified to match consistent terminology
. improved pictures
. added elements of procedure
. changed snmpv3Message to Message
. modified naming of msgFlags
. securityParameters size limitation removed
. removed limits on lengths of contextEngineID and contextName
. new names for the application types
. more bullets to make it easier to read
. primitives have consistent format with expanded comments
. glossary (not filled in) removed
[version 3.0]
. published as draft-ietf-snmpv3-mpc-model-01.txt
[version 2.1]
. ?? not sure if there were any changes
Case/Harrington/Wijnen Expires February 1998 [Page 4]
Draft Message Processing and Dispatching for SNMP August 1997
[version 2.0]
. changes as a result of 1st interim meeting
. some new wording in introduction
. reword in overview with a drawing
. added reportFlag to msgFlags
. describe overall MPC model: MPC Selection mechanism
. describe overall MPC model: MPC Multiplexing Layer
. describe v3MPC model.
. added the abstract interface definitions for interacting
with SNMPv3 USEC Model
. added the abstract interface definitions for interacting
with applications
. added MIB definitions for error Counters (statistics)
. removed references to LPM and Access Control
[version 1.2]
. add text regarding security threats
. add text regarding access control
. remove text regarding agent installation of views
. removed Naming-Scope
. removed discussion of MPC determining to which application a
message/request should be forwarded.
. added Issues section
. added sending a notification for an application
. spell-check, renumber, paginate
[version 1.1]
. separated architecture from Message Processing and Control
Model for SNMPv3
. clarified snmpV3Message definition
. rewrote introduction and overviews
. wrote transport mappings
. documented snmpV3Message format
. changed Quality of Service (QoS) to Level of Security (LoS)
. changed end-user to security entity
. Tried to clarify MMS of engine versus MMS of message.
. change security entity to securityIdentity
[version 1.0]
. Initial document, with SNMPng architecture and MPCv3 merged.
Case/Harrington/Wijnen Expires February 1998 [Page 5]
Draft Message Processing and Dispatching for SNMP August 1997
1. Introduction
The Architecture for describing Internet Management Frameworks
[SNMP-ARCH] describes that an SNMP engine is composed of:
1) a Dispatcher
2) a Message Processing Subsystem,
3) a Security Subsystem, and
4) an Access Control Subsystem.
Applications make use of the services of these subsystems.
It is important to understand the SNMP architecture and its terminology
to understand where the Message Processing and Dispatching 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 Dispatcher in the SNMP engine sends and receives SNMP messages. It
also dispatches SNMP PDUs to SNMP applications. When an SNMP
message needs to be prepared or when data needs to be extracted from
an SNMP message, then the Dispatcher delegates these tasks to a message
version specific Message Processing Model.
A Message Processing Model has the responsibility for processing a
SNMP version specific message and for coordinating the interaction with
the Security Subsystem to ensure proper security is applied to the SNMP
message being handled.
The interactions between the Dispatcher, the Message Processing
Subsystem and applications are performed using abstract data elements
and abstract service interface primitives as defined by the SNMP
architecture.
Similarly, the interactions between the Message Processing Subsystem
and the Security Subsystem are performed using abstract data elements
and abstract service interface primitives as defined by the SNMP
architecture.
Case/Harrington/Wijnen Expires February 1998 [Page 6]
Draft Message Processing and Dispatching for SNMP August 1997
2. Overview
The following illustration depicts the Message Processing in relation
to SNMP applications, the Security Subsystem and Transport Mappings.
+--------------------------------------------------------------------+
| SNMP Entity |
| |
| +----------------------------------------------------------------+ |
| | Applications | |
| | +------------+ +--------------+ | |
| | | Command | | Notification | | |
| | | Generator | | Originator | +-----------+ +--------------+| |
| | +------------+ +--------------+ | Proxy | | Other | |
| | +------------+ +--------------+ | Forwarder | |Application(s)|| |
| | | Command | | Notification | +-----------+ +--------------+| |
| | | Responder | | Receiver | | |
| | +------------+ +--------------+ | |
| +----------------------------------------------------------------+ |
| ^ ^ ^ ^ |
| | | | | |
| v v v v |
| +--------+--------+---------------+-----------+ |
| ^ |
| | +---------------------+ +-----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | PDU Dispatcher | | +->| v1MP * |<--->| +-------------+ | |
| | | | | +------------+ | | | Other | | |
| | | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +-------------+ | |
| | Dispatcher <--------->+ | | | |
| | | | | +------------+ | | +-------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | Transport | | | +------------+ | | | Security | | |
| | Mapping | | | +------------+ | | | Model | | |
| | (e.g RFC1906) | | +->| otherMP * |<--->| +-------------+ | |
| +-------------------+ | +------------+ | | | |
| ^ +---------------------+ +-----------------+ |
| | |
+----------|---------------------------------------------------------+
v
+-------------------+
| Network |
+-------------------+
Case/Harrington/Wijnen Expires February 1998 [Page 7]
Draft Message Processing and Dispatching for SNMP August 1997
2.1. The Dispatcher.
The Dispatcher is a key piece of an SNMP engine. There is only one
in an SNMP engine, and its job is to dispatch tasks to the multiple
version-specific Message Processing Models, and to dispatch PDUs to
various applications.
For incoming messages, the Dispatcher determines the SNMP version of
the incoming message and passes the message to the version-specific
Message Processing Model to extract the components of the message and
to coordinate the processing of security services for the message.
After version-specific processing, the PDU Dispatcher determines to
which application the PDU should be sent for processing.
For outgoing messages, an application provides a PDU to be sent, plus
the data needed to prepare and send the message, and the application
specifies which version-specific Message Processing Model should be
used to prepare the message with the desired security processing.
Once the message is prepared, the Dispatcher sends the message.
The Dispatcher, while sending and receiving SNMP messages, collects
statistics about SNMP messages and the behavior of the SNMP engine
in managed objects to make them accessible to remote SNMP entities.
This document defines these managed objects, the MIB module which
contains them, and how these managed objects might be used to provide
useful management.
2.2. Message Processing Subsystem
The SNMP Message Processing Subsystem is the part of an SNMP engine
which interacts with the Dispatcher to handle the version specific
SNMP messages. It contains one or more Message Processing Models.
This document describes one Message Processing Model, the SNMPv3
Message Processing Model, in section 6. The SNMPv3 Message Processing
Model is defined in a separate section to show that multiple
(independent) Message Processing Models can exist at the same time and
that such Models can be described in different documents. The SNMPv3
Message Processing Model can be replaced or supplemented with other
Message Processing Models in the future. Two Message Processing Models
which are expected to be developed in the future are the SNMPv1
message format [RFC1157] and the SNMPv2c message format [RFC1901].
Others may be developed as needed.
Case/Harrington/Wijnen Expires February 1998 [Page 8]
Draft Message Processing and Dispatching for SNMP August 1997
3. Elements of Message Processing
See [SNMP-ARCH] for the definitions of
contextEngineID
contextName
scopedPDU
maxSizeResponseScopedPDU
securityModel
securityName
securityLevel
snmpVersion
For incoming messages, a version-specific message processing module
provides these values to the Dispatcher. For outgoing messages, an
application provides these values to the Dispatcher.
For some version-specific processing, the values may be extracted
from received messages; for other versions, the values may be
determined by algorithm, or by an implementation-defined mechanism.
How the value is determined is irrelevant to the Dispatcher
The following additional or expanded definitions are for use within
the Dispatcher.
3.1. messageProcessingModel
The messageProcessingModel identifies a Message Processing Model.
A Model describes the version-specific procedures for extracting data
from messages, generating messages, calling upon a securityModel to
use its security services for a message, and for converting data from
a version-specific message format into a generic format usable by the
Dispatcher, and for converting data from Dispatcher format into a
version-specific message format.
3.2. pduVersion
A value which represents a specific version of protocol operation
and its associated PDU formats. The values of pduVersion are specific
to the version of the PDU contained in a message, and the PDUs
processed by applications. The Dispatcher does not use the values of
pduVersion directly.
An application can specify the pduVersion when it requests the PDU
Dispatcher to send a PDU to another SNMP engine. The Dispatcher
passes the pduVersion to a Message Processing Model, so it knows how to
handle the PDU properly.
For incoming messages, pduVersion is provided to the Dispatcher
by a version-specific Message Processing module. The PDU Dispatcher
passes the pduVersion to the application so it knows how to handle
the PDU properly.
Case/Harrington/Wijnen Expires February 1998 [Page 9]
Draft Message Processing and Dispatching for SNMP August 1997
3.3. pduType
A value which represents a specific type of protocol operation.
The values of pduType are specific to the version of the PDU
contained in a message.
Applications register to support particular pduTypes for particular
contextEngineIDs.
For incoming messages, pduType is provided to the Dispatcher by a
version-specific Message Processing module. It is subsequently used to
dispatch the PDU to the application which registered for the pduType
for the contextEngineID of the associated scopedPDU.
3.4. sendPduHandle
This handle is generated for coordinating the processing of requests
and responses between the SNMP engine and an application. The handle
must be unique across all version-specific Message Processing Models.
Implementation Hint: If sendPduhandle is implemented as a 32-bit
integer, its value could be used as a generic unique ID.
For example, the values of an SNMPv3 msgID or an SNMPv1 request-id
could be taken from the sendPduhandle.
Case/Harrington/Wijnen Expires February 1998 [Page 10]
Draft Message Processing and Dispatching for SNMP August 1997
4. Elements of Procedure
This section describes the procedures followed by the Dispatcher
when generating and processing SNMP messages.
4.1. Sending an SNMP Message to the Network
This section describes the procedure followed by an SNMP engine
whenever it must send an SNMP message.
4.1.1. Sending a Request or Notification
An application wants an SNMP PDU to be sent to another (remote)
application.
1) The application requests this using the abstract service primitive:
statusInformation = -- sendPduHandle if success
-- errorIndication if failure
sendPdu(
IN transportDomain -- transport domain to be used
IN transportAddress -- destination network address
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
)
2) If the messageProcessingModel value does not represent a Message
Processing Model known to the Dispatcher, then an errorIndication
(implementation-dependent) is returned to the calling application.
No further processing is done.
3) The Dispatcher generates a sendPduHandle to coordinate subsequent
processing.
4) The Message Dispatcher sends the request to the version-specific
Message Processing module identified by messageProcessingModel
using the abstract service primitive:
statusInformation = - success or error indication
prepareOutgoingMessage(
IN transportDomain -- as specified by application
IN transportAddress -- as specified by application
IN messageProcessingModel -- as specified by application
IN securityModel -- as specified by application
Case/Harrington/Wijnen Expires February 1998 [Page 11]
Draft Message Processing and Dispatching for SNMP August 1997
IN securityName -- as specified by application
IN securityLevel -- as specified by application
IN contextEngineID -- as specified by application
IN contextName -- as specified by application
IN pduVersion -- the version of the PDU
IN PDU -- as specified by application
IN expectResponse -- as specified by application
IN sendPduHandle -- as determined in step 3.
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- the message length
)
5) If the statusInformation indicates an error, the errorIndication
is returned to the calling application.
6) If the statusInformation indicates success, the sendPduHandle
is returned to the application, and the outgoingMessage is sent
over the transport specified by the transportDomain to the address
specified by the transportAddress.
Outgoing Message Processing is complete.
4.1.2. Sending a Response to the Network
An application wants a response to be sent back to the originator
of an SNMP Request.
1) An application can request this using the abstract service
primitive:
returnResponsePdu(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
) -- error counter OID/value if error
2) The Message Dispatcher sends the request to the version-specific
protocol specified by messageProcessingModel using the abstract
service primitive:
Case/Harrington/Wijnen Expires February 1998 [Page 12]
Draft Message Processing and Dispatching for SNMP August 1997
result = -- SUCCESS or errorIndication
prepareResponseMessage(
IN messageProcessingModel -- as specified by application
IN securityModel -- as specified by application
IN securityName -- as specified by application
IN securityLevel -- as specified by application
IN contextEngineID -- as specified by application
IN contextName -- as specified by application
IN pduVersion -- as specified by application
IN PDU -- as specified by application
IN maxSizeResponseScopedPDU -- as specified by application
IN stateReference -- as specified by application
IN statusInformation -- as specified by application
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- the message length
)
3) If the result is an errorIndication, the errorIndication is returned
to the calling application.
4) If the result is success, the outgoingMessage is sent over the
transport specified by the transportDomain to the address specified
by the transportAddress.
Message Processing is complete.
4.2. Receiving an SNMP Message from the Network
This section describes the procedure followed by an SNMP engine
whenever it receives an SNMP message.
Please note, that for the sake of clarity and to prevent the text from
being even longer and more complicated, some details were omitted from
the steps below.
a) The elements of procedure do not always explicitly indicate when
state information needs to be released. The general rule is that
if state information is available when a message is to be
"discarded without further processing", then the state information
must also be released at that same time.
4.2.1. Message Dispatching
1) The snmpInPkts counter [RFC1907] is incremented.
2) The version of the SNMP message is determined in an implementation
dependent manner. If the version cannot be determined, or the
version is not supported, then the snmpInBadVersions [RFC1907]
counter is incremented, and the message is discarded without
Case/Harrington/Wijnen Expires February 1998 [Page 13]
Draft Message Processing and Dispatching for SNMP August 1997
further processing.
3) The origin transportDomain and origin transportAddress are
determined.
4) The message is passed to the version-specific Message Processing
Model which returns the abstract data elements required by the
Dispatcher. This is done using the abstract service primitive:
result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin as determined in step 3.
IN transportAddress -- origin as determined in step 3.
IN wholeMsg -- as received from the network
IN wholeMsglength -- as received from the network
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- the version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for a matched request
OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- to be used for a possible
) -- Response
5) If the result is a FAILURE errorIndication, the message is discarded
without further processing.
6) The abstract data elements have been prepared now. Continue with
the section that describes the PDU Dispatching.
4.2.2. PDU Dispatching for Incoming Messages
If the value of sendPduhandle is <none>, then this is a request or
notification.
1) The combination of contextEngineID, and pduType are used to
determine which application has registered for this request or
notification.
2) If no application has registered for the combination, then
a) The snmpUnknownPDUHandlers counter is incremented.
Case/Harrington/Wijnen Expires February 1998 [Page 14]
Draft Message Processing and Dispatching for SNMP August 1997
b) A Response message is generated using the abstract service
primitive:
result = -- SUCCESS or FAILURE
prepareResponseMessage(
IN messageProcessingModel -- as provided by MP module
IN securityModel -- as provided by MP module
IN securityName -- as provided by MP module
IN securityLevel -- as provided by MP module
IN contextEngineID -- as provided by MP module
IN contextName -- as provided by MP module
IN pduVersion -- as provided by MP module
IN PDU -- as provided by MP module
IN maxSizeResponseScopedPDU -- as provided by MP module
IN stateReference -- as provided by MP module
IN statusInformation -- errorIndication plus
-- snmpUnknownPDUHandlers OID
-- value pair.
OUT transportDomain -- destination transportDomain
OUT transportAddress -- destination transportAddress
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
)
c) If the result is SUCCESS, then the prepared message is sent
to the originator of the request as identified by the
transportDomain and transportAddress.
d) The incoming message is discarded without further processing.
Message Processing for this message is complete.
3) The PDU is dispatched to the application, using the abstract
service interface:
processPdu( -- process Request/Notification
IN messageProcessingModel -- as provided by MP module
IN securityModel -- as provided by MP module
IN securityName -- as provided by MP module
IN securityLevel -- as provided by MP module
IN contextEngineID -- as provided by MP module
IN contextName -- as provided by MP module
IN pduVersion -- as provided by MP module
IN PDU -- as provided by MP module
IN maxSizeResponseScopedPDU -- as provided by MP module
IN stateReference -- as provided by MP module
) -- needed when sending a response
Message processing for this message is complete.
If the value of sendPduHandle is not <none>, then this is a response.
Case/Harrington/Wijnen Expires February 1998 [Page 15]
Draft Message Processing and Dispatching for SNMP August 1997
1) The value of sendPduHandle is used to determine, in an
implementation-defined manner, which application is waiting for a
response PDU associated with this sendPduHandle.
2) If no waiting application is found, the message is discarded
without further processing, and the stateReference is released.
Message Processing is complete for this message.
3) Any cached information, including stateReference, about the
message is discarded.
4) The response is dispatched to the application using the abstract
service primitive:
processResponsePdu( -- process Response PDU
IN messageProcessingModel -- as provided by the MP module
IN securityModel -- as provided by the MP module
IN securityName -- as provided by the MP module
IN securityLevel -- as provided by the MP module
IN contextEngineID -- as provided by the MP module
IN contextName -- as provided by the MP module
IN pduVersion -- as provided by the MP module
IN PDU -- as provided by the MP module
IN statusInformation -- as provided by the MP module
IN sendPduHandle -- as provided by the MP module
)
Message Processing is complete for this message.
4.3. Application Registration for Handling PDU types
Applications that want to process certain PDUs must register with the
PDU Dispatcher. Applications specify for which combination of
contextEngineID, and pduType(s) they want to take responsibility.
1) An application registers according to the abstract interface
primitive:
statusInformation = -- success or errorIndication
registerContextEngineID(
IN contextEngineID -- take responsibility for this one
IN pduType -- the pduType(s) to be registered
)
2) The parameters may be checked to be valid; if they are not, then an
errorIndication (invalidParameter) is returned to the application.
3) Each combination of contextEngineID and pduType can be registered
only once. If another application has already registered for the
specified combination, then an errorIndication (alreadyRegistered)
is returned to the application.
Case/Harrington/Wijnen Expires February 1998 [Page 16]
Draft Message Processing and Dispatching for SNMP August 1997
4) Otherwise, the registration is saved so that SNMP PDUs can be
dispatched to this application.
4.3. Application Unregistration for Handling PDU Types
Applications that no longer want to process certain PDUs must
unregister with the PDU Dispatcher.
1) An application unregisters using the abstract service primitive:
unregisterContextEngineID(
IN contextEngineID -- give up responsibility for this
IN pduType -- the pduType(s) to be unregistered
)
2) If the contextEngineID and pduType combination has been registered,
then the registration is deleted.
If no such registration exists, then the request is ignored.
Case/Harrington/Wijnen Expires February 1998 [Page 17]
Draft Message Processing and Dispatching for SNMP August 1997
5. Definitions
5.1. Definitions for SNMP Message Processing and Dispatching
SNMP-MPD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
MODULE-IDENTITY, OBJECT-TYPE,
snmpModules, Counter32 FROM SNMPv2-SMI;
snmpMPDMIB MODULE-IDENTITY
LAST-UPDATED "9707270000Z" -- 27 July 1997, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In message body: subscribe snmpv3
Chair: Russ Mundy
Trusted Information Systems
postal: 3060 Washington Road
Glenwood MD 21738
USA
email: mundy@tis.com
phone: +1-301-854-6889
Co-editor: Jeffrey Case
SNMP Research, Inc.
postal: 3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
USA
email: case@snmp.com
phone: +1-423-573-1434
Co-editor Dave Harrington
Cabletron Systems, Inc
postal: Post Office Box 5005
MailStop: Durham
35 Industrial Way
Rochester NH 03867-5005
USA
email: dbh@cabletron.com
phone: +1- 603-337-7357
Co-editor: Bert Wijnen
IBM T. J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-432-794
Case/Harrington/Wijnen Expires February 1998 [Page 18]
Draft Message Processing and Dispatching for SNMP August 1997
"
DESCRIPTION "The MIB for Message Processing and Dispatching"
::= { snmpModules 8 } -- check if assignment is OK
-- Administrative assignments ****************************************
snmpMPDAdmin OBJECT IDENTIFIER ::= { snmpMPDMIB 1 }
snmpMPDMIBObjects OBJECT IDENTIFIER ::= { snmpMPDMIB 2 }
snmpMPDMIBConformance OBJECT IDENTIFIER ::= { snmpMPDMIB 3 }
-- Statistics for SNMP Messages **************************************
snmpMPDStats OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 }
snmpUnknownSecurityModels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they referenced a
securityModel that was not known to or supported by
the SNMP engine, e.g., was not registered by any
application.
"
::= { snmpMPDStats 1 }
snmpInvalidMsgs 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 there were invalid
or inconsistent components in the SNMP message.
"
::= { snmpMPDStats 2 }
snmpUnknownPDUHandlers OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because the PDU contained
in the packet could not be passed to an application
responsible for handling the pduType, i.e. no SNMP
application had registered for the proper combination
of the messageProcessingModel, the contextEngineID
and the pduType.
"
::= { snmpMPDStats 3 }
Case/Harrington/Wijnen Expires February 1998 [Page 19]
Draft Message Processing and Dispatching for SNMP August 1997
-- Conformance information *******************************************
snmpMPDMIBCompliances OBJECT IDENTIFIER ::= { snmpMPDMIBConformance 1 }
snmpMPDMIBGroups OBJECT IDENTIFIER ::= { snmpMPDMIBConformance 2 }
-- Compliance statements
snmpMPDCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP entities which
implement the SNMP-MPD-MIB.
"
MODULE -- this module
MANDATORY-GROUPS { snmpMPDGroup }
::= { snmpMPDMIBCompliances 1 }
snmpMPDGroup OBJECT-GROUP
OBJECTS {
snmpUnknownSecurityModels,
snmpInvalidMsgs,
snmpUnknownPDUHandlers
}
STATUS current
DESCRIPTION "A collection of objects providing for remote
monitoring of the SNMP Message Processing and
Dispatching process.
"
::= { snmpMPDMIBGroups 1 }
END
Case/Harrington/Wijnen Expires February 1998 [Page 20]
Draft Message Processing and Dispatching for SNMP August 1997
6. The SNMPv3 Message Format
This section defines the SNMPv3 message format and the corresponding
SNMP version 3 Message Processing Model (v3MP).
DEFINITIONS ::= BEGIN
SNMPv3Message ::= SEQUENCE {
-- administrative parameters
msgGlobalData headerData
-- security model-specific parameters
-- format defined by Security Model
msgSecurityParameters OCTET STRING
msgData scopedPduData
}
headerData ::= SEQUENCE {
msgVersion INTEGER { snmpv3 (3) },
msgID INTEGER (0..2147483647),
msgMaxSize INTEGER (484..2147483647),
msgFlags OCTET STRING (SIZE(1)),
-- .... ...1 authFlag
-- .... ..1. privFlag
-- .... .1.. reportableFlag
-- .... 1... reportFlag
--
-- Please observe:
-- .... ..00 is OK, means noAuthNoPriv
-- .... ..01 is OK, means authNoPriv
-- .... ..10 reserved, must NOT be used.
-- .... ..11 is OK, means authPriv
msgSecurityModel INTEGER (0..2147483647)
}
scopedPduData ::= CHOICE {
plaintext scopedPDU,
encryptedPDU OCTET STRING -- encrypted scopedPDU value
}
scopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING
contextName OCTET STRING
data ANY -- e.g. PDUs as defined in RFC1905
}
END
Case/Harrington/Wijnen Expires February 1998 [Page 21]
Draft Message Processing and Dispatching for SNMP August 1997
6.1. msgVersion
The msgVersion field is set to snmpv3(3) and identifies the message as
an SNMP version 3 Message.
6.2. msgID
The msgID is used between two SNMP entities to coordinate request
messages and responses, and by the v3MP to coordinate the processing
of the message by different subsystem models within the architecture.
Another purpose of msgID is to provide protection against message
replays. This requires that msgID generated must vary from one
message to another, and it should be initialized to an unpredictable
value. A good method would be to initialize msgID when the SNMP
engine is started and then increase its value monotonically with
each subsequent message.
Note that the request-id in a PDU is used by SNMP applications to
identify the PDU; the msgID is used by the engine to identify the
message which carries a PDU. The engine may need to identify the
message even if decrypting of the PDU (and request-id) fails. No
assumption should be made that the value of the msgID and the value
of the request-id are equivalent.
6.3. msgMaxSize
The msgMaxSize field of the message conveys the maximum message size
supported by the sender of the message, i.e., the maximum message size
that the sender can accept when another SNMP engine sends an SNMP
message (be it a response or any other message) to the sender of this
message.
When an SNMP message is being generated, the msgMaxSize is provided by
the SNMP engine which generates the message. At the receiving SNMP
engine the msgMaxSize is used to determine how big the Response to a
Request message can be.
6.4. msgFlags
The msgFlags field of the message contains several bit fields which
assist with the processing of the message.
a) reportableFlag
If the reportableFlag is set, then Report PDUs are allowed to be
returned to the sender under those conditions which cause the
generation of Report PDUs. If the reportableFlag is zero, then a
Report PDU must not be sent. The reportableFlag should always be
zero when the message contains a Report PDU, a Response PDU, or an
Case/Harrington/Wijnen Expires February 1998 [Page 22]
Draft Message Processing and Dispatching for SNMP August 1997
SNMPv2-trap PDU. The reportableFlag should always be set for a
Request PDU.
b) reportFlag
The reportFlag indicates whether or not the message contains a
Report PDU.
Report PDUs are engine-to-engine communications and are processed
directly by the SNMPv3 Message Processing Model, and are not passed
to applications for processing, unlike all other PDU types. The
reportFlag is set for a message containing a Report PDU so the
SNMPv3 Message Processing Model can easily recognize such messages.
The authFlag and privFlag portions of the msgFlags field are set by the
sender to indicate the securityLevel that was applied to the message
before it was sent on the wire. The receiver of the message should
apply the same securityLevel when the message is received and the
contents are being processed.
There are 3 securityLevels, namely noAuthNoPriv, which is less than
authNoPriv, which is in turn less than authPriv. See the SNMP
architecture document [SNMP-ARCH] for details about the securityLevel.
a) authFlag
If the authFlag is set, then the securityModel used by the SNMP
engine which sent the message must identify the securityName on
whose behalf the SNMP message was generated and must provide, in a
securityModel-specific manner, sufficient data for the receiver of
the message to be able to authenticate that identification. In
general, this authentication will allow the receiver to determine
with reasonable certainty that the message was:
- sent on behalf of the principal associated with the securityName,
- was not redirected,
- was not modified in transit, and
- was not replayed.
If the authFlag is not set, then the securityModel used by the
SNMP engine which sent the message must identify the securityName
on whose behalf the SNMP message was generated but it does not
need to provide sufficient data for the receiver of the message
to authenticate the identification, as there is no need to
authenticate the message in this case.
b) privFlag
If the privFlag is set, then the securityModel used by the SNMP
engine which sent the message must also protect the scopedPDU in
an SNMP message from disclosure, i.e. must encrypt/decrypt the
scopedPDU. If the privFlag is zero, then the securityModel in use
Case/Harrington/Wijnen Expires February 1998 [Page 23]
Draft Message Processing and Dispatching for SNMP August 1997
does not need to protect the data from disclosure.
It is an explicit requirement of the SNMP architecture that if
privacy is selected, then authentication is also required. That
means that if the privFlag is set, then the authFlag should also
be set.
The combination of the authFlag and the privFlag comprises a Level of
Security as follows:
authFlag zero and privFlag zero -> securityLevel is noAuthNoPriv
authFlag zero and privFlag one -> invalid combination
authFlag one and privFlag zero -> securityLevel is authNoPriv
authFlag one and privFlag one -> securityLevel is authPriv
6.5. msgSecurityModel
The v3MP supports the concurrent existence of multiple Security Models
to provide security services for SNMPv3 messages. The msgSecurityModel
field in an SNMPv3 Message identifies which Security Model was used by
the sender to generate the message and therefore which securityModel
should be used by the receiver to perform security processing for the
message. The mapping to the appropriate securityModel implementation
within an SNMP engine is accomplished in an implementation-dependent
manner.
6.6. msgSecurityParameters
The msgSecurityParameters field of the SNMPv3 Message is used for
communication between the Security Model modules in the sending and
receiving SNMP engines. The data in the msgSecurityParameters field is
used exclusively by the Security Model, and the contents and format
of the data is defined by the Security Model. This OCTET STRING is
not interpreted by the v3MP, but is passed to the local implementation
of the Security Model indicated by the msgSecurityModel field in the
message.
6.7. scopedPduData
The scopedPduData field represents either the plain text scopedPDU
if the privFlag in the msgFlags is zero, or it represents an
encryptedPDU which must be decrypted by the securityModel in use to
produce a plaintext scopedPDU.
6.8. scopedPDU
The scopedPDU contains information to identify an administratively
unique context and a PDU. The object identifiers in the PDU refer to
managed objects which are (expected to be) accessible within the
specified context.
Case/Harrington/Wijnen Expires February 1998 [Page 24]
Draft Message Processing and Dispatching for SNMP August 1997
6.8.1. contextEngineID
The contextEngineID in the SNMPv3 message, uniquely identifies, within
an administrative domain, an SNMP entity that may realize an instance
of a context with a particular contextName.
For incoming messages, the contextEngineID is used to determine to
which application the scopedPDU should be sent for processing.
For outgoing messages, the v3MP sets the contextEngineID to the value
provided by the application in the request for a message to be sent.
6.8.2. contextName
The contextName field in an SNMPv3 message, in conjunction with the
contextEngineID field, identifies the particular context associated
with the management information contained in the PDU portion of the
message. The contextName is unique within the SNMP entity specified
by the contextEngineID, which may realize the managed objects
referenced within the PDU. An application which originates a message
provides the value for the contextName field and this value may be
used during processing by an application at the receiving SNMP Engine.
6.8.3. data
The data field of the SNMPv3 Message contains the PDU. Among other
things, the PDU contains the PDU type that is used by the v3MP to
determine the type of the incoming SNMP message. The v3MP specifies
that the PDU must be one of those specified in [RFC1905].
Case/Harrington/Wijnen Expires February 1998 [Page 25]
Draft Message Processing and Dispatching for SNMP August 1997
7. Elements of Procedure
This section describes the procedures followed by an SNMP engine when
generating and processing SNMP messages according to the SNMPv3 Message
Processing Model.
Please note, that for the sake of clarity and to prevent the text from
being even longer and more complicated, some details were omitted from
the steps below.
a) Some steps specify that when some error conditions are encountered
when processing a received message, a message containing a Report
PDU is generated and the received message is discarded without
further processing. However, a Report-PDU must not be generated
unless the reportableFlag is set in the received message.
b) The elements of procedure do not always explicitly indicate when
state information needs to be released. The general rule is that
if state information is available when a message is to be
"discarded without further processing", then the state information
must also be released at that same time.
7.1. Prepare an Outgoing SNMP Message
This section describes the procedure followed to prepare an SNMPv3
message from the data elements passed by the Message Dispatcher.
1) The Message Dispatcher may request that an SNMPv3 message
containing a GetRequest-PDU, a GetNextRequest-PDU, a
GetBulkRequest-PDU, a SetRequest-PDU, an InformRequest-PDU,
or an SNMPv2-Trap-PDU be prepared for sending.
a) It makes such a request according to the abstract service
primitive:
statusInformation = -- success or errorIndication
prepareOutgoingMessage(
IN transportDomain -- requested transport domain
IN transportAddress -- requested destination address
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the handle for matching
-- incoming responses
OUT destTransportDomain -- destination transport domain
Case/Harrington/Wijnen Expires February 1998 [Page 26]
Draft Message Processing and Dispatching for SNMP August 1997
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- the length of the message
)
b) A unique msgID is generated. It is best to use unpredictable
numbers for the msgID.
* SNMPv3 does not use the values of expectResponse or pduVersion.
2) The Message Dispatcher may request that an SNMPv3 message
containing a Response-PDU or a Report-PDU be prepared for sending.
a) It makes such a request according to the abstract service
primitive:
result = -- SUCCESS or FAILURE
prepareResponseMessage(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- same as on incoming request
IN securityName -- same as on incoming request
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT transportDomain -- destination transport domain
OUT transportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- the length of the message
)
b) The cached information for the original request, pointed to
by the stateReference, is retrieved, including
- msgID,
- contextEngineID,
- contextName,
- securityModel,
- securityName,
- securityLevel,
- securityStateReference,
- reportableFlag,
- transportDomain, and
- transportAddress.
Case/Harrington/Wijnen Expires February 1998 [Page 27]
Draft Message Processing and Dispatching for SNMP August 1997
The SNMPv3 Message Processing Model does not allow cached data
to be overidden by specified parameters.
3) If statusInformation contains values for an OID/value combination,
then
a) If reportableFlag is zero, then the original message is
discarded, and no further processing is done. A result of
FAILURE is returned. SNMPv3 Message Processing is complete.
b) If a PDU is provided, it is the PDU from the original request.
If possible, extract the request-id.
c) A Report PDU is prepared:
1) the varBindList is set to contain the OID and value from
the statusInformation
2) error-status is set to 0
3) error-index is set to 0.
4) request-id is set to the value extracted in step b)
Otherwise, request-id is set to 0
d) If the errorIndication is NotInTimeWindow, then securityLevel is
set to authNoPriv, otherwise securityLevel is set to noAuthNoPriv.
e) PDU is set to refer to the new Report-PDU. The old PDU
is discarded.
f) contextEngineID is set to the value of snmpEngineID
g) contextName is set to the default contextName
4) If contextEngineID is not yet determined, then the contextEngineID
is determined, in an implementation-dependent manner, possibly using
the transportDomain and transportAddress.
5) If the contextName is not yet determined, the contextName is set
to the default context.
6) A scopedPDU is prepared from the contextEngineID, contextName,
and PDU.
7) msgGlobalData is constructed as follows
a) The msgVersion field is set to snmpv3(3).
b) msgID is set as determined in step 1 or 2.
c) msgMaxSize is set to an implementation dependent value.
d) msgFlags are set as follows:
- If securityLevel specifies noAuthNoPriv, then authFlag
Case/Harrington/Wijnen Expires February 1998 [Page 28]
Draft Message Processing and Dispatching for SNMP August 1997
and privFlag are both set to zero.
- If securityLevel specifies authNoPriv, then authFlag
is set to one and privFlag is set to zero.
- If securityLevel specifies authPriv, then authFlag is
set to one and privFlag is set to one.
- If the PDU is a Response-PDU, a Report-PDU or an SNMPv2-Trap-PDU,
then the reportableFlag is set to zero;
- If the PDU is a GetRequest-PDU, a GetNextRequest-PDU,
a GetBulkRequest-PDU, a SetRequest-PDU, or an InformRequest-PDU
then the reportableFlag is set to one.
- If the PDU is a Report-PDU, the reportFlag is set to one;
otherwise it is set to zero.
- All other msgFlags bits are set to zero.
e) msgSecurityModel is set to the value of securityModel
8) If the PDU is a Response-PDU or a Report-PDU, then
a) The specified Security Model is called to generate the message
according to the primitive:
statusInformation =
generateResponseMsg(
IN messageProcessingModel -- SNMPv3 Message Processing Model
IN globalData -- msgGlobalData from step 7
IN maxMessageSize -- from msgMaxSize in step 7 c)
IN securityModel -- as determined in step 7 e)
IN securityEngineID -- the value of snmpEngineID
IN securityName -- on behalf of this principal
IN securityLevel -- for the outgoing message
IN scopedPDU -- as prepared in step 6)
IN securityStateReference -- as determined in step 2
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
If, upon return from the Security Model, the statusInformation
includes an errorIndication, then any cached information about
the outstanding request message is discarded, and an
errorIndication is returned, so it can be returned to the
calling application. SNMPv3 Message Processing is complete.
b) A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
9) If the PDU is a GetRequest-PDU, a GetNextRequest-PDU,
a GetBulkRequest-PDU, a SetRequest-PDU, an InformRequest-PDU, or
or an SNMPv2-Trap-PDU, then
a) If the PDU is an SNMPv2-Trap-PDU, then securityEngineID
Case/Harrington/Wijnen Expires February 1998 [Page 29]
Draft Message Processing and Dispatching for SNMP August 1997
is set to the value of this entity's snmpEngineID,
Otherwise, the snmpEngineID of the target entity is determined,
in an implementation-dependent manner, possibly using
transportDomain and transportAddress. securityEngineID is
set to the value of the target entity's snmpEngineID.
b) The specified Security Model is called to generate the message
according to the primitive:
statusInformation =
generateRequestMsg(
IN messageProcessingModel -- SNMPv3 Message Processing Model
IN globalData -- msgGlobalData, from step 7
IN maxMessageSize -- from msgMaxSize in step 7 c)
IN securityModel -- as provided by caller
IN securityEngineID -- authoritative SNMP entity
IN securityName -- as provided by caller
IN securityLevel -- as provided by caller
IN snmpEngineID -- as determined in step 9 a)
IN scopedPDU -- as prepared in step 6
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
If, upon return from the Security Model, the statusInformation
includes an errorIndication, then the message is discarded, and
the errorIndication is returned, so it can be returned to the
calling application, and no further processing is done.
SNMPv3 Message Processing is complete.
c) Information about the outgoing message is cached, and a
stateReference is created (implementation specific).
Information to be cached includes the values of:
- sendPduHandle
- msgID
- snmpEngineID
- securityModel
- securityName
- securityLevel
- contextEngineID
- contextName
d) A SUCCESS result is returned.
SNMPv3 Message Processing is complete.
Case/Harrington/Wijnen Expires February 1998 [Page 30]
Draft Message Processing and Dispatching for SNMP August 1997
7.2. Prepare Data Elements from an Incoming SNMP Message
This section describes the procedure followed to extract data from
an SNMPv3 message, and to prepare the data elements required for
further processing of the message by the Message Dispatcher.
1) The message is passed in from the Message Dispatcher according to
the abstract service primitive:
result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network
IN wholeMsglength -- as received from the network
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- to be used for a possible
) -- Response
2) If the received message is not the serialization (according to
the conventions of [RFC1906]) of an SNMPv3Message value, then the
snmpInASNParseErrs counter [RFC1907] is incremented, the message
is discarded without further processing, and a FAILURE result is
returned. SNMPv3 Message Processing is complete.
3) The values for msgVersion, msgID, msgMaxSize, msgFlags,
msgSecurityModel, msgSecurityParameters, and msgData are extracted
from the message.
4) If the value of the msgSecurityModel component does not match a
supported securityModel, then the snmpUnknownSecurityModels
counter is incremented, a Report PDU is generated, the
message is discarded without further processing, and a FAILURE
result is returned. SNMPv3 Message Processing is complete.
5) The securityLevel is determined from the authFlag and the privFlag
bits of the msgFlags component as follows:
Case/Harrington/Wijnen Expires February 1998 [Page 31]
Draft Message Processing and Dispatching for SNMP August 1997
a) If the authFlag is not set and the privFlag is not set, then
securityLevel is set to noAuthNoPriv.
b) If the authFlag is set and the privFlag is not set, then
securityLevel is set to authNoPriv.
c) If the authFlag is set and the privFlag is set, then
securityLevel is set to authPriv.
d) If the authFlag is not set and privFlag is set, then the
snmpInvalidMessages counter is incremented, a Report PDU is
generated, the message is discarded without further processing,
and a FAILURE result is returned. SNMPv3 Message Processing is
complete.
6) The security module implementing the Security Model as specified
by the securityModel component is called for authentication and
privacy services. This is done according to the abstract service
primitive:
statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- SNMPv3 Message Processing Model
IN expectResponse -- TRUE or FALSE
IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for the received message
IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU
OUT securityStateReference -- reference to security state
) -- information, needed for response
If an errorIndication is returned by the security module, then
a) If statusInformation contains values for an OID/value pair,
then a Report PDU is generated.
1) If the scopedPDU has been returned from ProcessIncomingMessage
then determine contextEngineID, contextName, and PDU.
2) Information about the message is cached and a stateReference
is created (implementation specific). Information to be cached
includes the values of:
msgVersion,
Case/Harrington/Wijnen Expires February 1998 [Page 32]
Draft Message Processing and Dispatching for SNMP August 1997
msgID,
securityLevel,
msgFlags,
msgMaxSize,
securityModel,
maxSizeResponseScopedPDU,
securityStateReference
3) Request that a Report-PDU be prepared and sent, according to
the abstract service primitive:
result = -- SUCCESS or FAILURE
returnResponsePDU(
IN messageProcessingModel -- SNMPv3(3)
IN securityModel -- same as on incoming request
IN securityName -- from ProcessIncomingMessage
IN securityLevel -- same as on incoming request
IN contextEngineID -- from step 6 a) 1)
IN contextName -- from step 6 a) 1)
IN pduVersion -- SNMPv2-PDU
IN PDU -- from step 6 a) 1)
IN maxSizeResponseScopedPDU -- from ProcessIncomingMessage
IN stateReference -- from step 6 a) 2)
IN statusInformation -- from ProcessIncomingMsg
OUT transportDomain -- destination transport domain
OUT transportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- the length of the message
)
b) The incoming message is discarded without further processing,
and a FAILURE result is returned. SNMPv3 Message Processing is
complete.
7) The scopedPDU is parsed to extract the contextEngineID, the
contextName and the PDU. If any parse error occurs, then the
snmpInASNParseErrs counter [RFC1907] is incremented, the security
state information is discarded, the message is discarded without
further processing, and a FAILURE result is returned. SNMPv3
Message Processing is complete.
8) The pduVersion is set to an SNMPv2-PDU.
9) The pduType is determined, in an implementation-dependent manner,
to be:
- a GetRequest-PDU,
- a GetNextRequest-PDU,
- a GetBulkRequest-PDU,
- a SetRequest-PDU,
- an InformRequest-PDU,
Case/Harrington/Wijnen Expires February 1998 [Page 33]
Draft Message Processing and Dispatching for SNMP August 1997
- an SNMPv2-Trap-PDU,
- a Response-PDU, or
- a Report-PDU.
10) If the pduType is a Response-PDU or a Report-PDU, then
a) The value of the msgID component is used to find the cached
information for a corresponding outstanding Request message.
If no such outstanding Request message is found, then the
security state information is discarded, the message is
discarded without further processing, and a FAILURE result
is returned. SNMPv3 Message Processing is complete.
b) sendPduhandle is retrieved from the cached information.
Otherwise, sendPduhandle is set to <none>, an implementation
defined value.
11) If the pduType is a Report-PDU, then
a) statusInformation is created using the contents of the
Report-PDU, in an implementation-dependent manner. This
statusInformation will be forwarded to the application
associated with the sendPduHandle.
b) Any cached information about the outstanding Request message
message is discarded.
c) The security state information for this incoming message
is discarded.
d) stateReference is set to <none>
e) A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
12) If the pduType is a Response-PDU, then
a) The cached data for the outstanding request, referred to
by stateReference, is retrieved, including
- snmpEngineID
- securityModel
- securityName
- securityLevel
- contextEngineID
- contextName
b) If the values extracted from the incoming message differ
from the cached data, then the security state information
is discarded, any cached information about the outstanding
Case/Harrington/Wijnen Expires February 1998 [Page 34]
Draft Message Processing and Dispatching for SNMP August 1997
Request message is discarded, the incoming message is discarded
without further processing, and a FAILURE result is returned.
SNMPv3 Message Processing is complete.
c) Otherwise, any cached information about the outstanding Request
message is discarded, and stateReference is set to <none>.
d) A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
13) If the pduType is a GetRequest-PDU, a GetNextRequest-PDU,
a GetBulkRequest-PDU, a SetRequest-PDU, an InformRequest-PDU,
then
a) If the value of securityEngineID is not equal to the value of
snmpEngineID, then the security state information is discarded,
any cached information about the outstanding Request message
is discarded, the incoming message is discarded without further
processing, and a FAILURE result is returned.
SNMPv3 Message Processing is complete.
b) Information about the message is cached and a stateReference
is created (implementation specific). Information to be cached
includes the values of:
msgVersion,
msgID,
securityLevel,
msgFlags,
msgMaxSize,
securityModel,
maxSizeResponseScopedPDU,
securityStateReference
c) A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
14) If the pduType is an SNMPv2-Trap-PDU, then
A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
Case/Harrington/Wijnen Expires February 1998 [Page 35]
Draft Message Processing and Dispatching for SNMP August 1997
8. Security Considerations
The Multi-Lingual Message Processing Model coordinates the processing
of messages to provide a level of security for management messages and
to direct the SNMP PDUs to the proper SNMP application(s).
The level of security actually provided is primarily determined by
the specific Security Model implementation(s) and the specific
SNMP application implementation(s) incorporated into this framework.
Applications have access to data which is not secured. Applications
should take reasonable steps to protect the data from disclosure, and
when they send data across the network, they should obey the
securityLevel and call upon the services of an Access Control Model
to apply access control.
Case/Harrington/Wijnen Expires February 1998 [Page 36]
Draft Message Processing and Dispatching for SNMP August 1997
9. Editor's Addresses
Co-editor: Jeffrey Case
SNMP Research, Inc.
postal: 3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
USA
email: case@snmp.com
phone: +1-423-573-1434
Co-editor Dave Harrington
Cabletron Systems, Inc
postal: Post Office Box 5005
MailStop: Durham
35 Industrial Way
Rochester NH 03867-5005
USA
email: dbh@cabletron.com
phone: +1-603-337-7357
Co-editor: Bert Wijnen
IBM T. J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-432-794
Case/Harrington/Wijnen Expires February 1998 [Page 37]
Draft Message Processing and Dispatching for SNMP August 1997
10. Acknowledgements
This document is the result of the efforts of the SNMPv3 Working Group.
Some special thanks are in order to the following SNMPv3 WG members:
Dave Battle (SNMP Research, Inc.)
Uri Blumenthal (IBM T.J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
John Curran (BBN)
T. Max Devlin (Hi-TECH Connections)
John Flick (Hewlett Packard)
David Harrington (Cabletron Systems Inc.)
N.C. Hien (IBM T.J. Watson Research Center)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Russ Mundy (Trusted Information Systems, Inc.)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reid (SNMP Research, Inc.)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Bert Wijnen (IBM T.J. Watson Research Center)
The document is based on recommendations of the IETF Security and
Administrative Framework Evolution for SNMP Advisory Team.
Members of that Advisory Team were:
David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco Systems)
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 Center)
As recommended by the Advisory Team and the SNMPv3 Working Group
Charter, the design incorporates as much as practical from previous
RFCs and drafts. As a result, special thanks are due to the authors
of previous designs known as SNMPv2u and SNMPv2*:
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
Keith McCloghrie (Cisco Systems)
Case/Harrington/Wijnen Expires February 1998 [Page 38]
Draft Message Processing and Dispatching for SNMP August 1997
Brian O'Keefe (Hewlett Packard)
Marshall T. Rose (Dover Beach Consulting)
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
Glenn W. Waters (Bell-Northern Research Ltd.)
Case/Harrington/Wijnen Expires February 1998 [Page 39]
Draft Message Processing and Dispatching for SNMP August 1997
11. 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 SNMP Management Frameworks",
draft-ietf-snmpv3-next-gen-arch-04.txt, August 1997.
[SNMP-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B.,
"The User-Based Security Model for Version 3 of the Simple
Network Management Protocol (SNMPv3)",
draft-ietf-snmpv3-usm-01.txt, August 1997.
[SNMP-ACM] The SNMPv3 Working Group, Wijnen, B., Presuhn, R.,
McCloghrie, K., "View-based Access Control Model for the Simple
Network Management Protocol (SNMP)",
draft-ietf-snmpv3-acm-02.txt, August 1997.
[SNMP-APPL] The SNMPv3 Working Group, Levi, D. B., Meyer, P.,
Stewart, B., "SNMPv3 Applications",
<draft-ietf-snmpv3-appl-01.txt>, August 1997
Case/Harrington/Wijnen Expires February 1998 [Page 40]
Draft Message Processing and Dispatching for SNMP August 1997
Table of Contents
0. Issues 2
0.1. Resolved Issues 2
0.2. Change Log 3
1. Introduction 6
2. Overview 7
2.1. The Dispatcher. 8
2.2. Message Processing Subsystem 8
3. Elements of Message Processing 9
3.1. messageProcessingModel 9
3.2. pduVersion 9
3.3. pduType 10
3.4. sendPduHandle 10
4. Elements of Procedure 11
4.1. Sending an SNMP Message to the Network 11
4.1.1. Sending a Request or Notification 11
4.1.2. Sending a Response to the Network 12
4.2. Receiving an SNMP Message from the Network 13
4.2.1. Message Dispatching 13
4.2.2. PDU Dispatching for Incoming Messages 14
4.3. Application Registration for Handling PDU types 16
4.3. Application Unregistration for Handling PDU Types 17
5. Definitions 18
5.1. Definitions for SNMP Message Processing and Dispatching 18
6. The SNMPv3 Message Format 21
6.1. msgVersion 22
6.2. msgID 22
6.3. msgMaxSize 22
6.4. msgFlags 22
6.5. msgSecurityModel 24
6.6. msgSecurityParameters 24
6.7. scopedPduData 24
6.8. scopedPDU 24
6.8.1. contextEngineID 25
6.8.2. contextName 25
6.8.3. data 25
7. Elements of Procedure 26
7.1. Prepare an Outgoing SNMP Message 26
7.2. Prepare Data Elements from an Incoming SNMP Message 31
8. Security Considerations 36
9. Editor's Addresses 37
10. Acknowledgements 38
11. References 40
Case/Harrington/Wijnen Expires February 1998 [Page 41]
