rfc1503.txt

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

Network Working Group                                      K. McCloghrie
Request for Comments: 1503                            Hughes LAN Systems
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                             August 1993


                Algorithms for Automating Administration
                           in SNMPv2 Managers

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Table of Contents

   1. Introduction ..........................................    1
   2. Implementation Model ..................................    1
   3. Configuration Assumptions .............................    3
   4. Normal Operations .....................................    4
   4.1 Getting a Context Handle .............................    4
   4.2 Requesting an Operation ..............................    7
   5. Determining and Using Maintenance Knowledge ...........    8
   5.1 Determination of Synchronization Knowledge ...........    9
   5.2 Use of Clock Synchronization Knowledge ...............   10
   5.3 Determination of Secret Update Knowledge .............   11
   5.4 Use of Secret Update Knowledge .......................   13
   6. Other Kinds and Uses of Maintenance Knowledge .........   13
   7. Security Considerations ...............................   13
   8. Acknowledgements ......................................   13
   9. References ............................................   14
   10. Authors' Addresses ...................................   14

1.  Introduction

   When a user invokes an SNMPv2 [1] management application, it may be
   desirable for the user to specify the minimum amount of information
   necessary to establish and maintain SNMPv2 communications.  This memo
   suggests an approach to achieve this goal.

2.  Implementation Model

   In order to discuss the approach outlined in this memo, it is useful
   to have a model of how the various parts of an SNMPv2 manager fit
   together.  The model assumed in this memo is depicted in Figure 2.1.
   This model is, of course, merely for expository purposes, and the



McCloghrie & Rose                                               [Page 1]

RFC 1503      Automating Administration in SNMPv2 Manager    August 1993


   approach should be readily adaptable to other models.

                                 (Human) User
                                      *
                                      *
                   ===========User Interface (UI)===========
                                      *
                              +--------------------------+
                          ... | Management Application N |
                       +---------------------------+     |
                       | Management Application 2  |-----+
                   +--------------------------+    |   *
                   | Management Application 1 |----+   *
                   +--------------------------+  *     *
                                           *     *     *
                  ========Management API======================
                      *                                  *
                      *             ________             *
                +-------------+    / Local  \    +---------------+
                | Context     |***/  Party   \***| SNMP protocol |
                | Resolver(s) |   \ Database /   |   engine(s)   |
                +-------------+    \________/    +---------------+
                                                         *
                                                         *
                            ===========Transport APIs============
                                             *
                             +---------------------------------+
                             | Transport Stacks (e.g., UDP/IP) |
                             +---------------------------------+
                                             *
                                         Network(s)

                 Figure 2.1  SNMPv2 Manager Implementation Model

   Note that there might be just one SNMP protocol engine and one
   "context resolver" which are accessed by all local management
   applications, or, each management application might have its own SNMP
   protocol engine and its own "context resolver", all of which have
   shared access to the local party database [2].

   In addition to the elements shown in the figure, there would need to
   be an interface for the administrator to access the local party
   database, e.g., for configuring initial information, including
   secrets.  There might also be facilities for different users to have
   different access privileges, and/or other reasons for there to be
   multiple (coordinated) subsets of the local party database.





McCloghrie & Rose                                               [Page 2]

RFC 1503      Automating Administration in SNMPv2 Manager    August 1993


