rfc1503.txt

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

               So, only instances corresponding to party #4 are
               examined.

          (6)  For each instance of "partyAuthProtocol", if the
               corresponding value does not match the value in the local
               database, then a configuration error is signalled, and
               the corresponding party is marked as being unavailable
               for maintenance knowledge.

               So, we make sure that the manager and the agent agree
               that party #4 is an md5Auth party.

          (7)  For each instance of "partyAuthClock", if the
               corresponding value is greater than the value in the
               local database, then the authentication clock of the
               party is warped according to the procedures defined in
               Section 5.3 of [3].  Regardless, A is recorded as the
               clock synchronization knowledge for the corresponding
               party.

               So, if the column sweep returns information for party #4,
               then party #4's authentication clock is advanced if
               necessary, and the clock synchronization knowledge for
               party #4 is recorded as acl #1.

5.2.  Use of Clock Synchronization Knowledge

   Whenever a response to an authenticated operation is not received,
   the SNMP protocol engine may suspect that a clock synchronization
   problem for the source party is the cause [3].  The SNMP protocol
   engine may use different criteria when making this determination; for



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


   example: on a retrieval operation, the operation might be retried
   using an exponential back-off algorithm; in contrast, on a
   modification operation, the operation would not be automatically
   retried.

   When clock mis-synchronization for a source party, S, is suspected,
   if clock synchronization knowledge for S is present, then this
   knowledge is used to perform steps 4-7 above, which should retrieve
   the instances of the "partyAuthProtocol" and "partyAuthClock" objects
   which correspond to S (and perhaps other parties as well).  If
   information on these objects cannot be determined, then S is marked
   as no longer having clock synchronization knowledge.  Otherwise, if
   the value of the corresponding instance of "partyAuthClock" is
   greater than the value in the local database, then the authentication
   clock of the party is warped according to the procedures defined in
   Section 5.3 of [3], and the original operation is retried, if
   appropriate.

   So, if traffic from party #4 times out, then a column sweep is
   automatically initiated, using acl #1 (party #1, party #2, context
   #1).

   When clock mis-synchronization for a source party, S, is suspected,
   and clock synchronization knowledge for S is not present, then the
   full algorithm above can be used.  In this case, if clock
   synchronization knowledge for S can be determined, and as a result,
   "partyAuthClock" value for S in the local database is warped
   according to the procedures defined in Section 5.3 of [3], then the
   original operation is retried, if appropriate.

5.3.  Determination of Secret Update Knowledge

   To determine maintenance knowledge for secret update:

          (1)  The SNMP protocol engine examines each active, non-local,
               md5Auth party.

               So, this would be party #3.

          (2)  For each such party, P, all access control entries having
               that party as its aclTarget, and allowing the get-bulk
               and set operations, are identified.

               So, for party #3, this would be acl #2.

          (3)  For each such access control entry, A, at least one
               active, non-local, md5Auth party, Q, must be present
               which meets the following criteria:



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


            -  the transport domain and address of P and Q are
               identical;

            -  an access control entry, B, exists having either: Q as
               its aclTarget and a local party, R, as its aclSubject,
               or, Q as its aclSubject and a local party, R, as its
               aclTarget; and,

            -  no secret update knowledge is known for R.

               So, for acl #2, party #3 is (redundantly) identified as
               having the same transport domain and address as party #3,
               and being present as the aclTarget in acl #2, which has
               local party #4 as the aclSubject.

          (4)  Whenever such a party, Q, is present, then all instances
               of the "partyAuthProtocol", "partyAuthClock", and
               "partyAuthPrivate" objects are retrieved via the get-bulk
               operator using the parties and context identified by the
               access control entry, A.

               So, party #3, party #4, and context #2 would be used to
               sweep these three columns on the agent.

          (5)  Only those instances corresponding to parties in the
               local database, which have no secret update knowledge,
               and are md5Auth parties, are examined.

               So, only instances corresponding to parties #3 and #4 are
               examined.

          (6)  For each instance of "partyAuthProtocol", if the
               corresponding value does not match the value in the local
               database, then a configuration error is signalled, and
               this party is marked as being unavailable for maintenance
               knowledge.

               So, we make sure that the manager and the agent agree
               that both party #3 and #4 are md5Auth parties.

          (7)  For each instance of "partyAuthPrivate", if a
               corresponding instance of "partyAuthClock" was also
               returned, then A is recorded as the secret update
               knowledge for this party.

               So, if the column sweep returned information on party #3,
               then the clock synchronization knowledge for party #3
               would be recorded as acl #2.  Further, if the column



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


               sweep returned information on party #4, then the clock
               synchronization knowledge for party #4 would be recorded
               as acl #2.

5.4.  Use of Secret Update Knowledge

   Whenever the SNMP protocol engine determines that the authentication
   clock of a party, S, is approaching an upper limit, and secret update
   knowledge for S is present, then this knowledge is used to modify the
   current secret of S and reset the authentication clock of S,
   according to the procedures defined in Section 5.4 of [3].

   So, whenever the SNMP protocol engine decides to update the secrets
   for party #4, it can automatically use acl #2 (party #3, party #4,
   context #2) for this purpose.

6.  Other Kinds and Uses of Maintenance Knowledge

   Readers should note that there are other kinds of maintenance
   knowledge that an SNMPv2 manager could derive and use.  In the
   interests of brevity, one example is now considered: when an SNMPv2
   manager first communicates with an agent, it may wish to synchronize
   the maximum-message size values held by itself and the agent.

   For those parties that execute at the agent, the manager retrieves
   the corresponding instances of partyMaxMessageSize (preferrably using
   authentication), and, if need be, adjusts the values held in the
   manager's local party database.  Thus, the maintenance knowledge to
   be determined must allow for retrieval of partyMaxMessageSize.

   For those parties that execute at the manager, the manager retrieves
   the corresponding instances of partyMaxMessageSize (using
   authentication), and, if need be, adjusts the values held in the
   agent's local party database using the set operation.  Thus, the
   maintenance knowledge to be determined must allow both for retrieval
   and modification of partyMaxMessageSize.

7.  Security Considerations

   Security issues are not discussed in this memo.

8.  Acknowledgements

   Jeffrey D. Case of SNMP Research and the University of Tennessee, and
   Robert L. Stewart of Xyplex, both provided helpful comments on the
   ideas contained in this document and the presentation of those ideas.





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


9.  References

   [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
       "Introduction to version 2 of the Internet-standard Network
       Management Framework", RFC 1441, SNMP Research, Inc., Hughes LAN
       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
       University, April 1993.

   [2] McCloghrie, K., and J. Galvin, "Party MIB for version 2 of the
       Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes
       LAN Systems, Trusted Information Systems, April 1993.

   [3] Galvin, J., and K. McCloghrie, "Security Protocols for version 2
       of the Simple Network Management Protocol (SNMPv2)", RFC 1446,
       Trusted Information Systems, Hughes LAN Systems, April 1993.

10.  Authors' Addresses

   Keith McCloghrie
   Hughes LAN Systems
   1225 Charleston Road
   Mountain View, CA  94043
   US

   Phone: [phone]
   EMail: [e-mail]


   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Mountain View, CA  94043-2186
   US

   Phone: [phone]
   EMail: [e-mail]















McCloghrie & Rose                                              [Page 14]