idnits 2.17.1 draft-various-snmpv2-adminv2-syn-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-20) 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 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 779 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 18 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 77: '...o authenticate the packet, but it MUST...' RFC 2119 keyword, line 1364: '...uth/priv service MUST define an authMe...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 817 has weird spacing: '... ation ation...' == Line 2153 has weird spacing: '...ayering withi...' -- 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 (September 1995) is 10445 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) -- Missing reference section? '14' on line 2003 looks like a reference -- Missing reference section? '9' on line 2075 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Administrative Model for SNMPv2 September 1995 4 Administrative Model for Version 2 of the 5 Simple Network Management Protocol (SNMPv2) 7 Fri Sep 08 1995 9 draft-various-snmpv2-adminv2-syn-01.txt 11 Tell U. Later 12 snmpv2@tis.com 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference material 24 or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 29 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 31 running list of open issues: 33 tie procedures more closely to specific mib objects 35 reference list 36 reference citations 37 acknowledgements 38 authors 39 author addresses 40 spell check 42 Abstract 44 Computer security systems can be usually be understood as being composed 45 of two or more logically distinct components. There is often a privacy 46 service that protects data from disclosure, an authentication service 47 that validates the identity of the entity requesting service, and an 48 access control service which, given an authorized entity, restricts the 49 data and operations to which that entity has access. 51 The SNMPv2 Administrative Model makes these distinctions. It specifies 52 the data and protocols that a compliant SNMPv2 entity must implement in 53 order to provide an access control service. However, it does not say 54 anything about how authentication, privacy, timeliness, and the like 55 ought to be implemented. Rather, it leaves the hooks in place for these 56 services to be implemented in a variety of ways. Henceforth, this 57 collection of unspecified services will be collectively referred to as 58 "the authentication and privacy services". Consequently, the SNMPv2 59 Administrative Model provides an architecture that realizes an access 60 control service, and provides the means for integrating authentication 61 and privacy services. 63 The access control service of the SNMPv2 Administrative Model contains 64 the following key concepts: groups, contexts, MIB views, and access 65 rights. The idea is that on a particular SNMPv2 entity, the identities 66 within a group have access (within a particular context) to a set of MIB 67 variables specified by the MIB view and can operate on those variables 68 according to the what the access rights allow. 70 There are two principal provisions for integrating authentication and 71 privacy services. First, there is a field in the SNMPv2 message header 72 that indicates which authentication and privacy service the sender used 73 and therefore a receiver of the message should use; and there is an 74 opaque set of fields which contain security information specific to the 75 indicated authentication and privacy service. Second, and more 76 significantly, there is the concept of an "identity". The security 77 service may use this identity to authenticate the packet, but it MUST 78 also map the identity to a group so that the access control service can 79 perform access control checking. In other words, the concept of an 80 identity is used by the authentication and privacy service, while the 81 concept of a group is used by the access control service. It is the 82 responsibility of the authentication and privacy service to maintain the 83 mapping between an identity and a group. 85 1. Introduction 87 A management system contains: several (potentially many) manageable 88 nodes, each with a processing entity, termed an agent, which has access 89 to management instrumentation; at least one management station; and, a 90 management protocol. The management protocol is used to convey 91 management information between the agents and management stations; and, 92 for manager-to-manager communications, between management stations. 93 Operations of the protocol are carried out under an administrative 94 framework which defines authentication, authorization, access control, 95 and privacy policies. 97 Management stations execute management applications which monitor and 98 control managed elements. Managed elements are devices such as hosts, 99 routers, terminal servers, etc., which are monitored and controlled via 100 access to their management information. 102 It is the purpose of this document, the Administrative Model for SNMPv2, 103 to define an administrative framework which realizes effective 104 management in a variety of configurations and environments. 106 The model described here includes the identification of | 107 the entities on whose behalf SNMPv2 messages are exchanged. Thus, it 108 represents a departure from the community-based administrative model of 109 the original SNMP [@ref 1157]. This new strategy improves upon the 110 historical community-based scheme by defining a model for 111 authentication, authorization, access control, and privacy including 112 definitions of an initial set of mechanisms to provide these services. 113 A wide range of mechanisms are compatible with this model, including 114 mechanisms based on symmetric (private key) security protocols and 115 mechanisms based on asymmetric (public key) security protocols. 117 1.1. A Note on Terminology 119 The original Internet-standard Network Management Framework, as 120 described in RFCs 1155, 1157, and 1212, [@ref 1155, 1157, 1212], defined 121 an initial community-based administrative model, and an initial set of 122 protocol operations. For the purpose of exposition, this is termed the 123 SNMP version 1 framework (SNMPv1). 125 The SNMPv2 management framework consists of multiple building blocks, 126 including SMI definitions [@ref v2smi], [@ref tc], and [@ref conf]; MIB 127 definitions [@ref ]; an administrative framework consisting of an 128 administrative model described herein, definitions of security and 129 privacy services such as those found in [@ref sec], and a set of MIB 130 definitions to support the administrative model [@ref adminmib]; 131 definitions of protocol operations [@ref protoops]; and SNMPv2 132 applications. 134 The SNMP version 2 administrative framework (SNMPv2) includes an 135 administrative model as described herein which couples SNMPv2 136 applications to one or more transport stacks and thereby provides 137 remote, networked, access to management information via an enhanced set 138 of protocol operations as described in [@ref protoops]. 140 A transitional approach, using the SNMP version 1 administrative model 141 in combination with the SNMP version 2 protocol operations is defined in | 142 [@ref v2Cadmin]. | 144 2. Overview 146 This section provides an overview of the remainder of the document, 147 including an introduction to some of the pertinent vocabulary. As such, 148 there is some overlap between this section and the subsequent ones in 149 order to avoid forward references. 151 The administrative model which is a part of the SNMP version 2 152 administrative framework couples SNMPv2 applications to one or more 153 transport stacks and thereby provides remote, networked, access to 154 management information (See Figure 1). 156 An SNMPv2 entity is an implementation of the administrative framework 157 described herein, coupled with one or more applications, such as agent, 158 manager, or dual-role entity applications, which remotely access 159 management information via the SNMPv2. 161 +----------------------------------------+ 162 | SNMPv2 Applications | +---------------+ 163 | e.g., |--->| Management | 164 | Agent, Manager, and Dual-Role Entity |<---| Information | 165 | Applications | +---------------+ 166 +----------------------------------------+ 167 | Administrative | 168 | Framework | 169 | including | 170 | Administrative Model | 171 +----------------------------------------+ 172 | | 173 | Transport Stack(s) | 174 | | 175 +----------------------------------------+ 177 Figure 1: The SNMPv2 Administrative Framework 179 2.1. Management Information 181 A management domain typically contains a large amount of management 182 information. Each individual item of management information is an 183 instance of a managed object type. The definition of a related set of 184 managed object types is contained in a Management Information Base (MIB) 185 module. Many such MIB modules are defined. For each managed object 186 type it describes, a MIB module defines not only the semantics and 187 syntax of that managed object type, but also the method of identifying 188 an individual instance so that multiple instances of the same managed 189 object type can be distinguished. 191 2.2. Contexts 193 Typically, there are many instances of each managed object type within a 194 management domain. For simplicity, the method for identifying instances 195 specified by the MIB module does not allow each instance to be 196 distinguished amongst the set of all instances within the management 197 domain; rather, it allows each instance to be identified only within 198 some scope or "context", where there are multiple such contexts within 199 the management domain. Often, a context is a physical device, or 200 perhaps, a logical device, although a context can also encompass 201 multiple devices, or a subset of a single device, or even a subset of 202 multiple devices. Thus, in order to identify an individual item of 203 management information within the management domain, its context must be 204 identified in addition to its object type and its instance. Note that 205 this requires each context to have a globally-unique identification 206 within the management domain. Note also that the same item of 207 management information can exist in multiple contexts. Contexts are 208 identified in an unambiguous and a globally unique manner by the pairing 209 of a contextSnmpID and a contextName; with the contextSnmpID identifying 210 a SNMPv2 entity which is an implementation of the administrative 211 framework including its administrative model, and the contextName 212 identifying a context within that entity. 214 For example, the managed object type, ifDescr [@ref ifevolution], is 215 defined as the description of a network interface. To identify the 216 description of device-X's first network interface, four pieces of 217 information are needed: the contextSnmpID which uniquely identifies 218 device-X, the contextName within device-X, ifDescr (the managed object 219 type), and "1" (the instance). 221 The contextName is expressed as a user-friendly, and often mnemonic, 222 string-based label which is convenient for manipulation by humans within 223 a system, such as when configuring a device. 225 Management information often changes over time, for example, where the 226 value of a device parameter after the device's next restart is to be 227 different than its current value. Thus, when naming a specific value of 228 a managed object instance, an indication of time is needed. In most 229 situations, it is the value at the current time which is of interest to 230 the network manager. There are, however, situations where times other 231 than the current time are of interest, e.g., such as after the next 232 restart. To accommodate this, each context has an associated notion of 233 time, called its temporal domain. This allows, for example, one context 234 to refer to the current values of a device's parameters, and a different 235 context to refer to the values that the same parameters for the same 236 device will have after the device's next restart. 238 2.3. MIB Views 240 For security reasons, it is often valuable to be able to restrict the 241 access rights of some management applications to only a subset of the 242 management information in the management domain. To provide this 243 capability, access to a context is via a "MIB view" which details a 244 specific set of managed object types (and optionally, the specific 245 instances of object types) within that context. For example, for a 246 given context, there will typically always be one MIB view which 247 provides access to all management information in that context, and often 248 there will be other MIB views each of which contains some subset of the 249 information. So, by providing access rights to a management application 250 in terms of the particular (subset) MIB view it can access for that 251 context, then the management application is restricted in the desired 252 manner. 254 Since managed object types (and their instances) are identified via the 255 tree-like naming structure of ISO's OBJECT IDENTIFIERs [@ref iso8824, 256 v2smi], it is convenient to define a MIB view as the combination of a 257 set of "view subtrees", where each view subtree is a sub-tree within the 258 managed object naming tree. Thus, a simple MIB view (e.g., all managed 259 objects within the Internet Network Management Framework) can be defined 260 as a single view sub-tree, while more complicated MIB views (e.g., all 261 information relevant to a particular network interface) can be 262 represented by the union of multiple view sub-trees. 264 While any set of managed objects can be described by the union of some 265 number of view subtrees, situations can arise that would require a very 266 large number of view subtrees. This could happen, for example, when 267 specifying all columns in one conceptual row of a MIB table because they 268 could appear in separate subtrees, one per column, each with a very 269 similar format. Because the formats are similar, the required set of 270 subtrees can easily be aggregated into one structure. This structure is 271 named a family of view subtrees after the set of subtrees that it 272 conceptually represents. A family of view subtrees can either be 273 included or excluded from a MIB view. 275 2.4. Access Rights 277 In addition to restricting access rights by identifying (sub-)sets of 278 management information, it is also valuable to restrict the operations 279 allowed on the management information within a particular context. For 280 example, one management application might not be permitted write-access 281 to a particular context, while another might be allowed to perform any 282 type of operation. 284 2.5. Authentication and Privacy 286 The enforcement of access rights requires the means not only to identify 287 the entity on whose behalf a request is generated but also to 288 authenticate such identification. Another security capability which is 289 (optionally) provided is the ability to protect the data within an 290 SNMPv2 operation from disclosure (i.e., to encrypt the data). This is 291 particularly useful when sensitive data (e.g., passwords) are accessed 292 via SNMPv2 requests. 294 2.6. Security Mechanisms and Algorithms 296 Recommendations for which algorithms are best for authentication and 297 privacy are subject to change. Such changes may occur when new research 298 results on the vulnerability of various algorithms are published, and/or 299 with the prevailing status of export control and patent issues. Thus, 300 it is valuable to allow these algorithms to be specified as parameters, 301 so that new algorithms can be accommodated over time. In particular, 302 one type of algorithm which may become increasingly useful in the future 303 is the set of algorithms associated with asymmetric (public key) 304 cryptography. 306 Note that not all accesses via SNMPv2 requests need to be secure. 307 Indeed, there are purposes for which insecure access is required. One 308 example of this is the ability of a management application to learn 309 about devices of which it has no previous knowledge. Another example is 310 to perform any synchronization which the security algorithms need before 311 they can be used to communicate securely. This need for insecure access 312 is accommodated by defining one of the algorithms for security as 313 providing neither authentication nor protection against disclosure. 315 2.7. Security Protocol Identifiers and the Reportable Flag 317 Each SNMPv2 message header contains a field which indicates the 318 particular authentication and privacy mechanisms and protocols in use 319 within that message. This is called the security flags field. 321 The security flags field conveys two aspects: the security protocol 322 identifier (sPI) value and the reportableFlag (reportableFlag). 324 The sPI value can be used to select a particular authentication and 325 privacy service, which, among other things, can be used to derive an 326 identity from a message. Correspondingly, the sPI value is added to a 327 message as a part of message generation for later use in the decoding 328 process. 330 In general, it is poor protocol design to generate an error message in 331 response to an error message and the SNMPv2 administrative framework 332 includes mechansims to prevent such behaviors. The reportableFlag 333 portion of the security flags is used to indicate if the message 334 contains an SNMPv2 protocol operation which could possibly result in a 335 report operation signifying an error. That is, the reportableFlag is 336 true if the message contains a GetRequest, GetNextRequest, 337 GetBulkRequest, SetRequest, or InformRequest operation. This 338 reportableFlag is never true for a message which contains a Response, 339 SNMPv2-Trap, or Report operation. 341 The security flags field is a signed integer, consisting of two parts 342 corresponding to the reportableFlag and the sPI. The reportableFlag is 343 communicated in the least significant bit of the security flags field. 345 The remaining bits convey the value of the sPI. 347 The values of sPI are allocated as follows. Negative and zero values 348 for sPI are reserved. Values of sPI between 1 and 127, inclusive, are 349 reserved for use with standards-track protocols and are managed by the 350 Internet Assigned Numbers Authority (IANA). 352 Values of sPI greater than 127 are allocated to enterprise-specific 353 protocol definitions. An enterprise-specific sPI value is defined to be 354 the enterprise number * 128 + the protocol number within that 355 enterprise. For example, the fourth protocol defined by the enterprise 356 whose enterprise number is 1 would be 132. 358 These seven bits allow a maximum of 128 standards-based authentication 359 and privacy services. Similarly, they allow a maximum of 128 360 authentication and privacy services per enterprise. It is believed that 361 the assignment of new sPI values should be rare in practice because the 362 larger the number of simultaneously utilized security protocols, the 363 larger the chance that interoperability will suffer. Consequently, it 364 is believed that such a range will be sufficient. In the unlikely event 365 that the standards committee finds this number to be insufficient over 366 time, an enterprise number can be allocated to obtain an additional 127 367 possible values. 369 Note that the most significant bit must be zero; hence, there are 23 370 bits allocated for various organizations to design and define non- 371 standard security protocols. This limits the ability to define new 372 proprietary implementations of security protocols to approximately the 373 first 8 million enterprises. 375 It is worthwhile to note that, in its encoded form, the sPI value will 376 normally require only a single byte since, in practice, the leftmost 377 bits will be zero for most messages and sign extension is suppressed by 378 the encoding rules. 380 As of this writing, there are several values of sPI defined for use with 381 SNMPv2 or reserved for use with supporting MIB objects. They are as 382 follows: 383 1 reserved for use in MIB objects and in association with the SNMPv1 384 administrative framework [@ref 1157] 386 2 reserved for use in MIB objects and in association with the | 387 SNMPv2C administrative framework [@ref v2Cadmin] | 389 3 unauthenticated report messages 391 4 usecNoAuth messages [@ref sec] 393 5 usecAuth messages [@ref sec] 395 6 usecPriv messages [@ref sec] 397 2.8. Identities and Group Names 399 Each SNMPv2 message conveys information on behalf of an identity. To 400 provide the necessary security capabilities, an SNMPv2 message needs to 401 indicate that identity. The identity can be conveyed either explicitly 402 or implicitly. 404 The exact manner in which an identity is conveyed in an SNMPv2 message 405 is dependent upon the particular security mechanisms and protocols which 406 have been applied to that SNMPv2 message and these may vary from time- 407 to-time and from message-to-message. 409 In addition to the sPI value, each message header also contains a set of 410 fields, called the authInfo sequence, which contains the necessary 411 parameters used by the authentication and privacy service identified by 412 the sPI. 414 Accordingly, the sPI field indicates how a receiver should parse and 415 interpret the data found in the authInfo portion of the header upon 416 receipt as well as how to generate the authInfo portion of the header 417 prior to transmission. 419 While there are a nearly infinite number of possibilities as to how the 420 information regarding an identity can be encoded in the packet header, 421 identities within a system are always identified by user-friendly, and 422 often mnemonic, string-based labels which are convenient for 423 manipulation by humans within a system, such as when configuring a 424 device. 426 It is the responsibility of the authentication and privacy service to 427 transform the encoded information in a packet header into a string-based 428 identity upon receipt of a message and to transform a string-based 429 identity into the properly encoded information for the sPI in effect. 431 An identity may operate at more than one manager location and more than 432 one agent location or may be restricted to a single pair of locations, 433 depending upon the particular authentication and privacy sPI in effect. 435 As a result, an identityName alone is insufficient to uniquely designate 436 an identity. Consequently, in some parts of an SNMPv2 infrastructure, 437 an identityName is paired with an authSnmpID, in order to provide a 438 globally unique designation of an identity and its associated 439 parameters. This allows, for example, the use of multiple passwords by 440 a single identity. However, in some parts of an SNMPv2 infrastructure, 441 in particular some low cost systems, the authSnmpID is always a constant 442 value corresponding to an identifier which uniquely identifies that 443 entity. 445 For some protocol operations, local agent operations in particular, it 446 is both convenient and efficient to grant access based on various group 447 profiles rather than per individual identity. For implementations of 448 this model which perform those operations, each identity is also 449 associated with a groupName. 451 A groupName, like an identityName, is always identified by a user- 452 friendly, and often mnemonic, string-based label which is convenient for 453 manipulation by humans within a system, such as when configuring a 454 device. For example, an identity might be associated with a group of 455 identities with a groupName of "ActiveDayShiftSupervisor" whereas other 456 identities might be associated with a group of identities with a 457 groupName of "FieldServiceTechnician". 459 2.9. Authorization: Access Control 461 As described above, an SNMPv2 message is associated with one context, 462 parameters in an authInfo sequence, and security flags field, where the 463 context determines the set of management information being accessed by 464 the message, the authInfo parameters convey the identity on whose behalf 465 the information is being communicated, and the security flags field 466 conveys the reportableFlag and sPI values. The reportableFlag indicates 467 if failures in the processing of the message are allowed to invoke 468 report operations and the sPI value indicates the type and nature of the 469 authentication and privacy parameters. These properties of the message 470 are used for access control within local operations and to control the 471 forwarding of messages within proxy operations. Specifically, access 472 control is specified as a set of local access policies which regulate 473 access to data within a specified local context by a given identity 474 using a particular sPI. The local access control specifies the set of 475 permitted operations and the MIB views which are allowed. If the 476 context, the identity derived from the authInfo sequence, and sPI are 477 not a valid combination, or the operation requested is not one of the 478 operations allowed by the triple, then the requested access is denied. 480 2.10. Construction of an SNMPv2 Message 482 The purpose of an SNMPv2 message is to contain an SNMPv2 PDU. (The PDU 483 contains an operation-code, some additional request/response parameters 484 and a list of names and values of specific managed object instances; for 485 details, see [@ref protoops].) 487 There are seven parts to every SNMPv2 message. They are as follows: 489 - The first part of every SNMPv2 message conveys the version number. 490 Every SNMPv2 message has a version number of "2" which denotes that 491 it supports version 2 of the administrative model as described 492 herein and version 2 of the protocol operations, as described in 493 [@ref protoops]. (Version 1 of the Internet-standard management 494 framework allocated "0" to this field. The value "1" is reserved | 495 for use to denote the SNMPv2C administrative model [@ref | 496 v2Cadmin].) | 498 By doing so, a parser of received messages can determine if a 499 packet should be processed by the SNMPv2 engine, or should be 500 redirected to an SNMPv1 protocol engine [@ref 1157], or an SNMPv2C | 501 protocol engine [@ref v2Cadmin]. | 503 - The mms portion of the message conveys information about the 504 sender's maximum message size for messages received via the same 505 transport layering used by the message. 507 - The security flags portion conveys the reportableFlag and the 508 security protocol identifier (sPI). The sPI indicates the 509 authentication and privacy service used by the message. 511 - The authInfo portion of the header contains the parameters used by 512 that authentication and privacy service. Hence, the exact contents 513 of the authInfo portion of the header varies, depending upon the 514 value of sPI. 516 - The contextSnmpID is the fifth portion of the header. The 517 contextSnmpID conveys the globally unique portion of the context 518 identification. 520 - The contextName is the sixth portion of the header. The 521 contextName conveys the locally-significant portion of the context 522 identification within the system denoted by the contextSnmpID. 524 - The PDU is the seventh, and last, portion of the message. 526 The concatenation of a contextSnmpID, contextName, and PDU is termed a 527 ScopedPDU for the convenience of exposition. The format of a message is 528 illustrated in Figure 2 (formal ASN.1 definitions follow in a later 529 section). 531 | <----- SnmpV2Message -------------------------------------> | 532 | | <------------ SnmpV2AuthMessage ----------> | 533 | sec | <---- ScopedPDU ------------> | 534 | ver mms flgs| authInfo | Context ID| PDU | 535 +---------------+-------------+-----------+-------------------+ 536 | S | | m | s | S | c | c | c | S p | | 537 | E | v | m | e | E | o | o S | o | E d | | 538 | Q | e | s | c | Q | n v | n n | n N | Q u | P | 539 | = | r | | f | = | t a ... | t m | t a | = | | D | 540 | T | = | | l | [ | e r | e p | e m | t | U | 541 | a | 0 | | a | 9 | n y | x I | x e | y | | | 542 | g | 2 | | g | ] | t | t D | t | p | | | 543 | | | | s | | s | | | e | | | 544 +---------------+-------------+-----------+-------------------+ 546 Figure 2: SNMPv2 Message Format 548 2.11. Authentication and Privacy Service 550 There can be a number of authentication and privacy services, denoted by 551 various values of sPI, defined for use with the administrative framework 552 defined by this document. Any particular implementation may support one 553 or more of the possible authentication and privacy services. The 554 definition of an initial set of these is found in accompanying documents 555 [@ref sec] and additional values of sPI may be defined in future 556 documents. 558 Any newly-defined authentication and privacy service must: 560 o process the authInfo portion of the message to derive an 561 identityName, authSnmpID, and groupName; 563 o decrypt, if necessary, the ScopedPDU containing the context 564 information and PDU to provide plaintext, and 566 o provide any other information needed, if any, to be cached for use 567 when producing a subsequent message, e.g., a response to a query or 568 command, or in association with proxy forwarding operations. 570 Any newly-defined authentication and privacy service must also be able 571 to generate an SnmpV2AuthMessage value from: 573 o an identityName and authSnmpID; 575 o an sPI value; and 577 o a ScopedPDU with context information consisting of a contextName 578 and contextSnmpID followed by a PDU. 580 2.12. An SNMPv2 Entity's Local Configuration Datastore 582 To implement the model described in the preceding sections, each SNMPv2 583 entity needs to retain its own set of information about contexts, 584 identities, access rights and policies, and the like. This set of 585 information is called the SNMPv2 entity's Local Configuration Datastore 586 (LCD) because it is locally-stored information. Note, however, that the 587 LCD often contains information about both local and remote systems. 589 In order to allow an SNMPv2 entity's LCD to be configured, and to allow 590 the synchronization needed by the security algorithms before they can be 591 used to communicate securely, portions of the LCD need to be accessible 592 as managed objects. A MIB module, the SNMPv2 Administration MIB, which 593 defines these managed object types is contained in [@ref adminmib]. 594 Furthermore, each definition of an authentication and privacy service, 595 denoted by an sPI, must also define any MIB and LCD support needed by 596 that authentication and privacy service. It can do this either by 597 describing new MIB elements, defining additional MIB objects which 598 AUGMENT those of another authentication and privacy service, or by 599 explaining the proper semantics and rules for use of MIB objects 600 previously defined for use by another authentication and privacy sPI. 602 It is expected that, over time, each of these three approaches will be 603 used for defining the relevant information in the LCD. As of this 604 writing, one set of authentication service-specific MIB objects are 605 shared by three authentication and privacy services [@ref sec]. Other 606 objects provide shared support for the SNMPv1 [@ref 1157] and SNMPv2 | 607 [@ref v2Cadmin]. | 608 2.13. Maintenance Functions 610 In order to facilitate communication between SNMPv2 entities, certain 611 "maintenance" functions are defined. A maintenance function is 612 identified as a management communication which accesses a well-known or 613 algorithmically derived maintenance context and makes use of a 614 corresponding well-known or algorithmically derived maintenance 615 identity. For example, error reporting and clock synchronization, are 616 achieved by performing SNMP operations in this manner. 618 When processing a maintenance function, an SNMPv2 entity utilizes the 619 same mechanisms defined for normal operations; however, unlike normal 620 operations which are executed with respect to an administration's 621 security policy (which may vary between administrations), maintenance 622 functions always occur within a fixed, standardized security policy. 623 This is advantageous in that it allows code re-use within an SNMPv2 624 entity, while also not allowing an administration's policy to impair the 625 proper operation of essential maintenance functions. However, many of 626 the rules applicable to normal identities and contexts specified in this 627 document do not always apply to these maintenance functions. 629 The sole purpose of maintenance functions is to ensure that all SNMPv2 630 entities provide essential maintenance functionality within a well- 631 known, standardized, security environment. Maintenance functions are 632 intended for use only by the internal operations of an SNMPv2 entity. 633 Thus, their scope is intentionally restricted to be the minimum 634 necessary to fulfill their purpose. 636 The only maintenance function defined in this specification of the 637 administrative model is that of error reporting. 639 Additional maintenance functions may be defined by particular security 640 and privacy services. 642 2.14. Proxy 644 The identification of a context is (architecturally) independent of the 645 location at which its management information can be accessed. Of 646 course, it is an SNMPv2 agent which responds to requests for access to 647 management information. Each such request is contained within an SNMPv2 648 message which provides the capability to perform a single operation on a 649 list of items of management information. Rather than having to identify 650 the context as well as the managed object type and instance for each 651 item of management information, each SNMPv2 message is concerned with 652 only a single context. Thus, an SNMPv2 agent must be able to process 653 each request for items of management information within one of the 654 possibly multiple contexts it supports. 656 In responding to a request, an SNMPv2 agent might be acting as a proxy 657 for some other agent. The term "proxy" has historically been used very 658 loosely, with multiple different meanings. These different meanings 659 include (among others): 661 (1) the forwarding of SNMPv2 requests to other SNMP agents without 662 regard for what managed object types are being accessed; for 663 example, in order to forward an SNMPv2 request from one transport 664 domain to another, or to translate SNMPv2 requests into SNMPv1 665 requests; 667 (2) the translation of SNMPv2 requests into operations of some non-SNMP 668 management protocol; and 670 (3) support for aggregated managed objects where the value of one 671 managed object instance depends upon the values of multiple other 672 (remote) items of management information. 674 Each of these scenarios can be advantageous; for example, support for 675 aggregation of management information can significantly reduce the 676 bandwidth requirements of large-scale management activities. However, 677 using a single term to cover multiple different scenarios causes 678 confusion. 680 To avoid such confusion, the SNMPv2 administrative framework uses the 681 term "proxy" with a much more tightly defined meaning which covers only 682 the first of those listed above. Specifically, the distinction between 683 a regular SNMPv2 agent and a "proxy SNMPv2 agent" is simple: 685 - a proxy SNMPv2 agent is an SNMPv2 agent which forwards requests on 686 to other agents according to the context, and irrespective of the 687 specific managed object types being accessed; 689 - in contrast, an SNMPv2 agent which processes SNMPv2 requests 690 according to the (names of the) individual managed object types and 691 instances being accessed, is NOT a proxy SNMPv2 agent from the 692 perspective of this administrative framework. 694 Thus, when an SNMPv2 agent acts as a proxy SNMPv2 agent for a particular 695 context, not only is the information on how to forward the request 696 specifically associated with that context, but the proxy SNMPv2 agent 697 has no need of a detailed definition of the MIB view (since the proxy 698 SNMPv2 agent forwards the request irrespective of the managed object 699 types). 701 In contrast, a non-proxy SNMPv2 agent must have the detailed definition 702 of the MIB view, and even if it needs to issue requests to other agents, 703 that need is dependent on the individual managed object instances being 704 accessed (i.e., not only on the context). 706 An SNMPv2 agent need not implement proxy forwarding operations in order 707 to be compliant with this specification. 709 2.15. Transparency Principle 711 The transparency principle that defines the behavior of an SNMPv2 entity 712 in general, applies in particular to a proxy SNMPv2 context: 714 The manner in which a receiving SNMPv2 entity processes SNMPv2 715 protocol messages sent by another SNMPv2 entity is entirely 716 transparent to the sending SNMPv2 entity. 718 Implicit in the transparency principle is the requirement that the 719 semantics of SNMPv2 management operations are preserved between any two 720 SNMPv2 peers. In particular, the "as if simultaneous" semantics of a 721 Set operation are extremely difficult to guarantee if its scope extends 722 to management information resident at multiple network locations. For 723 this reason, proxy configurations which support Set operations to 724 information at multiple locations are discouraged, although such 725 operations are not explicitly precluded by the architecture in those 726 rare cases where they might be supported in a conformant way. 728 Also implicit in the transparency principle is the requirement that, 729 throughout its interaction with a proxy SNMPv2 agent, an SNMPv2 manager 730 is supplied with no information about the nature or progress of the 731 proxy mechanisms used to perform its requests. That is, it should seem 732 to the SNMPv2 manager (except for any distinction in an underlying 733 transport address) as if it were interacting via SNMPv2 directly with 734 the proxied device. Thus, a timeout in the communication between a 735 proxy SNMPv2 agent and its proxied device should be represented as a 736 timeout in the communication between the SNMPv2 manager and the proxy 737 SNMPv2 agent. Similarly, an error response from a proxied device should 738 - as much as possible - be represented by the corresponding error 739 response in the interaction between the proxy SNMPv2 agent and SNMPv2 740 manager. 742 (Note, however that amongst the error conditions indicated by a Report 743 PDU received by a proxy SNMPv2 agent from a proxied device, some may be 744 corrected without being reported back to the SNMPv2 manager; for 745 example, when a clock resynchronization is needed. Even when such 746 errors can not be corrected, they are only indirectly reported back. 748 3. Elements of the Model 750 This section provides a more formal description of the model. 752 3.1. SNMPv2 Applications 754 An SNMPv2 application is an application-layer component which effects 755 logically remote monitoring and control functions by generating or 756 receiving (and processing) one or more types of transactions contained 757 within SNMPv2 messages. 759 SNMPv2 entities include: SNMPv2 agents, SNMPv2 managers, and SNMPv2 760 dual-role entities. 762 3.1.1. SNMPv2 Agent 764 An SNMPv2 agent is the operational role assumed by an SNMPv2 entity when 765 it acts in an agent role. Specifically, an SNMPv2 agent performs SNMPv2 766 protocol operations in response to received SNMPv2 protocol messages 767 (except for inform notifications) generated by an SNMPv2 manager. Some 768 SNMPv2 agents also emit trap notifications. 770 For the purposes of this administrative model, when a dual-role entity 771 is acting in an agent role, it is considered to be an SNMPv2 Agent. 773 3.1.2. SNMPv2 Manager 775 An SNMPv2 manager is the operational role assumed by an SNMPv2 entity 776 when it acts in a manager role on behalf of management applications. 777 Specifically, an SNMPv2 entity acts in a manager role when it initiates 778 SNMPv2 management operations by the generation of appropriate SNMPv2 779 protocol messages, including when it generates inform notifications, 780 when it receives and processes trap and inform notifications, and when 781 it receives reports. In those cases where an SNMPv2 manager receives 782 inform requests, it also generates reports. 784 For the purposes of this administrative model, when a dual-role entity 785 is acting in a manager role, it is considered to be an SNMPv2 manager. 787 3.1.3. SNMPv2 Dual-Role Entity 789 An SNMPv2 entity which sometimes acts in an agent role and sometimes 790 acts in a manager role, is termed an SNMPv2 dual-role entity. An SNMPv2 791 dual-role entity receives requests for service through acting in an 792 agent role and performs requests through acting in a manager role. 794 There are two categories of SNMPv2 dual-role entities: 796 (1) proxy SNMPv2 agents, and 798 (2) (so-called) mid-level managers. 800 Proxy SNMPv2 agents only forward requests/responses; they do not 801 originate requests. In contrast, mid-level managers often originate 802 requests. A primary purpose of SNMPv2 dual-role entities is often to 803 generate requests and aggregate responses. 805 3.1.4. SNMPv2 Application Layering within the Administrative 806 Framework 808 The following drawing of the administrative framework illustrates the 809 conceptual layering of SNMPv2 applications on top of the administrative 810 model (See Figure 3). 812 +----------------------------------------------------------------------+ 813 | Agent Role Applications | Manager Role Applications | 814 +----------------------------------------------------------------------+ 815 | Local Proxy Trap Report | Local Recvd- Notifi- Recvd Report | 816 | Agent Forwarding Gener- Gener- | Mgr Notifi- cation Report Gener- | 817 | OPs OPs ation ation | OPs cation Gen'n OPs ation | 818 | | OPs | 819 +----------------------------------------------------------------------+ 820 | Applications | 821 +----------------------------------------------------------------------+ 822 | ^ 823 v <.... Management Transactions ...> | 824 +----------------+ +----------------+ 825 | Transmit | | Received | 826 | Scoped-PDU | | Scoped-PDU | 827 | Processing | | Processing | 828 +----------------+ +----------------+ 829 | <.......... ScopedPDUs ..........> ^ 830 | +-------------------+ | 831 +------->| Authentication |-------+ 832 | and Privacy | 833 +--------| Services |<------+ 834 | +-------------------+ | 835 v <...... SnmpV2AuthMessages ......> | 836 +----------------+ +----------------+ 837 | Transmit | | Received | 838 | Wrapper | | Wrapper | 839 | Processing | | Processing | 840 +----------------+ +----------------+ 841 Non-V2 ----+ | < ........ SnmpV2Messages .......> ^ Non-V2, 842 Traffic, | | | +--> Traffic, 843 e.g.,V1,V2C v v | | e.g., V1,V2C | 844 +---------------------------------------------------------+ 845 | Transport Stack(s) | 846 +---------------------------------------------------------+ 848 Figure 3: Conceptual Layering of SNMPv2 Applications and 849 the Administrative Model 851 3.1.5. SNMPv2 Agent Role Applications 853 There are at least four functional services provided by SNMPv2 entities 854 acting in an agent role. These include: Local Agent Operations, Proxy 855 Forwarding Operations, Trap Generation, and Report Generation. 857 3.1.5.1. Local Agent Operations 859 Local Agent Operations are performed by an SNMPv2 entity acting in an 860 agent role in response to request messages received from a logically 861 remote SNMPv2 entity acting in a manager role. These operations 862 manipulate data which are locally accessible by the agent. These 863 request messages include several types of operations, including 864 GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations. 866 Local Agent Operations almost always result in the production and 867 transmission of an appropriate response, (sometimes including error or 868 other exceptional indicators), termed the Response message. 870 3.1.5.2. Proxy Forwarding Operations 872 Proxy Forwarding Operations are performed by an SNMPv2 entity by 873 receiving SNMPv2 messages from one or more SNMPv2 entities, analyzing 874 them to determine a disposition, and then transmitting regenerated 875 messages to one or more SNMPv2 entities. 877 Entities which perform Proxy Forwarding Operations are often bi- 878 directional, forwarding messages both "upstream" and "downstream" but 879 this is not necessarily the case. For example, this would not be the 880 case for an entity which is able to perform forwarding operations of 881 unidirectional messages, i.e., trap messages, either because of 882 implementation restrictions or due to local policies such as security, 883 configuration, or administration policies. 885 3.1.5.3. Trap Generation Operations 887 Trap Generation Operations are performed by an entity acting in an agent 888 role when it generates a trap message and sends it to one or more SNMPv2 889 entities acting in a manager role. 891 3.1.5.4. Report Generation Operations 893 An SNMPv2 entity acting in an agent role performs Report Generation 894 Operations when it prepares and sends error report messages to a 895 logically remote SNMPv2 entity acting in a manager role. 897 These error reports are generated in response to received messages on 898 behalf of the administrative model, i.e., as a byproduct of processing 899 by the core of the administrative model as described herein or by one of 900 the authentication and privacy services. 902 3.1.6. SNMPv2 Manager Role Applications 904 There are at least five functional services provided by SNMPv2 entities 905 acting in a manager role. These include: Local Manager Operations, 906 Received Notification Operations, Notification Generation, Received 907 Report Operations, and Report Generation. 909 3.1.6.1. Local Manager Operations 911 Local Manager Operations are initiated by SNMPv2 entities acting in a 912 manager role. They include the generation of requests containing 913 queries or commands (i.e., GetRequest, GetNextRequest, GetBulkRequest, 914 or SetRequest) to read or write management information. Local Manager 915 Operations also include the receiving and processing of responses to 916 these requests, i.e., messages containing a Response to a GetRequest, 917 GetNextRequest, GetBulkRequest, or SetRequest. 919 3.1.6.2. Received Notification Operations 921 Received Notification Operations are performed by SNMPv2 entities acting 922 in a manager role whenever they receive and process a trap message from 923 an SNMPv2 entity acting in an agent role, i.e., SNMPv2-Trap. Received 924 Notification Operations are also performed by SNMPv2 entities acting in 925 a manager role whenever they receive and process a manager-to-manager 926 message, i.e., one containing an InformRequest. The processing of an 927 InformRequest normally includes generation of a confirmation message to 928 indicate information was received, (e.g., a Response confirming an 929 InformRequest. 931 3.1.6.3. Notification Generation by Managers 933 Notification Generation is performed by SNMPv2 entities acting in a 934 manager role whenever they initiate a manager-to-manager message, i.e., 935 one containing an InformRequest. 937 3.1.6.4. Received Report Operations 939 Received Report Operations are performed by SNMPv2 entities acting in a 940 manager role whenever they receive, process, and [if appropriate] act 941 upon reports received by the manager. 943 3.1.6.5. Report Generation by Managers 945 Report Generation by Managers is performed by SNMPv2 entities acting in 946 a manager role whenever they generate and send a message containing an 947 error report, i.e., one containing a Report. A Report is initiated by a 948 manager only in response to an InformRequest, and since InformRequests 949 are initiated only by SNMPv2 entities acting in a manager role, a 950 manager never sends a report to an agent. Consequently, an entity 951 acting in an agent role does not receive and process reports. 953 3.2. SNMPv2 snmpID 955 SNMPv2 entities are named by an SNMPv2 snmpID [@ref adminmib]. An 956 SNMPv2 snmpID is a 12 byte quantity which provides a unique 957 identification of SNMPv2 entities throughout the administrative domain; 958 preferably globally as well. 960 Each implementation of the administrative model described in this memo 961 which initiates request operations or trap operations (including those 962 which initiate InformRequest operations) is assigned an SNMPv2 snmpID. 963 An implementation of the administrative model described in this memo 964 which does not initiate request operations nor trap operations may be 965 assigned an SNMPv2 snmpID, but this is not necessary. 967 An SNMPv2 entity which implements this administrative model typically 968 includes a SNMPv2 protocol engine which is associated with one or more 969 applications. 971 Two management applications are part of the same SNMPv2 entity if and 972 only if they have the same value of snmpID. That is, multiple 973 applications, e.g., an agent and a manager, or two management 974 applications on a platform, are part of the same named entity if they 975 have the same snmpID. 977 Hence, a set of coordinated management applications from a single vendor 978 might share the same snmpID and thereby be a part of the same SNMPv2 979 entity whereas a set of decoupled applications, each of which having 980 their own values for snmpID, would not be a part of the same SNMPv2 981 entity. 983 The snmpID is used within the administrative model to provide uniqueness 984 for contexts and identities. For example, the local value of snmpID is 985 sometimes used for authSnmpID or contextSnmpID when generating an SNMPv2 986 message at an SNMPv2 entity. The determination of the source of the 987 snmpID to be used, i.e., remote, local, or that of a third party, is 988 different for different transactions. 990 The snmpID value assigned to the contextSnmpID value in a message is 991 always that snmpID value associated with the context name and the 992 information in the variable bindings list. Accordingly, the snmpID 993 value assigned to the contextSnmpID value in a Get, GetNext, GetBulk, or 994 Set operation is always the snmpID value associated with the agent 995 receiving the request. Similarly, the contextSnmpID value in the 996 response to any of these operations is that same snmpID value. Further, 997 the snmpID value assigned to the contextSnmpID value in a Trap 998 notification operation is always the snmpID value associated with the 999 agent originating the trap message. 1001 The assignment of the contextSnmpID value for use in an InformRequest 1002 operation follows these same rules. Accordingly, the snmpID value 1003 assigned to the contextSnmpID value in an InformRequest may be that of 1004 the originating manager, the receiving manager, or that of a third 1005 party. For example, in the last case, manager 1 may tell manager 2 1006 about what it has discovered about information contained within a 1007 context on agent a. In this case, the contextSnmpID value will be that 1008 snmpID value associated with agent a. The contextSnmpID value used in 1009 the response to an InformRequest is always the same as that contained in 1010 the request. 1012 There are parallel sets of rules for the selection of authSnmpID values. 1013 The authSnmpID value is always set to the value of snmpID associated 1014 with the SNMPv2 entity which is considered to be "authoritative". For a 1015 Get, GetNext, GetBulk, or Set request operation, the "next hop" 1016 destination, i.e., the agent or the next intervening agent which 1017 provides proxy forwarding services is said to be authoritative, and is 1018 the source of the value of snmpID to be used for authSnmpID. This same 1019 value of authSnmpID is used for the responses to these request 1020 operations. 1022 For trap notification operations, the snmpID value associated with the 1023 agent which originates the trap, or the agent which provides proxy 1024 forwarding services is said to be authoritative, and is the source of 1025 the value of snmpID to be used for authSnmpID. 1027 For an inform notification request operation, the "next hop" 1028 destination, i.e., the destination manager or the next intervening agent 1029 which provides proxy forwarding services is said to be authoritative, 1030 and is the source of the value of snmpID to be used for authSnmpID. 1031 This same value of authSnmpID is used for the responses to these request 1032 operations. 1034 3.3. SNMPv2 Identities 1036 An identity is assumed by an SNMPv2 entity in order to restrict its 1037 operations (for security or other purposes) to an administratively 1038 defined subset of all possible SNMPv2 operations. Whenever an SNMPv2 1039 entity processes an SNMPv2 message, it does so by operating as a SNMPv2 1040 identity and is thereby restricted to the set of operations defined for 1041 that identity. The set of possible operations specified for an SNMPv2 1042 identity may be overlapping or disjoint with respect to the sets of 1043 other SNMPv2 identities. 1045 Each SNMPv2 identity is named by the pairing of an identityName and an 1046 authSnmpID. The identityName is derived from the authInfo sequence of a 1047 message and other parameters in accordance with the rules of the sPI in 1048 effect for the message. Similarly, the authInfo sequence of a message 1049 is derived from an identityName and other parameters in accordance with 1050 the rules of the sPI in effect for the message. These other parameters 1051 might include the authentication and privacy data in use on behalf of 1052 the identity, such as secret or public keys. The specifics of the 1053 mapping algorithm are dependent upon the authentication and privacy 1054 mechanisms and algorithms identified by the sPI. 1056 An SNMPv2 identity is unique only when used in conjunction with both an 1057 sPI and an authSnmpID. For example, if managers M1, M2, M3, and M4 1058 communicate with one another and with agents A1, A2, and A3 directly and 1059 via proxies P1, P2, and P3 as shown in the following figure, then the 1060 required knowledge about a prototypical identity "joe" for a given sPI 1061 is as depicted (See Figure 4.) 1063 There are multiple instances of "joe" on each manager and each proxy 1064 node to allow for different security parameters for identity "joe", for 1065 example, different passwords on different nodes. It is through this 1066 capability that a change to the private security keys associated with 1067 "joe" might be updated and distributed through the administrative domain 1068 over a period of time. Configuration of agents is the easiest whereas 1069 managers and proxies require additional configuration. 1071 In addition, the identity "joe" may have different security parameters 1072 for different values of sPI. For example, it is possible for "joe" to 1073 have one authentication key for use with one authentication and privacy 1074 service and a different key for another authentication and privacy 1075 service. 1077 Indeed, it is even possible for there to be two different identities 1078 with the identityName of "joe" for two different values of sPI which 1079 +--------+ +--------+ +--------+ +--------+ +--------+ 1080 | M1 | | M2 | | M3 | | P3 | | M4 | 1081 | joe@M1 | | joe@M1 | | joe@M2 | | joe@M3 | | joe@P4 | 1082 | joe@M2 |__| joe@M2 |__| joe@M3 |__| joe@P3 |__| joe@M4 | 1083 | joe@P1 | | joe@M3 | | joe@P3 | | joe@M4 | | | 1084 | | | joe@A2 | | joe@A2 | | | | | 1085 | | | joe@A3 | | joe@A3 | | | | | 1086 +--------+ +--------+ +--------+ +--------+ +--------+ 1087 | | \ / | 1088 | | /\ | 1089 +--------+ +--------+ +--------+ 1090 | P1 | | A2 | | A3 | 1091 | joe@M1 | | joe | | joe | 1092 | joe@P1 | +--------+ +--------+ 1093 | joe@P2 | 1094 +--------+ 1095 | 1096 +--------+ 1097 | P2 | 1098 | joe@P1 | 1099 | joe@P2 | 1100 | joe@A1 | 1101 +--------+ 1102 | 1103 +--------+ 1104 | A1 | 1105 | joe | 1106 +--------+ 1108 Figure 4: Inter-entity Identity Relationships 1110 correspond to two different human users by the name of "joe". However, 1111 the prudent administrator will likely attempt to avoid such 1112 configurations as a matter of policy even though such configurations are 1113 possible via the model and underlying protocols. 1115 It is worth mentioning that an identityName is unique within the 1116 authentication and privacy service for a given sPI on a simple agent, 1117 i.e., one which does not perform proxy forwarding operations. The 1118 authSnmpID is implicit in such systems. 1120 3.4. SNMPv2 Entity 1122 An SNMPv2 entity is an actual process or set of processes which performs 1123 management operations by generating and/or responding to SNMPv2 messages 1124 in the manner specified in [@ref protoops] and Section 4.3, Proxy 1125 Forwarding Operations. An SNMPv2 entity assumes the identity of a 1126 particular SNMPv2 identity when processing an SNMPv2 message. 1128 An SNMPv2 entity is not required to process multiple protocol messages 1129 concurrently, regardless of whether such messages require it to assume 1130 the identity of the same or different SNMPv2 identities. Thus, 1131 implementation of an SNMPv2 entity to support more than one identity 1132 need not be multi-threaded. However, there may be situations where 1133 implementors may choose to use multi-threading. 1135 Every SNMPv2 entity maintains a Local Configuration Datastore (LCD) 1136 which includes information on all identities which it uses to 1137 communicate, as well as other information (see below). 1139 An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages on 1140 each transport service address for which it is configured to do so. It 1141 is a local matter whether an SNMPv2 entity also listens for SNMPv2 1142 messages on any other transport service addresses. In the absence of 1143 any other information on where to listen, an SNMPv2 entity must listen 1144 on the transport service addresses corresponding to the standard 1145 transport-layer "ports" [@ref tm] on its local network-layer addresses. 1147 3.5. View Subtree and Families 1149 A view subtree is the set of all MIB object instances which have a 1150 common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree is 1151 identified by the OBJECT IDENTIFIER value which is the longest OBJECT 1152 IDENTIFIER prefix common to all (potential) MIB object instances in that 1153 subtree. 1155 For example, the subtree 1.3.6.1.2.1.1, which corresponds to the object 1156 system, identifies the objects within the system group of MIB-II [@ref 1157 v2mib4v2] as a view subtree. 1159 A family of view subtrees is a pairing of an OBJECT IDENTIFIER value 1160 (called the family name) together with a bitstring value (called the 1161 family mask). The family mask indicates which sub-identifiers of the 1162 associated family name are significant to the family's definition. 1164 For each possible managed object instance, that instance belongs to a 1165 particular view subtree family if both of the following conditions are 1166 true: 1168 o the OBJECT IDENTIFIER name of the managed object instance contains 1169 at least as many sub-identifiers as does the family name, and 1171 o each sub-identifier in the the OBJECT IDENTIFIER name of the 1172 managed object instance matches the corresponding sub-identifier of 1173 the family name whenever the corresponding bit of the associated 1174 family mask is non-zero. 1176 When the configured value of the family mask is all ones, the view 1177 subtree family is identical to the single view subtree identified by the 1178 family name. 1180 When the configured value of the family mask is shorter than required to 1181 perform the above test, its value is implicitly extended with ones. 1182 Consequently, a view subtree family having a family mask of zero length 1183 always corresponds to a single view subtree. 1185 When the OBJECT IDENTIFIER prefix identifying a view subtree is longer 1186 than the OBJECT IDENTIFIER of an object type defined according to the 1187 SMI [@ref v2smi], then the use of such a view subtree for access control 1188 has granularity at the object instance level. Such granularity is 1189 considered beyond the scope of an SNMPv2 agent. As such, no 1190 implementation of an SNMPv2 agent is required to support values of 1191 viewSubtree [@ref adminmib] which have more sub-identifiers than is 1192 necessary to identify a particular leaf object type. However, it may 1193 choose to do so. 1195 3.6. MIB View 1197 A MIB view is a subset of the set of all instances of all object types 1198 defined according to the SMI [@ref v2smi] within an SNMPv2 context, 1199 subject to the following constraints: 1201 o It is possible to specify a MIB view which contains the full set of 1202 all object instances within an SNMPv2 context. 1204 o Each object instance within a MIB view is uniquely named by an 1205 ASN.1 OBJECT IDENTIFIER value. 1207 As such, identically-named instances of a particular object type must be 1208 contained within different SNMPv2 contexts. That is, a particular 1209 object instance name resolves within a particular SNMPv2 context to at 1210 most one object instance. 1212 A MIB view is defined as a collection of view subtree families, where 1213 each view subtree family has a type. The type determines whether the 1214 view subtree family is included in, or excluded from, the MIB view. 1216 A managed object instance is contained/not contained within the MIB view 1217 according to the view subtree families to which the instance belongs: 1219 o If a managed object instance belongs to none of the relevant 1220 subtree families, then that instance is not in the MIB view. 1222 o If a managed object instance belongs to exactly one of the relevant 1223 subtree families, then that instance is included in, or excluded 1224 from, the relevant MIB view according to the type of that subtree 1225 family. 1227 o If a managed object instance belongs to more than one of the 1228 relevant subtree families, then that instance is included in, or 1229 excluded from, the relevant MIB view according to the type of a 1230 particular one of the subtree families to which it belongs. The 1231 particular subtree family is the one for which, first, the 1232 associated family name comprises the greatest number of sub- 1233 identifiers, and, second, the associated family name is 1234 lexicographically greatest. 1236 3.7. SNMPv2 Context 1238 An SNMPv2 context is a collection of management information accessible 1239 by an SNMPv2 entity. The collection of management information 1240 identified by a context is either proxy or non-proxy. 1242 For a local SNMPv2 context which is realized by an SNMPv2 entity, that 1243 SNMPv2 entity uses locally-defined mechanisms to access the management 1244 information identified by the SNMPv2 context. 1246 For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 1247 agent to access the management information identified by the SNMPv2 1248 context. There is no requirement that an SNMPv2 entity acting in an 1249 agent role support any proxy contexts, i.e., support of proxy is not 1250 required for conformance with this specification. 1252 3.7.1. Local SNMPv2 Context 1254 A local context refers to a collection of managed (MIB) objects which 1255 logically belong to a single entity within a managed device, even if 1256 that device is constructed of multiple physical devices. When an SNMPv2 1257 entity accesses that management information, it does so using locally- 1258 defined mechanisms. 1260 A managed device may have multiple collections of managed objects 1261 belonging to multiple logical entities within the managed device, each 1262 local context has associated with it a "local entity" name. Further, 1263 because management information changes over time, each local context 1264 also has associated with it an associated temporal domain, termed its 1265 "local time". This allows, for example, one context to refer to the 1266 current values of a device's parameters, and a different context to 1267 refer to the values that the same parameters for the same device will 1268 have after the device's next restart. 1270 3.7.2. Proxy SNMPv2 Context 1272 A proxy relationship exists when a proxy SNMPv2 agent processes a 1273 received SNMPv2 message (a request or a response) by forwarding it to 1274 another entity according to the value of the context in the received 1275 message. Such a context is called a proxy SNMPv2 context. When an 1276 SNMPv2 entity processes management requests/responses for a proxy 1277 context, it is operating as a proxy SNMPv2 agent. 1279 3.8. SNMPv2 PDUs and Operations 1281 An SNMPv2 PDU is defined in [@ref protoops]. Each SNMPv2 PDU specifies 1282 a particular operation. The types of operation (see Table 1) are 1283 represented by the possible values of the ASN.1 tag for the appropriate 1284 PDU. 1286 GetRequest SetRequest SNMPv2-Trap 1287 GetNextRequest Response Inform 1288 GetBulkRequest Report 1290 Table 1: SNMPv2 Operation Types 1292 3.9. SNMPv2 Message 1294 A SNMPv2 message contains a single SNMPv2 PDU, is transmitted on behalf 1295 of an identity, and contains management information for an identified 1296 SNMPv2 context. 1298 In particular, an SNMPv2 message may be 1300 o a query (e.g., GetRequest, GetNextRequest, or GetBulkRequest), 1302 o an indicative assertion (e.g., Response, InformRequest, or SNMPv2- 1303 Trap), 1305 o an imperative assertion (e.g., SetRequest), 1307 o a confirmation message to indicate information was received (e.g., 1308 a Response confirming an InformRequest), or 1310 o an error report (e.g., Report). 1312 An SNMPv2 message is constructed by creating an ASN.1 SEQUENCE, 1313 constructed from several sub components, some of which are also 1314 SEQUENCEs: 1316 o The first portion is the version number, where 1318 version ::= INTEGER { 1319 version-2(2) 1320 } 1322 o The second portion is the mms, where 1324 mms ::= INTEGER (484..2147483647) 1326 o The third portion is the security protocol identifier, where 1328 securityFlags ::= INTEGER (1..2147483647) 1330 o The fourth portion is a sequence. This sequence consists of an 1331 sPI-dependent authInfo portion. 1333 o The fifth portion contains a contextSnmpID, a contextName, and PDU. | 1334 Depending upon the value of sPI, portions of some or all of these | 1335 may be either plaintext or protected from disclosure (encrypted). | 1337 where the syntax and semantics of the contents of the authInfo 1338 portion is designated by the value of sPI, and the PDU portion is 1339 an SNMPv2 PDU as defined in [@ref protoops]. 1341 More formally, the complete definition of an SNMPv2 message is: 1343 SnmpV2Admin DEFINITIONS EXPLICIT TAGS ::= BEGIN 1345 IMPORTS 1346 PDUS 1347 FROM SNMPv2-PDU 1349 SnmpV2Message ::= SEQUENCE { 1350 version -- version-2 for this RFC 1351 INTEGER { 1352 version-2(2) 1353 }, 1354 mms 1355 INTEGER (484..2147483647), 1356 securityFlags 1357 INTEGER (1..2147483647), 1358 authMessage 1359 ANY DEFINED BY securityFlags | 1360 } 1362 -- Where the value contained within an authMessage is defined by the | 1363 -- authentication and privacy service as selected by securityFlags. | 1364 -- The auth/priv service MUST define an authMessage such that the | 1365 -- decoded and unencrypted authMessage contains the following elements.| 1366 -- The auth/priv service is free to define the ASN.1 for the authMessage,| 1367 -- although it is suggested that the members be specified in the | 1368 -- following order: | 1369 -- | 1370 -- authInfo ( AuthInfo ) | 1371 -- contextSnmpID ( OCTET STRING (SIZE(12)) ) | 1372 -- contextName ( OCTET STRING ) | 1373 -- pdu ( PDUs ) | 1374 -- | 1375 -- AuthInfo is defined by the authentication and privacy service. | 1376 END 1378 3.10. SNMPv2 Access Control Policy 1380 An SNMPv2 access control policy is a specification of a local access 1381 policy which authorizes access to an SNMPv2 context via an identity. In 1382 particular, an SNMPv2 access policy specifies the accessible MIB views 1383 within various SNMPv2 contexts. 1385 The application of SNMPv2 access control policy is performed: on receipt 1386 of GetRequest, GetNextRequest, GetBulkRequest, and SetRequest 1387 operations. 1389 A set of MIB definitions allows for the configuration of some SNMPv2- 1390 Trap and InformRequest operations which are also based upon MIB views 1391 within various SNMPv2 contexts, but this is independent of the access 1392 control policy expressed in the acTable [@ref adminmib]. These MIB 1393 definitions are not the exclusive mechanisms by which SNMPv2-Trap and 1394 InformRequest operations can be configured. 1396 Note that application of SNMPv2 access control policy is not performed 1397 for messages containing Response nor Report operations. 1399 4. Elements of Procedure 1401 This section describes the procedures followed by an SNMPv2 entity in 1402 processing SNMPv2 messages. These procedures are independent of the 1403 particular authentication and privacy protocols that may be in use. 1405 The procedure and data flow are depicted in the following diagrams which 1406 are provided for expository purposes and are not meant to dictate any 1407 particular implementation strategy. 1409 A portion of an implementation of the model processes received messages, 1410 steers them to an appropriate authentication and privacy service, and, 1411 if they are deemed authentic, continues processing them until they are 1412 delivered to an SNMPv2 application for further disposition. Another 1413 portion of an implementation of the model generates messages from 1414 parameters provided by the application and found in the LCD, preparing 1415 them for transmission over the network, including applying an 1416 appropriate authentication and privacy service. 1418 4.1. Generating a Message 1420 This section describes the procedure followed by an SNMPv2 entity 1421 whenever an SNMPv2 message is to be transmitted by an SNMPv2 application 1422 on behalf of an SNMPv2 identity. 1424 4.1.1. Data Flow 1426 The following diagram illustrates the data flow when a message is 1427 generated (See Figure 5). It should be noted that, especially in the 1428 case of management station applications, the "applications" referenced 1429 in the procedures which follow may be isolated from the actual 1430 management station application by additional implementation-specific 1431 layers which add additional value. 1433 c 1434 o i 1435 c n d 1436 o t e a 1437 n e n u 1438 t x t t 1439 e t i h 1440 x S t S 1441 t n y n T 1442 N m N m I 1443 a p P a p s m n 1444 m I D m I P m f 1445 e D U e D I s o 1446 | | | | | | | | 1447 V v V | | | | | 1448 +------------------------------+ | | | | | 1449 | Scoped PDU Builder |<--| | | | | 1450 +------------------------------+ | | | | | 1451 | | | | | | | 1452 | reportable | Scoped PDU | | | | | 1453 | Flag V V V | | | 1454 | +------------------------------------+ | | | 1455 | | Authentication And Privacy Service |<--| | | | 1456 | +------------------------------------+ | | | 1457 | | | | | 1458 | |SnmpV2AuthMessage | | | 1459 V V V V | 1460 +-----------------------------------------------------+ | 1461 | Final Serializer | | 1462 +-----------------------------------------------------+ | 1463 | | 1464 Non-V2 | | 1465 operations ----| | SnmpV2Message | 1466 (e.g. v1,v2C) V V V | 1467 +--------------------------------------------------------------+ 1468 | Transport Stack(s) | 1469 +--------------------------------------------------------------+ 1470 | 1471 | Packet 1472 V 1473 ---------------------------------------------------------------- 1474 N E T W O R K 1476 Figure 5: Data Flow for Generating a Message 1478 The sending application provides several parameters, including the 1479 relevant values for: the destination transport domain and address; its 1480 maximum message size of received messages; the required sPI; the 1481 identityName and authSnmpID; a globally unique identification of a 1482 context, including its contextSnmpID and contextName; and a PDU 1483 indicating the desired operations and objects. 1485 4.1.2. Procedure 1487 The procedure is as follows. 1489 (1) The contextName, contextSnmpID, and PDU are assembled into a 1490 ScopedPDU value. 1492 (2) The PDU value is examined to determine the SNMPv2 operation type. 1493 If the SNMPv2 operation type indicates a GetRequest, 1494 GetNextRequest, GetBulkRequest, SetRequest, or InformRequest 1495 operation, then the reportableFlag is set to be true; and it is set 1496 to false for all other operation types, i.e., Response, SNMPv2- 1497 Trap, or Report operations. 1499 (3) The required sPI, authSnmpID, identityName, and ScopedPDU are 1500 passed to the authentication and privacy service designated by the 1501 sPI. 1503 (4) The selected authentication and privacy service follows its 1504 procedures using the provided parameters and those in the LCD to 1505 construct an appropriate authInfo portion which is prepended to the 1506 ScopedPDU, possibly encrypting all or part of the ScopedPDU and 1507 authInfo portion in accordance with the syntax and semantics 1508 defined in the specification associated with the value of sPI 1509 provided by the application; thereby producing an SnmpV2AuthMessage 1510 value. If there is an error or exception encountered in the 1511 authentication and privacy service, then the message cannot be sent 1512 and the requesting application is suitably advised. 1514 (5) The transport information provided by the management application is 1515 examined to determine the transport stack to be used to reach the 1516 destination and the value of mms is reduced (never increased) to 1517 the smallest of those for the application, SNMPv2 protocol engine, 1518 and the transport stack. The serialization of the mms parameter is 1519 deferred as long as possible so that this minimum can be determined 1520 with a late binding. 1522 (6) The provided value for sPI and the value of reportableFlag 1523 determined from the SNMPv2 operation type are combined to form a 1524 seurityFlags value. 1526 (7) The resultant values of mms, securityFlags, and the 1527 SnmpV2AuthMessage are serialized (i.e., encoded) according to the 1528 conventions of [@ref tm], thereby producing an SnmpV2Message value. 1530 (8) The serialized SNMPv2 message is transmitted using the transport 1531 address and transport domain provided by the management 1532 application. 1534 Note that the above procedure does not include any application of any 1535 SNMPv2 access control policy (see Section 3.11). 1537 4.2. Processing a Received Communication 1539 This section describes the procedure followed by an SNMPv2 entity 1540 whenever a SNMPv2 message is received. 1542 4.2.1. Data Flow 1544 The following diagram illustrates the data flow when processing a 1545 received communication (See Figure 6). 1547 r 1548 c e 1549 i o p 1550 d n c o | 1551 a e t o r | 1552 u n g e n t | 1553 t t r x t a | 1554 h i o t e b | 1555 S t u S x l | 1556 n y p n t e T | 1557 m N N m N F I | 1558 p a a p a P s l m n | 1559 I m m I m D P a m f | 1560 D e e D e U I g s o | 1561 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 1562 | | | | | | | | | | 1563 | | | | | | | | | | 1564 | | | +-----------------------------+ | | | | 1565 | | | | Context Processing |<--|--+ | | 1566 | | | +-----------------------------+ | | | | 1567 | | | ^ | | | | 1568 | | | | ScopedPDU | | | | 1569 | | | | | | | | 1570 +------------------------------------------+ | | | | 1571 | Authentication and Privacy Services |<-|--+ | | 1572 | |<-+ | | | 1573 +------------------------------------------+ | | | | 1574 Non-V2 ^ | | | | 1575 operations <----| | SnmpV2AuthMessage sPI | | | | 1576 (e.g. v1,v2C) | | | | | | | 1577 +-----------------------------------------------------+ | 1578 | Initial parsing and version determination | | 1579 +-----------------------------------------------------+ | 1580 ^ | 1581 | SnmpV2Message | 1582 | | 1583 ---------------------------------------------------------------- 1584 Transport Stack(s) 1586 Figure 6: Data Flow for Received Message Processing 1588 4.2.2. Procedure 1590 The steps of the procedure are as follows. 1592 (1) The snmpInPkts counter [@ref v2mib4v2] is incremented and an | 1593 initial | 1594 parse of the packet is performed. If the received message is not 1595 the serialization (according to the conventions of [@ref tm]) of an 1596 SnmpV2Message value, then that message is passed to another 1597 appropriate SNMP application running on the node, e.g., an SNMPv1 1598 [@ref 1157] or SNMPv2C [@ref v2Cadmin] entity, if any, for further | 1599 processing. Otherwise: | 1601 - If the first octet of the packet has the value hexadecimal 30, then | 1602 the snmpInBadVersions counter [@ref v2mib4v2] is incremented, and | 1603 the message is discarded without further processing. | 1605 - If the first octet of the packet is not the value hexadecimal 30, | 1606 then the snmpInASNParseErrs counter [@ref v2mib4v2] is incremented, | 1607 a report PDU is generated, and the message is discarded without | 1608 further processing. | 1610 (2) The value of mms is extracted and saved. 1612 (3) The values of sPI and reportableFlag are extracted and saved. If 1613 the sPI value is not implemented by this entity, then the value of | 1614 v2AdminStatsUnknownSPI counter [@ref v2mib4v2] is incremented, | 1615 a report PDU is generated, and the received message is discarded 1616 without further processing. 1618 (4) The SnmpV2AuthMessage value is forwarded to the authentication and 1619 privacy service designated by the sPI. Processing within the 1620 designated authentication and privacy service may result in one or 1621 more error conditions, in which case a report PDU may be generated 1622 by the authentication and privacy service, and the received message 1623 is discarded without further processing. 1625 However, if the snmpV2EnableAuthenTraps object [@ref v2mib4v2] is 1626 enabled, then the SNMPv2 entity sends authorizationFailure traps 1627 [@ref v2mib4v2] according to its configuration. 1629 If the message is deemed authentic, the selected authentication and 1630 privacy service translates the SnmpV2AuthMessage value into an 1631 identityName, authSnmpID, groupName, and a plaintext (i.e., 1632 unencrypted) version of the serialized ScopedPDU. 1634 (5) The LCD is consulted for information about the identity as named by 1635 the combination of the authSnmpID and identityName values. If 1636 information about the SNMPv2 identity is absent from the LCD, then 1637 the snmpStatsUnknownIdentities counter [@ref v2mib4v2] is 1638 incremented, a report PDU is generated, and the received message is 1639 discarded without further processing. 1641 (6) The portion of the ScopedPDU containing context information is 1642 processed to extract the values for contextSnmpID and a 1643 contextName. If the serialized ScopedPDU value is not the 1644 serialization (according to the conventions of [@ref tm]) of a 1645 ScopedPDU value, then the received message is discarded without 1646 further processing, after the snmpInASNParseErrs counter [@ref | 1647 v2mib4v2] is incremented | 1648 and a report PDU is generated. 1650 (7) The PDU portion of the ScopedPDU is processed. If the serialized 1651 PDU value is not the serialization (according to the conventions of 1652 [@ref tm]) of a PDU value, then the received message is discarded 1653 without further processing, after the snmpInASNParseErrs counter | 1654 [@ref v2mib4v2] is incremented | 1655 and a report PDU is generated. 1657 (8) If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or 1658 Set operation, then: 1660 a) If the receiving entity performs proxy forwarding operations 1661 and the context is such that it indicates a possible proxy 1662 operation, then the processing continues as described in 1663 Section 4.3, Proxy Forwarding Operations. 1665 b) If the identified context is such that it indicates a non- 1666 local operation, then the v2AdminStatsUnknownContexts counter | 1667 [@ref v2mib4v2] is incremented, | 1668 a report PDU is generated, and the received message is 1669 discarded without further processing. 1671 c) Otherwise, if the identified context indicates a configured 1672 local operation but the identified context is presently 1673 unavailable, perhaps because of the removal of a component 1674 from a hot-swappable chassis, then the received message is 1675 discarded without further processing, after the | 1676 v2AdminStatsUnavailableContexts counter | 1677 [@ref v2mib4v2] is incremented and a report PDU is generated. 1679 d) The LCD is consulted for access rights authorized for 1680 communications on behalf of the identity concerning management 1681 information in the indicated SNMPv2 context for the particular 1682 SNMPv2 operation type. 1684 e) If the SNMPv2 operation type is not among the authorized 1685 access rights, then the received message is discarded without 1686 further processing after generation and transmission of a 1687 response message. This response message is sent on behalf of 1688 the same identity. Its contextName, contextSnmpID, var-bind- 1689 list, and request-id values are identical to those of the 1690 received request. Its error-index portion is zero and its 1691 error-status portion is authorizationError [@ref protoops]. 1693 f) The information concerning the identityName, authSnmpID, 1694 contextSnmpID, contextName, and sending transport domain and 1695 address are cached for later use in generating a response 1696 message. 1698 g) The management operation represented by the SNMPv2 operation 1699 type is performed by the SNMPv2 entity with respect to the 1700 relevant MIB view within the SNMPv2 context according to the 1701 procedures set forth in [@ref protoops], where the relevant 1702 MIB view is determined by the groupName, authSnmpID, sPI, 1703 contextSnmpID, contextName, and type of operation requested; 1704 where the relevant MIB view is: 1706 SNMPv2 operation type MIB View given by 1707 --------------------- ----------------- 1708 read(get/getNext/getBulk) acReadViewName 1709 write(set) acWriteViewName 1711 (9) If the SNMPv2 operation type is a Response operation (to a Get, 1712 GetNext, GetBulk, Set, or Inform), then: 1714 a) The request-id is extracted from the PDUs portion of the 1715 ScopedPDU received from the authentication and privacy 1716 service. The value of request-id is used to locate a 1717 corresponding entry in the cache of outstanding requests (both 1718 those generated locally and those which were the result of 1719 proxy forwarding operations, if any). The values of 1720 authSnmpID, identityName, and sPI received from the 1721 authentication and privacy service are compared with the 1722 cached values for the forwarded request. The values of 1723 contextSnmpID and contextName found in the ScopedPDU are 1724 compared with the cached values for the forwarded request. If 1725 any of these values do not match, then the | 1726 v2AdminStatsCacheMisses counter [@ref v2mib4v2] is | 1727 incremented, the received message is discarded | 1728 without further processing, and the cached entry is deleted. 1730 b) If the located cached entry indicates this message is a 1731 response to a proxy forwarding operation, then processing 1732 continues as described in Section 4.3, Proxy Forwarding 1733 Operations, and if the located cached entry indicates this 1734 message is a response to a locally generated request, then 1735 processing continues as described by [@ref protoops]. 1737 (10) If the SNMPv2 operation type is a Trap notification operation, then 1739 a) If the receiving entity performs proxy forwarding operations 1740 and the context is such that it indicates a possible proxy 1741 operation, then the processing continues as described in 1742 Section 4.3, Proxy Forwarding Operations. 1744 b) Otherwise, processing of the message continues as described by 1745 [@ref protoops]. 1747 (11) If the SNMPv2 operation type is an Inform notification operation, 1748 then 1750 a) If the receiving entity performs proxy forwarding operations 1751 and the context is such that it indicates a possible proxy 1752 operation, then the processing continues as described in 1753 Section 4.3, Proxy Forwarding Operations. 1755 b) Otherwise, the receiving entity acknowledges receipt by 1756 sending a response as described in Section 4.4, Generating A 1757 Response, and [@ref protoops]. 1759 c) Processing of the message continues as described at [@ref 1760 protoops]. 1762 (12) If the SNMPv2 operation type is a Report operation, then 1764 a) The request-id is extracted from the PDUs portion of the 1765 ScopedPDU received from the authentication and privacy 1766 service. The value of request-id is used to locate a 1767 corresponding entry in the cache of outstanding requests (both 1768 those generated locally and those which were the result proxy 1769 forwarding operations, if any). (If no such entry is found, 1770 but the received request-id is 2147483647, then all entries 1771 are searched to attempt to locate an appropriate entry such 1772 that the values of authSnmpID, identityName, sPI, 1773 contextSnmpID, and contextName match.) 1774 The values of authSnmpID, identityName, and sPI received from 1775 the authentication and privacy service are compared with the 1776 cached values for the forwarded request. The values of 1777 contextSnmpID and contextName found in the ScopedPDU are 1778 compared with the cached values for the forwarded request. If 1779 any of these values do not match, (or no suitable matching 1780 entry can be located in the special case when the request-id 1781 is 2147483647) then the v2AdminStatsCacheMisses counter [@ref | 1782 v2mib4v2] is incremented, | 1783 the received message is discarded without further processing, | 1784 and the cached entry (if one was found) is deleted. | 1786 b) If the located cached entry indicates this message is a 1787 response to a proxy forwarding operation, then processing 1788 continues as described in Section 4.3, Proxy Forwarding 1789 Operations, and if the located cached entry indicates this 1790 message is a response to a locally generated request, then 1791 processing continues as described at [@ref protoops]. 1793 4.2.3. Common Constructs 1795 For the sake of clarity and to prevent the above procedure from being 1796 even longer, the following details were omitted from the above 1797 procedure. 1799 - Some situations in which an ASN.1 parsing error can occur were 1800 omitted (e.g., the possibility that a snmpV2AuthMessage portion is 1801 not a correct serialization of a SnmpV2AuthMessage value). The | 1802 snmpInASNParseErrs | 1803 counter [@ref v2mib4v2] is incremented and a report PDU is 1804 generated whenever such an ASN.1 parsing error is discovered. 1806 Some steps specify that the received message is discarded without | 1807 further processing whenever a report PDU is generated. However, a | 1808 report PDU must not be generated unless the reportableFlag is set, | 1809 which ensures that a reportPDU is not generated due to the receipt | 1810 of a report PDU. In addition, a generated report PDU must whenever | 1811 possible contain the same request-id value as in the PDU contained | 1812 in the received message. Meeting this constraint normally requires | 1813 the message to be further processed just enough so as to extract | 1814 its request-id. Even in the case where the identity cannot be | 1815 authenticated, an attempt must be made to extract the request-id by | 1816 assuming that no encryption is in use by the identity. With this | 1817 assumption, the only situation in which the request-id cannot be | 1818 extracted is when an ASN.1 parsing error occurs. | 1820 For a possible procedure to invoke on receipt of a message with an 1821 SNMPv2 operation type of SNMPv1 trap, see [@ref coex]. 1823 4.3. Proxy Forwarding Operations 1825 These procedures are implemented if and only if the entity also supports 1826 proxy forwarding operations. 1828 The procedures are as follows. 1830 (1) If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or 1831 Set operation, then: 1833 a) The LCD information is inspected to locate the entry in the 1834 proxyForwardingTable such that proxyDirection equals gnsb(1) 1835 for which there is a favorable comparison between the values 1836 of proxySPIIn, | 1837 proxyAuthSnmpIDIn, proxyIdentityNameIn, proxyContextSnmpIDIn, 1838 and proxyContextName with the corresponding values received in 1839 the ScopedPDU or determined from the authentication and 1840 privacy service. The values of proxySPIOut, 1841 proxyAuthSnmpIDOut, proxyIdentityNameOut, 1842 proxyTransportLabelOut, and proxyPrivs are extracted from the 1843 located entry. If there is no such entry, the snmpProxyDrops | 1844 [@ref v2mib4v2] is | 1845 incremented, a report PDU is generated and sent to the source 1846 of the original request, and the received message is discarded 1847 without further processing. 1849 b) The value of the proxyPrivs is compared with the SNMPv2 1850 operation type. If the requested operation is not among the 1851 permitted operations, the snmpProxyDrops [@ref v2mib4v2] is | 1852 incremented, a report PDU is generated and sent to the source 1853 of the original request, and the received message is discarded 1854 without further processing. 1856 c) A new ScopedPDU is constructed. 1858 Its PDUs portion is the same as the PDUs portion of the 1859 ScopedPDU request received from the authentication and privacy 1860 service except that the contained request-id is replaced by a 1861 unique value (this value will enable a subsequent response 1862 message to be correlated with this request). However, the new 1863 unique value should not equal 2147483647; this value is 1864 reserved. 1866 Its contextSnmpID and contextName are the same as the 1867 corresponding values in the ScopedPDU received from the 1868 authentication and privacy service. 1870 d) The appropriate authentication and privacy service, as 1871 selected by the extracted value of proxySPIOut is used to 1872 prepare an appropriate SnmpV2AuthMessage, using the extracted 1873 values of proxyAuthSnmpIDOut and proxyIdentityNameOut. If the 1874 value of proxySPIOut equals "1", which indicates that the next 1875 hop utilizes SNMPv1, then [@ref coex] defines an appropriate 1876 set of transformations to be applied. If a suitable 1877 SnmpV2AuthMessage cannot be constructed, the snmpProxyDrops | 1878 [@ref v2mib4v2] is | 1879 incremented, a report PDU is generated and sent to the source 1880 of the original request, and the received message is discarded 1881 without further processing. 1883 e) Several values associated with the original request are cached 1884 for later use in generating a response message. These values 1885 include: the request-id of the original request and the 1886 request-id of the newly generated request, the sPI used to 1887 forward the message, transport domain and address of the 1888 source of the original request, the contextSnmpID and 1889 contextName found in the ScopedPDU of the original request, 1890 proxyAuthSnmpIDIn, identityNameIn, and sPI values received 1891 from the authentication and privacy service when processing 1892 the original request. 1894 f) The extracted value of proxyTransportLabelOut is used to 1895 determine the transportDomain, transportAddress, and 1896 transportMMS for each destination. 1898 For each destination, the value of mms associated with the 1899 request is reduced, to the smallest of the mms of the protocol 1900 engine of the proxy agent and the mms of the transport to be 1901 used to forward the request, if either is smaller than the 1902 received value for mms. 1904 g) For each destination, the values for mms, sPI, and the 1905 SnmpV2AuthMessage are converted into a SnmpV2Message which is 1906 then sent via the transport layer. If the message cannot be 1907 constructed or is determined to be unforwardable, the | 1908 snmpProxyDrops [@ref v2mib4v2] is | 1909 incremented, a report PDU is generated and sent to the source 1910 of the original request, the received message is discarded 1911 without further processing, and the cached entry is deleted. 1913 (2) If the SNMPv2 operation type is a Response operation (to a Get, 1914 GetNext, GetBulk, Set, or Inform operation), then: 1916 a) The request-id is extracted from the PDUs portion of the 1917 ScopedPDU received from the authentication and privacy 1918 service. The value of request-id is used to locate a 1919 corresponding entry in the cache of outstanding requests. The 1920 values of authSnmpID, identityName, and sPI received from the 1921 authentication and privacy service are compared with the 1922 cached values for the forwarded request. The values of 1923 contextSnmpID and contextName found in the ScopedPDU are 1924 compared with the cached values for the forwarded request. If 1925 any of these values do not match, then the snmpProxyDrops | 1926 [@ref v2mib4v2] is | 1927 incremented, a report PDU is generated and sent to the source 1928 of the original request, the received message is discarded 1929 without further processing, and the cached entry is deleted. 1931 b) A new ScopedPDU is constructed. 1933 Its PDUs portion is the same as the PDUs portion of the 1934 ScopedPDU response received from the authentication and 1935 privacy service except that the contained request-id is 1936 replaced by the cached value of the original request. 1938 Its contextSnmpID and contextName are the same as the 1939 corresponding values in the ScopedPDU received from the 1940 authentication and privacy service. 1942 c) The appropriate authentication and privacy service, as 1943 selected by the cached value of sPI for the original request 1944 is used to prepare an appropriate SnmpV2AuthMessage, using the 1945 cached values authSnmpID and identityName derived from the 1946 original request message. If the received value of sPI 1947 indicates a SNMPv1message, then [@ref coex] defines a suitable 1948 set of transformations. If a suitable SnmpV2AuthMessage 1949 cannot be constructed, the snmpProxyDrops [@ref v2mib4v2] is | 1950 incremented, a report PDU is generated and sent to the source 1951 of the original request, the received message is discarded 1952 without further processing, and the cached entry is deleted. 1954 d) The value of mms associated with the response is reduced, to 1955 the smallest of the mms of the protocol engine of the proxy 1956 agent and the mms of the transport to be used to forward the 1957 request, if either are smaller than the received value for 1958 mms. 1960 This step is unnecessary for the purpose of processing the 1961 response message currently in transit. However, this step is 1962 useful as means to learn the effective path-mms for the 1963 purpose of optimizing subsequent request-message size. 1965 e) The values for mms, sPI, and the SnmpV2AuthMessage are 1966 converted into a SnmpV2Message and sent to the transport 1967 layer. The message is prepared and sent using the cached 1968 values of the original request sender's transport domain and 1969 address. If the message cannot be constructed or is 1970 determined to be unforwardable, the snmpProxyDrops [@ref | 1971 v2mib4v2] is | 1972 incremented, a report PDU is generated and sent to the source 1973 of the original request, the received response message is 1974 discarded without further processing, and the cached entry is 1975 deleted. 1977 (3) If the SNMPv2 operation type is either SNMPv2-Trap or Inform, then 1978 the steps are identical to those given above for Get, GetNext, 1979 GetBulk, or Set request operations, except: 1981 a) In step (1), the LCD entries which are consulted to locate the 1982 entry in the proxyForwardingTable are those such that 1983 proxyDirection equals trap(2) or inform(3), respecitively, 1984 instead of gnsb(1). 1986 b) If the operation type is SNMPv2-Trap, a report PDU is never 1987 generated, the request-id need not be remapped, and no values 1988 are cached. 1990 (4) If the SNMPv2 operation type is Report, then the request-id is 1991 extracted from the PDUs portion of the ScopedPDU received from the 1992 authentication and privacy service. The value of request-id is 1993 used to locate a corresponding entry in the cache of outstanding 1994 requests. If the correlation is successful, the appropriate 1995 maintenance function (e.g., time synchronization, proxy error 1996 propagation, etc.) is invoked and the cached entry is deleted. | 1997 Otherwise, the v2AdminStatsCacheMisses counter [@ref v2mib4v2] is | 1998 incremented, and the received message is discarded without further 1999 processing. 2001 If the result of such maintenance procedures determines that a 2002 proxy-forwarded request cannot be delivered to the proxied agent, | 2003 then the snmpProxyDrops counter [14] is incremented | 2004 and a report PDU is generated and transmitted to the transport 2005 address from which the original request was received. (Note that 2006 the receipt of a report PDU containing snmpProxyDrops as a varbind, | 2007 is included among the reasons why a proxy-forwarded request cannot 2008 be delivered.) 2010 4.4. Generating a Response 2012 The procedure for generating a response to a SNMPv2 management request 2013 is identical to the procedure for generating a message (see Section 2014 4.1), with these exceptions: 2016 (1) The response is sent on behalf of the same values for sPI, 2017 identityName, authSnmpID, contextSnmpID, and contextName as were 2018 communicated by the original request. 2020 (2) The PDUs value of the responding SnmpV2Message value is the 2021 response which results from performing the operation specified in 2022 the original PDUs value. The other relevant information is 2023 obtained, not from the LCD, but rather from information cached (in 2024 Step e) when processing the original message. 2026 (3) The serialized Message value is transmitted using the transport 2027 address and transport domain from which its corresponding request 2028 originated - even if that is different from any transport 2029 information obtained from the LCD. 2031 4.5. Report Generation Processing 2033 While processing a received communication, the procedures may result in 2034 a determination that the received message is unacceptable, that an 2035 appropriate counter in the snmp object group of [@ref v2mib4v2] or the | 2036 v2AdminStats object group of [adminmib] be incremented, | 2037 and that a message containing an error report should be generated. 2039 All messages containing an error report sent as a result of the 2040 procedures defined in this memo shall have an sPI value of maint(3). 2042 If possible, the request-id shall have the same value as the request-id 2043 field of the PDU in the message whose processing caused the error 2044 report. Otherwise, the value 2147483647 is used. 2046 The error-status and error-index fields of a report PDU are always set 2047 to zero. 2049 The variable-bindings field contains a single variable: the identity of 2050 the statistics counter which was incremented and its new value. 2052 A report PDU is never sent in response to a report PDU. A protocol 2053 entity makes this determination by examining the reportableFlag of the 2054 received message and only sending report PDUs when the reportableFlag is 2055 set. 2057 Several additional parameters must be provided to the protocol engine to 2058 send the reports. 2060 The identityName is "report". 2062 The authSnmpID and contextSnmpID are set to the value of snmpID for 2063 the local (generating) SNMPv2 entity. 2065 The contextName is set to "default". 2067 The values of contextSnmpID, contextName, and the report PDU are 2068 serialized to produce a ScopedPDU value. 2070 The values of identityName, and authSnmpID are used to build an AuthInfo 2071 structure defined as follows. (The similarity to the structure used by 2072 the usecNoAuth(4) authentication and privacy service [@ref sec] is 2073 intentional to allow shared code paths in typical implementations). 2075 AuthInfo ::= [9] IMPLICIT SEQUENCE { 2077 authSnmpID 2078 OCTET STRING (SIZE(12)), 2080 identityName 2081 OCTET STRING SIZE(6)), -- equal to "report" 2083 pad1 2084 Integer32 (0), 2086 pad2 2087 Integer32 (0) 2089 pad3 2090 OCTET STRING (SIZE(0)) 2091 } 2093 The AuthInfo and ScopedPDU values are serialized to form a 2094 SnmpV2AuthMessage value. 2096 A securityFlags object is built from an sPI value of maint(3) and a 2097 reportableFlag value of false. 2099 The local value of maximum message size for the transport used by the 2100 original message is determined. 2102 An SnmpV2Message is constructed from the maximum message size, 2103 securityFlags, and SnmpV2AuthMessage values. 2105 The resulting message is forwarded to the source of the original 2106 received message. 2108 5. Security Considerations 2110 In order to participate in the administrative model set forth in this 2111 memo, SNMPv2 implementations must support local, non-volatile storage of 2112 the LCD. Accordingly, every attempt has been made to minimize the 2113 amount of non-volatile storage required. 2115 6. Acknowledgements 2117 To be provided here. 2119 7. References 2121 To be provided here. 2123 8. Authors' Addresses 2125 Tell U. Later 2126 snmpv2@tis.com 2128 Table of Contents 2130 1 Introduction .................................................... 4 2131 1.1 A Note on Terminology ......................................... 4 2132 2 Overview ........................................................ 5 2133 2.1 Management Information ........................................ 6 2134 2.2 Contexts ...................................................... 6 2135 2.3 MIB Views ..................................................... 7 2136 2.4 Access Rights ................................................. 8 2137 2.5 Authentication and Privacy .................................... 8 2138 2.6 Security Mechanisms and Algorithms ............................ 9 2139 2.7 Security Protocol Identifiers and the Reportable Flag ......... 9 2140 2.8 Identities and Group Names .................................... 11 2141 2.9 Authorization: Access Control ................................. 12 2142 2.10 Construction of an SNMPv2 Message ............................ 13 2143 2.11 Authentication and Privacy Service ........................... 14 2144 2.12 An SNMPv2 Entity's Local Configuration Datastore ............. 15 2145 2.13 Maintenance Functions ........................................ 16 2146 2.14 Proxy ........................................................ 16 2147 2.15 Transparency Principle ....................................... 18 2148 3 Elements of the Model ........................................... 20 2149 3.1 SNMPv2 Applications ........................................... 20 2150 3.1.1 SNMPv2 Agent ................................................ 20 2151 3.1.2 SNMPv2 Manager .............................................. 20 2152 3.1.3 SNMPv2 Dual-Role Entity ..................................... 20 2153 3.1.4 SNMPv2 Application Layering within the Administrative 2154 Framework .................................................... 22 2155 3.1.5 SNMPv2 Agent Role Applications .............................. 23 2156 3.1.5.1 Local Agent Operations .................................... 24 2157 3.1.5.2 Proxy Forwarding Operations ............................... 24 2158 3.1.5.3 Trap Generation Operations ................................ 24 2159 3.1.5.4 Report Generation Operations .............................. 24 2160 3.1.6 SNMPv2 Manager Role Applications ............................ 25 2161 3.1.6.1 Local Manager Operations .................................. 25 2162 3.1.6.2 Received Notification Operations .......................... 25 2163 3.1.6.3 Notification Generation by Managers ....................... 25 2164 3.1.6.4 Received Report Operations ................................ 25 2165 3.1.6.5 Report Generation by Managers ............................. 25 2166 3.2 SNMPv2 snmpID ................................................. 26 2167 3.3 SNMPv2 Identities ............................................. 28 2168 3.4 SNMPv2 Entity ................................................. 30 2169 3.5 View Subtree and Families ..................................... 30 2170 3.6 MIB View ...................................................... 31 2171 3.7 SNMPv2 Context ................................................ 32 2172 3.7.1 Local SNMPv2 Context ........................................ 33 2173 3.7.2 Proxy SNMPv2 Context ........................................ 33 2174 3.8 SNMPv2 PDUs and Operations .................................... 34 2175 3.9 SNMPv2 Message ................................................ 34 2176 3.10 SNMPv2 Access Control Policy ................................. 36 2177 4 Elements of Procedure ........................................... 37 2178 4.1 Generating a Message .......................................... 37 2179 4.1.1 Data Flow ................................................... 37 2180 4.1.2 Procedure ................................................... 39 2181 4.2 Processing a Received Communication ........................... 40 2182 4.2.1 Data Flow ................................................... 40 2183 4.2.2 Procedure ................................................... 42 2184 4.2.3 Common Constructs ........................................... 46 2185 4.3 Proxy Forwarding Operations ................................... 47 2186 4.4 Generating a Response ......................................... 51 2187 4.5 Report Generation Processing .................................. 51 2188 5 Security Considerations ......................................... 54 2189 6 Acknowledgements ................................................ 54 2190 7 References ...................................................... 54 2191 8 Authors' Addresses .............................................. 55