3.  Configuration Assumptions

   Now, let's assume that the administrator has already configured a
   local party database for the management application, e.g.,

               partyIdentifier:         initialPartyId.a.b.c.d.1
               partyIndex:              1
               partyTAddress:           a.b.c.d:161
               partyLocal:              false
               partyAuthProtocol:       noAuth
               partyPrivProtocol:       noPriv

               partyIdentifier:         initialPartyId.a.b.c.d.2
               partyIndex:              2
               partyTAddress:           local address
               partyLocal:              true
               partyAuthProtocol:       noAuth
               partyPrivProtocol:       noPriv

               partyIdentifier:         initialPartyId.a.b.c.d.3
               partyIndex:              3
               partyTAddress:           a.b.c.d:161
               partyLocal:              false
               partyAuthProtocol:       md5Auth
               partyPrivProtocol:       noPriv

               partyIdentifier:         initialPartyId.a.b.c.d.4
               partyIndex:              4
               partyTAddress:           local address
               partyLocal:              true
               partyAuthProtocol:       md5Auth
               partyPrivProtocol:       noPriv

               contextIdentifier:       initialContextId.a.b.c.d.1
               contextIndex:            1
               contextLocal:            false
               textual handle:          router.xyz.com-public

               contextIdentifier:       initialContextId.a.b.c.d.2
               contextIndex:            2
               contextLocal:            false
               textual handle:          router.xyz.com-all

               aclTarget (dest. party): 1
               aclSubject (src party):  2
               aclResources (context):  1
               aclPrivileges:           get, get-next, get-bulk




McCloghrie & Rose                                               [Page 3]

RFC 1503      Automating Administration in SNMPv2 Manager    August 1993


               aclTarget (dest. party): 3
               aclSubject (src party):  4
               aclResources (context):  2
               aclPrivileges:           get, get-next, get-bulk, set

   Note that each context has associated with it a "textual handle".
   This is simply a string chosen by the administrator to aid in
   selecting a context.

4.  Normal Operations

   When the user tells the management application to do something, the
   user shouldn't have to specify party or context information.

   One approach to achieve this is as follows: the user provides a
   textual string indicating the managed objects to be manipulated, and
   the management application invokes the "context resolver" to map this
   into a "context handle", and later, when an SNMPv2 operation is
   performed, the "context handle" and a minimal set of security
   requirements are provided to the management API.

4.1.  Getting a Context Handle

   A "context handle" is created when the management application
   supplies a textual string, that was probably given to it by the user.
   The "context resolver" performs these steps based on the
   application's input:

          (1)  In the local party database, each context has associated
               with it a unique string, termed its "textual handle".  If
               a context in the local database has a textual handle
               which exactly matches the textual string, then the
               "context resolver" returns a handle identifying that
               context.

               So, if the application supplies "router.xyz.com-public",
               then the "context resolver" returns a handle to the first
               context; instead, if the application supplies
               "router.xyz.com-all", then the "context resolver" returns
               a handle to the second context.

          (2)  Otherwise, if any contexts are present whose textual
               handle is longer than the textual string, and whose
               initial characters exactly match the entire textual
               string, then the "context resolver" returns a handle
               identifying all of those contexts.

               So, if the application supplies "router.xyz.com", then



McCloghrie & Rose                                               [Page 4]

RFC 1503      Automating Administration in SNMPv2 Manager    August 1993


               the "context resolver" returns a handle to both contexts.

          (3)  Otherwise, if the textual string specifies an IP address
               or a domain name which resolves to a single IP address,
               then the "context resolver" adds to the local party
               database, a volatile noAuth/noPriv party pair, a volatile
               context, and a volatile access control entry allowing
               interrogation operations, using the "initialPartyId" and
               "initialContextId" conventions.  The "context resolver"
               returns a handle identifying the newly created context.

               So, if the application supplies "89.0.0.1", then the
               "context resolver" adds the following information to the
               local party database:

                    partyIdentifier:         initialPartyId.89.0.0.1.1
                    partyIndex:              101
                    partyTAddress:           89.0.0.1:161
                    partyLocal:              false
                    partyAuthProtocol:       noAuth
                    partyPrivProtocol:       noPriv
                    partyStorageType:        volatile

                    partyIdentifier:         initialPartyId.89.0.0.1.2
                    partyIndex:              102
                    partyTAddress:           local address
                    partyLocal:              true
                    partyAuthProtocol:       noAuth
                    partyPrivProtocol:       noPriv
                    partyStorageType:        volatile

                    contextIdentifier:       initialContextId.89.0.0.1.1
                    contextIndex:            101