rfc1909.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/4 页

Network Working Group                              K. McCloghrie, Editor
Request for Comments: 1909                           Cisco Systems, Inc.
Category: Experimental                                     February 1996


              An Administrative Infrastructure for SNMPv2

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Table of Contents

   1. Introduction ................................................    2
   2. Overview ....................................................    2
   2.1 Contexts ...................................................    3
   2.2 Authorization: Access Rights and MIB Views .................    3
   2.3 Authentication and Privacy .................................    4
   2.4 Access Control .............................................    5
   2.5 Security Models ............................................    5
   2.6 Proxy ......................................................    5
   3. Elements of the Model .......................................    7
   3.1 SNMPv2 Entity ..............................................    7
   3.2 SNMPv2 Agent ...............................................    7
   3.3 SNMPv2 Manager .............................................    8
   3.4 SNMPv2 Dual-Role Entity ....................................    8
   3.5 View Subtree and Families ..................................    9
   3.6 MIB View ...................................................    9
   3.7 SNMPv2 Context .............................................   10
   3.7.1 Local SNMPv2 Context .....................................   11
   3.7.2 Proxy SNMPv2 Context .....................................   11
   3.8 SNMPv2 PDUs and Operations .................................   12
   3.8.1 The Report-PDU ...........................................   12
   3.9 SNMPv2 Access Control Policy ...............................   13
   4. Security Considerations .....................................   13
   5. Editor's Address ............................................   14
   6. Acknowledgements ............................................   14
   7. References ..................................................   14
   Appendix A Disambiguating the SNMPv2 Protocol Definition .......   16
   Appendix B Who Sends Inform-Requests?  .........................   17
   Appendix B.1 Management Philosophy .............................   17
   Appendix B.2 The Danger of Trap Storms .........................   17
   Appendix B.3 Inform-Requests ...................................   18





McCloghrie                    Experimental                      [Page 1]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


1.  Introduction

   A management system contains:  several (potentially many) nodes, each
   with a processing entity, termed an agent, which has access to
   management instrumentation; at least one management station; and, a
   management protocol, used to convey management information between
   the agents and management stations.  Operations of the protocol are
   carried out under an administrative framework which defines
   authentication, authorization, access control, and privacy policies.

   Management stations execute management applications which monitor and
   control managed elements.  Managed elements are devices such as
   hosts, routers, terminal servers, etc., which are monitored and
   controlled via access to their management information.

   It is the purpose of this document, An Administrative Infrastructure
   for SNMPv2, to define an administrative framework which realizes
   effective management in a variety of configurations and environments.
   The SNMPv2 framework is fully described in [1-6].  This framework is
   derived from the original Internet-standard Network Management
   Framework (SNMPv1), which consists of these three documents:

      STD 16, RFC 1155 [7] which defines the Structure of Management
      Information (SMI), the mechanisms used for describing and naming
      objects for the purpose of management.

      STD 16, RFC 1212 [8] which defines a more concise description
      mechanism, which is wholly consistent with the SMI.

      STD 15, RFC 1157 [9] which defines the Simple Network Management
      Protocol (SNMP), the protocol used for network access to managed
      objects.

   For information on coexistence between SNMPv1 and SNMPv2, consult
   [10].

2.  Overview

   A management domain typically contains a large amount of management
   information.  Each individual item of management information is an
   instance of a managed object type.  The definition of a related set
   of managed object types is contained in a Management Information Base
   (MIB) module.  Many such MIB modules are defined.  For each managed
   object type it describes, a MIB module defines not only the semantics
   and syntax of that managed object type, but also the method of
   identifying an individual instance so that multiple instances of the
   same managed object type can be distinguished.




McCloghrie                    Experimental                      [Page 2]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


2.1.  Contexts

   Typically, there are many instances of each managed object type
   within a management domain.  For simplicity, the method for
   identifying instances specified by the MIB module does not allow each
   instance to be distinguished amongst the set of all instances within
   the management domain; rather, it allows each instance to be
   identified only within some scope or "context", where there are
   multiple such contexts within the management domain.  Often, a
   context is a physical device, or perhaps, a logical device, although
   a context can also encompass multiple devices, or a subset of a
   single device, or even a subset of multiple devices.  Thus, in order
   to identify an individual item of management information within the
   management domain, its context must be identified in addition to its
   object type and its instance.

   For example, the managed object type, ifDescr [11], is defined as the
   description of a network interface.  To identify the description of
   device-X's first network interface, three pieces of information are
   needed, e.g., device-X (the context), ifDescr (the managed object
   type), and "1" (the instance).

   Note that each context has (at least) one globally-unique
   identification within the management domain.  Note also that the same
   item of management information can exist in multiple contexts.  So,
   an item of management information can have multiple globally-unique
   identifications, either because it exists in multiple contexts,
   and/or because each such context has multiple globally-unique
   identifications.

