rfc2572.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,614 行 · 第 1/5 页

                    the SNMP engine.
                   "
       ::= { 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, e.g. no SNMP
                    application had registered for the proper
                    combination of the contextEngineID and the pduType.
                   "
       ::= { snmpMPDStats 3 }

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



SNMPv3 Working Group        Standards Track                    [Page 18]

RFC 2572           Message Processing and Dispatching           April 1999


                    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





























SNMPv3 Working Group        Standards Track                    [Page 19]

RFC 2572           Message Processing and Dispatching           April 1999


6.  The SNMPv3 Message Format

   This section defines the SNMPv3 message format and the corresponding
   SNMP version 3 Message Processing Model (v3MP).
   SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

       SNMPv3Message ::= SEQUENCE {
           -- identify the layout of the SNMPv3Message
           -- this element is in same position as in SNMPv1
           -- and SNMPv2c, allowing recognition
           -- the value 3 is used for snmpv3
           msgVersion INTEGER ( 0 .. 2147483647 ),
           -- administrative parameters
           msgGlobalData HeaderData,
           -- security model-specific parameters
           -- format defined by Security Model
           msgSecurityParameters OCTET STRING,
           msgData  ScopedPduData
       }

       HeaderData ::= SEQUENCE {
           msgID      INTEGER (0..2147483647),
           msgMaxSize INTEGER (484..2147483647),

           msgFlags   OCTET STRING (SIZE(1)),
                      --  .... ...1   authFlag
                      --  .... ..1.   privFlag
                      --  .... .1..   reportableFlag
                      --              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 (1..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 RFC 1905
       }
   END



SNMPv3 Working Group        Standards Track                    [Page 20]

RFC 2572           Message Processing and Dispatching           April 1999



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.

   Values for msgID SHOULD be generated in a manner that avoids re-use
   of any outstanding values.  Doing so provides protection against some
   replay attacks.  One possible implementation strategy would be to use
   the low-order bits of snmpEngineBoots [RFC2571] as the high-order
   portion of the msgID value and a monotonically increasing integer for
   the low-order portion of msgID.

   Note that the request-id in a PDU may be 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 needs to identify the message
   even if decryption 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.

   The value of the msgID field for a response takes the value of the
   msgID field from the message to which it is a response.  By use of
   the msgID value, an engine can distinguish the (potentially multiple)
   outstanding requests, and thereby correlate incoming responses with
   outstanding requests.  In cases where an unreliable datagram service
   is used, the msgID also provides a simple means of identifying
   messages duplicated by the network.  If a request is retransmitted, a
   new msgID value SHOULD be used for each retransmission.

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 on the transport in use for 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 the maximum message
   size the sender can accommodate.




SNMPv3 Working Group        Standards Track                    [Page 21]

RFC 2572           Message Processing and Dispatching           April 1999


6.4.  msgFlags

   The msgFlags field of the message contains several bit fields which
   control processing of the message.

   The reportableFlag is a secondary aid in determining whether a Report
   PDU must be sent.  It is only used in cases where the PDU portion of
   a message cannot be decoded, due to, for example, an incorrect
   encryption key.  If the PDU can be decoded, the PDU type forms the
   basis for decisions on sending Report PDUs.

   When the reportableFlag is used, if its value is one, a Report PDU
   MUST be returned to the sender under those conditions which can cause
   the generation of Report PDUs.  Similarly, when the reportableFlag is
   used and its value is zero, then a Report PDU MUST NOT be sent.  The
   reportableFlag MUST always be zero when the message contains a PDU
   from the Unconfirmed Class, such as a Report PDU, a response-type PDU
   (such as a Response PDU), or an unacknowledged notification-type PDU
   (such as an SNMPv2-trap PDU).  The reportableFlag MUST always be one
   for a PDU from the Confirmed Class, include request-type PDUs (such
   as a Get PDU) and an acknowledged notification-type PDUs (such as an
   Inform PDU).

   If the reportableFlag is set to one for a message containing a PDU
   from the Unconfirmed Class, such as a Report PDU, a response-type PDU
   (such as a Response PDU), or an unacknowledged notification-type PDU
   (such as an SNMPv2-trap PDU), then the receiver of that message MUST
   process it as though the reportableFlag had been set to zero.

   If the reportableFlag is set to zero for a message containing a
   request-type PDU (such as a Get PDU) or an acknowledged
   notification-type PDU (such as an Inform PDU), then the receiver of
   that message must process it as though the reportableFlag had been
   set to one.

   Report PDUs are generated directly by the SNMPv3 Message Processing
   Model, and support engine-to-engine communications, but may be passed
   to applications for processing.

   An SNMP engine that receives a reportPDU may use it to determine what
   kind of problem was detected by the remote SNMP engine.  It can do so
   based on the error counter included as the first (and only) varBind
   of the reportPDU.  Based on the detected error, the SNMP engine may
   try to send a corrected SNMP message.  If that is not possible, it
   may pass an indication of the error to the application on whose
   behalf the failed SNMP request was issued.





SNMPv3 Working Group        Standards Track                    [Page 22]

RFC 2572           Message Processing and Dispatching           April 1999


   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
   MUST apply the same securityLevel when the message is received and
   the contents are being processed.

   There are three securityLevels, namely noAuthNoPriv, which is less
   than authNoPriv, which is in turn less than authPriv.  See the SNMP
   architecture document [RFC2571] for details about the securityLevel.

   a) authFlag

      If the authFlag is set to one, 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 zero, 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., it MUST encrypt/decrypt the
      scopedPDU. If the privFlag is zero, then the securityModel in use
      does not need to protect the data from disclosure.







SNMPv3 Working Group        Standards Track                    [Page 23]

RFC 2572           Message Processing and Dispatching           April 1999