rfc3410.txt

开发snmp的开发包有两个开放的SNMP开发库

   It is the purpose of STD 62, RFC 3418, "Management Information Base
   (MIB) for the Simple Network Management Protocol (SNMP)" [30], to
   define managed objects which describe the behavior of portions of an
   SNMP entity.

7.5.  Architecture / Security and Administration

   It is the purpose of STD 62, RFC 3411, "An Architecture for
   Describing Simple Network Management Protocol (SNMP) Management
   Frameworks" [23], to define an architecture for specifying 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)

   STD 62, RFC 3412, "Message Processing and Dispatching for the Simple
   Network Management Protocol (SNMP)" [24], 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.



Case, et. al.                Informational                     [Page 17]

RFC 3410           Applicability Statements for SNMP       December 2002


   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.  For
   example, such a tri-lingual system which provides simultaneous
   support for SNMPv1, SNMPv2c, and SNMPv3 supports three message
   processing models.

7.7.  SNMP Applications

   It is the purpose of STD 62, RFC 3413, "Simple Network Management
   Protocol (SNMP) Applications" [25] 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)

   STD 62, RFC 3414, the "User-based Security Model (USM) for version 3
   of the Simple Network Management Protocol (SNMPv3)" [26] 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 [31] and the Secure Hash Algorithm [32] as keyed
   hashing algorithms [33] 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.




Case, et. al.                Informational                     [Page 18]

RFC 3410           Applicability Statements for SNMP       December 2002


   The USM uses the Data Encryption Standard (DES) [34] 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.

   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
   symmetric and asymmetric mechanisms and protocols (asymmetric
   mechanisms are commonly called public key cryptography) but, as of
   this writing, there are no SNMPv3 security models on the IETF
   standards track that use public key cryptography.

   Work is underway to specify how AES is to be used within the User-
   based Security Model (USM).  This will be a separate document.

7.9.  View-based Access Control (VACM)

   The purpose of STD 62, RFC 3415, the "View-based Access Control Model
   (VACM) for the Simple Network Management Protocol (SNMP)" [27], is to
   describe the View-based Access Control Model for use in the SNMP
   architecture.  The VACM can simultaneously be associated in a single
   engine implementation with multiple Message Processing Models and
   multiple Security Models.

   It is architecturally possible to have multiple, different, Access
   Control Models active and present simultaneously in a single engine
   implementation, but this is expected to be *_very_* rare in practice
   and *_far_* less common than simultaneous support for multiple
   Message Processing Models and/or multiple Security Models.

7.10.  SNMPv3 Coexistence and Transition

   The purpose of RFC 2576, "Coexistence between Version 1, Version 2,
   and Version 3 of the Internet-Standard Network Management Framework"
   [28], is to describe coexistence between the SNMPv3 Management
   Framework, the SNMPv2 Management Framework, and the original SNMPv1
   Management Framework.  In particular, this document describes four
   aspects of coexistence:

   *  Conversion of MIB documents from SMIv1 to SMIv2 format




Case, et. al.                Informational                     [Page 19]

RFC 3410           Applicability Statements for SNMP       December 2002


   *  Mapping of notification parameters

   *  Approaches to coexistence between entities which support the
      various versions of SNMP in a multi-lingual network, in particular
      the processing of protocol operations in multi-lingual
      implementations, as well as behavior of proxy implementations

   *  The SNMPv1 Message Processing Model and Community-Based Security
      Model, which provides mechanisms for adapting SNMPv1 and SNMPv2c
      into the View-Based Access Control Model (VACM) [27]

8.  Standardization Status

   Readers should consult the latest version of the "Internet Official
   Protocol Standards" list [20] to determine the standardization status
   of any document.

   However, the SNMPv3 Working Group explicitly requested that text be
   included in this document to amplify on the status of SMIv1, SNMPv1,
   and SNMPv2c.

8.1.  SMIv1 Status

   SMIv1, as described in STD 16, RFCs 1155 and 1212, was promoted to
   full Standard status in 1990 and has remained a Standard even after
   SMIv2 reached full Standard (see RFC 2026 [35] for more information
   about the Internet Standards Process).  In many cases, a Standard is
   declared "Historic" when its replacement reaches full Standard.  For
   example, MIB-1 [8] was declared "Historic" when MIB-2 [6] reached
   full Standard.  Similarly, when SMIv2 reached full Standard, it might
   have been reasonable at that time to retire SMIv1 and declare it to
   be "Historic" but as the result of a conscious decision, STD 16, RFCs
   1155 and 1212 continue to have the standardization status of full
   "Standard" but are not recommended.  These documents were not
   declared "Historic" and remain on the standards track because they
   provide normative references for other documents on the standards
   track and cannot be declared "Historic" without rendering the
   documents which rely on them to also become "Historic".
   Consequently, STD 16 retains its standardization status but is not
   recommended because it has been superseded by the newer SMIv2
   specifications which are identified somewhat later in this document.

   On a pragmatic level, since about 1993 it has been wise for users of
   the data definition language to use SMIv2 for all new work because
   the realities of the marketplace have occasionally required the
   support of data definitions in both the SMIv1 and SMIv2 formats.
   While there are tools widely available at low cost or no cost to
   translate SMIv2 definitions to SMIv1 definitions, it is impractical