2.2.  Authorization: Access Rights and MIB Views

   For security reasons, it is often valuable to be able to restrict the
   access rights of some management applications to only a subset of the
   management information in the management domain.  To provide this
   capability, access to a context is via a "MIB view" which details a
   specific set of managed object types (and optionally, the specific
   instances of object types) within that context.  For example, for a
   given context, there will typically always be one MIB view which
   provides access to all management information in that context, and
   often there will be other MIB views each of which contains some
   subset of the information.  So, by providing access rights to a
   management application in terms of the particular (subset) MIB view
   it can access for that context, then the management application is
   restricted in the desired manner.

   Since managed object types (and their instances) are identified via
   the tree-like naming structure of ISO's OBJECT IDENTIFIERs [12, 1],



McCloghrie                    Experimental                      [Page 3]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


   it is convenient to define a MIB view as the combination of a set of
   "view subtrees", where each view subtree is a sub-tree within the
   managed object naming tree.  Thus, a simple MIB view (e.g., all
   managed objects within the Internet Network Management Framework) can
   be defined as a single view sub-tree, while more complicated MIB
   views (e.g., all information relevant to a particular network
   interface) can be represented by the union of multiple view sub-
   trees.

   While any set of managed objects can be described by the union of
   some number of view subtrees, situations can arise that would require
   a very large number of view subtrees.  This could happen, for
   example, when specifying all columns in one conceptual row of a MIB
   table because they would appear in separate subtrees, one per column,
   each with a very similar format.  Because the formats are similar,
   the required set of subtrees can easily be aggregated into one
   structure.  This structure is named a family of view subtrees after
   the set of subtrees that it conceptually represents.  A family of
   view subtrees can either be included or excluded from a MIB view.

   In addition to restricting access rights by identifying (sub-)sets of
   management information, it is also valuable to restrict the requests
   allowed on the management information within a particular context.
   For example, one management application might be prohibited from
   write-access to a particular context, while another might be allowed
   to perform any type of operation.

2.3.  Authentication and Privacy

   The enforcement of access rights requires the means not only to
   identify the entity on whose behalf a request is generated but also
   to authenticate such identification.  Another security capability
   which is (optionally) provided is the ability to protect the data
   within an SNMPv2 operation from disclosure (i.e., to encrypt the
   data).  This is particularly useful when sensitive data (e.g.,
   passwords, or security keys) are accessed via SNMPv2 requests.

   Recommendations for which algorithms are best for authentication and
   privacy are subject to change.  Such changes may occur as and when
   new research results on the vulnerability of various algorithms are
   published, and/or with the prevailing status of export control and
   patent issues.  Thus, it is valuable to allow these algorithms to be
   specified as parameters, so that new algorithms can be accommodated
   over time.  In particular, one type of algorithm which may become
   useful in the future is the set of algorithms associated with
   asymmetric (public key) cryptography.

   Note that not all accesses via SNMPv2 requests need to be secure.



McCloghrie                    Experimental                      [Page 4]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


   Indeed, there are purposes for which insecure access is required.
   One example of this is the ability of a management application to
   learn about devices of which it has no previous knowledge.  Another
   example is to perform any synchronization which the security
   algorithms need before they can be used to communicate securely.
   This need for insecure access is accommodated by defining one of the
   algorithms for authentication as providing no authentication, and
   similarly, one of the algorithms for privacy as providing no
   protection against disclosure.  (The combination of these two
   insecure algorithms is sometimes referred to as "noAuth/noPriv".)

2.4.  Access Control

   An access control policy specifies the types of SNMPv2 requests and
   associated MIB views which are authorized for a particular identity
   (on whose behalf a request is generated) when using a particular
   level of security to access a particular context.

2.5.  Security Models

   A security model defines the mechanisms used to achieve an
   administratively-defined level of security for protocol interactions:

(1)  by defining the security parameters associated with a
     communication, including the authentication and privacy algorithms
     and the security keys (if any) used.

(2)  by defining how entities on whose behalf requests are generated are
     identified.

(3)  by defining how contexts are identified.

(4)  by defining the mechanisms by which an access control policy is
     derived whenever management information is to be accessed.

2.6.  Proxy