rfc2570.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   The SNMPv3 document series defined by the SNMPv3 Working Group
   consists of seven documents at this time:

      RFC 2570, "Introduction to Version 3 of the Internet-standard
      Network Management Framework", which is this document.

      RFC 2571, "An Architecture for Describing SNMP Management
      Frameworks" [15], describes the overall architecture with special
      emphasis on the architecture for security and administration.

      RFC 2572, "Message Processing and Dispatching for the Simple
      Network Management Protocol (SNMP)" [16], describes the possibly
      multiple message processing models and the dispatcher portion that
      can be a part of an SNMP protocol engine.

      RFC 2573, "SNMP Applications" [17], describes the five types of
      applications that can be associated with an SNMPv3 engine and
      their elements of procedure.

      RFC 2574, "The User-Based Security Model for Version 3 of the
      Simple Network Management Protocol (SNMPv3)" [18], describes the
      threats, mechanisms, protocols, and supporting data used to
      provide SNMP message-level security.




Case, et al.                 Informational                     [Page 12]

RFC 2570                 Introduction to SNMPv3               April 1999


      RFC 2575, "View-based Access Control Model for the Simple Network
      Management Protocol (SNMP)" [19], describes how view-based access
      control can be applied within command responder and notification
      originator applications.

      The Work in Progress, "Coexistence between Version 1, Version 2,
      and Version 3 of the Internet-standard Network Management
      Framework" [20], describes coexistence between the SNMPv3
      Management Framework, the SNMPv2 Management Framework, and the
      original SNMPv1 Management Framework.

7 Document Summaries

   The following sections provide brief summaries of each document with
   slightly more detail than is provided in the overviews above.

7.1 Structure of Management Information

   Management information is viewed as a collection of managed objects,
   residing in a virtual information store, termed the Management
   Information Base (MIB).  Collections of related objects are defined
   in MIB modules.  These modules are written in the SNMP MIB module
   language, which contains elements of OSI's Abstract Syntax Notation
   One (ASN.1) [11] language.   STD 58, RFCs 2578, 2579, 2580, together
   define the MIB module language, specify the base data types for
   objects, specify a core set of short-hand specifications for data
   types called textual conventions, and specify a few administrative
   assignments of object identifier (OID) values.

   The SMI is divided into three parts:  module definitions, object
   definitions, and notification definitions.

   (1)  Module definitions are used when describing information modules.
        An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the
        semantics of an information module.

   (2)  Object definitions are used when describing managed objects.  An
        ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax
        and semantics of a managed object.

   (3)  Notification definitions are used when describing unsolicited
        transmissions of management information.  An ASN.1 macro,
        NOTIFICATION-TYPE, is used to convey concisely the syntax and
        semantics of a notification.







Case, et al.                 Informational                     [Page 13]

RFC 2570                 Introduction to SNMPv3               April 1999


7.1.1 Base SMI Specification

   STD 58, RFC 2578 specifies the base data types for the MIB module
   language, which include: Integer32, enumerated integers, Unsigned32,
   Gauge32, Counter32,  Counter64, TimeTicks, INTEGER, OCTET STRING,
   OBJECT IDENTIFIER, IpAddress, Opaque, and BITS. It also assigns
   values to several object identifiers.  STD 58, RFC 2578 further
   defines the following constructs of the MIB module language:

     * IMPORTS to allow the specification of items that are used
       in a MIB module, but defined in another MIB module.

     * MODULE-IDENTITY to specify for a MIB module a description
       and administrative information such as contact and revision
       history.

     * OBJECT-IDENTITY and OID value assignments to specify a
       an OID value.

     * OBJECT-TYPE to specify the data type, status, and the semantics
       of managed objects.

     * SEQUENCE type assignment to list the columnar objects in
       a table.

     * NOTIFICATION-TYPE construct to specify an event notification.

7.1.2 Textual Conventions

   When designing a MIB module, it is often useful to specify in a
   short-hand way the semantics for a set of objects with similar
   behavior.  This is done by defining a new data type using a base data
   type specified in the SMI.  Each new type has a different name, and
   specifies a base type with more restrictive semantics.  These newly
   defined types are termed textual conventions, and are used for the
   convenience of humans reading a MIB module and potentially by
   "intelligent" management applications.  It is the purpose of STD 58,
   RFC 2579, Textual Conventions for SMIv2 [27], to define the
   construct, TEXTUAL-CONVENTION, of the MIB module language used to
   define such new types and to specify an initial set of textual
   conventions available to all MIB modules.










Case, et al.                 Informational                     [Page 14]

RFC 2570                 Introduction to SNMPv3               April 1999


7.1.3 Conformance Statements

   It may be useful to define the acceptable lower-bounds of
   implementation, along with the actual level of implementation
   achieved.  It is the purpose of STD 58, RFC 2580, Conformance
   Statements for SMIv2 [28], to define the constructs of the MIB module
   language used for these purposes.  There are two kinds of constructs:

   (1)  Compliance statements are used when describing requirements for
        agents with respect to object and event notification
        definitions.  The MODULE-COMPLIANCE construct is used to convey
        concisely such requirements.

   (2)  Capability statements are used when describing capabilities of
        agents with respect to object and event notification
        definitions.  The AGENT-CAPABILITIES construct is used to convey
        concisely such capabilities.

   Finally, collections of related objects and collections of related
   event notifications are grouped together to form a unit of
   conformance.  The OBJECT-GROUP construct is used to convey concisely
   the objects in and the semantics of an object group. The
   NOTIFICATION-GROUP construct is used to convey concisely the event
   notifications in and the semantics of an event notification group.