Case, et. al.                Informational                     [Page 20]

RFC 3410           Applicability Statements for SNMP       December 2002


   to build automatic tools that automatically translate SMIv1
   definitions to SMIv2 definitions.  Consequently, if one works in
   primarily SMIv2, the cost of providing data definitions in both SMIv1
   and SMIv2 formats is trivial.  In contrast, if one works primarily in
   SMIv1 format, providing data definitions in both SMIv1 and SMIv2 is
   significantly more expensive.  The market requirements today for
   providing data definitions in SMIv1 format are greatly diminished
   when compared to those of 1993, and SMIv2 continues to be the
   strongly preferred format even though SMIv1 has not been declared
   "Historic".  Indeed, the IETF currently requires that new MIB modules
   be written using SMIv2.

8.2.  SNMPv1 and SNMPv2 Standardization Status

   Protocol operations via SNMPv1 and SNMPv2c message wrappers support
   only trivial authentication based on plain-text community strings
   and, as a result, are fundamentally insecure.  When the SNMPv3
   specifications for security and administration, which include strong
   security, reached full Standard status, the full Standard SNMPv1,
   formerly STD 15 [5], and the experimental SNMPv2c specifications
   described in RFC 1901 [16] were declared Historic due to their
   weaknesses with respect to security and to send a clear message that
   the third version of the Internet Standard Management Framework is
   the framework of choice.  The Party-based SNMPv2 (SNMPv2p), SNMPv2u,
   and SNMPv2* were either declared Historic circa 1995 or were never on
   the standards track.

   On a pragmatic level, it is expected that a number of vendors will
   continue to produce and users will continue to deploy and use multi-
   lingual implementations that support SNMPv1 and/or SNMPv2c as well as
   SNMPv3.  It should be noted that the IETF standards process does not
   control actions of vendors or users who may choose to promote or
   deploy historic protocols, such as SNMPv1 and SNMPv2c, in spite of
   known short-comings.  However, it is not expected that vendors will
   produce nor that users will deploy multi-lingual implementations that
   support the Party-based SNMPv2p (SNMPv2p), SNMPv2u, or SNMPv2*.

   Indeed, as described above, one of the SNMPv3 specifications for
   security and administration, RFC 2576, Coexistence between Version 1,
   Version 2, and Version 3 of the Internet-Standard Management
   Framework [28], addresses these issues.

   Of course, it is important that users deploying multi-lingual systems
   with insecure protocols exercise sufficient due diligence to insure
   that configurations limit access via SNMPv1 and SNMPv2c
   appropriately, in keeping with the organization's security policy,
   just as they should carefully limit access granted via SNMPv3 with a
   security level of no authentication and no privacy which is roughly



Case, et. al.                Informational                     [Page 21]

RFC 3410           Applicability Statements for SNMP       December 2002


   equivalent from a security point of view.  For example, it is
   probably unwise to allow SNMPv1 or SNMPv2c a greater level of access
   than is provided to unauthenticated SNMPv3 users, e.g., it does not
   make sense to guard the front door with armed guards, trained attack
   dogs, moats and drawbridges while providing unfettered access through
   an open back door.

   The SNMPv1 framework, SNMPv2 framework, and SNMPv2c had limited
   capabilities for administering the SNMPv1 and SNMPv2c protocols.  For
   example, there are no objects defined to view and configure
   communities or destinations for notifications (traps and informs).
   The result has been vendor defined mechanisms for administration that
   range from proprietary format configuration files that cannot be
   viewed or configured via SNMP to enterprise specific object
   definitions.  The SNMPv3 framework provides a rich standards-based
   approach to administration which, by design, can be used for the
   SNMPv1 and SNMPv2c protocols.  Thus, to foster interoperability of
   administration of SNMPv1 and SNMPv2c protocols in multi-lingual
   systems, the mechanisms and objects specified in [25], [27], and [28]
   should be used to supplement or replace the equivalent proprietary
   mechanisms.

8.3.  Working Group Recommendation

   Based on the explanations above, the SNMPv3 Working Group recommends
   that RFCs 1157, 1441, 1901, 1909 and 1910 be reclassified as
   Historical documents.

9.  Security Considerations

   As this document is primarily a roadmap document, it introduces no
   new security considerations.  The reader is referred to the relevant
   sections of each of the referenced documents for information about
   security considerations.