rfc2262.txt

RFC 的详细文档！

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



Case, et. al.               Standards Track                    [Page 17]

RFC 2262               SNMPv3 Management Protocol           January 1998


                 snmpInvalidMsgs,
                 snmpUnknownPDUHandlers
               }
       STATUS       current
       DESCRIPTION "A collection of objects providing for remote
                    monitoring of the SNMP Message Processing and
                    Dispatching process.
                   "
       ::= { snmpMPDMIBGroups 1 }

   END

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
           msgVersion INTEGER { snmpv3 (3) },
           -- 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 (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 value
       }

       ScopedPDU ::= SEQUENCE {
           contextEngineID  OCTET STRING,
           contextName      OCTET STRING,
           data             ANY -- e.g., PDUs as defined in RFC1905
       }
   END

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 [RFC2261] 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 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.







Case, et. al.               Standards Track                    [Page 19]

RFC 2262               SNMPv3 Management Protocol           January 1998


   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
   control processing of the message.

   When the reportableFlag is one, a Report PDU must be returned to the
   sender under those conditions which can cause the generation of
   Report PDUs.  When the reportableFlag is zero, then a Report PDU must
   not be sent.  The reportableFlag must always be zero when the message
   contains 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 request-type PDU
   (such as a Get PDU) and an acknowledged notification-type PDU (such
   as an Inform PDU).

   If the reportableFlag is set to one for a message containing 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 engine-to-engine communications and are processed
   directly by the SNMPv3 Message Processing Model, and are generally
   not passed to applications for processing, unlike all other PDU
   types.

   Note that 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 ecryption key.  If the PDU can be decoded, the PDU type
   forms the basis for decisions on sending Report PDUs.

   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.




Case, et. al.               Standards Track                    [Page 20]

RFC 2262               SNMPv3 Management Protocol           January 1998


   There are three securityLevels, namely noAuthNoPriv, which is less
   than authNoPriv, which is in turn less than authPriv.  See the SNMP
   architecture document [RFC2261] 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., must encrypt/decrypt the
      scopedPDU. If the privFlag is zero, then the securityModel in use
      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 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



Case, et. al.               Standards Track                    [Page 21]

RFC 2262               SNMPv3 Management Protocol           January 1998


         authFlag zero, privFlag one  -> invalid combination
         authFlag one,  privFlag zero -> securityLevel is authNoPriv
         authFlag one,  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 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.

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 (encoded as an OCTET STRING) 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.

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.






Case, et. al.               Standards Track                    [Page 22]

RFC 2262               SNMPv3 Management Protocol           January 1998