7.2 Protocol Operations

   The management protocol provides for the exchange of messages which
   convey management information between the agents and the management
   stations.  The form of these messages is a message "wrapper" which
   encapsulates a Protocol Data Unit (PDU).

   It is the purpose of RFC 1905, Protocol Operations for SNMPv2 [7], to
   define the operations of the protocol with respect to the sending and
   receiving of the PDUs.

7.3 Transport Mappings

   SNMP Messages may be used over a variety of protocol suites.  It is
   the purpose of RFC 1906, Transport Mappings for SNMPv2 [8], to define
   how SNMP messages maps onto an initial set of transport domains.
   Other mappings may be defined in the future.

   Although several mappings are defined, the mapping onto UDP is the
   preferred mapping.  As such, to provide for the greatest level of
   interoperability, systems which choose to deploy other mappings
   should also provide for proxy service to the UDP mapping.




Case, et al.                 Informational                     [Page 15]

RFC 2570                 Introduction to SNMPv3               April 1999


7.4 Protocol Instrumentation

   It is the purpose of RFC 1907, the Management Information Base for
   SNMPv2 document [9] to define managed objects which describe the
   behavior of an SNMPv2 entity.

7.5 Architecture / Security and Administration

   It is the purpose of RFC 2571, "An Architecture for Describing SNMP
   Management Frameworks" [15], to define an architecture for specifying
   SNMP Management Frameworks.  While addressing general architectural
   issues, it focuses on aspects related to security and administration.
   It defines a number of terms used throughout the SNMPv3 Management
   Framework and, in so doing, clarifies and extends the naming of

     * engines and applications,

     * entities (service providers such as the engines in agents
       and managers),

     * identities (service users), and

     * management information, including support for multiple
       logical contexts.

   The document contains a small MIB module which is implemented by all
   authoritative SNMPv3 protocol engines.

7.6 Message Processing and Dispatch (MPD)

   RFC 2572, "Message Processing and Dispatching for the Simple Network
   Management Protocol (SNMP)" [16], describes the Message Processing
   and Dispatching for SNMP messages within the SNMP architecture.  It
   defines the procedures for dispatching potentially multiple versions
   of SNMP messages to the proper SNMP Message Processing Models, and
   for dispatching PDUs to SNMP applications.  This document also
   describes one Message Processing Model - the SNMPv3 Message
   Processing Model.

   It is expected that an SNMPv3 protocol engine MUST support at least
   one Message Processing Model.  An SNMPv3 protocol engine MAY support
   more than one, for example in a multi-lingual system which provides
   simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c.








Case, et al.                 Informational                     [Page 16]

RFC 2570                 Introduction to SNMPv3               April 1999


7.7 SNMP Applications

   It is the purpose of RFC 2573, "SNMP Applications" to describe the
   five types of applications which can be associated with an SNMP
   engine.  They are: Command Generators, Command Responders,
   Notification Originators, Notification Receivers, and Proxy
   Forwarders.

   The document also defines MIB modules for specifying targets of
   management operations (including notifications), for notification
   filtering, and for proxy forwarding.

7.8 User-based Security Model (USM)

   RFC 2574, the "User-based Security Model (USM) for version 3 of the
   Simple Network Management Protocol (SNMPv3)" describes the User-based
   Security Model for SNMPv3.  It defines the Elements of Procedure for
   providing SNMP message-level security.

   The document describes the two primary and two secondary threats
   which are defended against by the User-based Security Model.  They
   are:  modification of information, masquerade, message stream
   modification, and disclosure.

   The USM utilizes MD5 [21] and the Secure Hash Algorithm [22] as keyed
   hashing algorithms [23] for digest computation to provide data
   integrity

     * to directly protect against data modification attacks,

     * to indirectly provide data origin authentication, and

     * to defend against masquerade attacks.

   The USM uses loosely synchronized monotonically increasing time
   indicators to defend against certain message stream modification
   attacks.  Automatic clock synchronization mechanisms based on the
   protocol are specified without dependence on third-party time sources
   and concomitant security considerations.

   The USM uses the Data Encryption Standard (DES) [24] in the cipher
   block chaining mode (CBC) if disclosure protection is desired.
   Support for DES in the USM is optional, primarily because export and
   usage restrictions in many countries make it difficult to export and
   use products which include cryptographic technology.






Case, et al.                 Informational                     [Page 17]

RFC 2570                 Introduction to SNMPv3               April 1999


   The document also includes a MIB suitable for remotely monitoring and
   managing the configuration parameters for the USM, including key
   distribution and key management.

   An entity may provide simultaneous support for multiple security
   models as well as multiple authentication and privacy protocols.  All
   of the protocols used by the USM are based on pre-placed keys, i.e.,
   private key mechanisms.  The SNMPv3 architecture permits the use of
   asymmetric mechanisms and protocols (commonly called "public key
   cryptography") but as of this writing, no such SNMPv3 security models
   utilizing public key cryptography have been published.