rfc2572.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,654 行 · 第 1/5 页

                   "
       ::= { 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


      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 MUST also be
      set to one.

      The combination of the authFlag and the privFlag comprises a Level
      of Security as follows:
         authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv
         authFlag zero, privFlag one  -> invalid combination, see below
         authFlag one,  privFlag zero -> securityLevel is authNoPriv
         authFlag one,  privFlag one  -> securityLevel is authPriv

   The elements of procedure (see below) describe the action to be taken
   when the invalid combination of authFlag equal to zero and privFlag
   equal to one is encountered.

   The remaining bits in msgFlags are reserved, and MUST be set to zero
   when sending a message and SHOULD be ignored when receiving a
   message.

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