idnits 2.17.1 draft-ietf-snmpv2-adminv2-ds-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 702 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 932: '...ch SNMPv2 entity MUST provide an inter...' RFC 2119 keyword, line 965: '...internalContext MUST NOT be accessible...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1621 has weird spacing: '...ncluded int...' == Line 1649 has weird spacing: '...ncluded int...' == Line 1650 has weird spacing: '...xcluded snm...' == Line 1651 has weird spacing: '...ncluded sys...' == Line 1652 has weird spacing: '...ncluded snm...' == (6 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1995) is 10633 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft SNMPv2 Administrative Infrastructure March 1995 4 Administrative Infrastructure for Version 2 of the | 5 Simple Network Management Protocol (SNMPv2) 7 19 March 1995 | 9 draft-ietf-snmpv2-adminv2-ds-01.txt | 11 Jeffrey D. Case | 12 SNMP Research, Inc. | 13 case@snmp.com | 15 James Galvin | 16 Trusted Information Systems 17 galvin@tis.com 19 Keith McCloghrie | 20 Cisco Systems, Inc. 21 kzm@cisco.com 23 Marshall T. Rose + 24 Dover Beach Consulting, Inc. + 25 mrose@dbc.mtview.ca.us + 27 Steven Waldbusser + 28 Carnegie Mellon University + 29 waldbusser@cmu.edu + 31 Status of this Memo 33 This document is an Internet-Draft. Internet-Drafts are working 34 documents of the Internet Engineering Task Force (IETF), its areas, and 35 its working groups. Note that other groups may also distribute working 36 documents as Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet- Drafts as reference material 41 or to cite them other than as ``work in progress.'' 42 To learn the current status of any Internet-Draft, please check the 43 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 44 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 45 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 47 1. Introduction 49 A management system contains: several (potentially many) nodes, each 50 with a processing entity, termed an agent, which has access to 51 management instrumentation; at least one management station; and, a 52 management protocol, used to convey management information between the 53 agents and management stations. Operations of the protocol are carried 54 out under an administrative framework which defines authentication, 55 authorization, access control, and privacy policies. 57 Management stations execute management applications which monitor and 58 control managed elements. Managed elements are devices such as hosts, 59 routers, terminal servers, etc., which are monitored and controlled via 60 access to their management information. 62 It is the purpose of this document, the Administrative Infrastructure | 63 for SNMPv2, | 64 to define how the administrative framework is applied to realize | 65 effective management in a variety of configurations and | 66 environments. 68 The model described here entails the use of distinct identities for 69 peers that exchange SNMPv2 messages. Thus, it represents a departure 70 from the community-based administrative model of the original SNMP [1]. 71 By unambiguously identifying the source and intended recipient of each 72 SNMPv2 message, this new strategy improves upon the historical community 73 scheme both by supporting a more convenient access control model and 74 allowing for effective use of asymmetric (public key) security protocols 75 in the future. 77 1.1. A Note on Terminology 79 For the purpose of exposition, the original Internet-standard Network 80 Management Framework, as described in RFCs 1155, 1157, and 1212, is 81 termed the SNMP version 1 framework (SNMPv1). The current framework is 82 termed the SNMP version 2 framework (SNMPv2). 84 1.2. Change Log 86 For the 19 March version: + 88 - The many changes adopted by the SNMPv2 Working Group. + 89 For the 1 November version: 91 - recast RFC 1445 into an Internet-Draft, 93 - added Overview section, 95 - rewrote Elements of the Model section, 97 - fixed typos in the Elements of Procedure section, 99 - rewrote parts of the Application of the Model section, and retitled 100 it as Usage Examples. 102 - tighted the definition of a proxy SNMPv2 agent, in order to remove 103 confusion, and thereby deleted discussion of foreign proxies. 105 - changed "local party database" to "local party datastore", and 106 introduced LPD as an acronym for it. 108 2. Overview 110 A management domain typically contains a large amount of management 111 information. Each individual item of management information is an 112 instance of a managed object type. The definition of a related set of 113 managed object types is contained in a Management Information Base (MIB) 114 module. Many such MIB modules are defined. For each managed object 115 type it describes, a MIB module defines not only the semantics and 116 syntax of that managed object type, but also the method of identifying 117 an individual instance so that multiple instances of the same managed 118 object type can be distinguished. 120 2.1. Contexts 122 Typically, there are many instances of each managed object type within a 123 management domain. For simplicity, the method for identifying instances 124 specified by the MIB module does not allow each instance to be 125 distinguished amongst the set of all instances within the management 126 domain; rather, it allows each instance to be identified only within 127 some scope or "context", where there are multiple such contexts within 128 the management domain. Often, a context is a physical device, or 129 perhaps, a logical device, although a context can also encompass 130 multiple devices, or a subset of a single device, or even a subset of 131 multiple devices. Thus, in order to identify an individual item of 132 management information within the management domain, its context must be 133 identified in addition to its object type and its instance. Note that 134 this requires each context to have a globally-unique identification 135 within the management domain. Note also that the same item of 136 management information can exist in multiple contexts. 138 For example, the managed object type, ifDescr [7], is defined as the 139 description of a network interface. To identify the description of 140 device-X's first network interface, three pieces of information are 141 needed: device-X (the context), ifDescr (the managed object type), and 142 "1" (the instance). 144 Management information often changes over time. Thus, when naming a 145 specific value of a managed object instance, an indication of time is 146 needed. In most situations, it is the value at the current time which 147 is of interest to the network manager. There are, however, situations 148 where times other than the current time are of interest. For example, 149 where the value of a device parameter after the device's next reboot is 150 to be different to its current value. To accommodate this, each context 151 has an associated notion of time, called its temporal domain. This 152 allows, for example, one context to refer to the current values of a 153 device's parameters, and a different context to refer to the values that 154 the same parameters for the same device will have after the device's 155 next restart. 157 2.2. Authorization: Access Rights and MIB Views 159 For security reasons, it is often valuable to be able to restrict the 160 access rights of some management applications to only a subset of the 161 management information in the management domain. To provide this | 162 capability, access to a context is via a "MIB view" which details a | 163 specific set of managed object types (and optionally, the specific | 164 instances of object types) within that context. For example, for a | 165 given context, there will typically always be one MIB view which | 166 provides access to all management information in that context, and often | 167 there will be other MIB views each of which contains some subset of the | 168 information. So, by providing access rights to a management application | 169 in terms of the particular (subset) MIB view it can access for that | 170 context, then the management application is restricted in the desired | 171 manner. | 173 Since managed object types (and their instances) are identified via the 174 tree-like naming structure of ISO's OBJECT IDENTIFIERs [8, 3], it is 175 convenient to define a MIB view as the combination of a set of "view 176 subtrees", where each view subtree is a sub-tree within the managed 177 object naming tree. Thus, a simple MIB view (e.g., all managed objects 178 within the Internet Network Management Framework) can be defined as a 179 single view sub-tree, while more complicated MIB views (e.g., all 180 information relevant to a particular network interface) can be 181 represented by the union of multiple view sub-trees. 183 While any set of managed objects can be described by the union of some 184 number of view subtrees, situations can arise that would require a very 185 large number of view subtrees. This could happen, for example, when 186 specifying all columns in one conceptual row of a MIB table because they 187 would appear in separate subtrees, one per column, each with a very 188 similar format. Because the formats are similar, the required set of 189 subtrees can easily be aggregated into one structure. This structure is 190 named a family of view subtrees after the set of subtrees that it 191 conceptually represents. A family of view subtrees can either be 192 included or excluded from a MIB view. 194 In addition to restricting access rights by identifying (sub-)sets of 195 management information, it is also valuable to restrict the operations 196 allowed on the management information within a particular context. For 197 example, one management application might be prohibited from write- 198 access to a particular context, while another might be allowed to 199 perform any type of operation. 201 2.3. Proxy 203 The identification of a context is (architecturally) independent of the 204 location at which its management information can be accessed. Of 205 course, it is an SNMPv2 agent which responds to requests for access to 206 management information. Each such request is contained within an SNMPv2 207 message which provides the capability to perform a single operation on a 208 list of items of management information. Rather than having to identify 209 the context as well as the managed object type and instance for each 210 item of management information, each SNMPv2 message is concerned with 211 only a single context. Thus, an SNMPv2 agent must be able to process 212 requests for all items of management information within the one or more 213 contexts it supports. 215 In responding to a request, an SNMPv2 agent might be acting as a proxy 216 for some other agent. The term "proxy" has historically been used very 217 loosely, with multiple different meanings. These different meanings 218 include (among others): 220 (1) the forwarding of SNMPv2 requests on to other SNMP agents without 221 regard for what managed object types are being accessed; for 222 example, in order to forward SNMPv2 request from one transport 223 domain to another, or to translate SNMPv2 requests into SNMPv1 224 requests; 226 (2) the translation of SNMPv2 requests into operations of some non-SNMP 227 management protocol; 229 (3) support for aggregated managed objects where the value of one 230 managed object instance depends upon the values of multiple other 231 (remote) items of management information. 233 Each of these scenarios can be advantageous; for example, support for 234 aggregation for management information can significantly reduce the 235 bandwidth requirements of large-scale management activities. However, 236 using a single term to cover multiple different scenarios causes 237 confusion. 239 To avoid such confusion, the SNMPv2 administrative framework uses the 240 term "proxy" with a much more tightly defined meaning, which covers only 241 the first of those listed above. Specifically, the distinction between 242 a regular SNMPv2 agent and a "proxy SNMPv2 agent" is simple: 244 - a proxy SNMPv2 agent is an SNMPv2 agent which forwards requests on 245 to other agents according to the context, and irrespective of the 246 specific managed object types being accessed; 248 - in contrast, an SNMPv2 agent which processes SNMPv2 requests 249 according to the (names of the) individual managed object types and 250 instances being accessed, is NOT a proxy SNMPv2 agent from the 251 perspective of this administrative model. 253 Thus, when an SNMPv2 agent acts as a proxy SNMPv2 agent for a particular 254 context, not only is the information on how to forward the request 255 specifically associated with that context, but the proxy SNMPv2 agent 256 has no need of a detailed definition of the MIB view | 257 (since the proxy SNMPv2 agent forwards the request irrespective of the 258 managed object types). 260 In contrast, a non-proxy SNMPv2 agent must have the detailed definition | 261 of the MIB view, and even if it needs to issue | 262 requests to other agents, that need is dependent on the individual 263 managed object instances being accessed (i.e., not only on the context). 265 2.4. Security 267 One aspect of security was discussed above: the ability to assign 268 different access rights to different management applications. The 269 enforcement of these access rights requires the means not only to 270 identify the source of a request but also to authenticate such 271 identification. Another security capability which SNMPv2 (optionally) 272 provides is the ability to protect the data within an SNMPv2 message 273 from disclosure (i.e., to encrypt the data). This is particularly | 274 useful when sensitive data (e.g., passwords, or security keys) are | 275 accessed via SNMPv2 requests. 277 Recommendations for which algorithms are best for authentication and 278 privacy are subject to change. Such changes may occur as and when new 279 research results on the vulnerability of various algorithms are 280 published, and/or with the prevailing status of export control and 281 patent issues. Thus, it is valuable to allow these algorithms to be 282 specified as parameters, so that new algorithms can be accommodated over 283 time. In particular, one type of algorithm which may become useful in 284 the future is the set of algorithms associated with asymmetric (public 285 key) cryptography. 287 Note that not all accesses via SNMPv2 requests need to be secure. 288 Indeed, there are purposes for which insecure access is required. One 289 example of this is the ability of a management application to learn 290 about devices of which it has no previous knowledge. Another example is 291 to perform any synchronization which the security algorithms need before 292 they can be used to communicate securely. This need for insecure access 293 is accommodated by defining one of the algorithms for authentication as 294 providing no authentication, and similarly, one of the algorithms for 295 privacy as providing no protection against disclosure. 297 2.5. Parties 299 To provide these security capabilities, an SNMPv2 message needs to 300 include the identity of its source and destination. Each such identity 301 is specified as an SNMPv2 "party". Different parties have different 302 security parameters, including the authentication and privacy algorithms 303 and the security keys (if any) used. For any SNMPv2 message, the 304 algorithm and parameters by which it is authenticated (or not) are those 305 of its source party. Similarly, for any SNMPv2 message, the algorithm 306 and parameters by which it is protected from disclosure (or not) are 307 those of its destination party. 309 When an SNMPv2 message is generated, the appropriate parties must be 310 chosen so that the message will have the desired level of authentication 311 and privacy. The parties' algorithms and security keys are used to add 312 authentication information to the message, and (if necessary) to encrypt 313 it. When an SNMPv2 message is received, the destination party's privacy 314 algorithm is used to decrypt it (if necessary), and the source party's 315 authentication information is used to authenticate it. 317 Typically, an SNMPv2 party operates at one and only one location, 318 although it is possible under some circumstances for an SNMPv2 party to 319 operate from a different location. In any case, in order to 320 authenticate the source party without having to rely on underlying 321 transport mechanisms to provide authentication of transport addresses, 322 it is necessary for a party to be globally unique, and have a globally 323 unique identifier. 325 2.6. Authorization: Access Control 327 As described above, an SNMPv2 message is associated with one context and 328 two parties, where the context determines the set of management 329 information being accessed by the message, and the parties are the 330 identities of the source and destination. These properties of the 331 message are used for access control. Specifically, access control is 332 specified as a set of local access policies, where each such policy is a 333 valid party/party/context triple against which to compare a received | 334 message. In addition, each such triple specifies the set of operations | 335 and the two MIB views (one for read access, the other for write access) | 336 which are allowed for that triple. Thus, | 337 if the context and the two parties specified by the received message are 338 not a valid triple or the operation requested is not one of the 339 operations allowed by the triple, then the requested access is denied. 341 Note that a local access policy (a party/party/context triple) is also 342 called an ACL (for historical reasons). 344 2.7. Construction of an SNMPv2 Message 346 The purpose of an SNMPv2 message is to contain an SNMPv2 PDU. (The PDU + 347 contains an operation-code, some additional request/response parameters + 348 and a list of names and values of specific managed object instances; for + 349 details, see [2].) To construct an SNMPv2 message, a number of headers + 350 are prepended in front of the PDU (specifically, each "header" is added + 351 as part of a new ASN.1 SEQUENCE). The header which is first prepended + 352 to the PDU contains the context and the source and destination parties. + 353 The second prepended header contains whatever authentication information + 354 needs to be transmitted as part of the message. The third identifies + 355 the destination party which determines if and how the remainder of the + 356 message (the PDU and the first two prepended headers) are encrypted. + 358 2.8. An SNMPv2 Entity's Local Party Datastore 360 An SNMPv2 entity is an SNMPv2 protocol implementation used by an SNMPv2 361 agent and/or by one or more management applications. The local parties 362 at an SNMPv2 entity are those which operate locally, and the local 363 contexts are those for which the SNMPv2 entity acts as a (proxy or non- 364 proxy) SNMPv2 agent in responding to requests. 366 To implement the model described in the preceding sections, each SNMPv2 367 entity needs to retain its own set of information about contexts, 368 parties, ACLs, and (in agents) views. This set of information is called 369 the SNMPv2 entity's Local Party Datastore (LPD) because it is locally- 370 stored information. Note, however, that the LPD contains information on 371 both local and remote parties, local and/or remote contexts, local ACLs, 372 and sometimes on remote ACLs as well. 374 In order to allow an SNMPv2 entity's LPD to be configured, and to allow | 375 the synchronization needed by the security algorithms before they can be | 376 used to communicate securely, the LPD needs to be accessible as managed | 377 objects. A MIB module, the SNMPv2 Party MIB, to define these managed | 378 object types is contained in [4]. | 379 2.9. Maintenance Functions 381 In order to facilitate communication between SNMPv2 entities, certain | 382 "maintenance" functions are defined. A maintenance function is | 383 identified as a management communication which accesses a well-known | 384 maintenance context and makes use of corresponding well-known | 385 maintenance parties. For example, error reporting (Section 4.1) and | 386 clock synchronization and secret update (Sections 5.3 and 5.4 of [6]) | 387 are achieved by performing SNMP operations which access a context known | 388 as "internalContext". | 390 When processing a maintenance function, an SNMPv2 entity utilizes the | 391 same mechanisms defined for normal operations; however, unlike normal | 392 operations which are executed with respect to an administration's | 393 security policy (which may vary between administrations), maintenance | 394 functions always occur within a fixed, standardized security policy. | 395 This is advantageous in that it allows code re-use within an SNMPv2 | 396 entity, while also not allowing an administration's policy to impair the | 397 proper operation of essential maintenance functions. However, many of | 398 the rules applicable to normal parties and contexts specified in this | 399 document do not always apply to these maintenance functions (e.g., | 400 maintenance contexts are not uniquely named). | 402 The sole purpose of maintenance functions is to ensure that all SNMPv2 | 403 entities provide essential maintenance functionality within a well- | 404 known, standardized, security environment. Maintenance functions are | 405 intended for use only by the internal operations of an SNMPv2 entity. | 406 Thus, their scope is intentionally restricted to be the minimum | 407 necessary to fulfill their purpose. | 408 3. Elements of the Model 410 This section provides a more formal description of the model. 412 3.1. SNMPv2 Party 414 An SNMPv2 party is an identity assumed by an SNMPv2 entity in order to 415 restrict its operations (for security or other purposes) to an 416 administratively defined subset of all SNMPv2 possible operations. 417 Whenever an SNMPv2 entity processes an SNMPv2 message, it does so by 418 operating as a SNMPv2 party and is thereby restricted to the set of 419 operations defined for that party. The set of possible operations 420 specified for an SNMPv2 party may be overlapping or disjoint with 421 respect to the sets of other SNMPv2 parties. 423 Each SNMPv2 party has a set of attributes which includes the following: 425 partyIdentity - 426 the value which uniquely identifies the party. 428 partyTDomain - 429 the kind of transport service by which the party receives | 430 management traffic. | 431 An example of a transport domain is snmpUDPDomain (SNMPv2 over UDP, 432 using SNMPv2 parties). 434 partyTAddress - 435 the transport service address at which the party normally receives | 436 management traffic. This address is used in sending requests or | 437 notifications to the party | 438 (but not in responding to requests from the party). Note that 439 there is no requirement that the party transmits management traffic | 440 from this transport address. | 442 partyMaxMessageSize - 443 the length in octets of the largest SNMPv2 message this party is 444 prepared to accept. 446 partyAuthProtocol - 447 the authentication protocol by which all messages generated by the 448 party are authenticated. In particular, the value 'noAuth' 449 signifies that messages generated by the party are not 450 authenticated. 452 partyAuthClock - 453 the party's authentication clock which represents a notion of the 454 current time that is specific to the party. The significance of 455 this component is specific to the authentication protocol. 457 partyAuthPrivate - 458 the party's private authentication key which is any secret value 459 needed to support the authentication protocol. The significance of 460 this component is specific to the authentication protocol. 462 partyAuthPublic - 463 the party's public authentication key which is any publically- 464 disclosable value that may be needed to support the authentication 465 protocol. The significance of this component is specific to the 466 authentication protocol. 468 partyAuthLifetime - 469 the administrative upper bound on acceptable delivery delay for 470 protocol messages generated by the party. The significance of this 471 component is specific to the authentication protocol. 473 partyPrivProtocol - 474 the privacy protocol by which all protocol messages received by the 475 party are protected from disclosure. In particular, the value 476 'noPriv' signifies that messages received by the party are not 477 protected from disclosure. 479 partyPrivPrivate - 480 the party's private privacy key which is any secret value needed to 481 support the privacy protocol. The significance of this component 482 is specific to the privacy protocol. 484 partyPrivPublic - 485 the party's public privacy key which is any publically-disclosable 486 value that may be needed to support the privacy protocol. The 487 significance of this component is specific to the privacy protocol. 489 An SNMPv2 entity, which supports only SNMPv2 parties for which the 490 authentication protocol is noAuth and the privacy protocol is noPriv, is 491 called non-secure. 493 3.2. SNMPv2 Entity 495 An SNMPv2 entity is an actual process which performs | 496 management operations by generating and/or responding to SNMPv2 protocol 497 messages in the manner specified in [2]. An SNMPv2 entity assumes the 498 identity of a particular local SNMPv2 party when processing an SNMPv2 499 message. 501 An SNMPv2 entity is not required to process multiple protocol messages 502 concurrently, regardless of whether such messages require it to assume 503 the identity of the same or different SNMPv2 parties. Thus, 504 implementation of an SNMPv2 entity to support more than one party need 505 not be multi-threaded. However, there may be situations where 506 implementors may choose to use multi-threading. 508 Every SNMPv2 entity maintains a Local Party Datastore (LPD) which 509 includes information on all local SNMPv2 parties, and on those remote 510 SNMPv2 parties which are known locally, as well as other information 511 (see below). 513 An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages on + 514 each transport service address configured for a local SNMPv2 party. It + 515 is a local matter whether an SNMPv2 entity also listens for SNMPv2 + 516 messages on any other transport service addresses. In the absence of + 517 any other information on where to listen, an SNMPv2 entity must listen + 518 on the transport service addresses corresponding to the standard + 519 transport-layer "ports" [5] on its local network-layer addresses. + 521 3.3. SNMPv2 Manager 523 An SNMPv2 manager is the operational role assumed by an SNMPv2 entity 524 when it acts in a manager role on behalf of management applications. 525 Specifically, an SNMPv2 manager initiates SNMPv2 management operations 526 by the generation of appropriate SNMPv2 protocol messages or when it 527 receives and processes trap and inform notifications. 529 3.4. SNMPv2 Agent 531 An SNMPv2 agent is the operational role assumed by an SNMPv2 entity when 532 it acts in an agent role. Specifically, an SNMPv2 agent performs SNMPv2 533 management operations in response to received SNMPv2 protocol messages 534 (except for inform notifications) generated by an SNMPv2 manager. 536 3.5. SNMPv2 Dual-Role Entity 538 An SNMPv2 entity which sometimes acts in an agent role and sometimes + 539 acts in a manager role, is termed an SNMPv2 dual-role entity. An SNMPv2 + 540 dual-role entity receives requests for service through acting in an + 541 agent role and performs requests through acting in a manager role. + 542 There are two categories of SNMPv2 dual-role entities: + 544 (1) proxy SNMPv2 agents. + 546 (2) (so-called) mid-level managers. + 548 Proxy SNMPv2 agents only forward requests; they do not originate + 549 requests. In contrast, mid-level managers often originate requests. + 550 (Note that the term proxy SNMPv2 agent does not include an SNMPv2 agent + 551 which translates SNMPv2 requests into the requests of some other + 552 management protocol; see section 2.3.) + 554 3.6. View Subtree 556 A view subtree is the set of all MIB object instances which have a 557 common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree is 558 identified by the OBJECT IDENTIFIER value which is the longest OBJECT 559 IDENTIFIER prefix common to all (potential) MIB object instances in that 560 subtree. 562 When the OBJECT IDENTIFIER prefix identifying a view subtree is longer 563 than the OBJECT IDENTIFIER of an object type defined according to the 564 SMI [3], then the use of such a view subtree for access control has 565 granularity at the object instance level. Such granularity is 566 considered beyond the scope of an SNMPv2 agent. As such, no 567 implementation of an SNMPv2 agent is required to support values of 568 viewSubtree [4] which have more sub-identifiers than is necessary to 569 identify a particular leaf object type. However, access control 570 information is also used in determining which SNMPv2 entities operating 571 on behalf of management applications should receive trap notifications 572 (Section 4.2.6 of [2]). As such, agent implementors might wish to 573 provide instance-level granularity in order to allow SNMPv2 entity 574 operating on behalf of management applications to use fine-grain 575 configuration of trap notifications. 577 3.7. View Subtree Families 579 A family of view subtrees is a pairing of an OBJECT IDENTIFIER value 580 (called the family name) together with a bitstring value (called the 581 family mask). The family mask indicates which sub-identifiers of the 582 associated family name are significant to the family's definition. 584 For each possible managed object instance, that instance belongs to a 585 particular view subtree family if both of the following conditions are 586 true: 588 o the OBJECT IDENTIFIER name of the managed object instance contains 589 at least as many sub-identifiers as does the family name, and 591 o each sub-identifier in the the OBJECT IDENTIFIER name of the 592 managed object instance matches the corresponding sub-identifier of 593 the family name whenever the corresponding bit of the associated 594 family mask is non-zero. 596 When the configured value of the family mask is all ones, the view 597 subtree family is identical to the single view subtree identified by the 598 family name. 600 When the configured value of the family mask is shorter than required to 601 perform the above test, its value is implicitly extended with ones. 602 Consequently, a view subtree family having a family mask of zero length 603 always corresponds to a single view subtree. 605 3.8. MIB View 607 A MIB view is a subset of the set of all instances of all object types | 608 defined according to the SMI [3] within an SNMPv2 context, subject to | 609 the following constraints: | 611 o It is possible to specify a MIB view which contains the full set of | 612 all object instances within an SNMPv2 context. | 614 o Each object instance within a MIB view is uniquely named by an | 615 ASN.1 OBJECT IDENTIFIER value. 617 As such, identically named instances of a particular object type must be | 618 contained within different SNMPv2 contexts. | 619 That is, a particular object instance name resolves within a particular | 620 SNMPv2 context to | 621 at most one object instance. 623 A MIB view is defined as a collection of view subtree families, where 624 each view subtree family has a type. The type determines whether the 625 view subtree family is included in, or excluded from, the MIB view. 627 A managed object instance is contained/not contained within the MIB view | 628 according to the view subtree families to which the instance belongs: | 630 o If a managed object instance belongs to none of the relevant 631 subtree families, then that instance is not in the MIB view. 633 o If a managed object instance belongs to exactly one of the relevant 634 subtree families, then that instance is included in, or excluded 635 from, the relevant MIB view according to the type of that subtree 636 family. 638 o If a managed object instance belongs to more than one of the 639 relevant subtree families, then that instance is included in, or 640 excluded from, the relevant MIB view according to the type of a 641 particular one of the subtree families to which it belongs. The 642 particular subtree family is the one for which, first, the 643 associated family name comprises the greatest number of sub- 644 identifiers, and, second, the associated family name is 645 lexicographically greatest. 647 An SNMPv2 agent's LPD includes information on the definitions of all MIB | 648 views specified for use with local non-proxy SNMPv2 contexts. | 650 3.9. Proxy Context 652 A proxy relationship exists when a proxy SNMPv2 agent processes a 653 received management request by forwarding it to another entity, solely 654 according to the SNMPv2 context of the received message. Such a context 655 is called a proxy SNMPv2 context. When an SNMPv2 entity processes 656 management requests for a proxy context, it is operating as a proxy 657 SNMPv2 agent. 659 The transparency principle that defines the behavior of an SNMPv2 entity 660 in general, applies in particular to a proxy SNMPv2 context: 662 The manner in which a receiving SNMPv2 entity processes SNMPv2 | 663 protocol messages sent by another SNMPv2 entity | 664 is entirely transparent to the sending SNMPv2 entity. 666 Implicit in the transparency principle is the requirement that the 667 semantics of SNMPv2 management operations are preserved between any two 668 SNMPv2 peers. In particular, the "as if simultaneous" semantics of a 669 Set operation are extremely difficult to guarantee if its scope extends 670 to management information resident at multiple network locations. For 671 this reason, proxy configurations which support Set operations to 672 information at multiple locations are discouraged, although such 673 operations are not explicitly precluded by the architecture in those 674 rare cases where they might be supported in a conformant way. 676 Also implicit in the transparency principle is the requirement that, 677 throughout its interaction with a proxy SNMPv2 agent, an SNMPv2 manager 678 is supplied with no information about the nature or progress of the 679 proxy mechanisms used to perform its requests. That is, it should seem 680 to the SNMPv2 manager (except for any distinction in an underlying 681 transport address) as if it were interacting via SNMPv2 directly with 682 the proxied device. Thus, a timeout in the communication between a 683 proxy SNMPv2 agent and its proxied device should be represented as a 684 timeout in the communication between the SNMPv2 manager and the proxy 685 SNMPv2 agent. Similarly, an error response from a proxied device should 686 - as much as possible - be represented by the corresponding error 687 response in the interaction between the proxy SNMPv2 agent and SNMPv2 688 manager. 690 3.10. SNMPv2 Context 692 An SNMPv2 context is a collection of management information accessible 693 by an SNMPv2 entity. The collection of management information 694 identified by a context is either proxy or non-proxy. 696 For a non-proxy SNMPv2 context which is realized by an SNMPv2 entity, | 697 that SNMPv2 entity uses locally-defined mechanisms to access the | 698 management information identified by the SNMPv2 context. Each non-proxy 699 SNMPv2 context has a set of attributes which include the following: 701 contextIdentity - 702 the value which uniquely identifies the SNMPv2 context. 704 contextType - 705 a value which indicates that this is a non-proxy SNMPv2 context, | 706 and also indicates that it is of type local which is realized by | 707 the local SNMPv2 entity, or of type remote which is realized by | 708 some other SNMPv2 entity. | 710 contextLocalEntity - 711 the value which identifies the local entity (e.g., a logical device | 712 local to the SNMPv2 entity which realizes the context) | 713 whose management information is contained in the SNMPv2 context. 715 contextLocalTime - 716 the temporal context of the management information contained in the 717 SNMPv2 context. 719 For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 720 agent to access the management information identified by the SNMPv2 721 context. Each proxy SNMPv2 context has a set of attributes which 722 include the following: 724 contextIdentity - 725 the value which uniquely identifies the SNMPv2 context. 727 contextType - 728 a value which indicates that this is a proxy SNMPv2 context. | 730 contextProxyDstParty - 731 the SNMPv2 party to which retrieval and modification SNMPv2 | 732 requests received for this context are forwarded. | 734 contextProxySrcParty - 735 the SNMPv2 party to be used as the source SNMPv2 party when | 736 retrieval and modification SNMPv2 requests received for this | 737 context are forwarded. | 739 contextProxyContext - 740 the SNMPv2 context to be used in forwarding retrieval and | 741 modification SNMPv2 requests received for this context. | 743 The applicability of contextProxySrcParty and contextProxyContext are 744 dependent upon the partyTDomain attribute of the contextProxyDstParty 745 party. 747 An SNMPv2 entity's LPD includes information on all local contexts and on 748 any remote contexts which are known locally. 750 3.11. SNMPv2 PDU 752 An SNMPv2 PDU is defined in [2]. Each SNMPv2 PDU specifies a particular 753 operation. The types of operation (see Table 1) are represented by the 754 possible values of the ASN.1 tag for the appropriate PDU. 756 GetRequest SetRequest SNMPv2-Trap 757 GetNextRequest Response Inform 758 GetBulkRequest Report | 760 Table 1: SNMPv2 Operation Types 762 Note that a report PDU is only used as part of maintenance functions + 763 (see section 4.1). + 765 3.12. SNMPv2 Message 767 A SNMPv2 message contains a single SNMPv2 PDU, is transmitted from a 768 source SNMPv2 party to a destination SNMPv2 party, and contains 769 management information for an SNMPv2 context which is accessible by the | 770 source/destination SNMPv2 party. | 772 In particular, an SNMPv2 message may be 774 o a query by the source party about information accessible by the 775 destination party (e.g., GetRequest, GetNextRequest, or 776 GetBulkRequest), 778 o an indicative assertion to the destination party about information 779 accessible by the source party (e.g., Response, InformRequest, or 780 SNMPv2-Trap), 782 o an imperative assertion by the source party about information 783 accessible by the destination party (e.g., SetRequest), or 785 o a confirmation to the destination party about information received 786 by the source party (e.g., a Response confirming an InformRequest). 788 Starting from the PDU, an SNMPv2 message is constructed by creating 789 three successive ASN.1 SEQUENCEs, where: 791 - the PDU is a component of the first SEQUENCE, which is called an 792 SNMPv2 management communication, 794 - the first SEQUENCE is a component of the second SEQUENCE, which is 795 called an SNMPv2 authenticated management communication, | 797 - the second SEQUENCE is a component of the third SEQUENCE, which is 798 called an SNMPv2 private management communication, and | 800 - the third SEQUENCE corresponds exactly to an SNMPv2 message. 802 3.13. SNMPv2 Management Communication 804 An SNMPv2 management communication is an ASN.1 value with the following 805 syntax: 807 SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE { 808 dstParty 809 OBJECT IDENTIFIER, 810 srcParty 811 OBJECT IDENTIFIER, 812 context 813 OBJECT IDENTIFIER, 814 pdu 815 PDUs 816 } 818 where: 820 o The dstParty component identifies the destination SNMPv2 party | 821 of the SNMPv2 message. 823 o The srcParty component identifies the source SNMPv2 party | 824 of the SNMPv2 message. 826 o The context component identifies the SNMPv2 context containing the | 827 management information referenced by the SNMPv2 message. 829 o The pdu component is an SNMPv2 PDU as defined in [2]. | 830 3.14. SNMPv2 Authenticated Management Communication 832 An SNMPv2 authenticated management communication is an ASN.1 value with 833 the following syntax: 835 SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE { 836 authInfo 837 ANY, -- defined by authentication protocol 838 authData 839 SnmpMgmtCom 840 } 842 where: 844 o The authInfo component contains the authentication information | 845 required in support of the authentication protocol used by the 846 source SNMPv2 party. The detailed significance of the 847 authentication information is specific to the authentication 848 protocol in use, and its only use is in determining whether the 849 communication is authentic or not. 851 o The authData component is an SNMPv2 management communication. | 853 3.15. SNMPv2 Private Management Communication 855 An SNMPv2 private management communication is an ASN.1 value with the 856 following syntax: 858 SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE { 859 privDst 860 OBJECT IDENTIFIER, 861 privData 862 [1] IMPLICIT OCTET STRING 863 } 865 where: 867 o The privDst component identifies the destination SNMPv2 party | 868 of the SNMPv2 message. 870 o The privData component is the (possibly encrypted) serialization | 871 (i.e., encoding according to the conventions of [5]) of an SNMPv2 872 authenticated management communication. 874 3.16. SNMPv2 Access Control Policy 876 An SNMPv2 access control policy is a specification of a local access | 877 policy which authorizes access to an SNMPv2 context via a pair of SNMPv2 | 878 parties. In particular, an SNMPv2 access policy specifies the | 879 authorized types of SNMPv2 operations and the accessible MIB views. | 881 Each such local access policy, called an ACL (for historical reasons), | 882 has six attributes: | 884 acContext - | 885 the context - an SNMPv2 context which identifies the management | 886 information on which requested management operations are to be | 887 performed; | 889 acTarget - | 890 the target - a SNMPv2 party for which the SNMPv2 context is a local | 891 or proxy context; | 893 acSubject - | 894 the subject - a SNMPv2 party for which the SNMPv2 context is a | 895 remote context; | 897 acPrivileges - | 898 the access privileges - the types of SNMPv2 operations on the | 899 particular context that are authorized for SNMPv2 messages between | 900 the subject and the target; | 902 acReadViewIndex - | 903 the read MIB view - the (sub-)set of management information within | 904 the context to which the subject is authorized to have read-access | 905 via the target; | 906 and 908 acWriteViewIndex - 909 the write MIB view - the (sub-)set of management information within | 910 the context to which the subject is authorized to have write-access | 911 via the target. | 913 An SNMPv2 entity's LPD includes information on all ACLs containing local | 914 access control policies. An SNMPv2 manager | 915 may also include remote ACLs in its LPD in order to determine which | 916 operations are authorized by particular parties for a | 917 particular remote context. 919 The application of SNMPv2 access control policy is performed: | 921 o on receipt of GetRequest, GetNextRequest, GetBulkRequest, and | 922 SetRequest operations; and | 924 o prior to transmission of SNMPv2-Trap and Inform operations (the | 925 procedures by which this access-control is performed are specified | 926 in [2]). | 928 Note that application of SNMPv2 access control policy is never performed | 929 for Response nor Report operations. | 930 4. Maintenance Functions 932 Each SNMPv2 entity MUST provide an internalParty and internalContext for + 933 use with, and only with, maintenance functions, as defined in the this + 934 document. + 936 The internalParty has these characteristics: + 938 partyIdentity 0.0 + 939 partyMaxMessageSize 484 + 940 partyAuthProtocol noAuth + 941 partyPrivProtocol noPriv + 943 The internalContext is local to any SNMPv2 entity acting in an agent + 944 role, and has these characteristics: + 946 contextIdentity 0.0 + 947 contextType local (to agent) + 949 Usage of internalParty and internalContext are effectively governed by a + 950 pseudo-ACL: + 952 acTarget internalParty + 953 acSubject internalParty + 954 acContext internalContext + 955 acReadViewIndex + 956 acWriteViewIndex 0 + 957 acPrivileges 35 (Get, GetNext & GetBulk) + 959 where is statically defined to be all instances of all + 960 objects in exactly two subtrees: snmpStats [7] and snmpParties [4]. + 962 Note that internalParty, internalContext, the pseudo-ACL and the + 963 pseudo-view all have a StorageType of "readOnly" [4], in that they + 964 always exist and cannot be modified. Further, internalParty and + 965 internalContext MUST NOT be accessible to entities outside of an SNMPv2 + 966 entity itself. Consequently, even though they are conceptually + 967 represented in the LPD, neither internalParty nor internalContext are + 968 visible through the SNMPv2 Party MIB [4], neither are the pseudo-ACL and + 969 pseudo-view that they use. + 971 It should be noted that the use of a fixed context-identity + 972 (internalContext) is contrary to the architectural principles of the + 973 administrative framework: in SNMPv2, management information is always + 974 uniquely identified by a combination of context local-entity, context + 975 local-time, object type, and object instance. However, in the interests + 976 of both simplicity and the reuse of infrastructure, maintenance + 977 functions are provided "outside" of the administrative infrastructure + 978 available to applications which make use of an SNMPv2 entity. It must + 979 be emphasized that a management communication using internalContext + 980 belongs to a logically different protocol than SNMP, just as the ICMP is + 981 logically a different protocol from the IP. Thus, use of internalParty + 982 and internalContext, except for the purpose of performing maintenance + 983 functions, is prohibited. + 985 4.1. Error Reporting + 987 While processing a received communication, an SNMPv2 entity may + 988 determine that the message is unacceptable (see Section 5.2). In this + 989 case, the appropriate counter from the snmpStats group [7] is + 990 incremented and the received message is discarded without further + 991 processing or reply. + 993 If an SNMPv2 entity acting in the agent role makes such a determination, + 994 then after incrementing the appropriate counter, it is required to + 995 generate a report PDU and to send it to the transport address which + 996 originated the received message. (Note, however, that the transmission + 997 of report PDUs may be disabled through the use of the managed object, + 998 snmpV2EnableReports [7].) + 1000 Report-PDU ::= + 1001 [8] + 1002 IMPLICIT PDU + 1004 The report PDU is always transmitted within an SNMPv2 message for which + 1005 the components of the SnmpMgmtCom have these values: + 1007 srcParty = internalParty + 1008 dstParty = internalParty + 1009 context = internalContext + 1011 If the agent is able to determine the request-id field of the received + 1012 PDU, then it uses that value for the request-id field of the report PDU. + 1013 Otherwise, the value 2147483647 is used. + 1015 The error-status and error-index fields of the report PDU are always set + 1016 to zero. + 1017 The variable-bindings field contains a single variable: the identity of + 1018 the snmpStats counter which was incremented and its new value. + 1020 There are two cases in which a report PDU must not be sent by an SNMPv2 + 1021 entity acting in the agent role: if the snmpStats30Something counter is + 1022 incremented; or, if the received message was tagged as a report PDU. + 1023 5. Elements of Procedure 1025 This section describes the procedures followed by an SNMPv2 entity in 1026 processing SNMPv2 messages. These procedures are independent of the 1027 particular authentication and privacy protocols that may be in use. 1029 5.1. Generating a Request 1031 This section describes the procedure followed by an SNMPv2 entity | 1032 whenever either a management request or notification is | 1033 to be transmitted by an SNMPv2 party. (Note: in this procedure, the + 1034 values retrieved from the LPD may be overridden at the SNMPv2 entity's + 1035 discretion by values obtained through other local knowledge.) + 1037 (1) A SnmpMgmtCom value is constructed for which the srcParty component 1038 identifies the originating party, for which the dstParty component 1039 identifies the receiving party, for which the context component 1040 identifies the desired SNMPv2 context, and for which the pdu 1041 component represents the desired management operation. 1043 (2) The LPD is consulted to determine the authentication protocol and 1044 other relevant information for the originating and receiving SNMPv2 1045 parties. 1047 (3) A SnmpAuthMsg value is constructed with the following properties: 1049 Its authInfo component is constructed according to the 1050 authentication protocol specified for the originating party. 1052 In particular, if the authentication protocol for the 1053 originating SNMPv2 party is identified as noAuth, then this 1054 component corresponds to the OCTET STRING value of zero 1055 length. 1057 Its authData component is the constructed SnmpMgmtCom value. 1059 (4) The LPD is consulted to determine the privacy protocol and other 1060 relevant information for the receiving SNMPv2 party. 1062 (5) A SnmpPrivMsg value is constructed with the following properties: 1064 Its privDst component identifies the receiving SNMPv2 party. 1066 Its privData component is the (possibly encrypted) 1067 serialization of the SnmpAuthMsg value according to the 1068 conventions of [5]. 1070 In particular, if the privacy protocol for the receiving 1071 SNMPv2 party is identified as noPriv, then the privData 1072 component is unencrypted. Otherwise, the privData 1073 component is processed according to the privacy protocol. 1075 (6) The constructed SnmpPrivMsg value is serialized (i.e., encoded) 1076 according to the conventions of [5]. 1078 (7) The serialized SnmpPrivMsg value is transmitted using the transport 1079 address and transport domain (as specified in the LPD) for the 1080 receiving SNMPv2 party. 1082 Note that the above procedure does not include any application of any | 1083 SNMPv2 access control policy (but see Section 3.15). | 1085 5.2. Processing a Received Communication 1087 This section describes the procedure followed by an SNMPv2 entity 1088 whenever a SNMPv2 message is received. This procedure is independent of + 1089 the transport service address at which the message was received. + 1091 (1) The snmpStatsPackets counter [7] is incremented. If the received 1092 message is not the serialization (according to the conventions of 1093 [5]) of an SnmpPrivMsg value, then that message is discarded 1094 without further processing. (If the first octet of the packet has 1095 the value hexadecimal 30, then the snmpStats30Something counter [7] 1096 is incremented prior to discarding the message; otherwise the | 1097 snmpStatsEncodingErrors counter [7] is incremented and a report PDU | 1098 is generated.) | 1100 (2) The LPD is consulted for information about the receiving SNMPv2 1101 party identified by the privDst component of the SnmpPrivMsg value. 1103 (3) If information about the receiving SNMPv2 party is absent from the 1104 LPD, or indicates that the receiving party's operations are not 1105 performed by the local SNMPv2 entity, then the | 1106 snmpStatsUnknownDstParties counter [7] is incremented, a report PDU | 1107 is generated, and | 1108 the received message is discarded without further processing. 1110 (4) An ASN.1 OCTET STRING value is constructed (possibly by decryption, 1111 according to the privacy protocol in use) from the privData 1112 component of said SnmpPrivMsg value. 1114 In particular, if the privacy protocol recorded for the party is 1115 noPriv, then the OCTET STRING value corresponds exactly to the 1116 privData component of the SnmpPrivMsg value. 1118 (5) If the OCTET STRING value is not the serialization (according to 1119 the conventions of [5]) of an SnmpAuthMsg value, then the received 1120 message is discarded without further processing, after the | 1121 snmpStatsEncodingErrors counter [7] is incremented and a report PDU | 1122 is generated. | 1124 (6) If the dstParty component of the authData component of the obtained 1125 SnmpAuthMsg value is not the same as the privDst component of the 1126 SnmpPrivMsg value, then the received message is discarded without 1127 further processing, after the snmpStatsDstPartyMismatches counter | 1128 [7] is incremented and a report PDU is generated. | 1130 (7) The LPD is consulted for information about the originating SNMPv2 1131 party identified by the srcParty component of the authData 1132 component of the SnmpAuthMsg value. 1134 (8) If information about the originating SNMPv2 party is absent from 1135 the LPD, then the received message is discarded without further 1136 processing, after the snmpStatsUnknownSrcParties counter [7] is | 1137 incremented and a report PDU is generated. | 1139 (9) The obtained SnmpAuthMsg value is evaluated according to the 1140 authentication protocol and other relevant information associated 1141 with the originating and receiving SNMPv2 parties in the LPD. 1143 In particular, if the authentication protocol is identified as 1144 noAuth, then the SnmpAuthMsg value is always evaluated as 1145 authentic. 1147 (10) If the SnmpAuthMsg value is evaluated as unauthentic, then the | 1148 relevant counter (e.g., snmpStatsWrongDigestValues [7]) is | 1149 incremented, a report PDU is generated, the received message is | 1150 discarded | 1151 without further processing, and if the snmpV2EnableAuthenTraps 1152 object [7] is enabled, then the SNMPv2 entity sends 1153 authorizationFailure traps [7] according to its configuration 1154 (Section 4.2.6 of [2]). 1156 (11) The SnmpMgmtCom value is extracted from the authData component of 1157 the SnmpAuthMsg value. 1159 (12) The LPD is consulted for information about the SNMPv2 context 1160 identified by the context component of the SnmpMgmtCom value. 1162 (13) If information about the SNMPv2 context is absent from the LPD, 1163 then the received message is discarded without further processing, | 1164 after the snmpStatsUnknownContexts counter [7] is incremented and a | 1165 report PDU is generated. | 1167 (14) The SNMPv2 operation type is determined from the ASN.1 tag value | 1168 associated with the PDUs component of the SnmpMgmtCom value. | 1170 (15) If the SNMPv2 operation type indicates that the message contains a | 1171 report PDU, then appropriate maintenance procedures are invoked. | 1173 In particular, when a proxy SNMPv2 agent receives a report PDU from | 1174 a proxy destination party, and the result of the invoked | 1175 maintenance procedures determines that a proxy-forwarded request | 1176 cannot be delivered to the proxy destination party, then | 1177 snmpStatsProxyDrops [7] is incremented and a report PDU is | 1178 generated and transmitted to the transport address from which the | 1179 original request was received. [Note that the receipt of a report | 1180 PDU containing snmpStatsProxyDrops [7] as a varbind, is included | 1181 among the reasons why a proxy-forwarded request cannot be | 1182 delivered.] | 1184 (16) If the SNMPv2 operation type is either 32, 8, 2, or 1 (i.e., | 1185 GetBulk, Set, GetNext or Get), then: | 1187 a) if the LPD information indicates that the SNMPv2 context is of | 1188 type remote, the received message is discarded without further | 1189 processing, after the snmpStatsUnknownContexts counter [7] is | 1190 incremented and a report PDU is generated. | 1192 b) the LPD is consulted for the access privileges authorized for | 1193 communications concerning management information in the | 1194 indicated SNMPv2 context from the originating SNMPv2 party to | 1195 the receiving SNMPv2 party, and for the associated MIB view | 1196 for the particular SNMPv2 operation type. | 1198 c) if the SNMPv2 operation type is not among the authorized | 1199 access privileges, then the received message is discarded | 1200 without further processing after generation and transmission | 1201 of a response message. This response message is directed to | 1202 the originating SNMPv2 party on behalf of the receiving SNMPv2 | 1203 party. Its context, var-bind-list and request-id components | 1204 are identical | 1205 to those of the received request. Its error-index component | 1206 is zero and its error-status component is authorizationError | 1207 [2]. | 1209 d) The information extracted from the LPD concerning the | 1210 originating SNMPv2 party, the destination SNMPv2 party, and | 1211 the SNMPv2 context, together with the sending transport | 1212 address of the received message is cached for later use in | 1213 generating a response message. | 1215 e) if the LPD information indicates the SNMPv2 context is of type | 1216 local, then the management operation represented by the | 1217 SnmpMgmtCom value is performed by the receiving SNMPv2 entity | 1218 with respect to the relevant MIB view within the SNMPv2 | 1219 context according to the procedures set forth in [2], where | 1220 the relevant MIB view is: | 1222 SNMPv2 operation type MIB View given by | 1223 --------------------- ----------------- | 1224 32, 2, or 1 (get/getNext/getBulk) acReadViewIndex | 1225 8 (set) acWriteViewIndex | 1227 f) if the LPD information indicates the SNMPv2 context is of type | 1228 proxy, then: | 1230 i. the values of contextProxyContext, contextProxyDstParty | 1231 and contextProxySrcParty associated with the SNMPv2 | 1232 context of the received message are extracted from the | 1233 LPD. If any of these extracted values have the value { 0 | 1234 0 } or if any of the indicated parties and context are | 1235 not present with an active status in the LPD, then | 1236 snmpStatsProxyDrops [7] is incremented, a report PDU is | 1237 generated, and the received message is discarded. | 1239 ii. a new SNMPv2 message is constructed: the pdu component | 1240 of the SnmpMgmtCom is copied from that in the received | 1241 message except that the contained request-id is replaced | 1242 by a unique value (this value will enable a subsequent | 1243 response message to be correlated with this request); and | 1244 the dstParty, srcParty and context components are set to | 1245 the extracted values of contextProxyDstParty, | 1246 contextProxySrcParty and contextProxyContext, | 1247 respectively. | 1249 iii. the information cached in step 16d above is augmented | 1250 with the request-id of the received message as well as | 1251 the request-id and context of the constructed message. | 1253 iv. the constructed message is forwarded to the transport | 1254 address associated with the party given by the extracted | 1255 value of contextProxyDstParty. | 1257 (17) If the SNMPv2 operation type is either 128, 64 or 4 (i.e., SNMPv2- | 1258 Trap, Inform, or Response), then: | 1260 a) if the LPD information indicates the SNMPv2 context is of type | 1261 local, then the received message is discarded without further | 1262 processing, after the snmpStatsUnknownContexts counter [7] is | 1263 incremented and a report PDU is generated. | 1265 b) if the LPD information indicates the SNMPv2 context is of type | 1266 remote, then the management operation represented by the | 1267 SnmpMgmtCom value is performed by the receiving SNMPv2 entity | 1268 according to the procedures set forth in [2]. | 1270 c) if the LPD information indicates the SNMPv2 context is of type | 1271 proxy and the SNMPv2 operation type is 4 (i.e., a Response), | 1272 then: | 1274 i. the request-id is extracted from the pdu component of the | 1275 received SnmpMgmtCom. The SNMPv2 context and extracted | 1276 request-id are used to correlate this response message to | 1277 the corresponding values for a previously forwarded | 1278 request by inspecting the cache of information as | 1279 augmented in substep iii of step 16f above. If no such | 1280 correlated information is found, then the received | 1281 message is discarded without further processing. | 1283 ii. a new SNMPv2 message is constructed: the pdu component | 1284 of the SnmpMgmtCom is copied from that in the received | 1285 message except that the contained request-id is replaced | 1286 by the value saved in the correlated information from the | 1287 original request; and the dstParty, srcParty and context | 1288 components are set to the saved values of the original | 1289 request's originating party, destination party and | 1290 context, respectively. | 1292 iii. the constructed message is forwarded to the transport | 1293 address saved in the correlated information as the | 1294 sending transport address of the original request. | 1296 iv. the correlated information is deleted from the cache of | 1297 information. | 1299 d) if the LPD information indicates the SNMPv2 context is of type | 1300 proxy, and the SNMPv2 operation type is 64 (i.e., Inform), | 1301 then: | 1303 i. a unique request-id is selected for use by all forwarded | 1304 copies of this request. This value will enable a | 1305 subsequent response message to be correlated with this | 1306 request. | 1307 ii. all contexts in the LPD are located for which | 1308 contextProxyContext has the same value as the context of | 1309 the received message, and for which contextProxyDstParty | 1310 has the same value as the originating party of the | 1311 received message. | 1313 iii. for each located context, all ACLs in the LPD are | 1314 located for which the value of acContext references the | 1315 located context, and for which the access privileges | 1316 allow Inform operations. | 1318 iv. for each located ACL, a new SNMPv2 message is | 1319 constructed: the pdu component of the SnmpMgmtCom is | 1320 copied from that in the received message except that the | 1321 contained request-id is replaced by the value selected in | 1322 step i) above; the dstParty, srcParty, and context | 1323 components are set to the values of acSubject, acTarget | 1324 and acContext respectively from the located ACL. | 1326 v. for each such constructed SNMPv2 message, the information | 1327 cached in step d) above is augmented with the request-id | 1328 of the received message as well as the request-id and | 1329 context of the constructed message, and the constructed | 1330 message is forwarded to the transport address associated | 1331 with acSubject from the located ACL. | 1333 e) if the LPD information indicates the SNMPv2 context is of type | 1334 proxy, and the SNMPv2 operation type is 128 (i.e., SNMPv2- | 1335 Trap), then: | 1337 i. all contexts in the LPD are located for which | 1338 contextProxyContext has the same value as the context of | 1339 the received message, and for which contextProxyDstParty | 1340 has the same value as the originating party of the | 1341 received message. | 1343 ii. for each located context, all ACLs in the LPD are | 1344 located for which the value of acContext references the | 1345 located context, and for which the access privileges | 1346 allow SNMPv2-Trap operations. | 1348 iii. for each located ACL, a new SNMPv2 message is | 1349 constructed: the pdu component of the SnmpMgmtCom is | 1350 copied from that in the received message; the dstParty, | 1351 srcParty, and context components are set to the values of | 1352 acSubject, acTarget and acContext respectively from the | 1353 located ACL. | 1355 iv. each such constructed SNMPv2 message is forwarded to the | 1356 transport address associated with acSubject from the | 1357 located ACL, and the instance of snmpTrapNumbers [7] | 1358 which corresponds to the acSubject party is incremented. | 1360 For the sake of clarity and to prevent the above procedure from being | 1361 even longer, the following details were omitted from the above | 1362 procedure. | 1364 - Some situations in which an ASN.1 parsing error can occur were | 1365 omitted | 1366 (e.g., the possibility that an authData component is not a correct | 1367 serialization of a SnmpMgmtCom value). The snmpStatsEncodingErrors | 1368 counter [7] is incremented and a report PDU is generated whenever | 1369 such an ASN.1 parsing error is discovered. | 1371 - Some steps specify that the received message is discarded without | 1372 further processing whenever a report PDU is generated. However, a | 1373 report PDU must not be generated unless and until the SNMPv2 | 1374 operation type can be determined, so as to ensure that a report PDU | 1375 is not generated due to the receipt of a report PDU. In addition, | 1376 a generated report PDU must whenever possible contain the same | 1377 request-id value as in the PDU contained in the received message. | 1378 Meeting these constraints normally requires the message to be | 1379 further processed just enough so as to extract its SNMPv2 operation | 1380 type and request-id. Even in the case where the receiving party is | 1381 unknown, an attempt must be made to extract the SNMPv2 operation | 1382 type and request-id by assuming that the privacy protocol of the | 1383 unknown party is noPriv. With this assumption, the only situation | 1384 in which the SNMPv2 operation type and request-id cannot be | 1385 extracted is when an ASN.1 parsing error occurs. | 1387 - All generation of report PDUs is suppressed if disabled by the | 1388 managed object, snmpV2EnableReports [7]. | 1390 For a possible procedure to invoke on receipt of a message with an | 1391 SNMPv2 operation type of 16, see section 3.1.2 (step 2) of [9]. | 1393 5.3. Generating a Response 1395 The procedure for generating a response to an SNMPv2 management request | 1396 is identical to the procedure for transmitting a request (see Section | 1397 5.1), | 1398 with these exceptions: 1400 (1) In Step 1, the dstParty component of the responding SnmpMgmtCom 1401 value is taken from the srcParty component of the original 1402 SnmpMgmtCom value; the srcParty component of the responding 1403 SnmpMgmtCom value is taken from the dstParty component of the 1404 original SnmpMgmtCom value; the context component of the responding 1405 SnmpMgmtCom value is taken from the context component of the 1406 original SnmpMgmtCom value; and, the pdu component of the 1407 responding SnmpMgmtCom value is the response which results from 1408 performing the operation specified in the original SnmpMgmtCom 1409 value. 1411 (2) In Step 2, the authentication protocol and other relevant + 1412 information for the originating and receiving SNMPv2 parties is + 1413 obtained, not from the LPD, but rather from information cached (in + 1414 Step 16d) when processing the original message. + 1416 (3) + 1417 In Step 7, the serialized SnmpPrivMsg value is transmitted using 1418 the transport address and transport domain from which its 1419 corresponding request originated - even if that is different from 1420 the transport information recorded in the LPD. 1422 6. Usage Examples 1424 6.1. Non-Secure Minimal Agent Configuration 1426 This section presents an example configuration for a minimal, non-secure | 1427 SNMPv2 agent that interacts with an SNMPv2 manager. Table 2 presents | 1428 information about the local access policy known by the minimal agent; | 1429 Table 3 presents the same information as known by the manager. Table 4 | 1430 presents information on the SNMPv2 parties known to both the minimal | 1431 agent and the manager. | 1433 Target: gracie | 1434 Subject: george | 1435 Context: device5 | 1436 Privileges: Get/GetNext/GetBulk/SNMPv2-Trap | 1437 ReadView: 10 | 1438 WriteView: 0 | 1440 Table 2: Minimal Agent's Access Information | 1442 Target: gracie + 1443 Subject: george + 1444 Context: device5 + 1445 Privileges: Get/GetNext/GetBulk/SNMPv2-Trap + 1447 Table 3: Manager's Access Information for Minimal Agent + 1448 Identity gracie george 1449 (agent) (manager) 1450 Domain snmpUDPDomain snmpUDPDomain 1451 Address 1.2.3.4, 161 1.2.3.5, 2001 1452 Auth Prot noAuth noAuth 1453 Auth Priv Key "" "" 1454 Auth Pub Key "" "" 1455 Auth Clock 0 0 1456 Auth Lifetime 0 0 1457 Priv Prot noPriv noPriv 1458 Priv Priv Key "" "" 1459 Priv Pub Key "" "" 1461 Table 4: Party Information for Minimal Agent | 1463 As shown in Table 4, the example agent party operates at UDP | 1464 port 161 at IP address 1.2.3.4 using the party identity gracie; the 1465 example manager operates at UDP port 2001 at IP address 1.2.3.5 using 1466 the identity george. At minimum, a non-secure SNMPv2 agent 1467 implementation must provide for administrative configuration (and non- 1468 volatile storage) of the identities and transport addresses of two 1469 SNMPv2 parties: the local and remote peers. 1471 Suppose that the SNMPv2 manager at 1.2.3.5 wishes to interrogate 1472 management information about the SNMPv2 context named "device5", by 1473 issuing an SNMPv2 GetNext request message. The manager consults its LPD | 1474 (Table 3) to discover that management | 1475 information for context "device5" is held by the party named gracie, and 1476 that the managing party george can be used to access that context. The | 1477 manager further consults its LPD (Table 4) | 1478 to obtain the parameters of the two parties: george and gracie. Because 1479 the authentication protocol for the party george is recorded as noAuth, 1480 the GetNext request message generated by the manager is not 1481 authenticated. Because the privacy protocol for the party gracie is 1482 noPriv, the GetNext request message is not protected from disclosure. 1483 Rather, it is simply assembled, serialized, and transmitted to the 1484 transport address (IP address 1.2.3.4, UDP port 161) associated in the 1485 manager's LPD with the party gracie. 1487 When the GetNext request message is received at the agent, the identity 1488 of the destination party (gracie) is extracted from the message, and the 1489 receiving entity consults its LPD. Because the privacy protocol for the 1490 party gracie is recorded as noPriv, the received message is assumed not 1491 to be protected from disclosure. Similarly, the identity of the source 1492 party (george) is extracted, and the LPD is consulted. Because the 1493 authentication protocol for the party george is recorded as noAuth, the 1494 received message is immediately accepted as authentic. 1496 The received message is processed only if the agent's LPD authorizes | 1497 GetNext request operations by the remote party george to the local party | 1498 gracie | 1499 with respect to the SNMPv2 context "device5". The LPD information 1500 presented as Table 2 does authorize such operations (as well as Get and 1501 GetBulk operations). 1503 During the processing of the received request, each specified item of | 1504 management information is accessed only as authorized by the relevant | 1505 MIB view. The LPD information in Table 2 authorizes access for GetNext | 1506 operations (as well as to Get and GetBulk operations), and authorizes | 1507 retrievals operations to the read MIB view identified by view-index 10. | 1509 To complete the processing of the request, the agent generates a | 1510 Response | 1511 message which references the SNMPv2 context "device5" and identifies the 1512 source party as gracie (since gracie was the request's destination 1513 party), and the destination party as george (since george was the 1514 request's source party). The agent now consults its LPD. Because the 1515 authentication protocol for gracie is noAuth, the generated Response 1516 message is not authenticated. Because the privacy protocol for the 1517 party george is noPriv, the Response message is not protected from 1518 disclosure. The Response message is transmitted to the transport 1519 address from which the corresponding request originated - without regard 1520 for the transport address associated with george in the LPD. 1522 When the generated Response is received by the manager, the identity of 1523 the destination party (george) is extracted from the message, and the 1524 manager consults its LPD. Because the privacy protocol for the party 1525 george is recorded as noPriv, the received Response is assumed not to be 1526 protected from disclosure. Similarly, the identity of the source party 1527 (gracie) is extracted, and the LPD is consulted. Because the 1528 authentication protocol for the party gracie is recorded as noAuth, the 1529 received Response is immediately accepted as authentic. Finally, since | 1530 the received message is a Response operation, this message is not | 1531 subject to access control. | 1532 6.2. Secure Minimal Agent Configuration 1534 This section presents an example configuration for a secure, minimal 1535 SNMPv2 agent that interacts with a single SNMPv2 manager. Table 5 | 1536 presents information about the local access policy known by the minimal | 1537 agent; Table 6 presents the same information as known by the manager. | 1538 Table 7 presents information about the SNMPv2 parties known to both the | 1539 minimal agent and the manager. | 1541 The interaction of manager and agent in this configuration is very 1542 similar to that sketched above for the non-secure minimal agent - except 1543 that all protocol messages are authenticated and protected from 1544 disclosure. This example requires encryption of all SNMPv2 messages. 1545 Another example having an additional pair of SNMPv2 parties could 1546 support the exchange of non-secret information in authenticated messages 1547 without incurring the cost of encryption. - 1549 Target: ollie | 1550 Subject: stan | 1551 Context: device6 | 1552 Privileges: Get/GetNext/GetBulk/Set/SNMPv2-Trap | 1553 ReadView: 16 | 1554 WriteView: 17 | 1556 Table 5: Secure Minimal Agent's Access Information | 1558 Target: ollie + 1559 Subject: stan + 1560 Context: device6 + 1561 Privileges: Get/GetNext/GetBulk/Set/SNMPv2-Trap + 1563 Table 6: Manager's Access Information for Secure Minimal Agent + 1564 Identity ollie stan 1565 (agent) (manager) 1566 Domain snmpUDPDomain snmpUDPDomain 1567 Address 1.2.3.4, 161 1.2.3.5, 2001 1568 Auth Prot v2md5AuthProtocol v2md5AuthProtocol 1569 Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" 1570 Auth Pub Key "config-file" "querty" | 1571 Auth Clock 0 0 1572 Auth Lifetime 300 300 1573 Priv Prot desPrivProtocol desPrivProtocol 1574 Priv Priv Key "MNOPQR0123456789" "STUVWX0123456789" 1575 Priv Pub Key "" "" 1577 Table 7: Party Information for Secure Minimal Agent | 1579 As shown in Table 7, the example agent party operates at UDP | 1580 port 161 at IP address 1.2.3.4 using the party identity ollie; the 1581 example manager operates at UDP port 2001 at IP address 1.2.3.5 using 1582 the identity stan. At minimum, a secure SNMPv2 agent implementation 1583 must provide for administrative configuration (and non-volatile storage) | 1584 of relevant information about two SNMPv2 parties: one local and the | 1585 other a remote peer. | 1586 Both ollie and stan authenticate all messages that they generate by 1587 using the SNMPv2 authentication protocol v2md5AuthProtocol and their 1588 distinct, private authentication keys. Although these private 1589 authentication key values ("0123456789ABCDEF" and "GHIJKL0123456789") 1590 are presented here and in other examples in this section for expository 1591 purposes, knowledge of private authentication keys is normally confined 1592 to those portions of the protocol implementation that require it, and 1593 not made known to human beings. 1595 When using the v2md5AuthProtocol, the public authentication key for each 1596 SNMPv2 party is not used in authentication and verification of SNMPv2 1597 exchanges. Also, because the v2md5AuthProtocol is symmetric in 1598 character, the private authentication key for each party must be known 1599 to each SNMPv2 entity with which authenticated communication is desired. 1600 In contrast, asymmetric (public key) authentication protocols would not 1601 depend upon sharing of a private key for their operation. 1603 All protocol messages generated for transmission to the party stan are 1604 encrypted using the desPrivProtocol privacy protocol and the private key 1605 "STUVWX0123456789"; they are decrypted upon reception according to the 1606 same protocol and key. Similarly, all messages generated for 1607 transmission to the party ollie are encrypted using the desPrivProtocol 1608 protocol and private privacy key "MNOPQR0123456789"; they are 1609 correspondingly decrypted on reception. As with authentication keys, 1610 knowledge of private privacy keys is normally confined to those portions 1611 of the protocol implementation that require it, and not made known to 1612 human beings. 1614 6.3. MIB View Configurations 1616 This section provides example configurations of MIB views illustrating 1617 both simple view subtrees, and more complicated uses of included and 1618 excluded families of view subtrees. 1620 View Index Type Family Name Family Mask | 1621 5 included internet ''H | 1623 Table 8: View Definition for Minimal Agent | 1625 Table 8 illustrates the definition of a MIB view | 1626 required for a minimal SNMPv2 entity that has a single MIB view | 1627 containing all instances | 1628 of all MIB objects defined within the SNMPv2 Network Management 1629 Framework. The first column identifies the View Index by which this | 1630 view is referenced by local access policies. Note that the value of | 1631 View Index has only local significance. | 1632 The type (included) signifies that any MIB object instance belonging to | 1633 the view subtree family is contained within the MIB view. | 1634 The family name is internet, and the zero-length family mask value 1635 signifies that the relevant subtree family corresponds to the single 1636 view subtree rooted at that node. 1638 Another example of MIB view definition (see Table 9) is that of a SNMPv2 | 1639 entity having multiple distinct MIB views. The MIB view associated with | 1640 View Index 7 | 1641 comprises all instances of all MIB objects defined within the SNMPv2 1642 Network Management Framework, except those pertaining to the 1643 administration of SNMPv2 parties. In contrast, the MIB view associated | 1644 with View Index 8 contains only MIB object instances defined in the | 1645 system group of the Internet-standard MIB together with those object 1646 instances by which SNMPv2 parties are administered. 1648 View Index Type Family Name Family Mask | 1649 7 included internet ''H | 1650 7 excluded snmpParties ''H | 1651 8 included system ''H | 1652 8 included snmpParties ''H | 1654 Table 9: Definition of Multiple Views | 1656 A more complicated example of MIB view configuration illustrates the use | 1657 of view subtree families (see Table 10). | 1658 In this example, the MIB view associated with the View Index 42 includes | 1659 all object instances in the system group of the Internet-standard MIB 1660 together with information related to the second network interface 1661 attached to the managed device. However, this interface-related 1662 information does not include the speed of the interface. The family 1663 mask value 'FFA0'H in the second table entry signifies that a MIB object 1664 instance belongs to the relevant subtree family if the initial prefix of 1665 its name places it within the ifEntry portion of the registration 1666 hierarchy and if the eleventh sub-identifier of its name is 2. The MIB 1667 object instance representing the speed of the second network interface 1668 belongs to the subtree families represented by both the second and third 1669 entries of the table, but that particular instance is excluded from the | 1670 MIB view for View Index 42 because the | 1671 lexicographically greater of the relevant family names appears in the 1672 table entry with type excluded. 1674 The MIB view for View Index 49 is also defined in this example, to | 1675 include all object instances | 1676 in the icmp group of the Internet-standard MIB, together with all 1677 information relevant to the fifth network interface attached to the 1678 managed device. In addition, the MIB view for View Index 49 | 1679 includes the number of octets received on the fourth attached network 1680 interface. 1682 View Index Type Family Name Family Mask | 1683 42 included system ''H | 1684 42 included { ifEntry 0 2 } 'FFA0'H | 1685 42 excluded { ifSpeed 2 } ''H | 1686 49 included icmp ''H | 1687 49 included { ifEntry 0 5 } 'FFA0'H | 1688 49 included { ifInOctets 4 } ''H | 1690 Table 10: More Elaborate View Definitions | 1692 While, as suggested by the examples above, a wide range of MIB view 1693 configurations are efficiently supported by the use of view subtree 1694 families, prudent MIB design can sometimes further reduce the size and 1695 complexity of the most likely MIB view definitions. On one hand, it is 1696 critical that mechanisms for MIB view configuration impose no absolute 1697 constraints either upon the access policies of local administrations or 1698 upon the structure of MIB namespaces; on the other hand, where the most 1699 common access policies are known, the configuration costs of realizing 1700 those policies may be slightly reduced by assigning to distinct portions 1701 of the registration hierarchy those MIB objects for which local policies 1702 most frequently require distinct treatment. 1704 Notwithstanding the above, instance level granularity is optional (see + 1705 section 3.6). + 1707 6.4. Proxy Configuration 1709 This section presents an example configuration that supports SNMPv2 1710 proxy operations - indirect interactions between an SNMPv2 agent and an 1711 SNMPv2 manager that are mediated by a second SNMPv2 agent which performs 1712 the role of a proxy SNMPv2 agent. 1714 Tables 11 and 12 present information the SNMPv2 manager's LPD: Table 11 | 1715 for access control policies, and Table 12 for SNMPv2 parties. Tables | 1716 13, 14 and 15 present information in the proxy SNMPv2 agent's LPD: Table | 1717 13 for SNMPv2 parties, Table 14 for proxy contexts, and Table 15 for | 1718 access control policies. | 1719 (These configurations are simplified for clarity: actual configurations 1720 may require additional parties in order to support other operations and | 1721 other managers.) | 1722 Target Subject Context Privileges 1723 chico groucho ducksoup Get/GetNext/GetBulk/SNMPv2-Trap | 1725 Table 11: Access Information for Management Station | 1727 Identity groucho chico 1728 (manager) (proxy agent) 1729 Domain snmpUDPDomain snmpUDPDomain 1730 Address 1.2.3.4, 2002 1.2.3.5, 161 1731 Auth Prot v2md5AuthProtocol v2md5AuthProtocol 1732 Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" 1733 Auth Pub Key "this" "that" | 1734 Auth Clock 0 0 1735 Auth Lifetime 300 300 1736 Priv Prot noPriv noPriv 1737 Priv Priv Key "" "" 1738 Priv Pub Key "" "" 1740 Table 12: Party Information for Management Station | 1742 Identity groucho chico 1743 (manager) (proxy agent) 1744 Domain snmpUDPDomain snmpUDPDomain 1745 Address 1.2.3.4, 2002 1.2.3.5, 161 1746 Auth Prot v2md5AuthProtocol v2md5AuthProtocol 1747 Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" 1748 Auth Pub Key "this" "the-other" | 1749 Auth Clock 0 0 1750 Auth Lifetime 300 300 1751 Priv Prot noPriv noPriv 1752 Priv Priv Key "" "" 1753 Priv Pub Key "" "" 1755 Identity harpo zeppo 1756 (proxy dst) (proxy src) 1757 Domain snmpUDPDomain snmpUDPDomain 1758 Address 1.2.3.6, 161 1.2.3.5, 161 1759 Auth Prot v2md5AuthProtocol v2md5AuthProtocol 1760 Auth Priv Key "MNOPQR0123456789" "STUVWX0123456789" 1761 Auth Pub Key "" "" 1762 Auth Clock 148448 5764309 | 1763 Auth Lifetime 300 300 1764 Priv Prot noPriv noPriv 1765 Priv Priv Key "" "" 1766 Priv Pub Key "" "" 1768 Table 13: Party Information for Proxy Agent | 1770 Context Type Proxy Dest. Proxy Source Proxy Context | 1771 ducksoup proxy harpo zeppo bigstore | 1772 bigstore proxy 0.0 0.0 0.0 | 1774 Table 14: Contexts known to Proxy Agent | 1776 Target Subject Context Privileges 1777 chico groucho ducksoup Get/GetNext/GetBulk/SNMPv2-Trap | 1778 zeppo harpo bigstore 0 | 1780 Table 15: Access Information for Proxy Agent | 1782 As shown in Table 13, | 1783 the proxy SNMPv2 agent party operates at UDP port 161 at IP address 1784 1.2.3.5 using the party identity chico; the example manager operates at 1785 UDP port 2002 at IP address 1.2.3.4 using the identity groucho; the 1786 proxy source party operates at UDP port 161 at IP address 1.2.3.5 using | 1787 the party identity zeppo, and | 1788 the proxy destination party operates at UDP port 161 at IP address 1789 1.2.3.6 using the party identity harpo. 1791 Messages generated by all four SNMPv2 parties are authenticated by using 1792 the authentication protocol v2md5AuthProtocol and their individual 1793 private authentication keys. 1795 Table 14 shows the SNMPv2 contexts known to the proxy SNMPv2 agent. | 1796 In particular, the SNMPv2 context ducksoup is a proxy context that is 1797 satisfied when the SNMPv2 party zeppo communicates with the SNMPv2 party 1798 harpo and references the SNMPv2 context bigstore. 1800 In order to interrogate the proxied device associated with the context | 1801 ducksoup (see Table 11), | 1802 the SNMPv2 manager constructs an SNMPv2 message from party groucho 1803 containing a GetNext request for the SNMPv2 context ducksoup, and | 1804 transmits it to the party chico operating (see Table 12) at UDP | 1805 port 161 and IP address 1.2.3.5. This request is authenticated using 1806 the private authentication key "0123456789ABCDEF". 1808 When that request is received by the party chico, the originator of the 1809 message is verified as being the party groucho by using local knowledge | 1810 (see Table 13) of the private authentication key "0123456789ABCDEF". | 1811 Because party groucho is authorized to issue GetNext (as well as Get and 1812 GetBulk) requests to party chico for the SNMPv2 context ducksoup by the | 1813 relevant access control policy (Table 15), | 1814 the request is accepted. Because the LPD (Table 14) indicates that the | 1815 SNMPv2 context ducksoup is a proxy context, the request is satisfied by 1816 its translation into a corresponding SNMPv2 GetNext request with a | 1817 unique request-id, source party zeppo, destination party harpo and with | 1818 SNMPv2 context bigstore. This new communication is authenticated using 1819 the private authentication key "STUVWX0123456789" and transmitted to 1820 party harpo at the IP address 1.2.3.6. 1822 When this new request is received by the party harpo, authentication and | 1823 access control is performed in the normal way, and an SNMPv2 Response | 1824 message representing the results of the query is generated from the | 1825 party harpo to party zeppo referencing SNMPv2 context bigstore. This 1826 response communication is authenticated using the private authentication 1827 key "MNOPQR0123456789" and transmitted to party zeppo at IP address 1828 1.2.3.5 (the source address for the corresponding request). 1830 When this response is received by party zeppo, the source of the message 1831 is verified as being the party harpo by using local knowledge (see Table | 1832 13) of the private authentication key "MNOPQR0123456789". Because this | 1833 message contains a Response operation, it is accepted without | 1834 application of access control. Its request-id is used to correlate this | 1835 request to the previously forwarded GetNext such that the appropriate | 1836 response can be constructed. This response is constructed to have the | 1837 request-id of the original GetNext request, an SNMPv2 context of | 1838 ducksoup, the source party chico and the destination party groucho; it | 1839 is authenticated using the chico's private authentication key | 1840 "GHIJKL0123456789" and is transmitted to IP address 1.2.3.4 (the source | 1841 address for the original request). | 1843 When this response is received by the party groucho, the source of the 1844 message is verified as being the party chico by using local knowledge | 1845 (see Table 13) of the private authentication key | 1846 "GHIJKL0123456789". Because this message contains a Response operation, | 1847 it is accepted without application of access control, | 1848 and the interrogation is complete. 1850 6.5. Public Key Configuration 1852 This section presents an example configuration predicated upon a 1853 hypothetical security protocol. This hypothetical protocol would be 1854 based on asymmetric (public key) cryptography as a means for providing 1855 data origin authentication (but not protection against disclosure). 1856 This example illustrates the consistency of the administrative model 1857 with public key technology, and the extension of the example to support 1858 protection against disclosure should be apparent. 1860 Identity ollie stan 1861 (agent) (manager) 1862 Domain snmpUDPDomain snmpUDPDomain 1863 Address 1.2.3.4, 161 1.2.3.5, 2004 1864 Auth Prot pkAuthProtocol pkAuthProtocol 1865 Auth Priv Key "0123456789ABCDEF" "" 1866 Auth Pub Key "abcdefghijklmnop" "0123456789012345" | 1867 Auth Clock 0 0 1868 Auth Lifetime 300 300 1869 Priv Prot noPriv noPriv 1870 Priv Priv Key "" "" 1871 Priv Pub Key "" "" 1873 Table 16: Party Information for Public Key Agent | 1875 The example configuration comprises a single SNMPv2 agent that interacts 1876 with a single SNMPv2 manager. Tables 16 and 17 | 1877 present information about SNMPv2 parties as known to the agent and | 1878 manager, respectively. Table 5 presents information about a local | 1879 access policy known by the agent, and Table 6 presents information about | 1880 a local access policy known by the manager. | 1882 Identity ollie stan 1883 (agent) (manager) 1884 Domain snmpUDPDomain snmpUDPDomain 1885 Address 1.2.3.4, 161 1.2.3.5, 2004 1886 Auth Prot pkAuthProtocol pkAuthProtocol 1887 Auth Priv Key "" "GHIJKL0123456789" 1888 Auth Pub Key "abcdefghijklmnop" "0123456789012345" | 1889 Auth Clock 0 0 1890 Auth Lifetime 300 300 1891 Priv Prot noPriv noPriv 1892 Priv Priv Key "" "" 1893 Priv Pub Key "" "" 1895 Table 17: Party Information for Public Key Management Station | 1897 As shown in Table 16, the example agent party operates at UDP | 1898 port 161 at IP address 1.2.3.4 using the party identity ollie; the 1899 example manager operates at UDP port 2004 at IP address 1.2.3.5 using 1900 the identity stan. Both ollie and stan authenticate all messages that 1901 they generate by using the hypothetical SNMPv2 authentication protocol 1902 pkAuthProtocol and their individual private authentication keys. 1904 In most respects, the interaction between manager and agent in this 1905 configuration is almost identical to that in the example of the minimal, 1906 secure SNMPv2 agent described above. The most significant difference is 1907 that neither SNMPv2 party in the public key configuration has knowledge 1908 of the private key by which the other party authenticates its 1909 transmissions. Instead, for each received authenticated SNMPv2 1910 communication, the identity of the originator is verified by applying an 1911 asymmetric cryptographic algorithm to the received message together with 1912 the public authentication key for the originating party. Thus, in this 1913 configuration, the agent knows the manager's public key | 1914 ("0123456789012345") but not its private key | 1915 ("GHIJKL0123456789"); similarly, the manager knows the agent's public | 1916 key ("abcdefghijklmnop") but not its private key | 1917 ("0123456789ABCDEF"). 1919 7. Security Considerations 1921 In order to participate in the administrative model set forth in this 1922 memo, SNMPv2 implementations must support local, non-volatile storage of 1923 the LPD. Accordingly, every attempt has been made to minimize the 1924 amount of non-volatile storage required. 1926 8. Acknowledgements 1928 The authors wish to acknowledge the contributions of the SNMPv2 Working 1929 Group in general. In particular, the following individuals 1931 Dave Arneson (Cabletron), 1932 Uri Blumenthal (IBM), 1933 Doug Book (Chipcom), 1934 Maria Greene (Ascom Timeplex), 1935 Deirdre Kostik (Bellcore), 1936 Dave Harrington (Cabletron), 1937 Jeff Johnson (Cisco Systems), 1938 Brian O'Keefe (Hewlett Packard), 1939 Dave Perkins (Bay Networks), 1940 Randy Presuhn (Peer Networks), 1941 Shawn Routhier (Epilogue), 1942 Bob Stewart (Cisco Systems), 1943 Kaj Tesink (Bellcore). 1945 deserve special thanks for their contributions. 1947 9. References 1949 [1] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 1950 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 1951 Systems International, MIT Laboratory for Computer Science, May 1952 1990. 1954 [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 1955 Operations for Version 2 of the Simple Network Management Protocol 1956 (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, 1957 Dover Beach Consulting, Inc., Carnegie Mellon University, March | 1958 1995. | 1960 [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 1961 of Management Information for Version 2 of the Simple Network 1962 Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., 1963 Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1964 University, March 1995. | 1966 [4] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., | 1967 "Party MIB for Version 2 of the Simple Network Management Protocol 1968 (SNMPv2)", Internet Draft, March 1995. SNMP Research, Inc., | 1969 Trusted Information Systems, Cisco Systems, Dover Beach Consulting, | 1970 Inc., Carnegie Mellon University, | 1972 [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 1973 Mappings for Version 2 of the Simple Network Management Protocol 1974 (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, 1975 Dover Beach Consulting, Inc., Carnegie Mellon University, March | 1976 1995. | 1978 [6] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., | 1979 "Security Protocols for Version 2 of the Simple Network Management 1980 Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Trusted | 1981 Information Systems, Cisco Systems, Dover Beach Consulting, Inc., | 1982 Carnegie Mellon University, March 1995. | 1984 [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management 1985 Information Base for Version 2 of the Simple Network Management 1986 Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco 1987 Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, | 1988 March 1995. | 1990 [8] Information processing systems - Open Systems Interconnection - 1991 Specification of Abstract Syntax Notation One (ASN.1), 1992 International Organization for Standardization. International 1993 Standard 8824, (December, 1987). 1995 [9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., + 1996 "Coexistence between Version 1 and Version 2 of the Internet- + 1997 standard Network Management Framework", Internet Draft, SNMP + 1998 Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., + 1999 Carnegie Mellon University, March 1995. + 2001 10. Authors' Addresses 2003 Jeffrey D. Case + 2004 SNMP Research, Inc. + 2005 3001 Kimberlin Heights Rd. + 2006 Knoxville, TN 37920-9716 + 2007 US + 2009 Phone: +1 615 573 1434 + 2010 Email: case@snmp.com + 2012 James M. Galvin 2013 Trusted Information Systems, Inc. 2014 3060 Washington Road, Route 97 2015 Glenwood, MD 21738 2017 Phone: +1 301 854-6889 2018 EMail: galvin@tis.com 2020 Keith McCloghrie 2021 Cisco Systems, Inc. 2022 170 West Tasman Drive, 2023 San Jose CA 95134-1706. 2025 Phone: +1 408 526 5260 2026 Email: kzm@cisco.com 2028 Marshall T. Rose + 2029 Dover Beach Consulting, Inc. + 2030 420 Whisman Court + 2031 Mountain View, CA 94043-2186 + 2032 US + 2034 Phone: +1 415 968 1052 + 2035 Email: mrose@dbc.mtview.ca.us + 2037 Steven Waldbusser + 2038 Carnegie Mellon University + 2039 5000 Forbes Ave + 2040 Pittsburgh, PA 15213 + 2041 US + 2042 Phone: +1 412 268 6628 + 2043 Email: waldbusser@cmu.edu + 2045 Table of Contents 2047 1 Introduction .................................................... 3 2048 1.1 A Note on Terminology ......................................... 3 2049 1.2 Change Log .................................................... 3 2050 2 Overview ........................................................ 5 2051 2.1 Contexts ...................................................... 5 2052 2.2 Authorization: Access Rights and MIB Views .................... 6 2053 2.3 Proxy ......................................................... 7 2054 2.4 Security ...................................................... 8 2055 2.5 Parties ....................................................... 9 2056 2.6 Authorization: Access Control ................................. 9 2057 2.7 Construction of an SNMPv2 Message ............................. 10 2058 2.8 An SNMPv2 Entity's Local Party Datastore ...................... 10 2059 2.9 Maintenance Functions ......................................... 11 2060 3 Elements of the Model ........................................... 12 2061 3.1 SNMPv2 Party .................................................. 12 2062 3.2 SNMPv2 Entity ................................................. 14 2063 3.3 SNMPv2 Manager ................................................ 14 2064 3.4 SNMPv2 Agent .................................................. 14 2065 3.5 SNMPv2 Dual-Role Entity ....................................... 15 2066 3.6 View Subtree .................................................. 15 2067 3.7 View Subtree Families ......................................... 16 2068 3.8 MIB View ...................................................... 16 2069 3.9 Proxy Context ................................................. 17 2070 3.10 SNMPv2 Context ............................................... 18 2071 3.11 SNMPv2 PDU ................................................... 20 2072 3.12 SNMPv2 Message ............................................... 20 2073 3.13 SNMPv2 Management Communication .............................. 21 2074 3.14 SNMPv2 Authenticated Management Communication ................ 22 2075 3.15 SNMPv2 Private Management Communication ...................... 22 2076 3.16 SNMPv2 Access Control Policy ................................. 23 2077 4 Maintenance Functions ........................................... 25 2078 4.1 Error Reporting ............................................... 26 2079 5 Elements of Procedure ........................................... 28 2080 5.1 Generating a Request .......................................... 28 2081 5.2 Processing a Received Communication ........................... 29 2082 5.3 Generating a Response ......................................... 36 2083 6 Usage Examples .................................................. 37 2084 6.1 Non-Secure Minimal Agent Configuration ........................ 37 2085 6.2 Secure Minimal Agent Configuration ............................ 40 2086 6.3 MIB View Configurations ....................................... 42 2087 6.4 Proxy Configuration ........................................... 44 2088 6.5 Public Key Configuration ...................................... 48 2089 7 Security Considerations ......................................... 51 2090 8 Acknowledgements ................................................ 51 2091 9 References ...................................................... 51 2092 10 Authors' Addresses ............................................. 53