Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc1503.txt.pdf Дата изменения: Wed Mar 27 23:11:45 2002 Дата индексирования: Tue Oct 2 18:38:56 2012 Кодировка:

Network Working Group Request for Comments: 1503

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

Introduction When a user invokes an desirable for the user necessary to establish suggests an approach to SNMPv2 [1] management application, it may be to specify the minimum amount of information and maintain SNMPv2 communications. This memo 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: partyIndex: partyTAddress: partyLocal: partyAuthProtocol: partyPrivProtocol: partyIdentifier: partyIndex: partyTAddress: partyLocal: partyAuthProtocol: partyPrivProtocol: partyIdentifier: partyIndex: partyTAddress: partyLocal: partyAuthProtocol: partyPrivProtocol: partyIdentifier: partyIndex: partyTAddress: partyLocal: partyAuthProtocol: partyPrivProtocol: contextIdentifier: contextIndex: contextLocal: textual handle: contextIdentifier: contextIndex: contextLocal: textual handle: aclTarget (dest. party): aclSubject (src party): aclResources (context): aclPrivileges: initialPartyId.a.b.c.d.1 1 a.b.c.d:161 false noAuth noPriv initialPartyId.a.b.c.d.2 2 local address true noAuth noPriv initialPartyId.a.b.c.d.3 3 a.b.c.d:161 false md5Auth noPriv initialPartyId.a.b.c.d.4 4 local address true md5Auth noPriv initialContextId.a.b.c.d.1 1 false router.xyz.com-public initialContextId.a.b.c.d.2 2 false router.xyz.com-all 1 2 1 get, get-next, get-bulk

McCloghrie & Rose

[Page 3]


RFC 1503

Automating Administration in SNMPv2 Manager

August 1993

aclTarget (dest. party): aclSubject (src party): aclResources (context): aclPrivileges:

3 4 2 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: partyIndex: partyTAddress: partyLocal: partyAuthProtocol: partyPrivProtocol: partyStorageType: partyIdentifier: partyIndex: partyTAddress: partyLocal: partyAuthProtocol: partyPrivProtocol: partyStorageType: contextIdentifier: contextIndex: contextLocal: contextStorageType: textual handle: aclTarget (dest. party): aclSubject (src party): aclResources (context): aclPrivileges: aclStorageType: initialPartyId.89.0.0.1.1 101 89.0.0.1:161 false noAuth noPriv volatile initialPartyId.89.0.0.1.2 102 local address true noAuth noPriv volatile initialContextId.89.0.0.1.1 101 false volatile 89.0.0.1 101 102 101 get, get-next, get-bulk 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: partyIndex: partyTDomain: partyTAddress: partyLocal: partyAuthProtocol: partyAuthPrivate: partyPrivProtocol: partyStorageType: contextIdentifier: contextIndex: contextLocal: contextStorageType: textual handle: aclTarget (dest. party): aclSubject (src party): aclResources (context): aclPrivileges: aclStorageType: initialPartyId.89.0.0.2.1 201 rfc1157Domain 89.0.0.2:161 false rfc1157noAuth public noPriv volatile initialContextId.89.0.0.2.1 201 false volatile 89.0.0.2 201 201 201 get, get-next, get-bulk 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. Otherwise, an error is raised.

(7) 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 nosecurity 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 precompute (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 SNMP protocol engine determines that it will be another SNMPv2 entity, the SNMP protocol engine local party database and then interrogates its in the actual communications. first time that the communicating with first consults its peer, before engaging

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 then party necessary, party #4 is 5.2. column sweep returns information for party #4, #4's authentication clock is advanced if and the clock synchronization knowledge for recorded as acl #1.

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]