rfc2570.txt

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

   renamed applications and engines, respectively.

   The SNMPv1 Framework also introduces the concept of an authentication
   service supporting one or more authentication schemes.  In addition
   to authentication, SNMPv3 defines the additional security capability
   referred to as privacy.  (Note: some literature from the security
   community would describe SNMPv3 security capabilities as providing
   data integrity, source authenticity, and confidentiality.)  The
   modular nature of the SNMPv3 Framework permits both changes and
   additions to the security capabilities.




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


   Finally, the SNMPv1 Framework introduces access control based on a
   concept called an SNMP MIB view.  The SNMPv3 Framework specifies a
   fundamentally similar concept called view-based access control.  With
   this capability, SNMPv3 provides the means for controlling access to
   information on managed devices.

   However, while the SNMPv1 Framework anticipated the definition of
   multiple authentication schemes, it did not define any such schemes
   other than a trivial authentication scheme based on community
   strings.  This was a known fundamental weakness in the SNMPv1
   Framework but it was thought at that time that the definition of
   commercial grade security might be contentious in its design and
   difficult to get approved because "security" means many different
   things to different people.  To that end, and because some users do
   not require strong authentication, the SNMPv1 architected an
   authentication service as a separate block to be defined "later" and
   the SNMPv3 Framework provides an architecture for use within that
   block as well as a definition for its subsystems.

4 The SNMPv2 Management Framework

   The SNMPv2 Management Framework is fully described in [4-9] and
   coexistence and transition issues relating to SNMPv1 and SNMPv2 are
   discussed in [10].

   SNMPv2 provides several advantages over SNMPv1, including:

     * expanded data types (e.g., 64 bit counter)

     * improved efficiency and performance (get-bulk operator)

     * confirmed event notification (inform operator)

     * richer error handling (errors and exceptions)

     * improved sets, especially row creation and deletion

     * fine tuning of the data definition language

   However, the SNMPv2 Framework, as described in these documents, is
   incomplete in that it does not meet the original design goals of the
   SNMPv2 project.  The unmet goals included provision of security and
   administration delivering so-called "commercial grade" security with

     * authentication:  origin identification, message integrity,
       and some aspects of replay protection;

     * privacy:  confidentiality;



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


     * authorization and access control; and

     * suitable remote configuration and administration capabilities
       for these features.

   The SNMPv3 Management Framework, as described in this document and
   the companion documents, addresses these significant deficiencies.

5 The SNMPv3 Working Group

   This document, and its companion documents, were produced by the
   SNMPv3 Working Group of the Internet Engineering Task Force (IETF).
   The SNMPv3 Working Group was chartered to prepare recommendations for
   the next generation of SNMP.  The goal of the Working Group was to
   produce the necessary set of documents that provide a single standard
   for the next generation of core SNMP functions.  The single, most
   critical need in the next generation is a definition of security and
   administration that makes SNMP-based management transactions secure
   in a way which is useful for users who wish to use SNMPv3 to manage
   networks, the systems that make up those networks, and the
   applications which reside on those systems, including manager-to-
   agent, agent-to-manager, and manager-to-manager transactions.

   In the several years prior to the chartering of the Working Group,
   there were a number of activities aimed at incorporating security and
   other improvements to SNMP.  These efforts included:

     * "SNMP Security" circa 1991-1992 [RFC 1351 - RFC 1353],

     * "SMP" circa 1992-1993,

     * "The Party-based SNMPv2" circa 1993-1995 [RFC 1441 - RFC 1452].

   Each of these efforts incorporated commercial grade, industrial
   strength security including authentication, privacy, authorization,
   view-based access control, and administration, including remote
   configuration.

   These efforts fed the development of the SNMPv2 Management Framework
   as described in RFCs 1902 - 1908.  However, the Framework described
   in those RFCs had no standards-based security and administrative
   framework of its own; rather, it was associated with multiple
   security and administrative frameworks, including:

     * "The Community-based SNMPv2" (SNMPv2c) [RFC 1901],

     * "SNMPv2u" [RFCs 1909 - 1910] and




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


     * "SNMPv2*".

   SNMPv2c had the endorsement of the IETF but no security and
   administration whereas both SNMPv2u and SNMPv2* had security but
   lacked the endorsement of the IETF.

   The SNMPv3 Working Group was chartered to produce a single set of
   specifications for the next generation of SNMP, based upon a
   convergence of the concepts and technical elements of SNMPv2u and
   SNMPv2*, as was suggested by an advisory team which was formed to
   provide a single recommended approach for SNMP evolution.

   In so doing, the Working Group charter defined the following
   objectives:

     * accommodate the wide range of operational environments with
       differing management demands;

     * facilitate the need to transition from previous, multiple
       protocols to SNMPv3;

     * facilitate the ease of setup and maintenance activities.

   In the initial work of the SNMPv3 Working Group, the group focused on
   security and administration, including

     * authentication and privacy,

     * authorization and view-based access control, and

     * standards-based remote configuration of the above.

   The SNMPv3 Working Group did not "reinvent the wheel," but reused the
   SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for
   those portions of the design that were outside the focused scope.

   Rather, the primary contributors to the SNMPv3 Working Group, and the
   Working Group in general, devoted their considerable efforts to
   addressing the missing link -- security and administration -- and in
   the process made invaluable contributions to the state-of-the-art of
   management.

   They produced a design based on a modular architecture with
   evolutionary capabilities with emphasis on layering.  As a result,
   SNMPv3 can be thought of as SNMPv2 with additional security and
   administration capabilities.





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


   In doing so, the Working Group achieved the goal of producing a
   single specification which has not only the endorsement of the IETF
   but also has security and administration.

