File: rfc1503.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (787 lines) | stat: -rw-r--r-- 33,542 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787






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
                    contextLocal:            false
                    contextStorageType:      volatile
                    textual handle:          89.0.0.1

                    aclTarget (dest. party): 101
                    aclSubject (src party):  102
                    aclResources (context):  101
                    aclPrivileges:           get, get-next, get-bulk
                    aclStorageType:          volatile

               and the "context resolver" returns a handle to the newly
               created context.

          (4)  Otherwise, if the textual string specifies a domain name
               which resolves to multiple IP addresses, then for each



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


               such IP address, 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.
               Then, the "context resolver" returns a handle identifying
               all of those newly created contexts.

          (5)  Otherwise, if the textual string contains a '/'-
               character, and everything to the left of the first
               occurrence of this character 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 SNMPv1 party, a volatile context, and a
               volatile access control entry allowing interrogation
               operations.  (The SNMPv1 community string consists of any
               characters following the first occurrence of the '/'-
               character in the textual string.) Then, the "context
               resolver" returns a handle identifying the newly created
               context.

               So, if the application supplied "89.0.0.2/public", then
               the "context resolver" adds the following information to
               the local party database:

                    partyIdentifier:         initialPartyId.89.0.0.2.1
                    partyIndex:              201
                    partyTDomain:            rfc1157Domain
                    partyTAddress:           89.0.0.2:161
                    partyLocal:              false
                    partyAuthProtocol:       rfc1157noAuth
                    partyAuthPrivate:        public
                    partyPrivProtocol:       noPriv
                    partyStorageType:        volatile

                    contextIdentifier:       initialContextId.89.0.0.2.1
                    contextIndex:            201
                    contextLocal:            false
                    contextStorageType:      volatile
                    textual handle:          89.0.0.2

                    aclTarget (dest. party): 201
                    aclSubject (src party):  201
                    aclResources (context):  201
                    aclPrivileges:           get, get-next, get-bulk
                    aclStorageType:          volatile

               and the "context resolver" returns a handle to the the



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


               newly created context.

          (6)  Otherwise, if the textual string contains a '/'-
               character, and everything to the left of the first
               occurrence of this character specifies a domain name
               which resolves to multiple IP addresses, then for each
               such IP address, the "context resolver" adds to the local
               party database, a volatile SNMPv1 party, a volatile
               context, and a volatile access control entry allowing
               interrogation operations.  (The SNMPv1 community string
               consists of any characters following the first occurrence
               of the '/'-character in the textual string.) Then, the
               "context resolver" returns a handle identifying all of
               those newly created contexts.

          (7)  Otherwise, an error is raised.

4.2.  Requesting an Operation

   Later, when an SNMPv2 operation is to be performed, the management
   application supplies a "context handle" and a minimal set of security
   requirements to the management API:

          (1)  If the "context handle" refers to a single context, then
               all access control entries having that context as its
               aclResources, allowing the specified operation, having a
               non-local SNMPv2 party as its aclTarget, which satisfies
               the privacy requirements, and having a local party as its
               aclSubject, which satisfies the authentication
               requirements, are identified.

               So, if the application wanted to issue a get-next
               operation, with no security requirements, and supplied a
               "context handle" identifying context #1, then acl #1
               would be identified.

          (2)  For each such access control entry, the one which
               minimally meets the security requirements is selected for
               use.  If no such entry is identified, and authentication
               requirements are present, then the operation will be not
               performed.

               So, if the application requests a get-next operation,
               with no security requirements, and supplies a "context
               handle" identifying context #1, and step 1 above
               identified acl #1, then because acl #1 satisfies the no-
               security requirements, the operation would be generated
               using acl #1, i.e., using party #1, party #2, and context



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


               #1.

          (3)  Otherwise, all access control entries having the (single)
               context as its aclResources, allowing the specified
               operation, and having a non-local SNMPv1 party as its
               aclTarget, are identified.  If no such entry is
               identified, then the operation will not performed.
               Otherwise, any of the identified access control entries
               may be selected for use.

               The effect of separating out step 3 is to prefer SNMPv2
               communications over SNMPv1 communications.

          (4)  If the "context handle" refers to more than one context,
               then all access control entries whose aclResources refers
               any one of the contexts, are identified.  For each such
               context, step 2 is performed, and any (e.g., the first)
               access control entry identified is selected for use.  If
               no access control entry is identified, then step 3 is
               performed for each such context, and any (e.g., the
               first) access control entry identified is selected for
               use.

               So, if the application wanted to issue a get-bulk
               operation, with no security requirements, and supplied a
               "context handle" identifying contexts #1 and #2, then
               acls #1 and #2 would be identified in step 1; and, in
               step 2, party #1, party #2, and context #1 would be
               selected.

               However, if the application wanted to issue an
               authenticated get-bulk operation, and supplied a "context
               handle" identifying contexts #1 and #2, then acls #1 and
               #2 would still be identified in step 1; but, in step 2,
               only acl #2 satisfies the security requirement, and so,
               party #3, party #4, and context #2 would be selected.

          (5)  If no access control entry is identified, then an error
               is raised.

   Note that for steps 1 and 3, an implementation might choose to pre-
   compute (i.e., cache) for each context those access control entries
   having that context as its aclResources.

5.  Determining and Using Maintenance Knowledge

   When using authentication services, two "maintenance" tasks may have
   to be performed: clock synchronization and secret update.  These



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


   tasks should be performed transparently, independent of the
   management applications, and without user/administrator intervention.
   In order to operate transparently, the SNMP protocol engine must
   maintain "maintenance knowledge" (knowledge of which parties and
   contexts to use).  It is useful for this maintenance knowledge to be
   determined at run-time, rather than being directly configured by an
   administrator.

   One approach to achieve this is as follows: the first time that the
   SNMP protocol engine determines that it will be communicating with
   another SNMPv2 entity, the SNMP protocol engine first consults its
   local party database and then interrogates its peer, before engaging
   in the actual communications.

   Note that with such an approach, both the clock synchronization
   knowledge, and the secret update knowledge, associated with a party,
   can each be represented as (a pointer to) an access control entry.
   Further note that once an implementation has computed this knowledge,
   it might choose to retain this knowledge across restarts.

5.1.  Determination of Synchronization Knowledge

   To determine maintenance knowledge for clock synchronization:

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

               So, this would be party #1.

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

               So, for party #1, this would be acl #1.

          (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:

            -  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 clock synchronization knowledge is known for R.



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


               So, for acl #1, party #3 is identified as having the same
               transport domain and address as party #1, 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" and "partyAuthClock" objects
               are retrieved via the get-bulk operator using the parties
               and context identified by the access control entry, A.

               So, party #1, party #2, and context #1 would be used to
               sweep these two columns on the agent.

          (5)  Only those instances corresponding to parties in the
               local database, which have no clock synchronization
               knowledge, and are local mdAuth parties, are examined.

               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: +1 415 966 7934
   EMail: kzm@hls.com


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

   Phone: +1 415 968 1052
   EMail: mrose@dbc.mtview.ca.us















McCloghrie & Rose                                              [Page 14]