Internet Draft SNMPv2 Administrative Infrastructure March 1995 Administrative Infrastructure for Version 2 of the | Simple Network Management Protocol (SNMPv2) 19 March 1995 | draft-ietf-snmpv2-adminv2-ds-01.txt | Jeffrey D. Case | SNMP Research, Inc. | case@snmp.com | James Galvin | Trusted Information Systems galvin@tis.com Keith McCloghrie | Cisco Systems, Inc. kzm@cisco.com Marshall T. Rose + Dover Beach Consulting, Inc. + mrose@dbc.mtview.ca.us + Steven Waldbusser + Carnegie Mellon University + waldbusser@cmu.edu + Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' Expires September 1995 [Page 1] Internet Draft SNMPv2 Administrative Infrastructure March 1995 To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires September 1995 [Page 2] Internet Draft SNMPv2 Administrative Infrastructure March 1995 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, the Administrative Infrastructure | for SNMPv2, | to define how the administrative framework is applied to realize | effective management in a variety of configurations and | environments. The model described here entails the use of distinct identities for peers that exchange SNMPv2 messages. Thus, it represents a departure from the community-based administrative model of the original SNMP [1]. By unambiguously identifying the source and intended recipient of each SNMPv2 message, this new strategy improves upon the historical community scheme both by supporting a more convenient access control model and allowing for effective use of asymmetric (public key) security protocols in the future. 1.1. A Note on Terminology For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2). 1.2. Change Log For the 19 March version: + - The many changes adopted by the SNMPv2 Working Group. + Expires September 1995 [Page 3] Internet Draft SNMPv2 Administrative Infrastructure March 1995 For the 1 November version: - recast RFC 1445 into an Internet-Draft, - added Overview section, - rewrote Elements of the Model section, - fixed typos in the Elements of Procedure section, - rewrote parts of the Application of the Model section, and retitled it as Usage Examples. - tighted the definition of a proxy SNMPv2 agent, in order to remove confusion, and thereby deleted discussion of foreign proxies. - changed "local party database" to "local party datastore", and introduced LPD as an acronym for it. Expires September 1995 [Page 4] Internet Draft SNMPv2 Administrative Infrastructure March 1995 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. 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. Note that this requires each context to have a globally-unique identification within the management domain. Note also that the same item of management information can exist in multiple contexts. For example, the managed object type, ifDescr [7], 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: device-X (the context), ifDescr (the managed object type), and "1" (the instance). Management information often changes over time. Thus, when naming a specific value of a managed object instance, an indication of time is needed. In most situations, it is the value at the current time which is of interest to the network manager. There are, however, situations where times other than the current time are of interest. For example, where the value of a device parameter after the device's next reboot is to be different to its current value. To accommodate this, each context has an associated notion of time, called its temporal domain. This allows, for example, one context to refer to the current values of a Expires September 1995 [Page 5] Internet Draft SNMPv2 Administrative Infrastructure March 1995 device's parameters, and a different context to refer to the values that the same parameters for the same device will have after the device's next restart. 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 [8, 3], 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 operations allowed on the management information within a particular context. For example, one management application might be prohibited from write- Expires September 1995 [Page 6] Internet Draft SNMPv2 Administrative Infrastructure March 1995 access to a particular context, while another might be allowed to perform any type of operation. 2.3. Proxy The identification of a context is (architecturally) independent of the location at which its management information can be accessed. Of course, it is an SNMPv2 agent which responds to requests for access to management information. Each such request is contained within an SNMPv2 message which provides the capability to perform a single operation on a list of items of management information. Rather than having to identify the context as well as the managed object type and instance for each item of management information, each SNMPv2 message is concerned with only a single context. Thus, an SNMPv2 agent must be able to process requests for all items of management information within the one or more contexts it supports. In responding to a request, an SNMPv2 agent might be acting as a proxy for some other agent. The term "proxy" has historically been used very loosely, with multiple different meanings. These different meanings include (among others): (1) the forwarding of SNMPv2 requests on to other SNMP agents without regard for what managed object types are being accessed; for example, in order to forward SNMPv2 request from one transport domain to another, or to translate SNMPv2 requests into SNMPv1 requests; (2) the translation of SNMPv2 requests into operations of some non-SNMP management protocol; (3) support for aggregated managed objects where the value of one managed object instance depends upon the values of multiple other (remote) items of management information. Each of these scenarios can be advantageous; for example, support for aggregation for management information can significantly reduce the bandwidth requirements of large-scale management activities. However, using a single term to cover multiple different scenarios causes confusion. To avoid such confusion, the SNMPv2 administrative framework uses the term "proxy" with a much more tightly defined meaning, which covers only the first of those listed above. Specifically, the distinction between a regular SNMPv2 agent and a "proxy SNMPv2 agent" is simple: Expires September 1995 [Page 7] Internet Draft SNMPv2 Administrative Infrastructure March 1995 - a proxy SNMPv2 agent is an SNMPv2 agent which forwards requests on to other agents according to the context, and irrespective of the specific managed object types being accessed; - in contrast, an SNMPv2 agent which processes SNMPv2 requests according to the (names of the) individual managed object types and instances being accessed, is NOT a proxy SNMPv2 agent from the perspective of this administrative model. Thus, when an SNMPv2 agent acts as a proxy SNMPv2 agent for a particular context, not only is the information on how to forward the request specifically associated with that context, but the proxy SNMPv2 agent has no need of a detailed definition of the MIB view | (since the proxy SNMPv2 agent forwards the request irrespective of the managed object types). In contrast, a non-proxy SNMPv2 agent must have the detailed definition | of the MIB view, and even if it needs to issue | requests to other agents, that need is dependent on the individual managed object instances being accessed (i.e., not only on the context). 2.4. Security One aspect of security was discussed above: the ability to assign different access rights to different management applications. The enforcement of these access rights requires the means not only to identify the source of a request but also to authenticate such identification. Another security capability which SNMPv2 (optionally) provides is the ability to protect the data within an SNMPv2 message 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. Indeed, there are purposes for which insecure access is required. One Expires September 1995 [Page 8] Internet Draft SNMPv2 Administrative Infrastructure March 1995 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. 2.5. Parties To provide these security capabilities, an SNMPv2 message needs to include the identity of its source and destination. Each such identity is specified as an SNMPv2 "party". Different parties have different security parameters, including the authentication and privacy algorithms and the security keys (if any) used. For any SNMPv2 message, the algorithm and parameters by which it is authenticated (or not) are those of its source party. Similarly, for any SNMPv2 message, the algorithm and parameters by which it is protected from disclosure (or not) are those of its destination party. When an SNMPv2 message is generated, the appropriate parties must be chosen so that the message will have the desired level of authentication and privacy. The parties' algorithms and security keys are used to add authentication information to the message, and (if necessary) to encrypt it. When an SNMPv2 message is received, the destination party's privacy algorithm is used to decrypt it (if necessary), and the source party's authentication information is used to authenticate it. Typically, an SNMPv2 party operates at one and only one location, although it is possible under some circumstances for an SNMPv2 party to operate from a different location. In any case, in order to authenticate the source party without having to rely on underlying transport mechanisms to provide authentication of transport addresses, it is necessary for a party to be globally unique, and have a globally unique identifier. 2.6. Authorization: Access Control As described above, an SNMPv2 message is associated with one context and two parties, where the context determines the set of management information being accessed by the message, and the parties are the identities of the source and destination. These properties of the message are used for access control. Specifically, access control is specified as a set of local access policies, where each such policy is a valid party/party/context triple against which to compare a received | Expires September 1995 [Page 9] Internet Draft SNMPv2 Administrative Infrastructure March 1995 message. In addition, each such triple specifies the set of operations | and the two MIB views (one for read access, the other for write access) | which are allowed for that triple. Thus, | if the context and the two parties specified by the received message are not a valid triple or the operation requested is not one of the operations allowed by the triple, then the requested access is denied. Note that a local access policy (a party/party/context triple) is also called an ACL (for historical reasons). 2.7. Construction of an SNMPv2 Message The purpose of an SNMPv2 message is to contain an SNMPv2 PDU. (The PDU + contains an operation-code, some additional request/response parameters + and a list of names and values of specific managed object instances; for + details, see [2].) To construct an SNMPv2 message, a number of headers + are prepended in front of the PDU (specifically, each "header" is added + as part of a new ASN.1 SEQUENCE). The header which is first prepended + to the PDU contains the context and the source and destination parties. + The second prepended header contains whatever authentication information + needs to be transmitted as part of the message. The third identifies + the destination party which determines if and how the remainder of the + message (the PDU and the first two prepended headers) are encrypted. + 2.8. An SNMPv2 Entity's Local Party Datastore An SNMPv2 entity is an SNMPv2 protocol implementation used by an SNMPv2 agent and/or by one or more management applications. The local parties at an SNMPv2 entity are those which operate locally, and the local contexts are those for which the SNMPv2 entity acts as a (proxy or non- proxy) SNMPv2 agent in responding to requests. To implement the model described in the preceding sections, each SNMPv2 entity needs to retain its own set of information about contexts, parties, ACLs, and (in agents) views. This set of information is called the SNMPv2 entity's Local Party Datastore (LPD) because it is locally- stored information. Note, however, that the LPD contains information on both local and remote parties, local and/or remote contexts, local ACLs, and sometimes on remote ACLs as well. In order to allow an SNMPv2 entity's LPD to be configured, and to allow | the synchronization needed by the security algorithms before they can be | used to communicate securely, the LPD needs to be accessible as managed | objects. A MIB module, the SNMPv2 Party MIB, to define these managed | object types is contained in [4]. | Expires September 1995 [Page 10] Internet Draft SNMPv2 Administrative Infrastructure March 1995 2.9. Maintenance Functions In order to facilitate communication between SNMPv2 entities, certain | "maintenance" functions are defined. A maintenance function is | identified as a management communication which accesses a well-known | maintenance context and makes use of corresponding well-known | maintenance parties. For example, error reporting (Section 4.1) and | clock synchronization and secret update (Sections 5.3 and 5.4 of [6]) | are achieved by performing SNMP operations which access a context known | as "internalContext". | When processing a maintenance function, an SNMPv2 entity utilizes the | same mechanisms defined for normal operations; however, unlike normal | operations which are executed with respect to an administration's | security policy (which may vary between administrations), maintenance | functions always occur within a fixed, standardized security policy. | This is advantageous in that it allows code re-use within an SNMPv2 | entity, while also not allowing an administration's policy to impair the | proper operation of essential maintenance functions. However, many of | the rules applicable to normal parties and contexts specified in this | document do not always apply to these maintenance functions (e.g., | maintenance contexts are not uniquely named). | The sole purpose of maintenance functions is to ensure that all SNMPv2 | entities provide essential maintenance functionality within a well- | known, standardized, security environment. Maintenance functions are | intended for use only by the internal operations of an SNMPv2 entity. | Thus, their scope is intentionally restricted to be the minimum | necessary to fulfill their purpose. | Expires September 1995 [Page 11] Internet Draft SNMPv2 Administrative Infrastructure March 1995 3. Elements of the Model This section provides a more formal description of the model. 3.1. SNMPv2 Party An SNMPv2 party is an identity assumed by an SNMPv2 entity in order to restrict its operations (for security or other purposes) to an administratively defined subset of all SNMPv2 possible operations. Whenever an SNMPv2 entity processes an SNMPv2 message, it does so by operating as a SNMPv2 party and is thereby restricted to the set of operations defined for that party. The set of possible operations specified for an SNMPv2 party may be overlapping or disjoint with respect to the sets of other SNMPv2 parties. Each SNMPv2 party has a set of attributes which includes the following: partyIdentity - the value which uniquely identifies the party. partyTDomain - the kind of transport service by which the party receives | management traffic. | An example of a transport domain is snmpUDPDomain (SNMPv2 over UDP, using SNMPv2 parties). partyTAddress - the transport service address at which the party normally receives | management traffic. This address is used in sending requests or | notifications to the party | (but not in responding to requests from the party). Note that there is no requirement that the party transmits management traffic | from this transport address. | partyMaxMessageSize - the length in octets of the largest SNMPv2 message this party is prepared to accept. partyAuthProtocol - the authentication protocol by which all messages generated by the party are authenticated. In particular, the value 'noAuth' signifies that messages generated by the party are not authenticated. Expires September 1995 [Page 12] Internet Draft SNMPv2 Administrative Infrastructure March 1995 partyAuthClock - the party's authentication clock which represents a notion of the current time that is specific to the party. The significance of this component is specific to the authentication protocol. partyAuthPrivate - the party's private authentication key which is any secret value needed to support the authentication protocol. The significance of this component is specific to the authentication protocol. partyAuthPublic - the party's public authentication key which is any publically- disclosable value that may be needed to support the authentication protocol. The significance of this component is specific to the authentication protocol. partyAuthLifetime - the administrative upper bound on acceptable delivery delay for protocol messages generated by the party. The significance of this component is specific to the authentication protocol. partyPrivProtocol - the privacy protocol by which all protocol messages received by the party are protected from disclosure. In particular, the value 'noPriv' signifies that messages received by the party are not protected from disclosure. partyPrivPrivate - the party's private privacy key which is any secret value needed to support the privacy protocol. The significance of this component is specific to the privacy protocol. partyPrivPublic - the party's public privacy key which is any publically-disclosable value that may be needed to support the privacy protocol. The significance of this component is specific to the privacy protocol. An SNMPv2 entity, which supports only SNMPv2 parties for which the authentication protocol is noAuth and the privacy protocol is noPriv, is called non-secure. Expires September 1995 [Page 13] Internet Draft SNMPv2 Administrative Infrastructure March 1995 3.2. SNMPv2 Entity An SNMPv2 entity is an actual process which performs | management operations by generating and/or responding to SNMPv2 protocol messages in the manner specified in [2]. An SNMPv2 entity assumes the identity of a particular local SNMPv2 party when processing an SNMPv2 message. An SNMPv2 entity is not required to process multiple protocol messages concurrently, regardless of whether such messages require it to assume the identity of the same or different SNMPv2 parties. Thus, implementation of an SNMPv2 entity to support more than one party need not be multi-threaded. However, there may be situations where implementors may choose to use multi-threading. Every SNMPv2 entity maintains a Local Party Datastore (LPD) which includes information on all local SNMPv2 parties, and on those remote SNMPv2 parties which are known locally, as well as other information (see below). An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages on + each transport service address configured for a local SNMPv2 party. It + is a local matter whether an SNMPv2 entity also listens for SNMPv2 + messages on any other transport service addresses. In the absence of + any other information on where to listen, an SNMPv2 entity must listen + on the transport service addresses corresponding to the standard + transport-layer "ports" [5] on its local network-layer addresses. + 3.3. SNMPv2 Manager An SNMPv2 manager is the operational role assumed by an SNMPv2 entity when it acts in a manager role on behalf of management applications. Specifically, an SNMPv2 manager initiates SNMPv2 management operations by the generation of appropriate SNMPv2 protocol messages or when it receives and processes trap and inform notifications. 3.4. SNMPv2 Agent An SNMPv2 agent is the operational role assumed by an SNMPv2 entity when it acts in an agent role. Specifically, an SNMPv2 agent performs SNMPv2 management operations in response to received SNMPv2 protocol messages (except for inform notifications) generated by an SNMPv2 manager. Expires September 1995 [Page 14] Internet Draft SNMPv2 Administrative Infrastructure March 1995 3.5. SNMPv2 Dual-Role Entity An SNMPv2 entity which sometimes acts in an agent role and sometimes + acts in a manager role, is termed an SNMPv2 dual-role entity. An SNMPv2 + dual-role entity receives requests for service through acting in an + agent role and performs requests through acting in a manager role. + There are two categories of SNMPv2 dual-role entities: + (1) proxy SNMPv2 agents. + (2) (so-called) mid-level managers. + Proxy SNMPv2 agents only forward requests; they do not originate + requests. In contrast, mid-level managers often originate requests. + (Note that the term proxy SNMPv2 agent does not include an SNMPv2 agent + which translates SNMPv2 requests into the requests of some other + management protocol; see section 2.3.) + 3.6. View Subtree A view subtree is the set of all MIB object instances which have a common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree is identified by the OBJECT IDENTIFIER value which is the longest OBJECT IDENTIFIER prefix common to all (potential) MIB object instances in that subtree. When the OBJECT IDENTIFIER prefix identifying a view subtree is longer than the OBJECT IDENTIFIER of an object type defined according to the SMI [3], then the use of such a view subtree for access control has granularity at the object instance level. Such granularity is considered beyond the scope of an SNMPv2 agent. As such, no implementation of an SNMPv2 agent is required to support values of viewSubtree [4] which have more sub-identifiers than is necessary to identify a particular leaf object type. However, access control information is also used in determining which SNMPv2 entities operating on behalf of management applications should receive trap notifications (Section 4.2.6 of [2]). As such, agent implementors might wish to provide instance-level granularity in order to allow SNMPv2 entity operating on behalf of management applications to use fine-grain configuration of trap notifications. Expires September 1995 [Page 15] Internet Draft SNMPv2 Administrative Infrastructure March 1995 3.7. View Subtree Families A family of view subtrees is a pairing of an OBJECT IDENTIFIER value (called the family name) together with a bitstring value (called the family mask). The family mask indicates which sub-identifiers of the associated family name are significant to the family's definition. For each possible managed object instance, that instance belongs to a particular view subtree family if both of the following conditions are true: o the OBJECT IDENTIFIER name of the managed object instance contains at least as many sub-identifiers as does the family name, and o each sub-identifier in the the OBJECT IDENTIFIER name of the managed object instance matches the corresponding sub-identifier of the family name whenever the corresponding bit of the associated family mask is non-zero. When the configured value of the family mask is all ones, the view subtree family is identical to the single view subtree identified by the family name. When the configured value of the family mask is shorter than required to perform the above test, its value is implicitly extended with ones. Consequently, a view subtree family having a family mask of zero length always corresponds to a single view subtree. 3.8. MIB View A MIB view is a subset of the set of all instances of all object types | defined according to the SMI [3] within an SNMPv2 context, subject to | the following constraints: | o It is possible to specify a MIB view which contains the full set of | all object instances within an SNMPv2 context. | o Each object instance within a MIB view is uniquely named by an | ASN.1 OBJECT IDENTIFIER value. As such, identically named instances of a particular object type must be | contained within different SNMPv2 contexts. | That is, a particular object instance name resolves within a particular | SNMPv2 context to | Expires September 1995 [Page 16] Internet Draft SNMPv2 Administrative Infrastructure March 1995 at most one object instance. A MIB view is defined as a collection of view subtree families, where each view subtree family has a type. The type determines whether the view subtree family is included in, or excluded from, the MIB view. A managed object instance is contained/not contained within the MIB view | according to the view subtree families to which the instance belongs: | o If a managed object instance belongs to none of the relevant subtree families, then that instance is not in the MIB view. o If a managed object instance belongs to exactly one of the relevant subtree families, then that instance is included in, or excluded from, the relevant MIB view according to the type of that subtree family. o If a managed object instance belongs to more than one of the relevant subtree families, then that instance is included in, or excluded from, the relevant MIB view according to the type of a particular one of the subtree families to which it belongs. The particular subtree family is the one for which, first, the associated family name comprises the greatest number of sub- identifiers, and, second, the associated family name is lexicographically greatest. An SNMPv2 agent's LPD includes information on the definitions of all MIB | views specified for use with local non-proxy SNMPv2 contexts. | 3.9. Proxy Context A proxy relationship exists when a proxy SNMPv2 agent processes a received management request by forwarding it to another entity, solely according to the SNMPv2 context of the received message. Such a context is called a proxy SNMPv2 context. When an SNMPv2 entity processes management requests for a proxy context, it is operating as a proxy SNMPv2 agent. The transparency principle that defines the behavior of an SNMPv2 entity in general, applies in particular to a proxy SNMPv2 context: The manner in which a receiving SNMPv2 entity processes SNMPv2 | protocol messages sent by another SNMPv2 entity | is entirely transparent to the sending SNMPv2 entity. Expires September 1995 [Page 17] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Implicit in the transparency principle is the requirement that the semantics of SNMPv2 management operations are preserved between any two SNMPv2 peers. In particular, the "as if simultaneous" semantics of a Set operation are extremely difficult to guarantee if its scope extends to management information resident at multiple network locations. For this reason, proxy configurations which support Set operations to information at multiple locations are discouraged, although such operations are not explicitly precluded by the architecture in those rare cases where they might be supported in a conformant way. Also implicit in the transparency principle is the requirement that, throughout its interaction with a proxy SNMPv2 agent, an SNMPv2 manager is supplied with no information about the nature or progress of the proxy mechanisms used to perform its requests. That is, it should seem to the SNMPv2 manager (except for any distinction in an underlying transport address) as if it were interacting via SNMPv2 directly with the proxied device. Thus, a timeout in the communication between a proxy SNMPv2 agent and its proxied device should be represented as a timeout in the communication between the SNMPv2 manager and the proxy SNMPv2 agent. Similarly, an error response from a proxied device should - as much as possible - be represented by the corresponding error response in the interaction between the proxy SNMPv2 agent and SNMPv2 manager. 3.10. SNMPv2 Context An SNMPv2 context is a collection of management information accessible by an SNMPv2 entity. The collection of management information identified by a context is either proxy or non-proxy. For a non-proxy SNMPv2 context which is realized by an SNMPv2 entity, | that SNMPv2 entity uses locally-defined mechanisms to access the | management information identified by the SNMPv2 context. Each non-proxy SNMPv2 context has a set of attributes which include the following: contextIdentity - the value which uniquely identifies the SNMPv2 context. contextType - a value which indicates that this is a non-proxy SNMPv2 context, | and also indicates that it is of type local which is realized by | the local SNMPv2 entity, or of type remote which is realized by | some other SNMPv2 entity. | Expires September 1995 [Page 18] Internet Draft SNMPv2 Administrative Infrastructure March 1995 contextLocalEntity - the value which identifies the local entity (e.g., a logical device | local to the SNMPv2 entity which realizes the context) | whose management information is contained in the SNMPv2 context. contextLocalTime - the temporal context of the management information contained in the SNMPv2 context. For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 agent to access the management information identified by the SNMPv2 context. Each proxy SNMPv2 context has a set of attributes which include the following: contextIdentity - the value which uniquely identifies the SNMPv2 context. contextType - a value which indicates that this is a proxy SNMPv2 context. | contextProxyDstParty - the SNMPv2 party to which retrieval and modification SNMPv2 | requests received for this context are forwarded. | contextProxySrcParty - the SNMPv2 party to be used as the source SNMPv2 party when | retrieval and modification SNMPv2 requests received for this | context are forwarded. | contextProxyContext - the SNMPv2 context to be used in forwarding retrieval and | modification SNMPv2 requests received for this context. | The applicability of contextProxySrcParty and contextProxyContext are dependent upon the partyTDomain attribute of the contextProxyDstParty party. An SNMPv2 entity's LPD includes information on all local contexts and on any remote contexts which are known locally. Expires September 1995 [Page 19] Internet Draft SNMPv2 Administrative Infrastructure March 1995 3.11. SNMPv2 PDU An SNMPv2 PDU is defined in [2]. Each SNMPv2 PDU specifies a particular operation. The types of operation (see Table 1) are represented by the possible values of the ASN.1 tag for the appropriate PDU. GetRequest SetRequest SNMPv2-Trap GetNextRequest Response Inform GetBulkRequest Report | Table 1: SNMPv2 Operation Types Note that a report PDU is only used as part of maintenance functions + (see section 4.1). + 3.12. SNMPv2 Message A SNMPv2 message contains a single SNMPv2 PDU, is transmitted from a source SNMPv2 party to a destination SNMPv2 party, and contains management information for an SNMPv2 context which is accessible by the | source/destination SNMPv2 party. | In particular, an SNMPv2 message may be o a query by the source party about information accessible by the destination party (e.g., GetRequest, GetNextRequest, or GetBulkRequest), o an indicative assertion to the destination party about information accessible by the source party (e.g., Response, InformRequest, or SNMPv2-Trap), o an imperative assertion by the source party about information accessible by the destination party (e.g., SetRequest), or o a confirmation to the destination party about information received by the source party (e.g., a Response confirming an InformRequest). Starting from the PDU, an SNMPv2 message is constructed by creating three successive ASN.1 SEQUENCEs, where: Expires September 1995 [Page 20] Internet Draft SNMPv2 Administrative Infrastructure March 1995 - the PDU is a component of the first SEQUENCE, which is called an SNMPv2 management communication, - the first SEQUENCE is a component of the second SEQUENCE, which is called an SNMPv2 authenticated management communication, | - the second SEQUENCE is a component of the third SEQUENCE, which is called an SNMPv2 private management communication, and | - the third SEQUENCE corresponds exactly to an SNMPv2 message. 3.13. SNMPv2 Management Communication An SNMPv2 management communication is an ASN.1 value with the following syntax: SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE { dstParty OBJECT IDENTIFIER, srcParty OBJECT IDENTIFIER, context OBJECT IDENTIFIER, pdu PDUs } where: o The dstParty component identifies the destination SNMPv2 party | of the SNMPv2 message. o The srcParty component identifies the source SNMPv2 party | of the SNMPv2 message. o The context component identifies the SNMPv2 context containing the | management information referenced by the SNMPv2 message. o The pdu component is an SNMPv2 PDU as defined in [2]. | Expires September 1995 [Page 21] Internet Draft SNMPv2 Administrative Infrastructure March 1995 3.14. SNMPv2 Authenticated Management Communication An SNMPv2 authenticated management communication is an ASN.1 value with the following syntax: SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE { authInfo ANY, -- defined by authentication protocol authData SnmpMgmtCom } where: o The authInfo component contains the authentication information | required in support of the authentication protocol used by the source SNMPv2 party. The detailed significance of the authentication information is specific to the authentication protocol in use, and its only use is in determining whether the communication is authentic or not. o The authData component is an SNMPv2 management communication. | 3.15. SNMPv2 Private Management Communication An SNMPv2 private management communication is an ASN.1 value with the following syntax: SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE { privDst OBJECT IDENTIFIER, privData [1] IMPLICIT OCTET STRING } where: o The privDst component identifies the destination SNMPv2 party | of the SNMPv2 message. o The privData component is the (possibly encrypted) serialization | (i.e., encoding according to the conventions of [5]) of an SNMPv2 authenticated management communication. Expires September 1995 [Page 22] Internet Draft SNMPv2 Administrative Infrastructure March 1995 3.16. SNMPv2 Access Control Policy An SNMPv2 access control policy is a specification of a local access | policy which authorizes access to an SNMPv2 context via a pair of SNMPv2 | parties. In particular, an SNMPv2 access policy specifies the | authorized types of SNMPv2 operations and the accessible MIB views. | Each such local access policy, called an ACL (for historical reasons), | has six attributes: | acContext - | the context - an SNMPv2 context which identifies the management | information on which requested management operations are to be | performed; | acTarget - | the target - a SNMPv2 party for which the SNMPv2 context is a local | or proxy context; | acSubject - | the subject - a SNMPv2 party for which the SNMPv2 context is a | remote context; | acPrivileges - | the access privileges - the types of SNMPv2 operations on the | particular context that are authorized for SNMPv2 messages between | the subject and the target; | acReadViewIndex - | the read MIB view - the (sub-)set of management information within | the context to which the subject is authorized to have read-access | via the target; | and acWriteViewIndex - the write MIB view - the (sub-)set of management information within | the context to which the subject is authorized to have write-access | via the target. | An SNMPv2 entity's LPD includes information on all ACLs containing local | access control policies. An SNMPv2 manager | may also include remote ACLs in its LPD in order to determine which | operations are authorized by particular parties for a | particular remote context. Expires September 1995 [Page 23] Internet Draft SNMPv2 Administrative Infrastructure March 1995 The application of SNMPv2 access control policy is performed: | o on receipt of GetRequest, GetNextRequest, GetBulkRequest, and | SetRequest operations; and | o prior to transmission of SNMPv2-Trap and Inform operations (the | procedures by which this access-control is performed are specified | in [2]). | Note that application of SNMPv2 access control policy is never performed | for Response nor Report operations. | Expires September 1995 [Page 24] Internet Draft SNMPv2 Administrative Infrastructure March 1995 4. Maintenance Functions Each SNMPv2 entity MUST provide an internalParty and internalContext for + use with, and only with, maintenance functions, as defined in the this + document. + The internalParty has these characteristics: + partyIdentity 0.0 + partyMaxMessageSize 484 + partyAuthProtocol noAuth + partyPrivProtocol noPriv + The internalContext is local to any SNMPv2 entity acting in an agent + role, and has these characteristics: + contextIdentity 0.0 + contextType local (to agent) + Usage of internalParty and internalContext are effectively governed by a + pseudo-ACL: + acTarget internalParty + acSubject internalParty + acContext internalContext + acReadViewIndex + acWriteViewIndex 0 + acPrivileges 35 (Get, GetNext & GetBulk) + where is statically defined to be all instances of all + objects in exactly two subtrees: snmpStats [7] and snmpParties [4]. + Note that internalParty, internalContext, the pseudo-ACL and the + pseudo-view all have a StorageType of "readOnly" [4], in that they + always exist and cannot be modified. Further, internalParty and + internalContext MUST NOT be accessible to entities outside of an SNMPv2 + entity itself. Consequently, even though they are conceptually + represented in the LPD, neither internalParty nor internalContext are + visible through the SNMPv2 Party MIB [4], neither are the pseudo-ACL and + pseudo-view that they use. + It should be noted that the use of a fixed context-identity + (internalContext) is contrary to the architectural principles of the + administrative framework: in SNMPv2, management information is always + uniquely identified by a combination of context local-entity, context + Expires September 1995 [Page 25] Internet Draft SNMPv2 Administrative Infrastructure March 1995 local-time, object type, and object instance. However, in the interests + of both simplicity and the reuse of infrastructure, maintenance + functions are provided "outside" of the administrative infrastructure + available to applications which make use of an SNMPv2 entity. It must + be emphasized that a management communication using internalContext + belongs to a logically different protocol than SNMP, just as the ICMP is + logically a different protocol from the IP. Thus, use of internalParty + and internalContext, except for the purpose of performing maintenance + functions, is prohibited. + 4.1. Error Reporting + While processing a received communication, an SNMPv2 entity may + determine that the message is unacceptable (see Section 5.2). In this + case, the appropriate counter from the snmpStats group [7] is + incremented and the received message is discarded without further + processing or reply. + If an SNMPv2 entity acting in the agent role makes such a determination, + then after incrementing the appropriate counter, it is required to + generate a report PDU and to send it to the transport address which + originated the received message. (Note, however, that the transmission + of report PDUs may be disabled through the use of the managed object, + snmpV2EnableReports [7].) + Report-PDU ::= + [8] + IMPLICIT PDU + The report PDU is always transmitted within an SNMPv2 message for which + the components of the SnmpMgmtCom have these values: + srcParty = internalParty + dstParty = internalParty + context = internalContext + If the agent is able to determine the request-id field of the received + PDU, then it uses that value for the request-id field of the report PDU. + Otherwise, the value 2147483647 is used. + The error-status and error-index fields of the report PDU are always set + to zero. + Expires September 1995 [Page 26] Internet Draft SNMPv2 Administrative Infrastructure March 1995 The variable-bindings field contains a single variable: the identity of + the snmpStats counter which was incremented and its new value. + There are two cases in which a report PDU must not be sent by an SNMPv2 + entity acting in the agent role: if the snmpStats30Something counter is + incremented; or, if the received message was tagged as a report PDU. + Expires September 1995 [Page 27] Internet Draft SNMPv2 Administrative Infrastructure March 1995 5. Elements of Procedure This section describes the procedures followed by an SNMPv2 entity in processing SNMPv2 messages. These procedures are independent of the particular authentication and privacy protocols that may be in use. 5.1. Generating a Request This section describes the procedure followed by an SNMPv2 entity | whenever either a management request or notification is | to be transmitted by an SNMPv2 party. (Note: in this procedure, the + values retrieved from the LPD may be overridden at the SNMPv2 entity's + discretion by values obtained through other local knowledge.) + (1) A SnmpMgmtCom value is constructed for which the srcParty component identifies the originating party, for which the dstParty component identifies the receiving party, for which the context component identifies the desired SNMPv2 context, and for which the pdu component represents the desired management operation. (2) The LPD is consulted to determine the authentication protocol and other relevant information for the originating and receiving SNMPv2 parties. (3) A SnmpAuthMsg value is constructed with the following properties: Its authInfo component is constructed according to the authentication protocol specified for the originating party. In particular, if the authentication protocol for the originating SNMPv2 party is identified as noAuth, then this component corresponds to the OCTET STRING value of zero length. Its authData component is the constructed SnmpMgmtCom value. (4) The LPD is consulted to determine the privacy protocol and other relevant information for the receiving SNMPv2 party. (5) A SnmpPrivMsg value is constructed with the following properties: Its privDst component identifies the receiving SNMPv2 party. Its privData component is the (possibly encrypted) Expires September 1995 [Page 28] Internet Draft SNMPv2 Administrative Infrastructure March 1995 serialization of the SnmpAuthMsg value according to the conventions of [5]. In particular, if the privacy protocol for the receiving SNMPv2 party is identified as noPriv, then the privData component is unencrypted. Otherwise, the privData component is processed according to the privacy protocol. (6) The constructed SnmpPrivMsg value is serialized (i.e., encoded) according to the conventions of [5]. (7) The serialized SnmpPrivMsg value is transmitted using the transport address and transport domain (as specified in the LPD) for the receiving SNMPv2 party. Note that the above procedure does not include any application of any | SNMPv2 access control policy (but see Section 3.15). | 5.2. Processing a Received Communication This section describes the procedure followed by an SNMPv2 entity whenever a SNMPv2 message is received. This procedure is independent of + the transport service address at which the message was received. + (1) The snmpStatsPackets counter [7] is incremented. If the received message is not the serialization (according to the conventions of [5]) of an SnmpPrivMsg value, then that message is discarded without further processing. (If the first octet of the packet has the value hexadecimal 30, then the snmpStats30Something counter [7] is incremented prior to discarding the message; otherwise the | snmpStatsEncodingErrors counter [7] is incremented and a report PDU | is generated.) | (2) The LPD is consulted for information about the receiving SNMPv2 party identified by the privDst component of the SnmpPrivMsg value. (3) If information about the receiving SNMPv2 party is absent from the LPD, or indicates that the receiving party's operations are not performed by the local SNMPv2 entity, then the | snmpStatsUnknownDstParties counter [7] is incremented, a report PDU | is generated, and | the received message is discarded without further processing. Expires September 1995 [Page 29] Internet Draft SNMPv2 Administrative Infrastructure March 1995 (4) An ASN.1 OCTET STRING value is constructed (possibly by decryption, according to the privacy protocol in use) from the privData component of said SnmpPrivMsg value. In particular, if the privacy protocol recorded for the party is noPriv, then the OCTET STRING value corresponds exactly to the privData component of the SnmpPrivMsg value. (5) If the OCTET STRING value is not the serialization (according to the conventions of [5]) of an SnmpAuthMsg value, then the received message is discarded without further processing, after the | snmpStatsEncodingErrors counter [7] is incremented and a report PDU | is generated. | (6) If the dstParty component of the authData component of the obtained SnmpAuthMsg value is not the same as the privDst component of the SnmpPrivMsg value, then the received message is discarded without further processing, after the snmpStatsDstPartyMismatches counter | [7] is incremented and a report PDU is generated. | (7) The LPD is consulted for information about the originating SNMPv2 party identified by the srcParty component of the authData component of the SnmpAuthMsg value. (8) If information about the originating SNMPv2 party is absent from the LPD, then the received message is discarded without further processing, after the snmpStatsUnknownSrcParties counter [7] is | incremented and a report PDU is generated. | (9) The obtained SnmpAuthMsg value is evaluated according to the authentication protocol and other relevant information associated with the originating and receiving SNMPv2 parties in the LPD. In particular, if the authentication protocol is identified as noAuth, then the SnmpAuthMsg value is always evaluated as authentic. (10) If the SnmpAuthMsg value is evaluated as unauthentic, then the | relevant counter (e.g., snmpStatsWrongDigestValues [7]) is | incremented, a report PDU is generated, the received message is | discarded | without further processing, and if the snmpV2EnableAuthenTraps object [7] is enabled, then the SNMPv2 entity sends authorizationFailure traps [7] according to its configuration (Section 4.2.6 of [2]). Expires September 1995 [Page 30] Internet Draft SNMPv2 Administrative Infrastructure March 1995 (11) The SnmpMgmtCom value is extracted from the authData component of the SnmpAuthMsg value. (12) The LPD is consulted for information about the SNMPv2 context identified by the context component of the SnmpMgmtCom value. (13) If information about the SNMPv2 context is absent from the LPD, then the received message is discarded without further processing, | after the snmpStatsUnknownContexts counter [7] is incremented and a | report PDU is generated. | (14) The SNMPv2 operation type is determined from the ASN.1 tag value | associated with the PDUs component of the SnmpMgmtCom value. | (15) If the SNMPv2 operation type indicates that the message contains a | report PDU, then appropriate maintenance procedures are invoked. | In particular, when a proxy SNMPv2 agent receives a report PDU from | a proxy destination party, and the result of the invoked | maintenance procedures determines that a proxy-forwarded request | cannot be delivered to the proxy destination party, then | snmpStatsProxyDrops [7] is incremented and a report PDU is | generated and transmitted to the transport address from which the | original request was received. [Note that the receipt of a report | PDU containing snmpStatsProxyDrops [7] as a varbind, is included | among the reasons why a proxy-forwarded request cannot be | delivered.] | (16) If the SNMPv2 operation type is either 32, 8, 2, or 1 (i.e., | GetBulk, Set, GetNext or Get), then: | a) if the LPD information indicates that the SNMPv2 context is of | type remote, the received message is discarded without further | processing, after the snmpStatsUnknownContexts counter [7] is | incremented and a report PDU is generated. | b) the LPD is consulted for the access privileges authorized for | communications concerning management information in the | indicated SNMPv2 context from the originating SNMPv2 party to | the receiving SNMPv2 party, and for the associated MIB view | for the particular SNMPv2 operation type. | c) if the SNMPv2 operation type is not among the authorized | access privileges, then the received message is discarded | without further processing after generation and transmission | Expires September 1995 [Page 31] Internet Draft SNMPv2 Administrative Infrastructure March 1995 of a response message. This response message is directed to | the originating SNMPv2 party on behalf of the receiving SNMPv2 | party. Its context, var-bind-list and request-id components | are identical | to those of the received request. Its error-index component | is zero and its error-status component is authorizationError | [2]. | d) The information extracted from the LPD concerning the | originating SNMPv2 party, the destination SNMPv2 party, and | the SNMPv2 context, together with the sending transport | address of the received message is cached for later use in | generating a response message. | e) if the LPD information indicates the SNMPv2 context is of type | local, then the management operation represented by the | SnmpMgmtCom value is performed by the receiving SNMPv2 entity | with respect to the relevant MIB view within the SNMPv2 | context according to the procedures set forth in [2], where | the relevant MIB view is: | SNMPv2 operation type MIB View given by | --------------------- ----------------- | 32, 2, or 1 (get/getNext/getBulk) acReadViewIndex | 8 (set) acWriteViewIndex | f) if the LPD information indicates the SNMPv2 context is of type | proxy, then: | i. the values of contextProxyContext, contextProxyDstParty | and contextProxySrcParty associated with the SNMPv2 | context of the received message are extracted from the | LPD. If any of these extracted values have the value { 0 | 0 } or if any of the indicated parties and context are | not present with an active status in the LPD, then | snmpStatsProxyDrops [7] is incremented, a report PDU is | generated, and the received message is discarded. | ii. a new SNMPv2 message is constructed: the pdu component | of the SnmpMgmtCom is copied from that in the received | message except that the contained request-id is replaced | by a unique value (this value will enable a subsequent | response message to be correlated with this request); and | the dstParty, srcParty and context components are set to | the extracted values of contextProxyDstParty, | Expires September 1995 [Page 32] Internet Draft SNMPv2 Administrative Infrastructure March 1995 contextProxySrcParty and contextProxyContext, | respectively. | iii. the information cached in step 16d above is augmented | with the request-id of the received message as well as | the request-id and context of the constructed message. | iv. the constructed message is forwarded to the transport | address associated with the party given by the extracted | value of contextProxyDstParty. | (17) If the SNMPv2 operation type is either 128, 64 or 4 (i.e., SNMPv2- | Trap, Inform, or Response), then: | a) if the LPD information indicates the SNMPv2 context is of type | local, then the received message is discarded without further | processing, after the snmpStatsUnknownContexts counter [7] is | incremented and a report PDU is generated. | b) if the LPD information indicates the SNMPv2 context is of type | remote, then the management operation represented by the | SnmpMgmtCom value is performed by the receiving SNMPv2 entity | according to the procedures set forth in [2]. | c) if the LPD information indicates the SNMPv2 context is of type | proxy and the SNMPv2 operation type is 4 (i.e., a Response), | then: | i. the request-id is extracted from the pdu component of the | received SnmpMgmtCom. The SNMPv2 context and extracted | request-id are used to correlate this response message to | the corresponding values for a previously forwarded | request by inspecting the cache of information as | augmented in substep iii of step 16f above. If no such | correlated information is found, then the received | message is discarded without further processing. | ii. a new SNMPv2 message is constructed: the pdu component | of the SnmpMgmtCom is copied from that in the received | message except that the contained request-id is replaced | by the value saved in the correlated information from the | original request; and the dstParty, srcParty and context | components are set to the saved values of the original | request's originating party, destination party and | context, respectively. | Expires September 1995 [Page 33] Internet Draft SNMPv2 Administrative Infrastructure March 1995 iii. the constructed message is forwarded to the transport | address saved in the correlated information as the | sending transport address of the original request. | iv. the correlated information is deleted from the cache of | information. | d) if the LPD information indicates the SNMPv2 context is of type | proxy, and the SNMPv2 operation type is 64 (i.e., Inform), | then: | i. a unique request-id is selected for use by all forwarded | copies of this request. This value will enable a | subsequent response message to be correlated with this | request. | ii. all contexts in the LPD are located for which | contextProxyContext has the same value as the context of | the received message, and for which contextProxyDstParty | has the same value as the originating party of the | received message. | iii. for each located context, all ACLs in the LPD are | located for which the value of acContext references the | located context, and for which the access privileges | allow Inform operations. | iv. for each located ACL, a new SNMPv2 message is | constructed: the pdu component of the SnmpMgmtCom is | copied from that in the received message except that the | contained request-id is replaced by the value selected in | step i) above; the dstParty, srcParty, and context | components are set to the values of acSubject, acTarget | and acContext respectively from the located ACL. | v. for each such constructed SNMPv2 message, the information | cached in step d) above is augmented with the request-id | of the received message as well as the request-id and | context of the constructed message, and the constructed | message is forwarded to the transport address associated | with acSubject from the located ACL. | Expires September 1995 [Page 34] Internet Draft SNMPv2 Administrative Infrastructure March 1995 e) if the LPD information indicates the SNMPv2 context is of type | proxy, and the SNMPv2 operation type is 128 (i.e., SNMPv2- | Trap), then: | i. all contexts in the LPD are located for which | contextProxyContext has the same value as the context of | the received message, and for which contextProxyDstParty | has the same value as the originating party of the | received message. | ii. for each located context, all ACLs in the LPD are | located for which the value of acContext references the | located context, and for which the access privileges | allow SNMPv2-Trap operations. | iii. for each located ACL, a new SNMPv2 message is | constructed: the pdu component of the SnmpMgmtCom is | copied from that in the received message; the dstParty, | srcParty, and context components are set to the values of | acSubject, acTarget and acContext respectively from the | located ACL. | iv. each such constructed SNMPv2 message is forwarded to the | transport address associated with acSubject from the | located ACL, and the instance of snmpTrapNumbers [7] | which corresponds to the acSubject party is incremented. | For the sake of clarity and to prevent the above procedure from being | even longer, the following details were omitted from the above | procedure. | - Some situations in which an ASN.1 parsing error can occur were | omitted | (e.g., the possibility that an authData component is not a correct | serialization of a SnmpMgmtCom value). The snmpStatsEncodingErrors | counter [7] is incremented and a report PDU is generated whenever | such an ASN.1 parsing error is discovered. | - Some steps specify that the received message is discarded without | further processing whenever a report PDU is generated. However, a | report PDU must not be generated unless and until the SNMPv2 | operation type can be determined, so as to ensure that a report PDU | is not generated due to the receipt of a report PDU. In addition, | a generated report PDU must whenever possible contain the same | request-id value as in the PDU contained in the received message. | Expires September 1995 [Page 35] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Meeting these constraints normally requires the message to be | further processed just enough so as to extract its SNMPv2 operation | type and request-id. Even in the case where the receiving party is | unknown, an attempt must be made to extract the SNMPv2 operation | type and request-id by assuming that the privacy protocol of the | unknown party is noPriv. With this assumption, the only situation | in which the SNMPv2 operation type and request-id cannot be | extracted is when an ASN.1 parsing error occurs. | - All generation of report PDUs is suppressed if disabled by the | managed object, snmpV2EnableReports [7]. | For a possible procedure to invoke on receipt of a message with an | SNMPv2 operation type of 16, see section 3.1.2 (step 2) of [9]. | 5.3. Generating a Response The procedure for generating a response to an SNMPv2 management request | is identical to the procedure for transmitting a request (see Section | 5.1), | with these exceptions: (1) In Step 1, the dstParty component of the responding SnmpMgmtCom value is taken from the srcParty component of the original SnmpMgmtCom value; the srcParty component of the responding SnmpMgmtCom value is taken from the dstParty component of the original SnmpMgmtCom value; the context component of the responding SnmpMgmtCom value is taken from the context component of the original SnmpMgmtCom value; and, the pdu component of the responding SnmpMgmtCom value is the response which results from performing the operation specified in the original SnmpMgmtCom value. (2) In Step 2, the authentication protocol and other relevant + information for the originating and receiving SNMPv2 parties is + obtained, not from the LPD, but rather from information cached (in + Step 16d) when processing the original message. + (3) + In Step 7, the serialized SnmpPrivMsg value is transmitted using the transport address and transport domain from which its corresponding request originated - even if that is different from the transport information recorded in the LPD. Expires September 1995 [Page 36] Internet Draft SNMPv2 Administrative Infrastructure March 1995 6. Usage Examples 6.1. Non-Secure Minimal Agent Configuration This section presents an example configuration for a minimal, non-secure | SNMPv2 agent that interacts with an SNMPv2 manager. Table 2 presents | information about the local access policy known by the minimal agent; | Table 3 presents the same information as known by the manager. Table 4 | presents information on the SNMPv2 parties known to both the minimal | agent and the manager. | Target: gracie | Subject: george | Context: device5 | Privileges: Get/GetNext/GetBulk/SNMPv2-Trap | ReadView: 10 | WriteView: 0 | Table 2: Minimal Agent's Access Information | Target: gracie + Subject: george + Context: device5 + Privileges: Get/GetNext/GetBulk/SNMPv2-Trap + Table 3: Manager's Access Information for Minimal Agent + Expires September 1995 [Page 37] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Identity gracie george (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2001 Auth Prot noAuth noAuth Auth Priv Key "" "" Auth Pub Key "" "" Auth Clock 0 0 Auth Lifetime 0 0 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 4: Party Information for Minimal Agent | As shown in Table 4, the example agent party operates at UDP | port 161 at IP address 1.2.3.4 using the party identity gracie; the example manager operates at UDP port 2001 at IP address 1.2.3.5 using the identity george. At minimum, a non-secure SNMPv2 agent implementation must provide for administrative configuration (and non- volatile storage) of the identities and transport addresses of two SNMPv2 parties: the local and remote peers. Suppose that the SNMPv2 manager at 1.2.3.5 wishes to interrogate management information about the SNMPv2 context named "device5", by issuing an SNMPv2 GetNext request message. The manager consults its LPD | (Table 3) to discover that management | information for context "device5" is held by the party named gracie, and that the managing party george can be used to access that context. The | manager further consults its LPD (Table 4) | to obtain the parameters of the two parties: george and gracie. Because the authentication protocol for the party george is recorded as noAuth, the GetNext request message generated by the manager is not authenticated. Because the privacy protocol for the party gracie is noPriv, the GetNext request message is not protected from disclosure. Rather, it is simply assembled, serialized, and transmitted to the transport address (IP address 1.2.3.4, UDP port 161) associated in the manager's LPD with the party gracie. When the GetNext request message is received at the agent, the identity of the destination party (gracie) is extracted from the message, and the receiving entity consults its LPD. Because the privacy protocol for the Expires September 1995 [Page 38] Internet Draft SNMPv2 Administrative Infrastructure March 1995 party gracie is recorded as noPriv, the received message is assumed not to be protected from disclosure. Similarly, the identity of the source party (george) is extracted, and the LPD is consulted. Because the authentication protocol for the party george is recorded as noAuth, the received message is immediately accepted as authentic. The received message is processed only if the agent's LPD authorizes | GetNext request operations by the remote party george to the local party | gracie | with respect to the SNMPv2 context "device5". The LPD information presented as Table 2 does authorize such operations (as well as Get and GetBulk operations). During the processing of the received request, each specified item of | management information is accessed only as authorized by the relevant | MIB view. The LPD information in Table 2 authorizes access for GetNext | operations (as well as to Get and GetBulk operations), and authorizes | retrievals operations to the read MIB view identified by view-index 10. | To complete the processing of the request, the agent generates a | Response | message which references the SNMPv2 context "device5" and identifies the source party as gracie (since gracie was the request's destination party), and the destination party as george (since george was the request's source party). The agent now consults its LPD. Because the authentication protocol for gracie is noAuth, the generated Response message is not authenticated. Because the privacy protocol for the party george is noPriv, the Response message is not protected from disclosure. The Response message is transmitted to the transport address from which the corresponding request originated - without regard for the transport address associated with george in the LPD. When the generated Response is received by the manager, the identity of the destination party (george) is extracted from the message, and the manager consults its LPD. Because the privacy protocol for the party george is recorded as noPriv, the received Response is assumed not to be protected from disclosure. Similarly, the identity of the source party (gracie) is extracted, and the LPD is consulted. Because the authentication protocol for the party gracie is recorded as noAuth, the received Response is immediately accepted as authentic. Finally, since | the received message is a Response operation, this message is not | subject to access control. | Expires September 1995 [Page 39] Internet Draft SNMPv2 Administrative Infrastructure March 1995 6.2. Secure Minimal Agent Configuration This section presents an example configuration for a secure, minimal SNMPv2 agent that interacts with a single SNMPv2 manager. Table 5 | presents information about the local access policy known by the minimal | agent; Table 6 presents the same information as known by the manager. | Table 7 presents information about the SNMPv2 parties known to both the | minimal agent and the manager. | The interaction of manager and agent in this configuration is very similar to that sketched above for the non-secure minimal agent - except that all protocol messages are authenticated and protected from disclosure. This example requires encryption of all SNMPv2 messages. Another example having an additional pair of SNMPv2 parties could support the exchange of non-secret information in authenticated messages without incurring the cost of encryption. - Target: ollie | Subject: stan | Context: device6 | Privileges: Get/GetNext/GetBulk/Set/SNMPv2-Trap | ReadView: 16 | WriteView: 17 | Table 5: Secure Minimal Agent's Access Information | Target: ollie + Subject: stan + Context: device6 + Privileges: Get/GetNext/GetBulk/Set/SNMPv2-Trap + Table 6: Manager's Access Information for Secure Minimal Agent + Expires September 1995 [Page 40] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Identity ollie stan (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2001 Auth Prot v2md5AuthProtocol v2md5AuthProtocol Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" Auth Pub Key "config-file" "querty" | Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot desPrivProtocol desPrivProtocol Priv Priv Key "MNOPQR0123456789" "STUVWX0123456789" Priv Pub Key "" "" Table 7: Party Information for Secure Minimal Agent | As shown in Table 7, the example agent party operates at UDP | port 161 at IP address 1.2.3.4 using the party identity ollie; the example manager operates at UDP port 2001 at IP address 1.2.3.5 using the identity stan. At minimum, a secure SNMPv2 agent implementation must provide for administrative configuration (and non-volatile storage) | of relevant information about two SNMPv2 parties: one local and the | other a remote peer. | Both ollie and stan authenticate all messages that they generate by using the SNMPv2 authentication protocol v2md5AuthProtocol and their distinct, private authentication keys. Although these private authentication key values ("0123456789ABCDEF" and "GHIJKL0123456789") are presented here and in other examples in this section for expository purposes, knowledge of private authentication keys is normally confined to those portions of the protocol implementation that require it, and not made known to human beings. When using the v2md5AuthProtocol, the public authentication key for each SNMPv2 party is not used in authentication and verification of SNMPv2 exchanges. Also, because the v2md5AuthProtocol is symmetric in character, the private authentication key for each party must be known to each SNMPv2 entity with which authenticated communication is desired. In contrast, asymmetric (public key) authentication protocols would not depend upon sharing of a private key for their operation. All protocol messages generated for transmission to the party stan are encrypted using the desPrivProtocol privacy protocol and the private key "STUVWX0123456789"; they are decrypted upon reception according to the same protocol and key. Similarly, all messages generated for Expires September 1995 [Page 41] Internet Draft SNMPv2 Administrative Infrastructure March 1995 transmission to the party ollie are encrypted using the desPrivProtocol protocol and private privacy key "MNOPQR0123456789"; they are correspondingly decrypted on reception. As with authentication keys, knowledge of private privacy keys is normally confined to those portions of the protocol implementation that require it, and not made known to human beings. 6.3. MIB View Configurations This section provides example configurations of MIB views illustrating both simple view subtrees, and more complicated uses of included and excluded families of view subtrees. View Index Type Family Name Family Mask | 5 included internet ''H | Table 8: View Definition for Minimal Agent | Table 8 illustrates the definition of a MIB view | required for a minimal SNMPv2 entity that has a single MIB view | containing all instances | of all MIB objects defined within the SNMPv2 Network Management Framework. The first column identifies the View Index by which this | view is referenced by local access policies. Note that the value of | View Index has only local significance. | The type (included) signifies that any MIB object instance belonging to | the view subtree family is contained within the MIB view. | The family name is internet, and the zero-length family mask value signifies that the relevant subtree family corresponds to the single view subtree rooted at that node. Another example of MIB view definition (see Table 9) is that of a SNMPv2 | entity having multiple distinct MIB views. The MIB view associated with | View Index 7 | comprises all instances of all MIB objects defined within the SNMPv2 Network Management Framework, except those pertaining to the administration of SNMPv2 parties. In contrast, the MIB view associated | with View Index 8 contains only MIB object instances defined in the | system group of the Internet-standard MIB together with those object instances by which SNMPv2 parties are administered. Expires September 1995 [Page 42] Internet Draft SNMPv2 Administrative Infrastructure March 1995 View Index Type Family Name Family Mask | 7 included internet ''H | 7 excluded snmpParties ''H | 8 included system ''H | 8 included snmpParties ''H | Table 9: Definition of Multiple Views | A more complicated example of MIB view configuration illustrates the use | of view subtree families (see Table 10). | In this example, the MIB view associated with the View Index 42 includes | all object instances in the system group of the Internet-standard MIB together with information related to the second network interface attached to the managed device. However, this interface-related information does not include the speed of the interface. The family mask value 'FFA0'H in the second table entry signifies that a MIB object instance belongs to the relevant subtree family if the initial prefix of its name places it within the ifEntry portion of the registration hierarchy and if the eleventh sub-identifier of its name is 2. The MIB object instance representing the speed of the second network interface belongs to the subtree families represented by both the second and third entries of the table, but that particular instance is excluded from the | MIB view for View Index 42 because the | lexicographically greater of the relevant family names appears in the table entry with type excluded. The MIB view for View Index 49 is also defined in this example, to | include all object instances | in the icmp group of the Internet-standard MIB, together with all information relevant to the fifth network interface attached to the managed device. In addition, the MIB view for View Index 49 | includes the number of octets received on the fourth attached network interface. Expires September 1995 [Page 43] Internet Draft SNMPv2 Administrative Infrastructure March 1995 View Index Type Family Name Family Mask | 42 included system ''H | 42 included { ifEntry 0 2 } 'FFA0'H | 42 excluded { ifSpeed 2 } ''H | 49 included icmp ''H | 49 included { ifEntry 0 5 } 'FFA0'H | 49 included { ifInOctets 4 } ''H | Table 10: More Elaborate View Definitions | While, as suggested by the examples above, a wide range of MIB view configurations are efficiently supported by the use of view subtree families, prudent MIB design can sometimes further reduce the size and complexity of the most likely MIB view definitions. On one hand, it is critical that mechanisms for MIB view configuration impose no absolute constraints either upon the access policies of local administrations or upon the structure of MIB namespaces; on the other hand, where the most common access policies are known, the configuration costs of realizing those policies may be slightly reduced by assigning to distinct portions of the registration hierarchy those MIB objects for which local policies most frequently require distinct treatment. Notwithstanding the above, instance level granularity is optional (see + section 3.6). + 6.4. Proxy Configuration This section presents an example configuration that supports SNMPv2 proxy operations - indirect interactions between an SNMPv2 agent and an SNMPv2 manager that are mediated by a second SNMPv2 agent which performs the role of a proxy SNMPv2 agent. Tables 11 and 12 present information the SNMPv2 manager's LPD: Table 11 | for access control policies, and Table 12 for SNMPv2 parties. Tables | 13, 14 and 15 present information in the proxy SNMPv2 agent's LPD: Table | 13 for SNMPv2 parties, Table 14 for proxy contexts, and Table 15 for | access control policies. | (These configurations are simplified for clarity: actual configurations may require additional parties in order to support other operations and | other managers.) | Expires September 1995 [Page 44] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Target Subject Context Privileges chico groucho ducksoup Get/GetNext/GetBulk/SNMPv2-Trap | Table 11: Access Information for Management Station | Identity groucho chico (manager) (proxy agent) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 2002 1.2.3.5, 161 Auth Prot v2md5AuthProtocol v2md5AuthProtocol Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" Auth Pub Key "this" "that" | Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 12: Party Information for Management Station | Expires September 1995 [Page 45] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Identity groucho chico (manager) (proxy agent) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 2002 1.2.3.5, 161 Auth Prot v2md5AuthProtocol v2md5AuthProtocol Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" Auth Pub Key "this" "the-other" | Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Identity harpo zeppo (proxy dst) (proxy src) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.6, 161 1.2.3.5, 161 Auth Prot v2md5AuthProtocol v2md5AuthProtocol Auth Priv Key "MNOPQR0123456789" "STUVWX0123456789" Auth Pub Key "" "" Auth Clock 148448 5764309 | Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 13: Party Information for Proxy Agent | Context Type Proxy Dest. Proxy Source Proxy Context | ducksoup proxy harpo zeppo bigstore | bigstore proxy 0.0 0.0 0.0 | Table 14: Contexts known to Proxy Agent | Expires September 1995 [Page 46] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Target Subject Context Privileges chico groucho ducksoup Get/GetNext/GetBulk/SNMPv2-Trap | zeppo harpo bigstore 0 | Table 15: Access Information for Proxy Agent | As shown in Table 13, | the proxy SNMPv2 agent party operates at UDP port 161 at IP address 1.2.3.5 using the party identity chico; the example manager operates at UDP port 2002 at IP address 1.2.3.4 using the identity groucho; the proxy source party operates at UDP port 161 at IP address 1.2.3.5 using | the party identity zeppo, and | the proxy destination party operates at UDP port 161 at IP address 1.2.3.6 using the party identity harpo. Messages generated by all four SNMPv2 parties are authenticated by using the authentication protocol v2md5AuthProtocol and their individual private authentication keys. Table 14 shows the SNMPv2 contexts known to the proxy SNMPv2 agent. | In particular, the SNMPv2 context ducksoup is a proxy context that is satisfied when the SNMPv2 party zeppo communicates with the SNMPv2 party harpo and references the SNMPv2 context bigstore. In order to interrogate the proxied device associated with the context | ducksoup (see Table 11), | the SNMPv2 manager constructs an SNMPv2 message from party groucho containing a GetNext request for the SNMPv2 context ducksoup, and | transmits it to the party chico operating (see Table 12) at UDP | port 161 and IP address 1.2.3.5. This request is authenticated using the private authentication key "0123456789ABCDEF". When that request is received by the party chico, the originator of the message is verified as being the party groucho by using local knowledge | (see Table 13) of the private authentication key "0123456789ABCDEF". | Because party groucho is authorized to issue GetNext (as well as Get and GetBulk) requests to party chico for the SNMPv2 context ducksoup by the | relevant access control policy (Table 15), | the request is accepted. Because the LPD (Table 14) indicates that the | SNMPv2 context ducksoup is a proxy context, the request is satisfied by its translation into a corresponding SNMPv2 GetNext request with a | unique request-id, source party zeppo, destination party harpo and with | SNMPv2 context bigstore. This new communication is authenticated using Expires September 1995 [Page 47] Internet Draft SNMPv2 Administrative Infrastructure March 1995 the private authentication key "STUVWX0123456789" and transmitted to party harpo at the IP address 1.2.3.6. When this new request is received by the party harpo, authentication and | access control is performed in the normal way, and an SNMPv2 Response | message representing the results of the query is generated from the | party harpo to party zeppo referencing SNMPv2 context bigstore. This response communication is authenticated using the private authentication key "MNOPQR0123456789" and transmitted to party zeppo at IP address 1.2.3.5 (the source address for the corresponding request). When this response is received by party zeppo, the source of the message is verified as being the party harpo by using local knowledge (see Table | 13) of the private authentication key "MNOPQR0123456789". Because this | message contains a Response operation, it is accepted without | application of access control. Its request-id is used to correlate this | request to the previously forwarded GetNext such that the appropriate | response can be constructed. This response is constructed to have the | request-id of the original GetNext request, an SNMPv2 context of | ducksoup, the source party chico and the destination party groucho; it | is authenticated using the chico's private authentication key | "GHIJKL0123456789" and is transmitted to IP address 1.2.3.4 (the source | address for the original request). | When this response is received by the party groucho, the source of the message is verified as being the party chico by using local knowledge | (see Table 13) of the private authentication key | "GHIJKL0123456789". Because this message contains a Response operation, | it is accepted without application of access control, | and the interrogation is complete. 6.5. Public Key Configuration This section presents an example configuration predicated upon a hypothetical security protocol. This hypothetical protocol would be based on asymmetric (public key) cryptography as a means for providing data origin authentication (but not protection against disclosure). This example illustrates the consistency of the administrative model with public key technology, and the extension of the example to support protection against disclosure should be apparent. Expires September 1995 [Page 48] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Identity ollie stan (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2004 Auth Prot pkAuthProtocol pkAuthProtocol Auth Priv Key "0123456789ABCDEF" "" Auth Pub Key "abcdefghijklmnop" "0123456789012345" | Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 16: Party Information for Public Key Agent | The example configuration comprises a single SNMPv2 agent that interacts with a single SNMPv2 manager. Tables 16 and 17 | present information about SNMPv2 parties as known to the agent and | manager, respectively. Table 5 presents information about a local | access policy known by the agent, and Table 6 presents information about | a local access policy known by the manager. | Identity ollie stan (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2004 Auth Prot pkAuthProtocol pkAuthProtocol Auth Priv Key "" "GHIJKL0123456789" Auth Pub Key "abcdefghijklmnop" "0123456789012345" | Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 17: Party Information for Public Key Management Station | As shown in Table 16, the example agent party operates at UDP | port 161 at IP address 1.2.3.4 using the party identity ollie; the example manager operates at UDP port 2004 at IP address 1.2.3.5 using Expires September 1995 [Page 49] Internet Draft SNMPv2 Administrative Infrastructure March 1995 the identity stan. Both ollie and stan authenticate all messages that they generate by using the hypothetical SNMPv2 authentication protocol pkAuthProtocol and their individual private authentication keys. In most respects, the interaction between manager and agent in this configuration is almost identical to that in the example of the minimal, secure SNMPv2 agent described above. The most significant difference is that neither SNMPv2 party in the public key configuration has knowledge of the private key by which the other party authenticates its transmissions. Instead, for each received authenticated SNMPv2 communication, the identity of the originator is verified by applying an asymmetric cryptographic algorithm to the received message together with the public authentication key for the originating party. Thus, in this configuration, the agent knows the manager's public key | ("0123456789012345") but not its private key | ("GHIJKL0123456789"); similarly, the manager knows the agent's public | key ("abcdefghijklmnop") but not its private key | ("0123456789ABCDEF"). Expires September 1995 [Page 50] Internet Draft SNMPv2 Administrative Infrastructure March 1995 7. Security Considerations In order to participate in the administrative model set forth in this memo, SNMPv2 implementations must support local, non-volatile storage of the LPD. Accordingly, every attempt has been made to minimize the amount of non-volatile storage required. 8. Acknowledgements The authors wish to acknowledge the contributions of the SNMPv2 Working Group in general. In particular, the following individuals Dave Arneson (Cabletron), Uri Blumenthal (IBM), Doug Book (Chipcom), Maria Greene (Ascom Timeplex), Deirdre Kostik (Bellcore), Dave Harrington (Cabletron), Jeff Johnson (Cisco Systems), Brian O'Keefe (Hewlett Packard), Dave Perkins (Bay Networks), Randy Presuhn (Peer Networks), Shawn Routhier (Epilogue), Bob Stewart (Cisco Systems), Kaj Tesink (Bellcore). deserve special thanks for their contributions. 9. References [1] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, March | 1995. | [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for Version 2 of the Simple Network Expires September 1995 [Page 51] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, March 1995. | [4] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., | "Party MIB for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, March 1995. SNMP Research, Inc., | Trusted Information Systems, Cisco Systems, Dover Beach Consulting, | Inc., Carnegie Mellon University, | [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, March | 1995. | [6] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., | "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Trusted | Information Systems, Cisco Systems, Dover Beach Consulting, Inc., | Carnegie Mellon University, March 1995. | [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, | March 1995. | [8] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., + "Coexistence between Version 1 and Version 2 of the Internet- + standard Network Management Framework", Internet Draft, SNMP + Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., + Carnegie Mellon University, March 1995. + Expires September 1995 [Page 52] Internet Draft SNMPv2 Administrative Infrastructure March 1995 10. Authors' Addresses Jeffrey D. Case + SNMP Research, Inc. + 3001 Kimberlin Heights Rd. + Knoxville, TN 37920-9716 + US + Phone: +1 615 573 1434 + Email: case@snmp.com + James M. Galvin Trusted Information Systems, Inc. 3060 Washington Road, Route 97 Glenwood, MD 21738 Phone: +1 301 854-6889 EMail: galvin@tis.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 5260 Email: kzm@cisco.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 + Steven Waldbusser + Carnegie Mellon University + 5000 Forbes Ave + Pittsburgh, PA 15213 + US + Expires September 1995 [Page 53] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Phone: +1 412 268 6628 + Email: waldbusser@cmu.edu + Expires September 1995 [Page 54] Internet Draft SNMPv2 Administrative Infrastructure March 1995 Table of Contents 1 Introduction .................................................... 3 1.1 A Note on Terminology ......................................... 3 1.2 Change Log .................................................... 3 2 Overview ........................................................ 5 2.1 Contexts ...................................................... 5 2.2 Authorization: Access Rights and MIB Views .................... 6 2.3 Proxy ......................................................... 7 2.4 Security ...................................................... 8 2.5 Parties ....................................................... 9 2.6 Authorization: Access Control ................................. 9 2.7 Construction of an SNMPv2 Message ............................. 10 2.8 An SNMPv2 Entity's Local Party Datastore ...................... 10 2.9 Maintenance Functions ......................................... 11 3 Elements of the Model ........................................... 12 3.1 SNMPv2 Party .................................................. 12 3.2 SNMPv2 Entity ................................................. 14 3.3 SNMPv2 Manager ................................................ 14 3.4 SNMPv2 Agent .................................................. 14 3.5 SNMPv2 Dual-Role Entity ....................................... 15 3.6 View Subtree .................................................. 15 3.7 View Subtree Families ......................................... 16 3.8 MIB View ...................................................... 16 3.9 Proxy Context ................................................. 17 3.10 SNMPv2 Context ............................................... 18 3.11 SNMPv2 PDU ................................................... 20 3.12 SNMPv2 Message ............................................... 20 3.13 SNMPv2 Management Communication .............................. 21 3.14 SNMPv2 Authenticated Management Communication ................ 22 3.15 SNMPv2 Private Management Communication ...................... 22 3.16 SNMPv2 Access Control Policy ................................. 23 4 Maintenance Functions ........................................... 25 4.1 Error Reporting ............................................... 26 5 Elements of Procedure ........................................... 28 5.1 Generating a Request .......................................... 28 5.2 Processing a Received Communication ........................... 29 5.3 Generating a Response ......................................... 36 6 Usage Examples .................................................. 37 6.1 Non-Secure Minimal Agent Configuration ........................ 37 6.2 Secure Minimal Agent Configuration ............................ 40 6.3 MIB View Configurations ....................................... 42 6.4 Proxy Configuration ........................................... 44 6.5 Public Key Configuration ...................................... 48 Expires September 1995 [Page 55] Internet Draft SNMPv2 Administrative Infrastructure March 1995 7 Security Considerations ......................................... 51 8 Acknowledgements ................................................ 51 9 References ...................................................... 51 10 Authors' Addresses ............................................. 53 Expires September 1995 [Page 56]