As per Relevance of the word management, we have this rfc below:
Network Working Group J.
Request for Comments: 2262 SNMP Research, Inc
Category: Standards Track D.
Cabletron Systems, Inc
R.
BMC Software, Inc
B.
IBM T. J. Watson
January 1998
Message Processing and Dispatching for
Simple Network Management Protocol (SNMP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document describes the Message Processing and Dispatching
SNMP messages within the SNMP architecture [RFC2261]. It defines
procedures for dispatching potentially multiple versions of
messages to the proper SNMP Message Processing Models, and
dispatching PDUs to SNMP applications. This document also
one Message Processing Model - the SNMPv3 Message Processing Model
Table of
1. Introduction ............................................... 2
2. Overview ................................................... 3
2.1. The Dispatcher. .......................................... 5
2.2. Message Processing Subsystem ............................. 5
3. Elements of Message Processing and Dispatching ............. 6
3.1. messageProcessingModel ................................... 6
3.2. pduVersion ............................................... 6
3.3. pduType .................................................. 7
3.4. sendPduHandle ............................................ 7
4. Dispatcher Elements of Procedure ........................... 7
4.1. Sending an SNMP Message to the Network ................... 7
Case, et. al. Standards Track [Page 1]
RFC 2262 SNMPv3 Management Protocol January 1998
4.1.1. Sending a Request or Notification ...................... 7
4.1.2. Sending a Response to the Network ...................... 9
4.2. Receiving an SNMP Message from the Network ............... 10
4.2.1. Message Dispatching of received SNMP Messages .......... 10
4.2.2. PDU Dispatching for Incoming Messages .................. 11
4.2.2.1. Incoming Requests and Notifications .................. 12
4.2.2.2. Incoming Responses ................................... 13
4.3. Application Registration for Handling PDU types .......... 14
4.4. Application Unregistration for Handling PDU Types ........ 14
5. Definitions ................................................ 15
5.1. Definitions for SNMP Message Processing and Dispatching .. 15
6. The SNMPv3 Message Format .................................. 18
6.1. msgVersion ............................................... 19
6.2. msgID .................................................... 19
6.3. msgMaxSize ............................................... 19
6.4. msgFlags ................................................. 20
6.5. msgSecurityModel ......................................... 22
6.6. msgSecurityParameters .................................... 22
6.7. scopedPduData ............................................ 22
6.8. scopedPDU ................................................ 22
6.8.1. contextEngineID ........................................ 22
6.8.2. contextName ............................................ 23
6.8.3. data ................................................... 23
7. Elements of Procedure for v3MP ............................. 23
7.1. Prepare an Outgoing SNMP Message ......................... 24
7.2. Prepare Data Elements from an Incoming SNMP Message ...... 29
8. Intellectual Property ...................................... 34
9. Acknowledgements ........................................... 35
10. Security Considerations ................................... 36
11. References ................................................ 36
12. Editors' Addresses ........................................ 38
13. Full Copyright Statement .................................. 39
1.
The Architecture for describing Internet Management
[RFC2261] describes that an SNMP engine is composed of
1) a
2) a Message Processing Subsystem
3) a Security Subsystem,
4) an Access Control Subsystem
Applications make use of the services of these subsystems
It is important to understand the SNMP architecture and
terminology to understand where the Message Processing Subsystem
Dispatcher described in this document fit into the architecture
Case, et. al. Standards Track [Page 2]
RFC 2262 SNMPv3 Management Protocol January 1998
interact with other subsystems within the architecture. The
is expected to have read and understood the description of the
architecture, defined in [RFC2261].
The Dispatcher in the SNMP engine sends and receives SNMP messages
It also dispatches SNMP PDUs to SNMP applications. When an
message needs to be prepared or when data needs to be extracted
an SNMP message, the Dispatcher delegates these tasks to a
version-specific Message Processing Model within the
Processing Subsystem
A Message Processing Model is responsibile for processing a
version-specific message and for coordinating the interaction
the Security Subsystem to ensure proper security is applied to
SNMP message being handled
Interactions between the Dispatcher, the Message
Subsystem, and applications are modelled using abstract data
and abstract service interface primitives defined by the
architecture
Similarly, interactions between the Message Processing Subsystem
the Security Subsystem are modelled using abstract data elements
abstract service interface primitives as defined by the
architecture
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.
2.
The following illustration depicts the Message Processing in
to SNMP applications, the Security Subsystem and Transport Mappings
Case, et. al. Standards Track [Page 3]
RFC 2262 SNMPv3 Management Protocol January 1998
+-------------------------------------------------------------------+
| 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 * |<--->| +-------------+ | |
| +------------------+ | +------------+ | | | |
| ^ +---------------------+ +-----------------+ |
| | |
+----------|--------------------------------------------------------+
+------------------+
| Network |
+------------------+
Case, et. al. Standards Track [Page 4]
RFC 2262 SNMPv3 Management Protocol January 1998
2.1. The Dispatcher
The Dispatcher is a key piece of an SNMP engine. There is only one
an SNMP engine, and its job is to dispatch tasks to the
version-specific Message Processing Models, and to dispatch PDUs
various applications
For outgoing messages, an application provides a PDU to be sent,
the data needed to prepare and send the message, and the
specifies which version-specific Message Processing Model will
used to prepare the message with the desired security processing
Once the message is prepared, the Dispatcher sends the message
For incoming messages, the Dispatcher determines the SNMP version
the incoming message and passes the message to the version-
Message Processing Model to extract the components of the message
to coordinate the processing of security services for the message
After version-specific processing, the PDU Dispatcher
which application, if any, should receive the PDU for processing
forwards it accordingly
The Dispatcher, while sending and receiving SNMP messages,
statistics about SNMP messages and the behavior of the SNMP engine
managed objects to make them accessible to remote SNMP entities
This document defines these managed objects, the MIB module
contains them, and how these managed objects might be used to
useful management
2.2. Message Processing
The SNMP Message Processing Subsystem is the part of an SNMP
which interacts with the Dispatcher to handle the version-
SNMP messages. It contains one or more Message Processing Models
This document describes one Message Processing Model, the SNMPv
Message Processing Model, in Section 6. The SNMPv3 Message
Model is defined in a separate section to show that
(independent) Message Processing Models can exist at the same
and that such Models can be described in different documents.
SNMPv3 Message Processing Model can be replaced or supplemented
other Message Processing Models in the future. Two Message
Models which are expected to be developed in the future are
SNMPv1 message format [RFC1157] and the SNMPv2c message
[RFC1901]. Others may be developed as needed
Case, et. al. Standards Track [Page 5]
RFC 2262 SNMPv3 Management Protocol January 1998
3. Elements of Message Processing and
See [RFC2261] for the definitions
For incoming messages, a version-specific message processing
provides these values to the Dispatcher. For outgoing messages,
application provides these values to the Dispatcher
For some version-specific processing, the values may be
from received messages; for other versions, the values may
determined by algorithm, or by an implementation-defined mechanism
The mechanism by which the value is determined is irrelevant to
Dispatcher
The following additional or expanded definitions are for use
the Dispatcher
3.1.
The value of messageProcessingModel identifies a Message
Model. A Message Processing Model describes the version-
procedures for extracting data from messages, generating messages
calling upon a securityModel to apply its security services
messages, for converting data from a version-specific message
into a generic format usable by the Dispatcher, and for
data from Dispatcher format into a version-specific message format
3.2.
The value of pduVersion represents a specific version of
operation and its associated PDU formats, such as SNMPv1 or SNMPv
[RFC1905]. The values of pduVersion are specific to the version
the PDU contained in a message, and the PDUs processed
applications. The Dispatcher does not use the value of
directly
An application specifies the pduVersion when it requests the
Dispatcher to send a PDU to another SNMP engine. The
passes the pduVersion to a Message Processing Model, so it knows
to handle the PDU properly
Case, et. al. Standards Track [Page 6]
RFC 2262 SNMPv3 Management Protocol January 1998
For incoming messages, pduVersion is provided to the Dispatcher by
version-specific Message Processing module. The PDU Dispatcher
the pduVersion to the application so it knows how to handle the
properly. For example, a command responder application needs to
whether to use [RFC1905] elements of procedure and syntax instead
those specified for SNMPv1.
3.3.
A value of pduType represents a specific type of protocol operation
The values of pduType are specific to the version of the
contained in a message
Applications register to support particular pduTypes for
contextEngineIDs
For incoming messages, pduType is provided to the Dispatcher by
version-specific Message Processing module. It is subsequently
to dispatch the PDU to the application which registered for
pduType for the contextEngineID of the associated scopedPDU
3.4.
This handle is generated for coordinating the processing of
and responses between the SNMP engine and an application. The
must be unique across all version-specific Message Processing Models
and is of local significance only
4. Dispatcher Elements of
This section describes the procedures followed by the Dispatcher
generating and processing SNMP messages
4.1. Sending an SNMP Message to the
This section describes the procedure followed by an SNMP
whenever it sends an SNMP message
4.1.1. Sending a Request or
The following procedures are followed by the Dispatcher when
application wants to send an SNMP PDU to another (remote
application, i.e., to initiate a communication by originating
message, such as one containing a request or a trap
1) The application requests this using the abstract
primitive
Case, et. al. Standards Track [Page 7]
RFC 2262 SNMPv3 Management Protocol January 1998
statusInformation = -- sendPduHandle if
-- errorIndication if
sendPdu
IN transportDomain -- transport domain to be
IN transportAddress -- destination network
IN messageProcessingModel -- typically, SNMP
IN securityModel -- Security Model to
IN securityName -- on behalf of this
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this
IN contextName -- data from/in this
IN pduVersion -- the version of the
IN PDU -- SNMP Protocol Data
IN expectResponse -- TRUE or
)
2) If the messageProcessingModel value does not represent a
Processing Model known to the Dispatcher, then an
(implementation-dependent) is returned to the calling application
No further processing is performed
3) The Dispatcher generates a sendPduHandle to
subsequent processing
4) The Message Dispatcher sends the request to the version-
Message Processing module identified by
using the abstract service primitive
statusInformation = - success or error
prepareOutgoingMessage
IN transportDomain -- as specified by
IN transportAddress -- as specified by
IN messageProcessingModel -- as specified by
IN securityModel -- as specified by
IN securityName -- as specified by
IN securityLevel -- as specified by
IN contextEngineID -- as specified by
IN contextName -- as specified by
IN pduVersion -- the version of the
IN PDU -- as specified by
IN expectResponse -- as specified by
IN sendPduHandle -- as determined in step 3.
OUT destTransportDomain -- destination transport
OUT destTransportAddress -- destination transport
OUT outgoingMessage -- the message to
OUT outgoingMessageLength -- the message
)
Case, et. al. Standards Track [Page 8]
RFC 2262 SNMPv3 Management Protocol January 1998
5) If the statusInformation indicates an error, the
is returned to the calling application. No further processing
performed
6) If the statusInformation indicates success, the sendPduHandle
returned to the application, and the outgoingMessage is sent
the transport specified by the transportDomain to the
specified by the transportAddress
Outgoing Message Processing is complete
4.1.2. Sending a Response to the
The following procedure is followed when an application wants
return a response back to the originator of an SNMP Request
1) An application can request this using the abstract
primitive
returnResponsePDU
IN messageProcessingModel -- typically, SNMP
IN securityModel -- Security Model in
IN securityName -- on behalf of this
IN securityLevel -- same as on incoming
IN contextEngineID -- data from/at this SNMP
IN contextName -- data from/in this
IN pduVersion -- the version of the
IN PDU -- SNMP Protocol Data
IN maxSizeResponseScopedPDU -- maximum size of Response
IN stateReference -- reference to state
-- as presented with the
IN statusInformation -- success or
) -- (error counter OID and
-- when errorIndication
2) The Message Dispatcher sends the request to the
Message Processing Model indicated by the received value
messageProcessingModel using the abstract service primitive
result = -- SUCCESS or
prepareResponseMessage
IN messageProcessingModel -- specified by
IN securityModel -- specified by
IN securityName -- specified by
IN securityLevel -- specified by
IN contextEngineID -- specified by
IN contextName -- specified by
IN pduVersion -- specified by
Case, et. al. Standards Track [Page 9]
RFC 2262 SNMPv3 Management Protocol January 1998
IN PDU -- specified by
IN maxSizeResponseScopedPDU -- specified by
IN stateReference -- specified by
IN statusInformation -- specified by
OUT destTransportDomain -- destination transport
OUT destTransportAddress -- destination transport
OUT outgoingMessage -- the message to
OUT outgoingMessageLength -- the message
)
3) If the result is an errorIndication, the errorIndication
returned to the calling application. No further processing
performed
4) If the result is success, the outgoingMessage is sent over
transport specified by the transportDomain to the
specified by the transportAddress
Message Processing is complete
4.2. Receiving an SNMP Message from the
This section describes the procedure followed by an SNMP
whenever it receives an SNMP message
Please note, that for the sake of clarity and to prevent the
from being even longer and more complicated, some details
omitted from the steps below. In particular, The elements
procedure do not always explicitly indicate when state
needs to be released. The general rule is that if state
is available when a message is to be "discarded without
processing", then the state information must also be released at
same time
4.2.1. Message Dispatching of received SNMP
1) The snmpInPkts counter [RFC1907] is incremented
2) The version of the SNMP message is determined in
implementation-dependent manner. If the packet cannot
sufficiently parsed to determine the version of the SNMP message
then the snmpInASNParseErrs [RFC1907] counter is incremented,
the message is discarded without further processing. If
version is not supported, then the snmpInBadVersions [RFC1907]
counter is incremented, and the message is discarded
further processing
Case, et. al. Standards Track [Page 10]
RFC 2262 SNMPv3 Management Protocol January 1998
3) The origin transportDomain and origin transportAddress
determined
4) The message is passed to the version-specific Message
Model which returns the abstract data elements required by
Dispatcher. This is performed using the abstract
primitive
result = -- SUCCESS or
prepareDataElements
IN transportDomain -- origin as determined in step 3.
IN transportAddress -- origin as determined in step 3.
IN wholeMsg -- as received from the
IN wholeMsgLength -- as received from the
OUT messageProcessingModel -- typically, SNMP
OUT securityModel -- Security Model to
OUT securityName -- on behalf of this
OUT securityLevel -- Level of Security
OUT contextEngineID -- data from/at this
OUT contextName -- data from/in this
OUT pduVersion -- the version of the
OUT PDU -- SNMP Protocol Data
OUT pduType -- SNMP PDU
OUT sendPduHandle -- handle for a matched
OUT maxSizeResponseScopedPDU -- maximum size of Response
OUT statusInformation -- success or
-- (error counter OID and
-- when errorIndication
OUT stateReference -- reference to state
-- to be used for a
) --
5) If the result is a FAILURE errorIndication, the message
discarded without further processing
6) At this point, the abstract data elements have been prepared
processing continues as described in Section 4.2.2,
Dispatching for Incoming Messages
4.2.2. PDU Dispatching for Incoming
The elements of procedure for the dispatching of PDUs depends on
value of sendPduHandle. If the value of sendPduHandle is ,
then this is a request or notification and the procedures
in Section 4.2.2.1 apply. If the value of snmpPduHandle is
, then this is a response and the procedures specified
Section 4.2.2.2 apply
Case, et. al. Standards Track [Page 11]
RFC 2262 SNMPv3 Management Protocol January 1998
4.2.2.1. Incoming Requests and
The following procedures are followed for the dispatching of
when the value of sendPduHandle is , indicating this is
request or notification
1) The combination of contextEngineID and pduType is used
determine which application has registered for this request
notification
2) If no application has registered for the combination,
a) The snmpUnknownPDUHandlers counter is incremented
b) A Response message is generated using the abstract
primitive
result = -- SUCCESS or
prepareResponseMessage
IN messageProcessingModel -- as provided by MP
IN securityModel -- as provided by MP
IN securityName -- as provided by MP
IN securityLevel -- as provided by MP
IN contextEngineID -- as provided by MP
IN contextName -- as provided by MP
IN pduVersion -- as provided by MP
IN PDU -- as provided by MP
IN maxSizeResponseScopedPDU -- as provided by MP
IN stateReference -- as provided by MP
IN statusInformation -- errorIndication
-- snmpUnknownPDUHandlers
-- value pair
OUT transportDomain -- destination
OUT transportAddress -- destination
OUT outgoingMessage -- the message to
OUT outgoingMessageLength -- its
)
c) If the result is SUCCESS, then the prepared message is sent
the originator of the request as identified by
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
service primitive
Case, et. al. Standards Track [Page 12]
RFC 2262 SNMPv3 Management Protocol January 1998
processPdu( -- process Request/
IN messageProcessingModel -- as provided by MP
IN securityModel -- as provided by MP
IN securityName -- as provided by MP
IN securityLevel -- as provided by MP
IN contextEngineID -- as provided by MP
IN contextName -- as provided by MP
IN pduVersion -- as provided by MP
IN PDU -- as provided by MP
IN maxSizeResponseScopedPDU -- as provided by MP
IN stateReference -- as provided by MP
-- needed when sending
)
Message processing for this message is complete
4.2.2.2. Incoming
The following procedures are followed for the dispatching of
when the value of sendPduHandle is not , indicating this is
response
1) The value of sendPduHandle is used to determine, in
implementation-defined manner, which application is waiting
a response PDU associated with this sendPduHandle
2) If no waiting application is found, the message is
without further processing, and the stateReference is released
The snmpUnknownPDUHandlers counter is incremented.
Processing is complete for this message
3) Any cached information, including stateReference, about
message is discarded
4) The response is dispatched to the application using
abstract service primitive
processResponsePdu( -- process Response
IN messageProcessingModel -- provided by the MP
IN securityModel -- provided by the MP
IN securityName -- provided by the MP
IN securityLevel -- provided by the MP
IN contextEngineID -- provided by the MP
IN contextName -- provided by the MP
IN pduVersion -- provided by the MP
IN PDU -- provided by the MP
Case, et. al. Standards Track [Page 13]
RFC 2262 SNMPv3 Management Protocol January 1998
IN statusInformation -- provided by the MP
IN sendPduHandle -- provided by the MP
)
Message Processing is complete for this message
4.3. Application Registration for Handling PDU
Applications that want to process certain PDUs must register with
PDU Dispatcher. Applications specify the combination
contextEngineID and pduType(s) for which they want to
1) An application registers according to the abstract
primitive
statusInformation = -- success or
registerContextEngineID
IN contextEngineID -- take responsibility for this
IN pduType -- the pduType(s) to be
)
Note: implementations may provide a means of
registration for simultaneous multiple contextEngineID values
e.g., all contextEngineID values, and may also provide means
requesting simultaneous registration for multiple values
pduType
2) The parameters may be checked for validity; if they are not,
an errorIndication (invalidParameter) is returned to
application
3) Each combination of contextEngineID and pduType can be
only once. If another application has already registered for
specified combination, then an errorIndication (alreadyRegistered
is returned to the application
4) Otherwise, the registration is saved so that SNMP PDUs can
dispatched to this application
4.4. Application Unregistration for Handling PDU
Applications that no longer want to process certain PDUs
unregister with the PDU Dispatcher
1) An application unregisters using the abstract service primitive
Case, et. al. Standards Track [Page 14]
RFC 2262 SNMPv3 Management Protocol January 1998
unregisterContextEngineID
IN contextEngineID -- give up responsibility for
IN pduType -- the pduType(s) to be
)
Note: implementations may provide means for
unregistration for simultaneous multiple contextEngineID values
e.g., all contextEngineID values, and may also provide means
requesting simultaneous unregistration for multiple values
pduType
2) If the contextEngineID and pduType combination has
registered, then the registration is deleted
If no such registration exists, then the request is ignored
5.
5.1. Definitions for SNMP Message Processing and
SNMP-MPD-MIB DEFINITIONS ::=
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-
MODULE-IDENTITY, OBJECT-TYPE
snmpModules, Counter32 FROM SNMPv2-SMI
snmpMPDMIB MODULE-
LAST-UPDATED "9711200000Z" -- 20 November 1997
ORGANIZATION "SNMPv3 Working Group
CONTACT-INFO "WG-email: snmpv3@tis.
Subscribe: majordomo@tis.
In message body: subscribe snmpv
Chair: Russ
Trusted Information
postal: 3060 Washington
Glenwood, MD 21738
email: mundy@tis.
phone: +1 301-854-6889
Co-editor: Jeffrey
SNMP Research, Inc
postal: 3001 Kimberlin Heights
Knoxville, TN 37920-9716
email: case@snmp.
phone: +1 423-573-1434
Case, et. al. Standards Track [Page 15]
RFC 2262 SNMPv3 Management Protocol January 1998
Co-editor Dave
Cabletron Systems, Inc
postal: Post Office Box 5005
MailStop:
35 Industrial
Rochester, NH 03867-5005
email: dbh@ctron.
phone: +1 603-337-7357
Co-editor: Randy
BMC Software, Inc
postal: 1190 Saratoga Ave, Suite 190
San Jose, CA 95120
email: rpresuhn@bmc.
phone: +1 408-556-0720
Co-editor: Bert
IBM T. J. Watson
postal: Schagen 33
3461 GL
email: wijnen@vnet.ibm.
phone: +31 348-432-794
"
DESCRIPTION "The MIB for Message Processing and Dispatching
::= { snmpModules 3 }
-- 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-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
DESCRIPTION "The total number of packets received by the
engine which were dropped because they referenced
securityModel that was not known to or supported
the SNMP engine
Case, et. al. Standards Track [Page 16]
RFC 2262 SNMPv3 Management Protocol January 1998
"
::= { snmpMPDStats 1 }
snmpInvalidMsgs OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
DESCRIPTION "The total number of packets received by the
engine which were dropped because there were
or inconsistent components in the SNMP message
"
::= { snmpMPDStats 2 }
snmpUnknownPDUHandlers OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
DESCRIPTION "The total number of packets received by the
engine which were dropped because the PDU
in the packet could not be passed to an
responsible for handling the pduType, e.g. no
application had registered for the
combination of the contextEngineID and the pduType
"
::= { snmpMPDStats 3 }
-- Conformance information ******************************************
snmpMPDMIBCompliances OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1}
snmpMPDMIBGroups OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2}
-- Compliance
snmpMPDCompliance MODULE-
STATUS
DESCRIPTION "The compliance statement for SNMP entities
implement the SNMP-MPD-MIB
"
MODULE -- this
MANDATORY-GROUPS { snmpMPDGroup }
::= { snmpMPDMIBCompliances 1 }
snmpMPDGroup OBJECT-
OBJECTS {
snmpUnknownSecurityModels
Case, et. al. Standards Track [Page 17]
RFC 2262 SNMPv3 Management Protocol January 1998
snmpInvalidMsgs
}
STATUS
DESCRIPTION "A collection of objects providing for
monitoring of the SNMP Message Processing
Dispatching process
"
::= { snmpMPDMIBGroups 1 }
6. The SNMPv3 Message
This section defines the SNMPv3 message format and the
SNMP version 3 Message Processing Model (v3MP).
SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::=
SNMPv3Message ::= SEQUENCE {
-- identify the layout of the SNMPv3
-- this element is in same position as in SNMPv
-- and SNMPv2c, allowing
msgVersion INTEGER { snmpv3 (3) },
-- administrative
msgGlobalData HeaderData
-- security model-specific
-- format defined by Security
msgSecurityParameters OCTET STRING
msgData
}
HeaderData ::= SEQUENCE {
msgID INTEGER (0..2147483647),
msgMaxSize INTEGER (484..2147483647),
msgFlags OCTET STRING (SIZE(1)),
-- .... ...1
-- .... ..1.
-- .... .1..
-- Please observe
-- .... ..00 is OK, means
-- .... ..01 is OK, means
-- .... ..10 reserved, must NOT be used
-- .... ..11 is OK, means
msgSecurityModel INTEGER (0..2147483647)
}
Case, et. al. Standards Track [Page 18]
RFC 2262 SNMPv3 Management Protocol January 1998
ScopedPduData ::= CHOICE {
plaintext ScopedPDU
encryptedPDU OCTET STRING -- encrypted scopedPDU
}
ScopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING
contextName OCTET STRING
data ANY -- e.g., PDUs as defined in RFC1905
}
6.1.
The msgVersion field is set to snmpv3(3) and identifies the
as an SNMP version 3 Message
6.2.
The msgID is used between two SNMP entities to coordinate
messages and responses, and by the v3MP to coordinate the
of the message by different subsystem models within the architecture
Values for msgID should be generated in a manner that avoids re-
of any outstanding values. Doing so provides protection against
replay attacks. One possible implementation strategy would be to
the low-order bits of snmpEngineBoots [RFC2261] as the high-
portion of the msgID value and a monotonically increasing integer
the low-order portion of msgID
Note that the request-id in a PDU is used by SNMP applications
identify the PDU; the msgID is used by the engine to identify
message which carries a PDU. The engine may need to identify
message even if decrypting of the PDU (and request-id) fails.
assumption should be made that the value of the msgID and the
of the request-id are equivalent
6.3.
The msgMaxSize field of the message conveys the maximum message
supported by the sender of the message, i.e., the maximum
size that the sender can accept when another SNMP engine sends
SNMP message (be it a response or any other message) to the sender
this message
Case, et. al. Standards Track [Page 19]
RFC 2262 SNMPv3 Management Protocol January 1998
When an SNMP message is being generated, the msgMaxSize is
by the SNMP engine which generates the message. At the
SNMP engine, the msgMaxSize is used to determine how big the
to a Request message can be
6.4.
The msgFlags field of the message contains several bit fields
control processing of the message
When the reportableFlag is one, a Report PDU must be returned to
sender under those conditions which can cause the generation
Report PDUs. When the reportableFlag is zero, then a Report PDU
not be sent. The reportableFlag must always be zero when the
contains a Report PDU, a response-type PDU (such as a Response PDU),
or an unacknowledged notification-type PDU (such as an SNMPv2-
PDU). The reportableFlag must always be one for a request-type
(such as a Get PDU) and an acknowledged notification-type PDU (
as an Inform PDU).
If the reportableFlag is set to one for a message containing a
PDU, a response-type PDU (such as a Response PDU), or
unacknowledged notification-type PDU (such as an SNMPv2-trap PDU),
then the receiver of that message must process it as though
reportableFlag had been set to zero
If the reportableFlag is set to zero for a message containing
request-type PDU (such as a Get PDU) or an acknowledged notification
type PDU (such as an Inform PDU), then the receiver of that
must process it as though the reportableFlag had been set to one
Report PDUs are engine-to-engine communications and are
directly by the SNMPv3 Message Processing Model, and are
not passed to applications for processing, unlike all other
types
Note that the reportableFlag is a secondary aid in
whether a Report PDU must be sent. It is only used in cases
the PDU portion of a message cannot be decoded, due to, for example
an incorrect ecryption key. If the PDU can be decoded, the PDU
forms the basis for decisions on sending Report PDUs
The authFlag and privFlag portions of the msgFlags field are set
the sender to indicate the securityLevel that was applied to
message before it was sent on the wire. The receiver of the
must apply the same securityLevel when the message is received
the contents are being processed
Case, et. al. Standards Track [Page 20]
RFC 2262 SNMPv3 Management Protocol January 1998
There are three securityLevels, namely noAuthNoPriv, which is
than authNoPriv, which is in turn less than authPriv. See the
architecture document [RFC2261] for details about the securityLevel
a)
If the authFlag is set to one, then the securityModel used by
SNMP engine which sent the message must identify the
on whose behalf the SNMP message was generated and must provide
in a securityModel-specific manner, sufficient data for
receiver of the message to be able to authenticate
identification. In general, this authentication will allow
receiver to determine with reasonable certainty that the
was
- sent on behalf of the principal associated with
securityName
- was not redirected
- was not modified in transit,
- was not replayed
If the authFlag is zero, then the securityModel used by the
engine which sent the message must identify the securityName
whose behalf the SNMP message was generated but it does not
to provide sufficient data for the receiver of the message
authenticate the identification, as there is no need
authenticate the message in this case
b)
If the privFlag is set, then the securityModel used by the
engine which sent the message must also protect the scopedPDU
an SNMP message from disclosure, i.e., must encrypt/decrypt
scopedPDU. If the privFlag is zero, then the securityModel in
does not need to protect the data from disclosure
It is an explicit requirement of the SNMP architecture that
privacy is selected, then authentication is also required.
means that if the privFlag is set, then the authFlag must also
set to one
The combination of the authFlag and the privFlag comprises a
of Security as follows
authFlag zero, privFlag zero -> securityLevel is
Case, et. al. Standards Track [Page 21]
RFC 2262 SNMPv3 Management Protocol January 1998
authFlag zero, privFlag one -> invalid
authFlag one, privFlag zero -> securityLevel is
authFlag one, privFlag one -> securityLevel is
6.5.
The v3MP supports the concurrent existence of multiple
Models to provide security services for SNMPv3 messages.
msgSecurityModel field in an SNMPv3 Message identifies which
Model was used by the sender to generate the message and
which securityModel must be used by the receiver to perform
processing for the message. The mapping to the
securityModel implementation within an SNMP engine is accomplished
an implementation-dependent manner
6.6.
The msgSecurityParameters field of the SNMPv3 Message is used
communication between the Security Model modules in the sending
receiving SNMP engines. The data in the msgSecurityParameters
is used exclusively by the Security Model, and the contents
format of the data is defined by the Security Model. This
STRING is not interpreted by the v3MP, but is passed to the
implementation of the Security Model indicated by
msgSecurityModel field in the message
6.7.
The scopedPduData field represents either the plain text scopedPDU
the privFlag in the msgFlags is zero, or it represents
encryptedPDU (encoded as an OCTET STRING) which must be decrypted
the securityModel in use to produce a plaintext scopedPDU
6.8.
The scopedPDU contains information to identify an
unique context and a PDU. The object identifiers in the PDU refer
managed objects which are (expected to be) accessible within
specified context
6.8.1.
The contextEngineID in the SNMPv3 message, uniquely identifies
within an administrative domain, an SNMP entity that may realize
instance of a context with a particular contextName
Case, et. al. Standards Track [Page 22]
RFC 2262 SNMPv3 Management Protocol January 1998
For incoming messages, the contextEngineID is used to determine
which application the scopedPDU will be sent for processing
For outgoing messages, the v3MP sets the contextEngineID to the
provided by the application in the request for a message to be sent
6.8.2.
The contextName field in an SNMPv3 message, in conjunction with
contextEngineID field, identifies the particular context
with the management information contained in the PDU portion of
message. The contextName is unique within the SNMP entity
by the contextEngineID, which may realize the managed
referenced within the PDU. An application which originates a
provides the value for the contextName field and this value may
used during processing by an application at the receiving
Engine
6.8.3.
The data field of the SNMPv3 Message contains the PDU. Among
things, the PDU contains the PDU type that is used by the v3MP
determine the type of the incoming SNMP message. The v3MP
that the PDU must be one of those specified in [RFC1905].
7. Elements of Procedure for v3
This section describes the procedures followed by an SNMP engine
generating and processing SNMP messages according to the SNMPv
Message Processing Model
Please note, that for the sake of clarity and to prevent the
from being even longer and more complicated, some details
omitted from the steps below
a) Some steps specify that when some error conditions
encountered when processing a received message, a
containing a Report PDU is generated and the received
is discarded without further processing. However, a Report-
must not be generated unless the reportableFlag is set in
received message
b) The elements of procedure do not always explicitly
when state information needs to be released. The general
is that if state information is available when a message is
be "discarded without further processing", then the
information must also be released at that same time
Case, et. al. Standards Track [Page 23]
RFC 2262 SNMPv3 Management Protocol January 1998
7.1. Prepare an Outgoing SNMP
This section describes the procedure followed to prepare an SNMPv
message from the data elements passed by the Message Dispatcher
1) The Message Dispatcher may request that an SNMPv3
containing a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest
PDU, SetRequest-PDU, InformRequest-PDU, or SNMPv2-Trap-PDU
prepared for sending
a) It makes such a request according to the abstract
primitive
statusInformation = -- success or
prepareOutgoingMessage
IN transportDomain -- requested transport
IN transportAddress -- requested destination
IN messageProcessingModel -- typically, SNMP
IN securityModel -- Security Model to
IN securityName -- on behalf of this
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this
IN contextName -- data from/in this
IN pduVersion -- version of the
IN PDU -- SNMP Protocol Data
IN expectResponse -- TRUE or
IN sendPduHandle -- the handle for
-- incoming
OUT destTransportDomain -- destination transport
OUT destTransportAddress -- destination transport
OUT outgoingMessage -- the message to
OUT outgoingMessageLength -- the length of the
)
b) A unique msgID is generated. The number used for msgID
not have been used recently, and must not be the same as
used for any outstanding request
* SNMPv3 does not use the values of expectResponse
pduVersion
2) The Message Dispatcher may request that an SNMPv3
containing a Response-PDU or Report-PDU be prepared for sending
a) It makes such a request according to the abstract
primitive
Case, et. al. Standards Track [Page 24]
RFC 2262 SNMPv3 Management Protocol January 1998
result = -- SUCCESS or
prepareResponseMessage
IN messageProcessingModel -- typically, SNMP
IN securityModel -- same as on incoming
IN securityName -- same as on incoming
IN securityLevel -- same as on incoming
IN contextEngineID -- data from/at this SNMP
IN contextName -- data from/in this
IN pduVersion -- version of the
IN PDU -- SNMP Protocol Data
IN maxSizeResponseScopedPDU -- maximum size of Response
IN stateReference -- reference to
-- information presented
-- the
IN statusInformation -- success or
-- error counter OID and
-- when
OUT transportDomain -- destination transport
OUT transportAddress -- destination transport
OUT outgoingMessage -- the message to
OUT outgoingMessageLength -- the length of the
)
b) The cached information for the original request is
via the stateReference,
- msgID
- contextEngineID
- contextName
- securityModel
- securityName
- securityLevel
- securityStateReference
- reportableFlag
- transportDomain,
- transportAddress
The SNMPv3 Message Processing Model does not allow cached
to be overridden, except by error indications as detailed
(3) below
3) If statusInformation contains values for an OID/value
(potentially also containing a securityLevel value
contextEngineID value, or contextName value),
a) If reportableFlag is zero, then the original message
discarded, and no further processing is done. A result
FAILURE is returned. SNMPv3 Message Processing is complete
Case, et. al. Standards Track [Page 25]
RFC 2262 SNMPv3 Management Protocol January 1998
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
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) The errorIndication in statusInformation may be accompanied
a securityLevel value, a contextEngineID value, or
contextName value
1) If statusInformation contains a value for securityLevel
then securityLevel is set to that value, otherwise it is
to noAuthNoPriv
2) If statusInformation contains a value for contextEngineID
then contextEngineID is set to that value, otherwise it
set to the value of this entity's snmpEngineID
3) If statusInformation contains a value for contextName,
contextName is set to that value, otherwise it is set to
default context of "" (zero-length string).
e) PDU is set to refer to the new Report-PDU. The old PDU
discarded
f) Processing continues with step 6) below
4) If contextEngineID is not yet determined, then the
is determined, in an implementation-dependent manner,
using the transportDomain and transportAddress
5) If the contextName is not yet determined, the contextName is
to the default context
6) A scopedPDU is prepared from the contextEngineID, contextName,
PDU
Case, et. al. Standards Track [Page 26]
RFC 2262 SNMPv3 Management Protocol January 1998
7) msgGlobalData is constructed as
a) The msgVersion field is set to snmpv3(3).
b) msgID is set as determined in step 1 or 2 above
c) msgMaxSize is set to an implementation-dependent value
d) msgFlags are set as follows
- If securityLevel specifies noAuthNoPriv, then authFlag
privFlag are both set to zero
- If securityLevel specifies authNoPriv, then authFlag is
to one and privFlag is set to zero
- If securityLevel specifies authPriv, then authFlag is set
one and privFlag is set to one
- If the PDU is a Response-PDU, Report-PDU or SNMPv2-Trap-PDU
then the reportableFlag is set to zero
- If the PDU is a GetRequest-PDU, GetNextRequest-PDU
GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-
then the reportableFlag is set to one
- All other msgFlags bits are set to zero
e) msgSecurityModel is set to the value of
8) If the PDU is a Response-PDU or Report-PDU,
a) The specified Security Model is called to generate the
according to the primitive
statusInformation =
generateResponseMsg
IN messageProcessingModel -- SNMPv3 Message
--
IN globalData -- msgGlobalData from step 7
IN maxMessageSize -- from msgMaxSize (step 7c
IN securityModel -- as determined in step 7
IN securityEngineID -- the value of
IN securityName -- on behalf of this
IN securityLevel -- for the outgoing
IN scopedPDU -- as prepared in step 6)
IN securityStateReference -- as determined in step 2
OUT securityParameters -- filled in by Security
Case, et. al. Standards Track [Page 27]
RFC 2262 SNMPv3 Management Protocol January 1998
OUT wholeMsg -- complete generated
OUT wholeMsgLength -- length of generated
)
If, upon return from the Security Model, the
includes an errorIndication, then any cached information
the outstanding request message is discarded, and
errorIndication is returned, so it can be returned to
calling application. SNMPv3 Message Processing is complete
b) A SUCCESS result is returned. SNMPv3 Message Processing
complete
9) If the PDU is a GetRequest-PDU, GetNextRequest-PDU
GetBulkRequest-PDU, SetRequest-PDU, InformRequest-PDU, or
SNMPv2-Trap-PDU,
a) If the PDU is an SNMPv2-Trap-PDU, then securityEngineID is
to the value of this entity's snmpEngineID
Otherwise, the snmpEngineID of the target entity is determined
in an implementation-dependent manner, possibly
transportDomain and transportAddress. The value
securityEngineID is set to the value of the target entity'
snmpEngineID
b) The specified Security Model is called to generate the
according to the primitive
statusInformation =
generateRequestMsg
IN messageProcessingModel -- SNMPv3 Message Processing
IN globalData -- msgGlobalData, from step 7
IN maxMessageSize -- from msgMaxSize in step 7 c
IN securityModel -- as provided by
IN securityEngineID -- authoritative SNMP
IN securityName -- as provided by
IN securityLevel -- as provided by
IN snmpEngineID -- as determined in step 9 a
IN scopedPDU -- as prepared in step 6
OUT securityParameters -- filled in by Security
OUT wholeMsg -- complete generated
OUT wholeMsgLength -- length of the generated
)
Case, et. al. Standards Track [Page 28]
RFC 2262 SNMPv3 Management Protocol January 1998
If, upon return from the Security Model, the
includes an errorIndication, then the message is discarded,
the errorIndication is returned, so it can be returned to
calling application, and no further processing is done
SNMPv3 Message Processing is complete
c) Information about the outgoing message is cached, and
stateReference is created (implementation-specific).
Information to be cached includes the values of
-
-
-
-
-
-
-
-
d) A SUCCESS result is returned. SNMPv3 Message Processing
complete
7.2. Prepare Data Elements from an Incoming SNMP
This section describes the procedure followed to extract data from
SNMPv3 message, and to prepare the data elements required for
processing of the message by the Message Dispatcher
1) The message is passed in from the Message Dispatcher according
the abstract service primitive
result = -- SUCCESS or
prepareDataElements
IN transportDomain -- origin transport
IN transportAddress -- origin transport
IN wholeMsg -- as received from the
IN wholeMsgLength -- as received from the
OUT messageProcessingModel -- typically, SNMP
OUT securityModel -- Security Model to
OUT securityName -- on behalf of this
OUT securityLevel -- Level of Security
OUT contextEngineID -- data from/at this
OUT contextName -- data from/in this
OUT pduVersion -- version of the
OUT PDU -- SNMP Protocol Data
OUT pduType -- SNMP PDU
OUT sendPduHandle -- handle for matched
OUT maxSizeResponseScopedPDU -- maximum size of Response
Case, et. al. Standards Track [Page 29]
RFC 2262 SNMPv3 Management Protocol January 1998
OUT statusInformation -- success or
-- error counter OID and
-- when
OUT stateReference -- reference to state
-- to be used for a
) --
2) If the received message is not the serialization (according
the conventions of [RFC1906]) of an SNMPv3Message value, then
snmpInASNParseErrs counter [RFC1907] is incremented, the
is discarded without further processing, and a FAILURE result
returned. SNMPv3 Message Processing is complete
3) The values for msgVersion, msgID, msgMaxSize, msgFlags
msgSecurityModel, msgSecurityParameters, and msgData are
from the message
4) If the value of the msgSecurityModel component does not match
supported securityModel, then the
counter is incremented, a Report PDU is generated, the message
discarded without further processing, and a FAILURE result
returned. SNMPv3 Message Processing is complete
5) The securityLevel is determined from the authFlag and
privFlag bits of the msgFlags component as follows
a) If the authFlag is not set and the privFlag is not set,
securityLevel is set to noAuthNoPriv
b) If the authFlag is set and the privFlag is not set,
securityLevel is set to authNoPriv
c) If the authFlag is set and the privFlag is set,
securityLevel is set to authPriv
d) If the authFlag is not set and privFlag is set, then
snmpInvalidMsgs counter is incremented, a Report PDU
generated, the message is discarded without further processing
and a FAILURE result is returned. SNMPv3 Message Processing
complete
6) The security module implementing the Security Model as
by the securityModel component is called for authentication
privacy services. This is done according to the abstract
primitive
statusInformation = -- errorIndication or
-- error counter OID
Case, et. al. Standards Track [Page 30]
RFC 2262 SNMPv3 Management Protocol January 1998
-- value if
processIncomingMsg
IN messageProcessingModel -- SNMPv3 Message Processing
IN expectResponse -- TRUE or
IN maxMessageSize -- of the sending SNMP
IN securityParameters -- for the received
IN securityModel -- for the received
IN securityLevel -- Level of
IN wholeMsg -- as received on the
IN wholeMsgLength -- length as received on the
OUT securityEngineID -- authoritative SNMP
OUT securityName -- identification of the
OUT scopedPDU, -- message (plaintext)
OUT maxSizeResponseScopedPDU -- maximum size of Response
OUT securityStateReference -- reference to security
) -- information, needed
--
If an errorIndication is returned by the security module,
a) If statusInformation contains values for an OID/value pair
then a Report PDU is generated
1) If the scopedPDU has been returned from
then determine contextEngineID, contextName, and PDU
2) Information about the message is cached and
stateReference is created (implementation-specific).
Information to be cached includes the values of
msgVersion
msgID
securityLevel
msgFlags
msgMaxSize
securityModel
maxSizeResponseScopedPDU
3) Request that a Report-PDU be prepared and sent,
to the abstract service primitive
result = -- SUCCESS or
returnResponsePDU
IN messageProcessingModel -- SNMPv3(3)
IN securityModel -- same as on incoming
IN securityName -- from
IN securityLevel -- same as on incoming
Case, et. al. Standards Track [Page 31]
RFC 2262 SNMPv3 Management Protocol January 1998
IN contextEngineID -- from step 6 a) 1)
IN contextName -- from step 6 a) 1)
IN pduVersion -- SNMPv2-
IN PDU -- from step 6 a) 1)
IN maxSizeResponseScopedPDU -- from
IN stateReference -- from step 6 a) 2)
IN statusInformation -- from
OUT transportDomain -- destination's
--
OUT transportAddress -- destination's
--
OUT outgoingMessage -- the message to
OUT outgoingMessageLength -- the length of the
)
b) The incoming message is discarded without further processing
and a FAILURE result is returned. SNMPv3 Message Processing
complete
7) The scopedPDU is parsed to extract the contextEngineID,
contextName and the PDU. If any parse error occurs, then
snmpInASNParseErrs counter [RFC1907] is incremented, the
state information is discarded, the message is discarded
further processing, and a FAILURE result is returned. SNMPv
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
- an SNMPv2-Trap-PDU
- a Response-PDU,
- a Report-PDU
10) If the pduType is a Response-PDU or Report-PDU,
a) The value of the msgID component is used to find the
information for a corresponding outstanding Request message
If no such outstanding Request message is found, then
security state information is discarded, the message
discarded without further processing, and a FAILURE result
returned. SNMPv3 Message Processing is complete
Case, et. al. Standards Track [Page 32]
RFC 2262 SNMPv3 Management Protocol January 1998
b) sendPduHandle is retrieved from the cached information
Otherwise, sendPduHandle is set to , an
defined value
11) If the pduType is a Report-PDU,
a) statusInformation is created using the contents of
Report-PDU, in an implementation-dependent manner.
statusInformation will be forwarded to the
associated with the sendPduHandle
b) Any cached information about the outstanding Request
message is discarded
c) The security state information for this incoming message
discarded
d) stateReference is set to
e) A SUCCESS result is returned. SNMPv3 Message Processing
complete
12) If the pduType is a Response-PDU,
a) The cached data for the outstanding request, referred to
stateReference, is retrieved,
-
-
-
-
-
-
b) If the values extracted from the incoming message differ
the cached data, then the security state information
discarded, any cached information about the
Request message is discarded, the incoming message
discarded without further processing, and a FAILURE result
returned. SNMPv3 Message Processing is complete
c) Otherwise, any cached information about the
Request message is discarded, and stateReference is set
.
d) A SUCCESS result is returned. SNMPv3 Message Processing
complete
Case, et. al. Standards Track [Page 33]
RFC 2262 SNMPv3 Management Protocol January 1998
13) If the pduType is a GetRequest-PDU, GetNextRequest-PDU
GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU,
a) If the value of securityEngineID is not equal to the value
snmpEngineID, then the security state information
discarded, any cached information about the
Request message is discarded, the incoming message
discarded without further processing, and a FAILURE result
returned. SNMPv3 Message Processing is complete
b) Information about the message is cached and a
is created (implementation-specific). Information to
cached includes the values of
msgVersion
msgID
securityLevel
msgFlags
msgMaxSize
securityModel
maxSizeResponseScopedPDU
c) A SUCCESS result is returned. SNMPv3 Message Processing
complete
14) If the pduType is an SNMPv2-Trap-PDU, then A SUCCESS result
returned. SNMPv3 Message Processing is complete
8. Intellectual
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat
Case, et. al. Standards Track [Page 34]
RFC 2262 SNMPv3 Management Protocol January 1998
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
9.
This document is the result of the efforts of the SNMPv3
Group. Some special thanks are in order to the following SNMPv3
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
Administrative Framework Evolution for SNMP Advisory Team.
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)
Shawn Routhier (Epilogue
Glenn Waters (Nortel
Bert Wijnen (IBM T. J. Watson Research Center
Case, et. al. Standards Track [Page 35]
RFC 2262 SNMPv3 Management Protocol January 1998
As recommended by the Advisory Team and the SNMPv3 Working
Charter, the design incorporates as much as practical from
RFCs and drafts. As a result, special thanks are due to the
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
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.)
10. Security
The Dispatcher coordinates the processing of messages to provide
level of security for management messages and to direct the SNMP
to the proper SNMP application(s).
A Message Processing Model, and in particular the V3MP defined
this document, interacts as part of the Message Processing
Security Models in the Security Subsystem via the abstract
interface primitives defined in [RFC2261] and elaborated above
The level of security actually provided is primarily determined
the specific Security Model implementation(s) and the specific
application implementation(s) incorporated into this framework
Applications have access to data which is not secured.
should take reasonable steps to protect the data from disclosure,
when they send data across the network, they should obey
securityLevel and call upon the services of an Access Control
as they apply access control
The values for the msgID element used in communication between
entities must be chosen to avoid replay attacks. The values do
need to be unpredictable; it is sufficient that they not repeat
11.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser
"Introduction to Community-based SNMPv2",
RFC 1901, January 1996.
Case, et. al. Standards Track [Page 36]
RFC 2262 SNMPv3 Management Protocol January 1998
[RFC1902] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser
"Structure of Management Information
Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1902, January 1996.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser
"Protocol Operations for Version 2 of
Simple Network Management Protocol (SNMPv2)", RFC 1905,
1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser
"Transport Mappings for Version 2 of
Simple Network Management Protocol (SNMPv2)", RFC 1906,
1996.
[RFC1907] 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] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser
"Coexistence between Version 1 and
2 of the Internet-standard Network Management Framework",
1908, January 1996.
[RFC 2028] Hovey, R., and S. Bradner, "The Organizations Involved
the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2261] Harrington, D., Presuhn, R., and B. Wijnen, "
Architecture for describing SNMP Management Frameworks",
RFC 2261, January 1998.
[RFC2264] Blumenthal, U., and B. Wijnen, "The User-
Security Model for Version 3 of the Simple
Management Protocol (SNMPv3)", RFC 2264, January 1998.
[RFC2265] Wijnen, B., Presuhn, R., and K. McCloghrie
"View-based Access Control Model for the
Network Management Protocol (SNMP)", RFC 2265, January 1998.
[RFC2263] Levi, D., Meyer, P., and B. Stewart, "SNMPv
Applications", RFC 2263, January 1998.
Case, et. al. Standards Track [Page 37]
RFC 2262 SNMPv3 Management Protocol January 1998
12. Editors'
Jeffrey
SNMP Research, Inc
3001 Kimberlin Heights
Knoxville, TN 37920-9716
Phone: +1 423-573-1434
EMail: case@snmp.
Dave
Cabletron Systems,
Post Office Box 5005
Mail Stop:
35 Industrial
Rochester, NH 03867-5005
Phone: +1 603-337-7357
EMail: dbh@ctron.
Randy
BMC Software, Inc
1190 Saratoga
Suite 130
San Jose, CA 95129
Phone: +1 408-556-0720
EMail: rpresuhn@bmc.
Bert
IBM T. J. Watson
Schagen 33
3461 GL
Phone: +31 348-432-794
EMail: wijnen@vnet.ibm.
Case, et. al. Standards Track [Page 38]
RFC 2262 SNMPv3 Management Protocol January 1998
13. Full Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Case, et. al. Standards Track [Page 39]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