6 SNMPv3 Framework Module Specifications

   The specification of the SNMPv3 Management Framework is partitioned
   in a modular fashion among several documents.  It is the intention of
   the SNMPv3 Working Group that, with proper care, any or all of the
   individual documents can be revised, upgraded, or replaced as
   requirements change, new understandings are obtained, and new
   technologies become available.

   Whenever feasible, the initial document set which defines the SNMPv3
   Management Framework leverages prior investments defining and
   implementing the SNMPv2 Management Framework by incorporating by
   reference each of the specifications of the SNMPv2 Management
   Framework.

   The SNMPv3 Framework augments those specifications with
   specifications for security and administration for SNMPv3.

   The documents which specify the SNMPv3 Management Framework follow
   the same architecture as those of the prior versions and can be
   organized for expository purposes into four main categories as
   follows:

     * the data definition language,

     * Management Information Base (MIB) modules,

     * protocol operations, and

     * security and administration.

   The first three sets of documents are incorporated from SNMPv2.  The
   fourth set of documents are new to SNMPv3, but, as described
   previously, build on significant prior related works.

6.1 Data Definition Language

   The specifications of the data definition language includes STD 58,
   RFC 2578, "Structure of Management Information Version 2 (SMIv2)"
   [26], and related specifications.  These documents are updates of
   RFCs 1902 - 1904 [4-6] which have evolved independently from the
   other parts of the framework and were republished as STD 58, RFCs
   2578 - 2580 [26-28] when promoted from Draft Standard.




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


   The Structure of Management Information (SMIv2) defines fundamental
   data types, an object model, and the rules for writing and revising
   MIB modules.  Related specifications include STD 58, RFCs 2579, 2580.
   The updated data definition language is sometimes referred to as
   SMIv2.

   STD 58, RFC 2579, "Textual Conventions for SMIv2" [27], defines an
   initial set of shorthand abbreviations which are available for use
   within all MIB modules for the convenience of human readers and
   writers.

   STD 58, RFC 2580, "Conformance Statements for SMIv2" [28], defines
   the format for compliance statements which are used for describing
   requirements for agent implementations and capability statements
   which can be used to document the characteristics of particular
   implementations.

6.2 MIB Modules

   MIB modules usually contain object definitions, may contain
   definitions of event notifications, and sometimes include compliance
   statements specified in terms of appropriate object and event
   notification groups.  As such, MIB modules define the management
   information maintained by the instrumentation in managed nodes, made
   remotely accessible by management agents, conveyed by the management
   protocol, and manipulated by management applications.

   MIB modules are defined according the rules defined in the documents
   which specify the data definition language, principally the SMI as
   supplemented by the related specifications.

   There is a large and growing number of standards-based MIB modules,
   as defined in the periodically updated list of standard protocols
   [STD 1, RFC 2400].  As of this writing, there are nearly 100
   standards-based MIB modules with a total number of defined objects
   approaching 10,000.  In addition, there is an even larger and growing
   number of enterprise-specific MIB modules defined unilaterally by
   various vendors, research groups, consortia, and the like resulting
   in an unknown and virtually uncountable number of defined objects.

   In general, management information defined in any MIB module,
   regardless of the version of the data definition language used, can
   be used with any version of the protocol.  For example, MIB modules
   defined in terms of the SNMPv1 SMI (SMIv1) are compatible with the
   SNMPv3 Management Framework and can be conveyed by the protocols
   specified therein.  Furthermore, MIB modules defined in terms of the
   SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and
   can be conveyed by it.  However, there is one noteworthy exception:



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


   the Counter64 datatype which can be defined in a MIB module defined
   in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol
   engine.

6.3 Protocol Operations and Transport Mappings

   The specifications for the protocol operations and transport mappings
   of the SNMPv3 Framework are incorporated by reference to the two
   SNMPv2 Framework documents.

   The specification for protocol operations is found in RFC 1905,
   "Protocol Operations for Version 2 of the Simple Network Management
   Protocol (SNMPv2)" [7].  The SNMPv3 Framework is designed to allow
   various portions of the architecture to evolve independently.  For
   example, it might be possible for a new specification of protocol
   operations to be defined within the Framework to allow for additional
   protocol operations.

   The specification of transport mappings is found in RFC 1906,
   "Transport Mappings for Version 2 of the Simple Network Management
   Protocol (SNMPv2)" [8].

6.4 SNMPv3 Security and Administration