Internet Draft Administrative Model for SNMPv2 September 1995 Administrative Model for Version 2 of the Simple Network Management Protocol (SNMPv2) Fri Sep 08 1995 draft-various-snmpv2-adminv2-syn-01.txt Tell U. Later snmpv2@tis.com 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.'' 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 February 1996 [Page 1] Internet Draft Administrative Model for SNMPv2 September 1995 running list of open issues: tie procedures more closely to specific mib objects reference list reference citations acknowledgements authors author addresses spell check Expires February 1996 [Page 2] Internet Draft Administrative Model for SNMPv2 September 1995 Abstract Computer security systems can be usually be understood as being composed of two or more logically distinct components. There is often a privacy service that protects data from disclosure, an authentication service that validates the identity of the entity requesting service, and an access control service which, given an authorized entity, restricts the data and operations to which that entity has access. The SNMPv2 Administrative Model makes these distinctions. It specifies the data and protocols that a compliant SNMPv2 entity must implement in order to provide an access control service. However, it does not say anything about how authentication, privacy, timeliness, and the like ought to be implemented. Rather, it leaves the hooks in place for these services to be implemented in a variety of ways. Henceforth, this collection of unspecified services will be collectively referred to as "the authentication and privacy services". Consequently, the SNMPv2 Administrative Model provides an architecture that realizes an access control service, and provides the means for integrating authentication and privacy services. The access control service of the SNMPv2 Administrative Model contains the following key concepts: groups, contexts, MIB views, and access rights. The idea is that on a particular SNMPv2 entity, the identities within a group have access (within a particular context) to a set of MIB variables specified by the MIB view and can operate on those variables according to the what the access rights allow. There are two principal provisions for integrating authentication and privacy services. First, there is a field in the SNMPv2 message header that indicates which authentication and privacy service the sender used and therefore a receiver of the message should use; and there is an opaque set of fields which contain security information specific to the indicated authentication and privacy service. Second, and more significantly, there is the concept of an "identity". The security service may use this identity to authenticate the packet, but it MUST also map the identity to a group so that the access control service can perform access control checking. In other words, the concept of an identity is used by the authentication and privacy service, while the concept of a group is used by the access control service. It is the responsibility of the authentication and privacy service to maintain the mapping between an identity and a group. Expires February 1996 [Page 3] Internet Draft Administrative Model for SNMPv2 September 1995 1. Introduction A management system contains: several (potentially many) manageable nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol. The management protocol is used to convey management information between the agents and management stations; and, for manager-to-manager communications, between 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 Model for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. The model described here includes the identification of | the entities on whose behalf SNMPv2 messages are exchanged. Thus, it represents a departure from the community-based administrative model of the original SNMP [@ref 1157]. This new strategy improves upon the historical community-based scheme by defining a model for authentication, authorization, access control, and privacy including definitions of an initial set of mechanisms to provide these services. A wide range of mechanisms are compatible with this model, including mechanisms based on symmetric (private key) security protocols and mechanisms based on asymmetric (public key) security protocols. 1.1. A Note on Terminology The original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, [@ref 1155, 1157, 1212], defined an initial community-based administrative model, and an initial set of protocol operations. For the purpose of exposition, this is termed the SNMP version 1 framework (SNMPv1). The SNMPv2 management framework consists of multiple building blocks, including SMI definitions [@ref v2smi], [@ref tc], and [@ref conf]; MIB definitions [@ref ]; an administrative framework consisting of an administrative model described herein, definitions of security and privacy services such as those found in [@ref sec], and a set of MIB Expires February 1996 [Page 4] Internet Draft Administrative Model for SNMPv2 September 1995 definitions to support the administrative model [@ref adminmib]; definitions of protocol operations [@ref protoops]; and SNMPv2 applications. The SNMP version 2 administrative framework (SNMPv2) includes an administrative model as described herein which couples SNMPv2 applications to one or more transport stacks and thereby provides remote, networked, access to management information via an enhanced set of protocol operations as described in [@ref protoops]. A transitional approach, using the SNMP version 1 administrative model in combination with the SNMP version 2 protocol operations is defined in | [@ref v2Cadmin]. | 2. Overview This section provides an overview of the remainder of the document, including an introduction to some of the pertinent vocabulary. As such, there is some overlap between this section and the subsequent ones in order to avoid forward references. The administrative model which is a part of the SNMP version 2 administrative framework couples SNMPv2 applications to one or more transport stacks and thereby provides remote, networked, access to management information (See Figure 1). An SNMPv2 entity is an implementation of the administrative framework described herein, coupled with one or more applications, such as agent, manager, or dual-role entity applications, which remotely access management information via the SNMPv2. Expires February 1996 [Page 5] Internet Draft Administrative Model for SNMPv2 September 1995 +----------------------------------------+ | SNMPv2 Applications | +---------------+ | e.g., |--->| Management | | Agent, Manager, and Dual-Role Entity |<---| Information | | Applications | +---------------+ +----------------------------------------+ | Administrative | | Framework | | including | | Administrative Model | +----------------------------------------+ | | | Transport Stack(s) | | | +----------------------------------------+ Figure 1: The SNMPv2 Administrative Framework 2.1. Management Information 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.2. 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 Expires February 1996 [Page 6] Internet Draft Administrative Model for SNMPv2 September 1995 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. Contexts are identified in an unambiguous and a globally unique manner by the pairing of a contextSnmpID and a contextName; with the contextSnmpID identifying a SNMPv2 entity which is an implementation of the administrative framework including its administrative model, and the contextName identifying a context within that entity. For example, the managed object type, ifDescr [@ref ifevolution], is defined as the description of a network interface. To identify the description of device-X's first network interface, four pieces of information are needed: the contextSnmpID which uniquely identifies device-X, the contextName within device-X, ifDescr (the managed object type), and "1" (the instance). The contextName is expressed as a user-friendly, and often mnemonic, string-based label which is convenient for manipulation by humans within a system, such as when configuring a device. Management information often changes over time, for example, where the value of a device parameter after the device's next restart is to be different than its current value. 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, e.g., such as after the next restart. 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 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.3. 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 Expires February 1996 [Page 7] Internet Draft Administrative Model for SNMPv2 September 1995 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 [@ref iso8824, v2smi], 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 could 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. 2.4. Access Rights 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 not be permitted write-access to a particular context, while another might be allowed to perform any type of operation. 2.5. Authentication and Privacy The enforcement of access rights requires the means not only to identify the entity on whose behalf a request is generated but also to authenticate such identification. Another security capability which is (optionally) provided is the ability to protect the data within an SNMPv2 operation from disclosure (i.e., to encrypt the data). This is particularly useful when sensitive data (e.g., passwords) are accessed via SNMPv2 requests. Expires February 1996 [Page 8] Internet Draft Administrative Model for SNMPv2 September 1995 2.6. Security Mechanisms and Algorithms Recommendations for which algorithms are best for authentication and privacy are subject to change. Such changes may occur 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 increasingly 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 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 security as providing neither authentication nor protection against disclosure. 2.7. Security Protocol Identifiers and the Reportable Flag Each SNMPv2 message header contains a field which indicates the particular authentication and privacy mechanisms and protocols in use within that message. This is called the security flags field. The security flags field conveys two aspects: the security protocol identifier (sPI) value and the reportableFlag (reportableFlag). The sPI value can be used to select a particular authentication and privacy service, which, among other things, can be used to derive an identity from a message. Correspondingly, the sPI value is added to a message as a part of message generation for later use in the decoding process. In general, it is poor protocol design to generate an error message in response to an error message and the SNMPv2 administrative framework includes mechansims to prevent such behaviors. The reportableFlag portion of the security flags is used to indicate if the message contains an SNMPv2 protocol operation which could possibly result in a report operation signifying an error. That is, the reportableFlag is true if the message contains a GetRequest, GetNextRequest, GetBulkRequest, SetRequest, or InformRequest operation. This reportableFlag is never true for a message which contains a Response, Expires February 1996 [Page 9] Internet Draft Administrative Model for SNMPv2 September 1995 SNMPv2-Trap, or Report operation. The security flags field is a signed integer, consisting of two parts corresponding to the reportableFlag and the sPI. The reportableFlag is communicated in the least significant bit of the security flags field. The remaining bits convey the value of the sPI. The values of sPI are allocated as follows. Negative and zero values for sPI are reserved. Values of sPI between 1 and 127, inclusive, are reserved for use with standards-track protocols and are managed by the Internet Assigned Numbers Authority (IANA). Values of sPI greater than 127 are allocated to enterprise-specific protocol definitions. An enterprise-specific sPI value is defined to be the enterprise number * 128 + the protocol number within that enterprise. For example, the fourth protocol defined by the enterprise whose enterprise number is 1 would be 132. These seven bits allow a maximum of 128 standards-based authentication and privacy services. Similarly, they allow a maximum of 128 authentication and privacy services per enterprise. It is believed that the assignment of new sPI values should be rare in practice because the larger the number of simultaneously utilized security protocols, the larger the chance that interoperability will suffer. Consequently, it is believed that such a range will be sufficient. In the unlikely event that the standards committee finds this number to be insufficient over time, an enterprise number can be allocated to obtain an additional 127 possible values. Note that the most significant bit must be zero; hence, there are 23 bits allocated for various organizations to design and define non- standard security protocols. This limits the ability to define new proprietary implementations of security protocols to approximately the first 8 million enterprises. It is worthwhile to note that, in its encoded form, the sPI value will normally require only a single byte since, in practice, the leftmost bits will be zero for most messages and sign extension is suppressed by the encoding rules. As of this writing, there are several values of sPI defined for use with SNMPv2 or reserved for use with supporting MIB objects. They are as follows: 1 reserved for use in MIB objects and in association with the SNMPv1 Expires February 1996 [Page 10] Internet Draft Administrative Model for SNMPv2 September 1995 administrative framework [@ref 1157] 2 reserved for use in MIB objects and in association with the | SNMPv2C administrative framework [@ref v2Cadmin] | 3 unauthenticated report messages 4 usecNoAuth messages [@ref sec] 5 usecAuth messages [@ref sec] 6 usecPriv messages [@ref sec] 2.8. Identities and Group Names Each SNMPv2 message conveys information on behalf of an identity. To provide the necessary security capabilities, an SNMPv2 message needs to indicate that identity. The identity can be conveyed either explicitly or implicitly. The exact manner in which an identity is conveyed in an SNMPv2 message is dependent upon the particular security mechanisms and protocols which have been applied to that SNMPv2 message and these may vary from time- to-time and from message-to-message. In addition to the sPI value, each message header also contains a set of fields, called the authInfo sequence, which contains the necessary parameters used by the authentication and privacy service identified by the sPI. Accordingly, the sPI field indicates how a receiver should parse and interpret the data found in the authInfo portion of the header upon receipt as well as how to generate the authInfo portion of the header prior to transmission. While there are a nearly infinite number of possibilities as to how the information regarding an identity can be encoded in the packet header, identities within a system are always identified by user-friendly, and often mnemonic, string-based labels which are convenient for manipulation by humans within a system, such as when configuring a device. It is the responsibility of the authentication and privacy service to transform the encoded information in a packet header into a string-based Expires February 1996 [Page 11] Internet Draft Administrative Model for SNMPv2 September 1995 identity upon receipt of a message and to transform a string-based identity into the properly encoded information for the sPI in effect. An identity may operate at more than one manager location and more than one agent location or may be restricted to a single pair of locations, depending upon the particular authentication and privacy sPI in effect. As a result, an identityName alone is insufficient to uniquely designate an identity. Consequently, in some parts of an SNMPv2 infrastructure, an identityName is paired with an authSnmpID, in order to provide a globally unique designation of an identity and its associated parameters. This allows, for example, the use of multiple passwords by a single identity. However, in some parts of an SNMPv2 infrastructure, in particular some low cost systems, the authSnmpID is always a constant value corresponding to an identifier which uniquely identifies that entity. For some protocol operations, local agent operations in particular, it is both convenient and efficient to grant access based on various group profiles rather than per individual identity. For implementations of this model which perform those operations, each identity is also associated with a groupName. A groupName, like an identityName, is always identified by a user- friendly, and often mnemonic, string-based label which is convenient for manipulation by humans within a system, such as when configuring a device. For example, an identity might be associated with a group of identities with a groupName of "ActiveDayShiftSupervisor" whereas other identities might be associated with a group of identities with a groupName of "FieldServiceTechnician". 2.9. Authorization: Access Control As described above, an SNMPv2 message is associated with one context, parameters in an authInfo sequence, and security flags field, where the context determines the set of management information being accessed by the message, the authInfo parameters convey the identity on whose behalf the information is being communicated, and the security flags field conveys the reportableFlag and sPI values. The reportableFlag indicates if failures in the processing of the message are allowed to invoke report operations and the sPI value indicates the type and nature of the authentication and privacy parameters. These properties of the message are used for access control within local operations and to control the forwarding of messages within proxy operations. Specifically, access control is specified as a set of local access policies which regulate Expires February 1996 [Page 12] Internet Draft Administrative Model for SNMPv2 September 1995 access to data within a specified local context by a given identity using a particular sPI. The local access control specifies the set of permitted operations and the MIB views which are allowed. If the context, the identity derived from the authInfo sequence, and sPI are not a valid combination, or the operation requested is not one of the operations allowed by the triple, then the requested access is denied. 2.10. 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 [@ref protoops].) There are seven parts to every SNMPv2 message. They are as follows: - The first part of every SNMPv2 message conveys the version number. Every SNMPv2 message has a version number of "2" which denotes that it supports version 2 of the administrative model as described herein and version 2 of the protocol operations, as described in [@ref protoops]. (Version 1 of the Internet-standard management framework allocated "0" to this field. The value "1" is reserved | for use to denote the SNMPv2C administrative model [@ref | v2Cadmin].) | By doing so, a parser of received messages can determine if a packet should be processed by the SNMPv2 engine, or should be redirected to an SNMPv1 protocol engine [@ref 1157], or an SNMPv2C | protocol engine [@ref v2Cadmin]. | - The mms portion of the message conveys information about the sender's maximum message size for messages received via the same transport layering used by the message. - The security flags portion conveys the reportableFlag and the security protocol identifier (sPI). The sPI indicates the authentication and privacy service used by the message. - The authInfo portion of the header contains the parameters used by that authentication and privacy service. Hence, the exact contents of the authInfo portion of the header varies, depending upon the value of sPI. - The contextSnmpID is the fifth portion of the header. The contextSnmpID conveys the globally unique portion of the context Expires February 1996 [Page 13] Internet Draft Administrative Model for SNMPv2 September 1995 identification. - The contextName is the sixth portion of the header. The contextName conveys the locally-significant portion of the context identification within the system denoted by the contextSnmpID. - The PDU is the seventh, and last, portion of the message. The concatenation of a contextSnmpID, contextName, and PDU is termed a ScopedPDU for the convenience of exposition. The format of a message is illustrated in Figure 2 (formal ASN.1 definitions follow in a later section). | <----- SnmpV2Message -------------------------------------> | | | <------------ SnmpV2AuthMessage ----------> | | sec | <---- ScopedPDU ------------> | | ver mms flgs| authInfo | Context ID| PDU | +---------------+-------------+-----------+-------------------+ | S | | m | s | S | c | c | c | S p | | | E | v | m | e | E | o | o S | o | E d | | | Q | e | s | c | Q | n v | n n | n N | Q u | P | | = | r | | f | = | t a ... | t m | t a | = | | D | | T | = | | l | [ | e r | e p | e m | t | U | | a | 0 | | a | 9 | n y | x I | x e | y | | | | g | 2 | | g | ] | t | t D | t | p | | | | | | | s | | s | | | e | | | +---------------+-------------+-----------+-------------------+ Figure 2: SNMPv2 Message Format 2.11. Authentication and Privacy Service There can be a number of authentication and privacy services, denoted by various values of sPI, defined for use with the administrative framework defined by this document. Any particular implementation may support one or more of the possible authentication and privacy services. The definition of an initial set of these is found in accompanying documents [@ref sec] and additional values of sPI may be defined in future documents. Any newly-defined authentication and privacy service must: o process the authInfo portion of the message to derive an identityName, authSnmpID, and groupName; Expires February 1996 [Page 14] Internet Draft Administrative Model for SNMPv2 September 1995 o decrypt, if necessary, the ScopedPDU containing the context information and PDU to provide plaintext, and o provide any other information needed, if any, to be cached for use when producing a subsequent message, e.g., a response to a query or command, or in association with proxy forwarding operations. Any newly-defined authentication and privacy service must also be able to generate an SnmpV2AuthMessage value from: o an identityName and authSnmpID; o an sPI value; and o a ScopedPDU with context information consisting of a contextName and contextSnmpID followed by a PDU. 2.12. An SNMPv2 Entity's Local Configuration Datastore To implement the model described in the preceding sections, each SNMPv2 entity needs to retain its own set of information about contexts, identities, access rights and policies, and the like. This set of information is called the SNMPv2 entity's Local Configuration Datastore (LCD) because it is locally-stored information. Note, however, that the LCD often contains information about both local and remote systems. In order to allow an SNMPv2 entity's LCD to be configured, and to allow the synchronization needed by the security algorithms before they can be used to communicate securely, portions of the LCD need to be accessible as managed objects. A MIB module, the SNMPv2 Administration MIB, which defines these managed object types is contained in [@ref adminmib]. Furthermore, each definition of an authentication and privacy service, denoted by an sPI, must also define any MIB and LCD support needed by that authentication and privacy service. It can do this either by describing new MIB elements, defining additional MIB objects which AUGMENT those of another authentication and privacy service, or by explaining the proper semantics and rules for use of MIB objects previously defined for use by another authentication and privacy sPI. It is expected that, over time, each of these three approaches will be used for defining the relevant information in the LCD. As of this writing, one set of authentication service-specific MIB objects are shared by three authentication and privacy services [@ref sec]. Other objects provide shared support for the SNMPv1 [@ref 1157] and SNMPv2 | [@ref v2Cadmin]. | Expires February 1996 [Page 15] Internet Draft Administrative Model for SNMPv2 September 1995 2.13. 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 or algorithmically derived maintenance context and makes use of a corresponding well-known or algorithmically derived maintenance identity. For example, error reporting and clock synchronization, are achieved by performing SNMP operations in this manner. 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 identities and contexts specified in this document do not always apply to these maintenance functions. 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. The only maintenance function defined in this specification of the administrative model is that of error reporting. Additional maintenance functions may be defined by particular security and privacy services. 2.14. 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 Expires February 1996 [Page 16] Internet Draft Administrative Model for SNMPv2 September 1995 each request for items of management information within one of the possibly multiple 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 to other SNMP agents without regard for what managed object types are being accessed; for example, in order to forward an 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; and (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 of 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: - 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 framework. 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 Expires February 1996 [Page 17] Internet Draft Administrative Model for SNMPv2 September 1995 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). An SNMPv2 agent need not implement proxy forwarding operations in order to be compliant with this specification. 2.15. Transparency Principle 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. 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. (Note, however that amongst the error conditions indicated by a Report Expires February 1996 [Page 18] Internet Draft Administrative Model for SNMPv2 September 1995 PDU received by a proxy SNMPv2 agent from a proxied device, some may be corrected without being reported back to the SNMPv2 manager; for example, when a clock resynchronization is needed. Even when such errors can not be corrected, they are only indirectly reported back. Expires February 1996 [Page 19] Internet Draft Administrative Model for SNMPv2 September 1995 3. Elements of the Model This section provides a more formal description of the model. 3.1. SNMPv2 Applications An SNMPv2 application is an application-layer component which effects logically remote monitoring and control functions by generating or receiving (and processing) one or more types of transactions contained within SNMPv2 messages. SNMPv2 entities include: SNMPv2 agents, SNMPv2 managers, and SNMPv2 dual-role entities. 3.1.1. 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 protocol operations in response to received SNMPv2 protocol messages (except for inform notifications) generated by an SNMPv2 manager. Some SNMPv2 agents also emit trap notifications. For the purposes of this administrative model, when a dual-role entity is acting in an agent role, it is considered to be an SNMPv2 Agent. 3.1.2. 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 entity acts in a manager role when it initiates SNMPv2 management operations by the generation of appropriate SNMPv2 protocol messages, including when it generates inform notifications, when it receives and processes trap and inform notifications, and when it receives reports. In those cases where an SNMPv2 manager receives inform requests, it also generates reports. For the purposes of this administrative model, when a dual-role entity is acting in a manager role, it is considered to be an SNMPv2 manager. 3.1.3. 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. Expires February 1996 [Page 20] Internet Draft Administrative Model for SNMPv2 September 1995 There are two categories of SNMPv2 dual-role entities: (1) proxy SNMPv2 agents, and (2) (so-called) mid-level managers. Proxy SNMPv2 agents only forward requests/responses; they do not originate requests. In contrast, mid-level managers often originate requests. A primary purpose of SNMPv2 dual-role entities is often to generate requests and aggregate responses. Expires February 1996 [Page 21] Internet Draft Administrative Model for SNMPv2 September 1995 3.1.4. SNMPv2 Application Layering within the Administrative Framework The following drawing of the administrative framework illustrates the conceptual layering of SNMPv2 applications on top of the administrative model (See Figure 3). Expires February 1996 [Page 22] Internet Draft Administrative Model for SNMPv2 September 1995 +----------------------------------------------------------------------+ | Agent Role Applications | Manager Role Applications | +----------------------------------------------------------------------+ | Local Proxy Trap Report | Local Recvd- Notifi- Recvd Report | | Agent Forwarding Gener- Gener- | Mgr Notifi- cation Report Gener- | | OPs OPs ation ation | OPs cation Gen'n OPs ation | | | OPs | +----------------------------------------------------------------------+ | Applications | +----------------------------------------------------------------------+ | ^ v <.... Management Transactions ...> | +----------------+ +----------------+ | Transmit | | Received | | Scoped-PDU | | Scoped-PDU | | Processing | | Processing | +----------------+ +----------------+ | <.......... ScopedPDUs ..........> ^ | +-------------------+ | +------->| Authentication |-------+ | and Privacy | +--------| Services |<------+ | +-------------------+ | v <...... SnmpV2AuthMessages ......> | +----------------+ +----------------+ | Transmit | | Received | | Wrapper | | Wrapper | | Processing | | Processing | +----------------+ +----------------+ Non-V2 ----+ | < ........ SnmpV2Messages .......> ^ Non-V2, Traffic, | | | +--> Traffic, e.g.,V1,V2C v v | | e.g., V1,V2C | +---------------------------------------------------------+ | Transport Stack(s) | +---------------------------------------------------------+ Figure 3: Conceptual Layering of SNMPv2 Applications and the Administrative Model 3.1.5. SNMPv2 Agent Role Applications There are at least four functional services provided by SNMPv2 entities acting in an agent role. These include: Local Agent Operations, Proxy Forwarding Operations, Trap Generation, and Report Generation. Expires February 1996 [Page 23] Internet Draft Administrative Model for SNMPv2 September 1995 3.1.5.1. Local Agent Operations Local Agent Operations are performed by an SNMPv2 entity acting in an agent role in response to request messages received from a logically remote SNMPv2 entity acting in a manager role. These operations manipulate data which are locally accessible by the agent. These request messages include several types of operations, including GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations. Local Agent Operations almost always result in the production and transmission of an appropriate response, (sometimes including error or other exceptional indicators), termed the Response message. 3.1.5.2. Proxy Forwarding Operations Proxy Forwarding Operations are performed by an SNMPv2 entity by receiving SNMPv2 messages from one or more SNMPv2 entities, analyzing them to determine a disposition, and then transmitting regenerated messages to one or more SNMPv2 entities. Entities which perform Proxy Forwarding Operations are often bi- directional, forwarding messages both "upstream" and "downstream" but this is not necessarily the case. For example, this would not be the case for an entity which is able to perform forwarding operations of unidirectional messages, i.e., trap messages, either because of implementation restrictions or due to local policies such as security, configuration, or administration policies. 3.1.5.3. Trap Generation Operations Trap Generation Operations are performed by an entity acting in an agent role when it generates a trap message and sends it to one or more SNMPv2 entities acting in a manager role. 3.1.5.4. Report Generation Operations An SNMPv2 entity acting in an agent role performs Report Generation Operations when it prepares and sends error report messages to a logically remote SNMPv2 entity acting in a manager role. These error reports are generated in response to received messages on behalf of the administrative model, i.e., as a byproduct of processing by the core of the administrative model as described herein or by one of the authentication and privacy services. Expires February 1996 [Page 24] Internet Draft Administrative Model for SNMPv2 September 1995 3.1.6. SNMPv2 Manager Role Applications There are at least five functional services provided by SNMPv2 entities acting in a manager role. These include: Local Manager Operations, Received Notification Operations, Notification Generation, Received Report Operations, and Report Generation. 3.1.6.1. Local Manager Operations Local Manager Operations are initiated by SNMPv2 entities acting in a manager role. They include the generation of requests containing queries or commands (i.e., GetRequest, GetNextRequest, GetBulkRequest, or SetRequest) to read or write management information. Local Manager Operations also include the receiving and processing of responses to these requests, i.e., messages containing a Response to a GetRequest, GetNextRequest, GetBulkRequest, or SetRequest. 3.1.6.2. Received Notification Operations Received Notification Operations are performed by SNMPv2 entities acting in a manager role whenever they receive and process a trap message from an SNMPv2 entity acting in an agent role, i.e., SNMPv2-Trap. Received Notification Operations are also performed by SNMPv2 entities acting in a manager role whenever they receive and process a manager-to-manager message, i.e., one containing an InformRequest. The processing of an InformRequest normally includes generation of a confirmation message to indicate information was received, (e.g., a Response confirming an InformRequest. 3.1.6.3. Notification Generation by Managers Notification Generation is performed by SNMPv2 entities acting in a manager role whenever they initiate a manager-to-manager message, i.e., one containing an InformRequest. 3.1.6.4. Received Report Operations Received Report Operations are performed by SNMPv2 entities acting in a manager role whenever they receive, process, and [if appropriate] act upon reports received by the manager. 3.1.6.5. Report Generation by Managers Report Generation by Managers is performed by SNMPv2 entities acting in a manager role whenever they generate and send a message containing an Expires February 1996 [Page 25] Internet Draft Administrative Model for SNMPv2 September 1995 error report, i.e., one containing a Report. A Report is initiated by a manager only in response to an InformRequest, and since InformRequests are initiated only by SNMPv2 entities acting in a manager role, a manager never sends a report to an agent. Consequently, an entity acting in an agent role does not receive and process reports. 3.2. SNMPv2 snmpID SNMPv2 entities are named by an SNMPv2 snmpID [@ref adminmib]. An SNMPv2 snmpID is a 12 byte quantity which provides a unique identification of SNMPv2 entities throughout the administrative domain; preferably globally as well. Each implementation of the administrative model described in this memo which initiates request operations or trap operations (including those which initiate InformRequest operations) is assigned an SNMPv2 snmpID. An implementation of the administrative model described in this memo which does not initiate request operations nor trap operations may be assigned an SNMPv2 snmpID, but this is not necessary. An SNMPv2 entity which implements this administrative model typically includes a SNMPv2 protocol engine which is associated with one or more applications. Two management applications are part of the same SNMPv2 entity if and only if they have the same value of snmpID. That is, multiple applications, e.g., an agent and a manager, or two management applications on a platform, are part of the same named entity if they have the same snmpID. Hence, a set of coordinated management applications from a single vendor might share the same snmpID and thereby be a part of the same SNMPv2 entity whereas a set of decoupled applications, each of which having their own values for snmpID, would not be a part of the same SNMPv2 entity. The snmpID is used within the administrative model to provide uniqueness for contexts and identities. For example, the local value of snmpID is sometimes used for authSnmpID or contextSnmpID when generating an SNMPv2 message at an SNMPv2 entity. The determination of the source of the snmpID to be used, i.e., remote, local, or that of a third party, is different for different transactions. Expires February 1996 [Page 26] Internet Draft Administrative Model for SNMPv2 September 1995 The snmpID value assigned to the contextSnmpID value in a message is always that snmpID value associated with the context name and the information in the variable bindings list. Accordingly, the snmpID value assigned to the contextSnmpID value in a Get, GetNext, GetBulk, or Set operation is always the snmpID value associated with the agent receiving the request. Similarly, the contextSnmpID value in the response to any of these operations is that same snmpID value. Further, the snmpID value assigned to the contextSnmpID value in a Trap notification operation is always the snmpID value associated with the agent originating the trap message. The assignment of the contextSnmpID value for use in an InformRequest operation follows these same rules. Accordingly, the snmpID value assigned to the contextSnmpID value in an InformRequest may be that of the originating manager, the receiving manager, or that of a third party. For example, in the last case, manager 1 may tell manager 2 about what it has discovered about information contained within a context on agent a. In this case, the contextSnmpID value will be that snmpID value associated with agent a. The contextSnmpID value used in the response to an InformRequest is always the same as that contained in the request. There are parallel sets of rules for the selection of authSnmpID values. The authSnmpID value is always set to the value of snmpID associated with the SNMPv2 entity which is considered to be "authoritative". For a Get, GetNext, GetBulk, or Set request operation, the "next hop" destination, i.e., the agent or the next intervening agent which provides proxy forwarding services is said to be authoritative, and is the source of the value of snmpID to be used for authSnmpID. This same value of authSnmpID is used for the responses to these request operations. For trap notification operations, the snmpID value associated with the agent which originates the trap, or the agent which provides proxy forwarding services is said to be authoritative, and is the source of the value of snmpID to be used for authSnmpID. For an inform notification request operation, the "next hop" destination, i.e., the destination manager or the next intervening agent which provides proxy forwarding services is said to be authoritative, and is the source of the value of snmpID to be used for authSnmpID. This same value of authSnmpID is used for the responses to these request operations. Expires February 1996 [Page 27] Internet Draft Administrative Model for SNMPv2 September 1995 3.3. SNMPv2 Identities An identity is assumed by an SNMPv2 entity in order to restrict its operations (for security or other purposes) to an administratively defined subset of all possible SNMPv2 operations. Whenever an SNMPv2 entity processes an SNMPv2 message, it does so by operating as a SNMPv2 identity and is thereby restricted to the set of operations defined for that identity. The set of possible operations specified for an SNMPv2 identity may be overlapping or disjoint with respect to the sets of other SNMPv2 identities. Each SNMPv2 identity is named by the pairing of an identityName and an authSnmpID. The identityName is derived from the authInfo sequence of a message and other parameters in accordance with the rules of the sPI in effect for the message. Similarly, the authInfo sequence of a message is derived from an identityName and other parameters in accordance with the rules of the sPI in effect for the message. These other parameters might include the authentication and privacy data in use on behalf of the identity, such as secret or public keys. The specifics of the mapping algorithm are dependent upon the authentication and privacy mechanisms and algorithms identified by the sPI. An SNMPv2 identity is unique only when used in conjunction with both an sPI and an authSnmpID. For example, if managers M1, M2, M3, and M4 communicate with one another and with agents A1, A2, and A3 directly and via proxies P1, P2, and P3 as shown in the following figure, then the required knowledge about a prototypical identity "joe" for a given sPI is as depicted (See Figure 4.) There are multiple instances of "joe" on each manager and each proxy node to allow for different security parameters for identity "joe", for example, different passwords on different nodes. It is through this capability that a change to the private security keys associated with "joe" might be updated and distributed through the administrative domain over a period of time. Configuration of agents is the easiest whereas managers and proxies require additional configuration. In addition, the identity "joe" may have different security parameters for different values of sPI. For example, it is possible for "joe" to have one authentication key for use with one authentication and privacy service and a different key for another authentication and privacy service. Indeed, it is even possible for there to be two different identities with the identityName of "joe" for two different values of sPI which Expires February 1996 [Page 28] Internet Draft Administrative Model for SNMPv2 September 1995 +--------+ +--------+ +--------+ +--------+ +--------+ | M1 | | M2 | | M3 | | P3 | | M4 | | joe@M1 | | joe@M1 | | joe@M2 | | joe@M3 | | joe@P4 | | joe@M2 |__| joe@M2 |__| joe@M3 |__| joe@P3 |__| joe@M4 | | joe@P1 | | joe@M3 | | joe@P3 | | joe@M4 | | | | | | joe@A2 | | joe@A2 | | | | | | | | joe@A3 | | joe@A3 | | | | | +--------+ +--------+ +--------+ +--------+ +--------+ | | \ / | | | /\ | +--------+ +--------+ +--------+ | P1 | | A2 | | A3 | | joe@M1 | | joe | | joe | | joe@P1 | +--------+ +--------+ | joe@P2 | +--------+ | +--------+ | P2 | | joe@P1 | | joe@P2 | | joe@A1 | +--------+ | +--------+ | A1 | | joe | +--------+ Figure 4: Inter-entity Identity Relationships correspond to two different human users by the name of "joe". However, the prudent administrator will likely attempt to avoid such configurations as a matter of policy even though such configurations are possible via the model and underlying protocols. It is worth mentioning that an identityName is unique within the authentication and privacy service for a given sPI on a simple agent, i.e., one which does not perform proxy forwarding operations. The authSnmpID is implicit in such systems. Expires February 1996 [Page 29] Internet Draft Administrative Model for SNMPv2 September 1995 3.4. SNMPv2 Entity An SNMPv2 entity is an actual process or set of processes which performs management operations by generating and/or responding to SNMPv2 messages in the manner specified in [@ref protoops] and Section 4.3, Proxy Forwarding Operations. An SNMPv2 entity assumes the identity of a particular SNMPv2 identity 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 identities. Thus, implementation of an SNMPv2 entity to support more than one identity need not be multi-threaded. However, there may be situations where implementors may choose to use multi-threading. Every SNMPv2 entity maintains a Local Configuration Datastore (LCD) which includes information on all identities which it uses to communicate, as well as other information (see below). An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages on each transport service address for which it is configured to do so. 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" [@ref tm] on its local network-layer addresses. 3.5. View Subtree and Families 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. For example, the subtree 1.3.6.1.2.1.1, which corresponds to the object system, identifies the objects within the system group of MIB-II [@ref v2mib4v2] as a view subtree. 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. Expires February 1996 [Page 30] Internet Draft Administrative Model for SNMPv2 September 1995 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. When the OBJECT IDENTIFIER prefix identifying a view subtree is longer than the OBJECT IDENTIFIER of an object type defined according to the SMI [@ref v2smi], 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 [@ref adminmib] which have more sub-identifiers than is necessary to identify a particular leaf object type. However, it may choose to do so. 3.6. MIB View A MIB view is a subset of the set of all instances of all object types defined according to the SMI [@ref v2smi] 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 Expires February 1996 [Page 31] Internet Draft Administrative Model for SNMPv2 September 1995 object instance name resolves within a particular SNMPv2 context to 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. 3.7. 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 local 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. For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 agent to access the management information identified by the SNMPv2 context. There is no requirement that an SNMPv2 entity acting in an agent role support any proxy contexts, i.e., support of proxy is not required for conformance with this specification. Expires February 1996 [Page 32] Internet Draft Administrative Model for SNMPv2 September 1995 3.7.1. Local SNMPv2 Context A local context refers to a collection of managed (MIB) objects which logically belong to a single entity within a managed device, even if that device is constructed of multiple physical devices. When an SNMPv2 entity accesses that management information, it does so using locally- defined mechanisms. A managed device may have multiple collections of managed objects belonging to multiple logical entities within the managed device, each local context has associated with it a "local entity" name. Further, because management information changes over time, each local context also has associated with it an associated temporal domain, termed its "local time". This allows, for example, one context to refer to the current values of a 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. 3.7.2. Proxy SNMPv2 Context A proxy relationship exists when a proxy SNMPv2 agent processes a received SNMPv2 message (a request or a response) by forwarding it to another entity according to the value of the context in the received message. Such a context is called a proxy SNMPv2 context. When an SNMPv2 entity processes management requests/responses for a proxy context, it is operating as a proxy SNMPv2 agent. Expires February 1996 [Page 33] Internet Draft Administrative Model for SNMPv2 September 1995 3.8. SNMPv2 PDUs and Operations An SNMPv2 PDU is defined in [@ref protoops]. 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 3.9. SNMPv2 Message A SNMPv2 message contains a single SNMPv2 PDU, is transmitted on behalf of an identity, and contains management information for an identified SNMPv2 context. In particular, an SNMPv2 message may be o a query (e.g., GetRequest, GetNextRequest, or GetBulkRequest), o an indicative assertion (e.g., Response, InformRequest, or SNMPv2- Trap), o an imperative assertion (e.g., SetRequest), o a confirmation message to indicate information was received (e.g., a Response confirming an InformRequest), or o an error report (e.g., Report). An SNMPv2 message is constructed by creating an ASN.1 SEQUENCE, constructed from several sub components, some of which are also SEQUENCEs: o The first portion is the version number, where version ::= INTEGER { version-2(2) } Expires February 1996 [Page 34] Internet Draft Administrative Model for SNMPv2 September 1995 o The second portion is the mms, where mms ::= INTEGER (484..2147483647) o The third portion is the security protocol identifier, where securityFlags ::= INTEGER (1..2147483647) o The fourth portion is a sequence. This sequence consists of an sPI-dependent authInfo portion. o The fifth portion contains a contextSnmpID, a contextName, and PDU. | Depending upon the value of sPI, portions of some or all of these | may be either plaintext or protected from disclosure (encrypted). | where the syntax and semantics of the contents of the authInfo portion is designated by the value of sPI, and the PDU portion is an SNMPv2 PDU as defined in [@ref protoops]. More formally, the complete definition of an SNMPv2 message is: SnmpV2Admin DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS PDUS FROM SNMPv2-PDU SnmpV2Message ::= SEQUENCE { version -- version-2 for this RFC INTEGER { version-2(2) }, mms INTEGER (484..2147483647), securityFlags INTEGER (1..2147483647), authMessage ANY DEFINED BY securityFlags | } -- Where the value contained within an authMessage is defined by the | -- authentication and privacy service as selected by securityFlags. | -- The auth/priv service MUST define an authMessage such that the | -- decoded and unencrypted authMessage contains the following elements.| -- The auth/priv service is free to define the ASN.1 for the authMessage,| Expires February 1996 [Page 35] Internet Draft Administrative Model for SNMPv2 September 1995 -- although it is suggested that the members be specified in the | -- following order: | -- | -- authInfo ( AuthInfo ) | -- contextSnmpID ( OCTET STRING (SIZE(12)) ) | -- contextName ( OCTET STRING ) | -- pdu ( PDUs ) | -- | -- AuthInfo is defined by the authentication and privacy service. | END 3.10. 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 an identity. In particular, an SNMPv2 access policy specifies the accessible MIB views within various SNMPv2 contexts. The application of SNMPv2 access control policy is performed: on receipt of GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations. A set of MIB definitions allows for the configuration of some SNMPv2- Trap and InformRequest operations which are also based upon MIB views within various SNMPv2 contexts, but this is independent of the access control policy expressed in the acTable [@ref adminmib]. These MIB definitions are not the exclusive mechanisms by which SNMPv2-Trap and InformRequest operations can be configured. Note that application of SNMPv2 access control policy is not performed for messages containing Response nor Report operations. Expires February 1996 [Page 36] Internet Draft Administrative Model for SNMPv2 September 1995 4. 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. The procedure and data flow are depicted in the following diagrams which are provided for expository purposes and are not meant to dictate any particular implementation strategy. A portion of an implementation of the model processes received messages, steers them to an appropriate authentication and privacy service, and, if they are deemed authentic, continues processing them until they are delivered to an SNMPv2 application for further disposition. Another portion of an implementation of the model generates messages from parameters provided by the application and found in the LCD, preparing them for transmission over the network, including applying an appropriate authentication and privacy service. 4.1. Generating a Message This section describes the procedure followed by an SNMPv2 entity whenever an SNMPv2 message is to be transmitted by an SNMPv2 application on behalf of an SNMPv2 identity. 4.1.1. Data Flow The following diagram illustrates the data flow when a message is generated (See Figure 5). It should be noted that, especially in the case of management station applications, the "applications" referenced in the procedures which follow may be isolated from the actual management station application by additional implementation-specific layers which add additional value. Expires February 1996 [Page 37] Internet Draft Administrative Model for SNMPv2 September 1995 c o i c n d o t e a n e n u t x t t e t i h x S t S t n y n T N m N m I a p P a p s m n m I D m I P m f e D U e D I s o | | | | | | | | V v V | | | | | +------------------------------+ | | | | | | Scoped PDU Builder |<--| | | | | +------------------------------+ | | | | | | | | | | | | | reportable | Scoped PDU | | | | | | Flag V V V | | | | +------------------------------------+ | | | | | Authentication And Privacy Service |<--| | | | | +------------------------------------+ | | | | | | | | | |SnmpV2AuthMessage | | | V V V V | +-----------------------------------------------------+ | | Final Serializer | | +-----------------------------------------------------+ | | | Non-V2 | | operations ----| | SnmpV2Message | (e.g. v1,v2C) V V V | +--------------------------------------------------------------+ | Transport Stack(s) | +--------------------------------------------------------------+ | | Packet V ---------------------------------------------------------------- N E T W O R K Figure 5: Data Flow for Generating a Message Expires February 1996 [Page 38] Internet Draft Administrative Model for SNMPv2 September 1995 The sending application provides several parameters, including the relevant values for: the destination transport domain and address; its maximum message size of received messages; the required sPI; the identityName and authSnmpID; a globally unique identification of a context, including its contextSnmpID and contextName; and a PDU indicating the desired operations and objects. 4.1.2. Procedure The procedure is as follows. (1) The contextName, contextSnmpID, and PDU are assembled into a ScopedPDU value. (2) The PDU value is examined to determine the SNMPv2 operation type. If the SNMPv2 operation type indicates a GetRequest, GetNextRequest, GetBulkRequest, SetRequest, or InformRequest operation, then the reportableFlag is set to be true; and it is set to false for all other operation types, i.e., Response, SNMPv2- Trap, or Report operations. (3) The required sPI, authSnmpID, identityName, and ScopedPDU are passed to the authentication and privacy service designated by the sPI. (4) The selected authentication and privacy service follows its procedures using the provided parameters and those in the LCD to construct an appropriate authInfo portion which is prepended to the ScopedPDU, possibly encrypting all or part of the ScopedPDU and authInfo portion in accordance with the syntax and semantics defined in the specification associated with the value of sPI provided by the application; thereby producing an SnmpV2AuthMessage value. If there is an error or exception encountered in the authentication and privacy service, then the message cannot be sent and the requesting application is suitably advised. (5) The transport information provided by the management application is examined to determine the transport stack to be used to reach the destination and the value of mms is reduced (never increased) to the smallest of those for the application, SNMPv2 protocol engine, and the transport stack. The serialization of the mms parameter is deferred as long as possible so that this minimum can be determined with a late binding. Expires February 1996 [Page 39] Internet Draft Administrative Model for SNMPv2 September 1995 (6) The provided value for sPI and the value of reportableFlag determined from the SNMPv2 operation type are combined to form a seurityFlags value. (7) The resultant values of mms, securityFlags, and the SnmpV2AuthMessage are serialized (i.e., encoded) according to the conventions of [@ref tm], thereby producing an SnmpV2Message value. (8) The serialized SNMPv2 message is transmitted using the transport address and transport domain provided by the management application. Note that the above procedure does not include any application of any SNMPv2 access control policy (see Section 3.11). 4.2. Processing a Received Communication This section describes the procedure followed by an SNMPv2 entity whenever a SNMPv2 message is received. 4.2.1. Data Flow The following diagram illustrates the data flow when processing a received communication (See Figure 6). Expires February 1996 [Page 40] Internet Draft Administrative Model for SNMPv2 September 1995 r c e i o p d n c o | a e t o r | u n g e n t | t t r x t a | h i o t e b | S t u S x l | n y p n t e T | m N N m N F I | p a a p a P s l m n | I m m I m D P a m f | D e e D e U I g s o | ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | | | | | | | | | | +-----------------------------+ | | | | | | | | Context Processing |<--|--+ | | | | | +-----------------------------+ | | | | | | | ^ | | | | | | | | ScopedPDU | | | | | | | | | | | | +------------------------------------------+ | | | | | Authentication and Privacy Services |<-|--+ | | | |<-+ | | | +------------------------------------------+ | | | | Non-V2 ^ | | | | operations <----| | SnmpV2AuthMessage sPI | | | | (e.g. v1,v2C) | | | | | | | +-----------------------------------------------------+ | | Initial parsing and version determination | | +-----------------------------------------------------+ | ^ | | SnmpV2Message | | | ---------------------------------------------------------------- Transport Stack(s) Figure 6: Data Flow for Received Message Processing Expires February 1996 [Page 41] Internet Draft Administrative Model for SNMPv2 September 1995 4.2.2. Procedure The steps of the procedure are as follows. (1) The snmpInPkts counter [@ref v2mib4v2] is incremented and an | initial | parse of the packet is performed. If the received message is not the serialization (according to the conventions of [@ref tm]) of an SnmpV2Message value, then that message is passed to another appropriate SNMP application running on the node, e.g., an SNMPv1 [@ref 1157] or SNMPv2C [@ref v2Cadmin] entity, if any, for further | processing. Otherwise: | - If the first octet of the packet has the value hexadecimal 30, then | the snmpInBadVersions counter [@ref v2mib4v2] is incremented, and | the message is discarded without further processing. | - If the first octet of the packet is not the value hexadecimal 30, | then the snmpInASNParseErrs counter [@ref v2mib4v2] is incremented, | a report PDU is generated, and the message is discarded without | further processing. | (2) The value of mms is extracted and saved. (3) The values of sPI and reportableFlag are extracted and saved. If the sPI value is not implemented by this entity, then the value of | v2AdminStatsUnknownSPI counter [@ref v2mib4v2] is incremented, | a report PDU is generated, and the received message is discarded without further processing. (4) The SnmpV2AuthMessage value is forwarded to the authentication and privacy service designated by the sPI. Processing within the designated authentication and privacy service may result in one or more error conditions, in which case a report PDU may be generated by the authentication and privacy service, and the received message is discarded without further processing. However, if the snmpV2EnableAuthenTraps object [@ref v2mib4v2] is enabled, then the SNMPv2 entity sends authorizationFailure traps [@ref v2mib4v2] according to its configuration. If the message is deemed authentic, the selected authentication and privacy service translates the SnmpV2AuthMessage value into an identityName, authSnmpID, groupName, and a plaintext (i.e., unencrypted) version of the serialized ScopedPDU. Expires February 1996 [Page 42] Internet Draft Administrative Model for SNMPv2 September 1995 (5) The LCD is consulted for information about the identity as named by the combination of the authSnmpID and identityName values. If information about the SNMPv2 identity is absent from the LCD, then the snmpStatsUnknownIdentities counter [@ref v2mib4v2] is incremented, a report PDU is generated, and the received message is discarded without further processing. (6) The portion of the ScopedPDU containing context information is processed to extract the values for contextSnmpID and a contextName. If the serialized ScopedPDU value is not the serialization (according to the conventions of [@ref tm]) of a ScopedPDU value, then the received message is discarded without further processing, after the snmpInASNParseErrs counter [@ref | v2mib4v2] is incremented | and a report PDU is generated. (7) The PDU portion of the ScopedPDU is processed. If the serialized PDU value is not the serialization (according to the conventions of [@ref tm]) of a PDU value, then the received message is discarded without further processing, after the snmpInASNParseErrs counter | [@ref v2mib4v2] is incremented | and a report PDU is generated. (8) If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or Set operation, then: a) If the receiving entity performs proxy forwarding operations and the context is such that it indicates a possible proxy operation, then the processing continues as described in Section 4.3, Proxy Forwarding Operations. b) If the identified context is such that it indicates a non- local operation, then the v2AdminStatsUnknownContexts counter | [@ref v2mib4v2] is incremented, | a report PDU is generated, and the received message is discarded without further processing. c) Otherwise, if the identified context indicates a configured local operation but the identified context is presently unavailable, perhaps because of the removal of a component from a hot-swappable chassis, then the received message is discarded without further processing, after the | v2AdminStatsUnavailableContexts counter | [@ref v2mib4v2] is incremented and a report PDU is generated. Expires February 1996 [Page 43] Internet Draft Administrative Model for SNMPv2 September 1995 d) The LCD is consulted for access rights authorized for communications on behalf of the identity concerning management information in the indicated SNMPv2 context for the particular SNMPv2 operation type. e) If the SNMPv2 operation type is not among the authorized access rights, then the received message is discarded without further processing after generation and transmission of a response message. This response message is sent on behalf of the same identity. Its contextName, contextSnmpID, var-bind- list, and request-id values are identical to those of the received request. Its error-index portion is zero and its error-status portion is authorizationError [@ref protoops]. f) The information concerning the identityName, authSnmpID, contextSnmpID, contextName, and sending transport domain and address are cached for later use in generating a response message. g) The management operation represented by the SNMPv2 operation type is performed by the SNMPv2 entity with respect to the relevant MIB view within the SNMPv2 context according to the procedures set forth in [@ref protoops], where the relevant MIB view is determined by the groupName, authSnmpID, sPI, contextSnmpID, contextName, and type of operation requested; where the relevant MIB view is: SNMPv2 operation type MIB View given by --------------------- ----------------- read(get/getNext/getBulk) acReadViewName write(set) acWriteViewName (9) If the SNMPv2 operation type is a Response operation (to a Get, GetNext, GetBulk, Set, or Inform), then: a) The request-id is extracted from the PDUs portion of the ScopedPDU received from the authentication and privacy service. The value of request-id is used to locate a corresponding entry in the cache of outstanding requests (both those generated locally and those which were the result of proxy forwarding operations, if any). The values of authSnmpID, identityName, and sPI received from the authentication and privacy service are compared with the cached values for the forwarded request. The values of Expires February 1996 [Page 44] Internet Draft Administrative Model for SNMPv2 September 1995 contextSnmpID and contextName found in the ScopedPDU are compared with the cached values for the forwarded request. If any of these values do not match, then the | v2AdminStatsCacheMisses counter [@ref v2mib4v2] is | incremented, the received message is discarded | without further processing, and the cached entry is deleted. b) If the located cached entry indicates this message is a response to a proxy forwarding operation, then processing continues as described in Section 4.3, Proxy Forwarding Operations, and if the located cached entry indicates this message is a response to a locally generated request, then processing continues as described by [@ref protoops]. (10) If the SNMPv2 operation type is a Trap notification operation, then a) If the receiving entity performs proxy forwarding operations and the context is such that it indicates a possible proxy operation, then the processing continues as described in Section 4.3, Proxy Forwarding Operations. b) Otherwise, processing of the message continues as described by [@ref protoops]. (11) If the SNMPv2 operation type is an Inform notification operation, then a) If the receiving entity performs proxy forwarding operations and the context is such that it indicates a possible proxy operation, then the processing continues as described in Section 4.3, Proxy Forwarding Operations. b) Otherwise, the receiving entity acknowledges receipt by sending a response as described in Section 4.4, Generating A Response, and [@ref protoops]. c) Processing of the message continues as described at [@ref protoops]. (12) If the SNMPv2 operation type is a Report operation, then a) The request-id is extracted from the PDUs portion of the ScopedPDU received from the authentication and privacy service. The value of request-id is used to locate a corresponding entry in the cache of outstanding requests (both Expires February 1996 [Page 45] Internet Draft Administrative Model for SNMPv2 September 1995 those generated locally and those which were the result proxy forwarding operations, if any). (If no such entry is found, but the received request-id is 2147483647, then all entries are searched to attempt to locate an appropriate entry such that the values of authSnmpID, identityName, sPI, contextSnmpID, and contextName match.) The values of authSnmpID, identityName, and sPI received from the authentication and privacy service are compared with the cached values for the forwarded request. The values of contextSnmpID and contextName found in the ScopedPDU are compared with the cached values for the forwarded request. If any of these values do not match, (or no suitable matching entry can be located in the special case when the request-id is 2147483647) then the v2AdminStatsCacheMisses counter [@ref | v2mib4v2] is incremented, | the received message is discarded without further processing, | and the cached entry (if one was found) is deleted. | b) If the located cached entry indicates this message is a response to a proxy forwarding operation, then processing continues as described in Section 4.3, Proxy Forwarding Operations, and if the located cached entry indicates this message is a response to a locally generated request, then processing continues as described at [@ref protoops]. 4.2.3. Common Constructs 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 a snmpV2AuthMessage portion is not a correct serialization of a SnmpV2AuthMessage value). The | snmpInASNParseErrs | counter [@ref v2mib4v2] 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 the reportableFlag is set, | which ensures that a reportPDU 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. Meeting this constraint normally requires | Expires February 1996 [Page 46] Internet Draft Administrative Model for SNMPv2 September 1995 the message to be further processed just enough so as to extract | its request-id. Even in the case where the identity cannot be | authenticated, an attempt must be made to extract the request-id by | assuming that no encryption is in use by the identity. With this | assumption, the only situation in which the request-id cannot be | extracted is when an ASN.1 parsing error occurs. | For a possible procedure to invoke on receipt of a message with an SNMPv2 operation type of SNMPv1 trap, see [@ref coex]. 4.3. Proxy Forwarding Operations These procedures are implemented if and only if the entity also supports proxy forwarding operations. The procedures are as follows. (1) If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or Set operation, then: a) The LCD information is inspected to locate the entry in the proxyForwardingTable such that proxyDirection equals gnsb(1) for which there is a favorable comparison between the values of proxySPIIn, | proxyAuthSnmpIDIn, proxyIdentityNameIn, proxyContextSnmpIDIn, and proxyContextName with the corresponding values received in the ScopedPDU or determined from the authentication and privacy service. The values of proxySPIOut, proxyAuthSnmpIDOut, proxyIdentityNameOut, proxyTransportLabelOut, and proxyPrivs are extracted from the located entry. If there is no such entry, the snmpProxyDrops | [@ref v2mib4v2] is | incremented, a report PDU is generated and sent to the source of the original request, and the received message is discarded without further processing. b) The value of the proxyPrivs is compared with the SNMPv2 operation type. If the requested operation is not among the permitted operations, the snmpProxyDrops [@ref v2mib4v2] is | incremented, a report PDU is generated and sent to the source of the original request, and the received message is discarded without further processing. c) A new ScopedPDU is constructed. Expires February 1996 [Page 47] Internet Draft Administrative Model for SNMPv2 September 1995 Its PDUs portion is the same as the PDUs portion of the ScopedPDU request received from the authentication and privacy service 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). However, the new unique value should not equal 2147483647; this value is reserved. Its contextSnmpID and contextName are the same as the corresponding values in the ScopedPDU received from the authentication and privacy service. d) The appropriate authentication and privacy service, as selected by the extracted value of proxySPIOut is used to prepare an appropriate SnmpV2AuthMessage, using the extracted values of proxyAuthSnmpIDOut and proxyIdentityNameOut. If the value of proxySPIOut equals "1", which indicates that the next hop utilizes SNMPv1, then [@ref coex] defines an appropriate set of transformations to be applied. If a suitable SnmpV2AuthMessage cannot be constructed, the snmpProxyDrops | [@ref v2mib4v2] is | incremented, a report PDU is generated and sent to the source of the original request, and the received message is discarded without further processing. e) Several values associated with the original request are cached for later use in generating a response message. These values include: the request-id of the original request and the request-id of the newly generated request, the sPI used to forward the message, transport domain and address of the source of the original request, the contextSnmpID and contextName found in the ScopedPDU of the original request, proxyAuthSnmpIDIn, identityNameIn, and sPI values received from the authentication and privacy service when processing the original request. f) The extracted value of proxyTransportLabelOut is used to determine the transportDomain, transportAddress, and transportMMS for each destination. For each destination, the value of mms associated with the request is reduced, to the smallest of the mms of the protocol engine of the proxy agent and the mms of the transport to be used to forward the request, if either is smaller than the received value for mms. Expires February 1996 [Page 48] Internet Draft Administrative Model for SNMPv2 September 1995 g) For each destination, the values for mms, sPI, and the SnmpV2AuthMessage are converted into a SnmpV2Message which is then sent via the transport layer. If the message cannot be constructed or is determined to be unforwardable, the | snmpProxyDrops [@ref v2mib4v2] is | incremented, a report PDU is generated and sent to the source of the original request, the received message is discarded without further processing, and the cached entry is deleted. (2) If the SNMPv2 operation type is a Response operation (to a Get, GetNext, GetBulk, Set, or Inform operation), then: a) The request-id is extracted from the PDUs portion of the ScopedPDU received from the authentication and privacy service. The value of request-id is used to locate a corresponding entry in the cache of outstanding requests. The values of authSnmpID, identityName, and sPI received from the authentication and privacy service are compared with the cached values for the forwarded request. The values of contextSnmpID and contextName found in the ScopedPDU are compared with the cached values for the forwarded request. If any of these values do not match, then the snmpProxyDrops | [@ref v2mib4v2] is | incremented, a report PDU is generated and sent to the source of the original request, the received message is discarded without further processing, and the cached entry is deleted. b) A new ScopedPDU is constructed. Its PDUs portion is the same as the PDUs portion of the ScopedPDU response received from the authentication and privacy service except that the contained request-id is replaced by the cached value of the original request. Its contextSnmpID and contextName are the same as the corresponding values in the ScopedPDU received from the authentication and privacy service. c) The appropriate authentication and privacy service, as selected by the cached value of sPI for the original request is used to prepare an appropriate SnmpV2AuthMessage, using the cached values authSnmpID and identityName derived from the original request message. If the received value of sPI indicates a SNMPv1message, then [@ref coex] defines a suitable Expires February 1996 [Page 49] Internet Draft Administrative Model for SNMPv2 September 1995 set of transformations. If a suitable SnmpV2AuthMessage cannot be constructed, the snmpProxyDrops [@ref v2mib4v2] is | incremented, a report PDU is generated and sent to the source of the original request, the received message is discarded without further processing, and the cached entry is deleted. d) The value of mms associated with the response is reduced, to the smallest of the mms of the protocol engine of the proxy agent and the mms of the transport to be used to forward the request, if either are smaller than the received value for mms. This step is unnecessary for the purpose of processing the response message currently in transit. However, this step is useful as means to learn the effective path-mms for the purpose of optimizing subsequent request-message size. e) The values for mms, sPI, and the SnmpV2AuthMessage are converted into a SnmpV2Message and sent to the transport layer. The message is prepared and sent using the cached values of the original request sender's transport domain and address. If the message cannot be constructed or is determined to be unforwardable, the snmpProxyDrops [@ref | v2mib4v2] is | incremented, a report PDU is generated and sent to the source of the original request, the received response message is discarded without further processing, and the cached entry is deleted. (3) If the SNMPv2 operation type is either SNMPv2-Trap or Inform, then the steps are identical to those given above for Get, GetNext, GetBulk, or Set request operations, except: a) In step (1), the LCD entries which are consulted to locate the entry in the proxyForwardingTable are those such that proxyDirection equals trap(2) or inform(3), respecitively, instead of gnsb(1). b) If the operation type is SNMPv2-Trap, a report PDU is never generated, the request-id need not be remapped, and no values are cached. (4) If the SNMPv2 operation type is Report, then the request-id is extracted from the PDUs portion of the ScopedPDU received from the Expires February 1996 [Page 50] Internet Draft Administrative Model for SNMPv2 September 1995 authentication and privacy service. The value of request-id is used to locate a corresponding entry in the cache of outstanding requests. If the correlation is successful, the appropriate maintenance function (e.g., time synchronization, proxy error propagation, etc.) is invoked and the cached entry is deleted. | Otherwise, the v2AdminStatsCacheMisses counter [@ref v2mib4v2] is | incremented, and the received message is discarded without further processing. If the result of such maintenance procedures determines that a proxy-forwarded request cannot be delivered to the proxied agent, | then the snmpProxyDrops counter [14] 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 snmpProxyDrops as a varbind, | is included among the reasons why a proxy-forwarded request cannot be delivered.) 4.4. Generating a Response The procedure for generating a response to a SNMPv2 management request is identical to the procedure for generating a message (see Section 4.1), with these exceptions: (1) The response is sent on behalf of the same values for sPI, identityName, authSnmpID, contextSnmpID, and contextName as were communicated by the original request. (2) The PDUs value of the responding SnmpV2Message value is the response which results from performing the operation specified in the original PDUs value. The other relevant information is obtained, not from the LCD, but rather from information cached (in Step e) when processing the original message. (3) The serialized Message value is transmitted using the transport address and transport domain from which its corresponding request originated - even if that is different from any transport information obtained from the LCD. 4.5. Report Generation Processing While processing a received communication, the procedures may result in a determination that the received message is unacceptable, that an appropriate counter in the snmp object group of [@ref v2mib4v2] or the | v2AdminStats object group of [adminmib] be incremented, | Expires February 1996 [Page 51] Internet Draft Administrative Model for SNMPv2 September 1995 and that a message containing an error report should be generated. All messages containing an error report sent as a result of the procedures defined in this memo shall have an sPI value of maint(3). If possible, the request-id shall have the same value as the request-id field of the PDU in the message whose processing caused the error report. Otherwise, the value 2147483647 is used. The error-status and error-index fields of a report PDU are always set to zero. The variable-bindings field contains a single variable: the identity of the statistics counter which was incremented and its new value. A report PDU is never sent in response to a report PDU. A protocol entity makes this determination by examining the reportableFlag of the received message and only sending report PDUs when the reportableFlag is set. Several additional parameters must be provided to the protocol engine to send the reports. The identityName is "report". The authSnmpID and contextSnmpID are set to the value of snmpID for the local (generating) SNMPv2 entity. The contextName is set to "default". The values of contextSnmpID, contextName, and the report PDU are serialized to produce a ScopedPDU value. The values of identityName, and authSnmpID are used to build an AuthInfo structure defined as follows. (The similarity to the structure used by the usecNoAuth(4) authentication and privacy service [@ref sec] is intentional to allow shared code paths in typical implementations). AuthInfo ::= [9] IMPLICIT SEQUENCE { authSnmpID OCTET STRING (SIZE(12)), identityName OCTET STRING SIZE(6)), -- equal to "report" Expires February 1996 [Page 52] Internet Draft Administrative Model for SNMPv2 September 1995 pad1 Integer32 (0), pad2 Integer32 (0) pad3 OCTET STRING (SIZE(0)) } The AuthInfo and ScopedPDU values are serialized to form a SnmpV2AuthMessage value. A securityFlags object is built from an sPI value of maint(3) and a reportableFlag value of false. The local value of maximum message size for the transport used by the original message is determined. An SnmpV2Message is constructed from the maximum message size, securityFlags, and SnmpV2AuthMessage values. The resulting message is forwarded to the source of the original received message. Expires February 1996 [Page 53] Internet Draft Administrative Model for SNMPv2 September 1995 5. 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 LCD. Accordingly, every attempt has been made to minimize the amount of non-volatile storage required. 6. Acknowledgements To be provided here. 7. References To be provided here. Expires February 1996 [Page 54] Internet Draft Administrative Model for SNMPv2 September 1995 8. Authors' Addresses Tell U. Later snmpv2@tis.com Expires February 1996 [Page 55] Internet Draft Administrative Model for SNMPv2 September 1995 Table of Contents 1 Introduction .................................................... 4 1.1 A Note on Terminology ......................................... 4 2 Overview ........................................................ 5 2.1 Management Information ........................................ 6 2.2 Contexts ...................................................... 6 2.3 MIB Views ..................................................... 7 2.4 Access Rights ................................................. 8 2.5 Authentication and Privacy .................................... 8 2.6 Security Mechanisms and Algorithms ............................ 9 2.7 Security Protocol Identifiers and the Reportable Flag ......... 9 2.8 Identities and Group Names .................................... 11 2.9 Authorization: Access Control ................................. 12 2.10 Construction of an SNMPv2 Message ............................ 13 2.11 Authentication and Privacy Service ........................... 14 2.12 An SNMPv2 Entity's Local Configuration Datastore ............. 15 2.13 Maintenance Functions ........................................ 16 2.14 Proxy ........................................................ 16 2.15 Transparency Principle ....................................... 18 3 Elements of the Model ........................................... 20 3.1 SNMPv2 Applications ........................................... 20 3.1.1 SNMPv2 Agent ................................................ 20 3.1.2 SNMPv2 Manager .............................................. 20 3.1.3 SNMPv2 Dual-Role Entity ..................................... 20 3.1.4 SNMPv2 Application Layering within the Administrative Framework .................................................... 22 3.1.5 SNMPv2 Agent Role Applications .............................. 23 3.1.5.1 Local Agent Operations .................................... 24 3.1.5.2 Proxy Forwarding Operations ............................... 24 3.1.5.3 Trap Generation Operations ................................ 24 3.1.5.4 Report Generation Operations .............................. 24 3.1.6 SNMPv2 Manager Role Applications ............................ 25 3.1.6.1 Local Manager Operations .................................. 25 3.1.6.2 Received Notification Operations .......................... 25 3.1.6.3 Notification Generation by Managers ....................... 25 3.1.6.4 Received Report Operations ................................ 25 3.1.6.5 Report Generation by Managers ............................. 25 3.2 SNMPv2 snmpID ................................................. 26 3.3 SNMPv2 Identities ............................................. 28 3.4 SNMPv2 Entity ................................................. 30 3.5 View Subtree and Families ..................................... 30 3.6 MIB View ...................................................... 31 3.7 SNMPv2 Context ................................................ 32 Expires February 1996 [Page 56] Internet Draft Administrative Model for SNMPv2 September 1995 3.7.1 Local SNMPv2 Context ........................................ 33 3.7.2 Proxy SNMPv2 Context ........................................ 33 3.8 SNMPv2 PDUs and Operations .................................... 34 3.9 SNMPv2 Message ................................................ 34 3.10 SNMPv2 Access Control Policy ................................. 36 4 Elements of Procedure ........................................... 37 4.1 Generating a Message .......................................... 37 4.1.1 Data Flow ................................................... 37 4.1.2 Procedure ................................................... 39 4.2 Processing a Received Communication ........................... 40 4.2.1 Data Flow ................................................... 40 4.2.2 Procedure ................................................... 42 4.2.3 Common Constructs ........................................... 46 4.3 Proxy Forwarding Operations ................................... 47 4.4 Generating a Response ......................................... 51 4.5 Report Generation Processing .................................. 51 5 Security Considerations ......................................... 54 6 Acknowledgements ................................................ 54 7 References ...................................................... 54 8 Authors' Addresses .............................................. 55 Expires February 1996 [Page 57]