idnits 2.17.1 draft-ietf-snmpv3-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 227 has weird spacing: '...es with comma...' == Line 915 has weird spacing: '...patcher v ...' -- 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 (21 October 1998) is 9317 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: 'RFC2044' is mentioned on line 1895, but not defined ** Obsolete undefined reference: RFC 2044 (Obsoleted by RFC 2279) == Unused Reference: 'RFC1155' is defined on line 2201, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 2205, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 2211, but no explicit reference was found in the text == Unused Reference: 'RFC1901' is defined on line 2214, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 2218, but no explicit reference was found in the text == Unused Reference: 'RFC1903' is defined on line 2223, but no explicit reference was found in the text == Unused Reference: 'RFC1904' is defined on line 2228, but no explicit reference was found in the text == Unused Reference: 'RFC1906' is defined on line 2238, but no explicit reference was found in the text == Unused Reference: 'RFC1907' is defined on line 2243, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 2248, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 2253, but no explicit reference was found in the text == Unused Reference: 'RFC2279' is defined on line 2259, but no explicit reference was found in the text == Unused Reference: 'BCP-11' is defined on line 2265, but no explicit reference was found in the text == Unused Reference: 'SNMP-MPD' is defined on line 2268, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 2273, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 2277, but no explicit reference was found in the text == Unused Reference: 'SNMP-APPL' is defined on line 2281, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (Obsoleted by RFC 2576) ** Downref: Normative reference to an Historic RFC: RFC 1909 ** Downref: Normative reference to an Historic RFC: RFC 1910 ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2028 (ref. 'BCP-11') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-MPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-USM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-APPL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-INTRO' ** Obsolete normative reference: RFC 2233 (Obsoleted by RFC 2863) Summary: 22 errors (**), 0 flaws (~~), 22 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Harrington 2 Will Obsolete: 2271 Cabletron Systems, Inc. 3 R. Presuhn 4 BMC Software, Inc. 5 B. Wijnen 6 IBM T. J. Watson Research 7 21 October 1998 9 An Architecture for Describing 10 SNMP Management Frameworks 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Copyright Notice 33 Copyright (C) The Internet Society (1998). All Rights Reserved. 35 Abstract 37 This document describes an architecture for describing SNMP 38 Management Frameworks. The architecture is designed to be modular to 39 allow the evolution of the SNMP protocol standards over time. The 40 major portions of the architecture are an SNMP engine containing a 41 Message Processing Subsystem, a Security Subsystem and an Access 42 Control Subsystem, and possibly multiple SNMP applications which 43 provide specific functional processing of management data. 45 Table of Contents 47 1. Introduction ................................................ 5 48 1.1. Overview .................................................. 5 49 1.2. SNMP ...................................................... 5 50 1.3. Goals of this Architecture ................................ 6 51 1.4. Security Requirements of this Architecture ................ 7 52 1.5. Design Decisions .......................................... 8 53 2. Documentation Overview ...................................... 9 54 2.1. Document Roadmap .......................................... 11 55 2.2. Applicability Statement ................................... 11 56 2.3. Coexistence and Transition ................................ 11 57 2.4. Transport Mappings ........................................ 11 58 2.5. Message Processing ........................................ 12 59 2.6. Security .................................................. 12 60 2.7. Access Control ............................................ 12 61 2.8. Protocol Operations ....................................... 13 62 2.9. Applications .............................................. 13 63 2.10. Structure of Management Information ...................... 13 64 2.11. Textual Conventions ...................................... 13 65 2.12. Conformance Statements ................................... 14 66 2.13. Management Information Base Modules ...................... 14 67 2.13.1. SNMP Instrumentation MIBs .............................. 14 68 2.14. SNMP Framework Documents ................................. 14 69 3. Elements of the Architecture ................................ 15 70 3.1. The Naming of Entities .................................... 15 71 3.1.1. SNMP engine ............................................. 16 72 3.1.1.1. snmpEngineID .......................................... 17 73 3.1.1.2. Dispatcher ............................................ 17 74 3.1.1.3. Message Processing Subsystem .......................... 18 75 3.1.1.3.1. Message Processing Model ............................ 18 76 3.1.1.4. Security Subsystem .................................... 19 77 3.1.1.4.1. Security Model ...................................... 19 78 3.1.1.4.2. Security Protocol ................................... 19 79 3.1.2. Access Control Subsystem ................................ 20 80 3.1.2.1. Access Control Model .................................. 20 81 3.1.3. Applications ............................................ 20 82 3.1.3.1. SNMP Manager .......................................... 21 83 3.1.3.2. SNMP Agent ............................................ 22 84 3.2. The Naming of Identities .................................. 23 85 3.2.1. Principal ............................................... 23 86 3.2.2. securityName ............................................ 23 87 3.2.3. Model-dependent security ID ............................. 24 88 3.3. The Naming of Management Information ...................... 25 89 3.3.1. An SNMP Context ......................................... 26 90 3.3.2. contextEngineID ......................................... 26 91 3.3.3. contextName ............................................. 27 92 3.3.4. scopedPDU ............................................... 27 93 3.4. Other Constructs .......................................... 27 94 3.4.1. maxSizeResponseScopedPDU ................................ 27 95 3.4.2. Local Configuration Datastore ........................... 27 96 3.4.3. securityLevel ........................................... 27 97 4. Abstract Service Interfaces ................................. 28 98 4.1. Dispatcher Primitives ..................................... 28 99 4.1.1. Generate Outgoing Request or Notification ............... 28 100 4.1.2. Process Incoming Request or Notification PDU ............ 28 101 4.1.3. Generate Outgoing Response .............................. 30 102 4.1.4. Process Incoming Response PDU ........................... 30 103 4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 30 104 4.2. Message Processing Subsystem Primitives ................... 31 105 4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 31 106 4.2.2. Prepare an Outgoing SNMP Response Message ............... 32 107 4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 33 108 4.3. Access Control Subsystem Primitives ....................... 33 109 4.4. Security Subsystem Primitives ............................. 34 110 4.4.1. Generate a Request or Notification Message .............. 34 111 4.4.2. Process Incoming Message ................................ 34 112 4.4.3. Generate a Response Message ............................. 35 113 4.5. Common Primitives ......................................... 35 114 4.5.1. Release State Reference Information ..................... 35 115 4.6. Scenario Diagrams ......................................... 36 116 4.6.1. Command Generator or Notification Originator ............ 36 117 4.6.2. Scenario Diagram for a Command Responder Application .... 37 118 5. Managed Object Definitions for SNMP Management Frameworks ... 38 119 6. IANA Considerations ......................................... 48 120 6.1. Security Models ........................................... 48 121 6.2. Message Processing Models ................................. 48 122 7. Intellectual Property ....................................... 48 123 8. Acknowledgements ............................................ 49 124 9. Security Considerations ..................................... 50 125 10. References ................................................. 51 126 11. Editor's Addresses ......................................... 54 127 A. Guidelines for Model Designers .............................. 55 128 A.1. Security Model Design Requirements ........................ 55 129 A.1.1. Threats ................................................. 55 130 A.1.2. Security Processing ..................................... 56 131 A.1.3. Validate the security-stamp in a received message ....... 56 132 A.1.4. Security MIBs ........................................... 57 133 A.1.5. Cached Security Data .................................... 57 134 A.2. Message Processing Model Design Requirements .............. 57 135 A.2.1. Receiving an SNMP Message from the Network .............. 58 136 A.2.2. Sending an SNMP Message to the Network .................. 58 137 A.3. Application Design Requirements ........................... 58 138 A.3.1. Applications that Initiate Messages ..................... 59 139 A.3.2. Applications that Receive Responses ..................... 59 140 A.3.3. Applications that Receive Asynchronous Messages ......... 59 141 A.3.4. Applications that Send Responses ........................ 60 142 A.4. Access Control Model Design Requirements .................. 60 143 B. Issues ...................................................... 61 144 B.1. Open Issues ............................................... 61 145 B.2. Change Log ................................................ 61 146 C. Full Copyright Statement .................................... 62 148 1. Introduction 150 1.1. Overview 152 This document defines a vocabulary for describing SNMP Management 153 Frameworks, and an architecture for describing the major portions of 154 SNMP Management Frameworks. 156 This document does not provide a general introduction to SNMP. Other 157 documents and books can provide a much better introduction to SNMP. 158 Nor does this document provide a history of SNMP. That also can be 159 found in books and other documents. 161 Section 1 describes the purpose, goals, and design decisions of this 162 architecture. 164 Section 2 describes various types of documents which define (elements 165 of) SNMP Frameworks, and how they fit into this architecture. It also 166 provides a minimal road map to the documents which have previously 167 defined SNMP frameworks. 169 Section 3 details the vocabulary of this architecture and its pieces. 170 This section is important for understanding the remaining sections, 171 and for understanding documents which are written to fit within this 172 architecture. 174 Section 4 describes the primitives used for the abstract service 175 interfaces between the various subsystems, models and applications 176 within this architecture. 178 Section 5 defines a collection of managed objects used to instrument 179 SNMP entities within this architecture. 181 Sections 6, 7, 8, 9, 10 and 11 are administrative in nature. 183 Appendix A contains guidelines for designers of Models which are 184 expected to fit within this architecture. 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 1.2. SNMP 192 An SNMP management system contains: 194 - several (potentially many) nodes, each with an SNMP entity 195 containing command responder and notification originator 196 applications, which have access to management instrumentation 197 (traditionally called agents); 199 - at least one SNMP entity containing command generator and/or 200 notification receiver applications (traditionally called a 201 manager) and, 203 - a management protocol, used to convey management information 204 between the SNMP entities. 206 SNMP entities executing command generator and notification receiver 207 applications monitor and control managed elements. Managed elements 208 are devices such as hosts, routers, terminal servers, etc., which are 209 monitored and controlled via access to their management information. 211 It is the purpose of this document to define an architecture which 212 can evolve to realize effective management in a variety of 213 configurations and environments. The architecture has been designed 214 to meet the needs of implementations of: 216 - minimal SNMP entities with command responder and/or 217 notification originator applications (traditionally called SNMP 218 agents), 220 - SNMP entities with proxy forwarder applications (traditionally 221 called SNMP proxy agents), 223 - command line driven SNMP entities with command generator and/or 224 notification receiver applications (traditionally called SNMP 225 command line managers), 227 - SNMP entities with command generator and/or notification 228 receiver, plus command responder and/or notification originator 229 applications (traditionally called SNMP mid-level managers or 230 dual-role entities), 232 - SNMP entities with command generator and/or notification 233 receiver and possibly other types of applications for managing 234 a potentially very large number of managed nodes (traditionally 235 called (network) management stations). 237 1.3. Goals of this Architecture 239 This architecture was driven by the following goals: 241 - Use existing materials as much as possible. It is heavily based 242 on previous work, informally known as SNMPv2u and SNMPv2*. 244 - Address the need for secure SET support, which is considered 245 the most important deficiency in SNMPv1 and SNMPv2c. 247 - Make it possible to move portions of the architecture forward 248 in the standards track, even if consensus has not been reached 249 on all pieces. 251 - Define an architecture that allows for longevity of the SNMP 252 Frameworks that have been and will be defined. 254 - Keep SNMP as simple as possible. 256 - Make it relatively inexpensive to deploy a minimal conforming 257 implementation. 259 - Make it possible to upgrade portions of SNMP as new approaches 260 become available, without disrupting an entire SNMP framework. 262 - Make it possible to support features required in large 263 networks, but make the expense of supporting a feature directly 264 related to the support of the feature. 266 1.4. Security Requirements of this Architecture 268 Several of the classical threats to network protocols are applicable 269 to the management problem and therefore would be applicable to any 270 Security Model used in an SNMP Management Framework. Other threats 271 are not applicable to the management problem. This section discusses 272 principal threats, secondary threats, and threats which are of lesser 273 importance. 275 The principal threats against which any Security Model used within 276 this architecture SHOULD provide protection are: 278 Modification of Information 279 The modification threat is the danger that some unauthorized 280 SNMP entity may alter in-transit SNMP messages generated on 281 behalf of an authorized principal in such a way as to effect 282 unauthorized management operations, including falsifying the 283 value of an object. 285 Masquerade 286 The masquerade threat is the danger that management operations 287 not authorized for some principal may be attempted by assuming 288 the identity of another principal that has the appropriate 289 authorizations. 291 Secondary threats against which any Security Model used within this 292 architecture SHOULD provide protection are: 294 Message Stream Modification 295 The SNMP protocol is typically based upon a connectionless 296 transport service which may operate over any subnetwork 297 service. The re-ordering, delay or replay of messages can and 298 does occur through the natural operation of many such 299 subnetwork services. The message stream modification threat is 300 the danger that messages may be maliciously re-ordered, delayed 301 or replayed to an extent which is greater than can occur 302 through the natural operation of a subnetwork service, in order 303 to effect unauthorized management operations. 305 Disclosure 306 The disclosure threat is the danger of eavesdropping on the 307 exchanges between SNMP engines. Protecting against this threat 308 may be required as a matter of local policy. 310 There are at least two threats against which a Security Model within 311 this architecture need not protect, since they are deemed to be of 312 lesser importance in this context: 314 Denial of Service 315 A Security Model need not attempt to address the broad range of 316 attacks by which service on behalf of authorized users is 317 denied. Indeed, such denial-of-service attacks are in many 318 cases indistinguishable from the type of network failures with 319 which any viable management protocol must cope as a matter of 320 course. 322 Traffic Analysis 323 A Security Model need not attempt to address traffic analysis 324 attacks. Many traffic patterns are predictable - entities may 325 be managed on a regular basis by a relatively small number of 326 management stations - and therefore there is no significant 327 advantage afforded by protecting against traffic analysis. 329 1.5. Design Decisions 331 Various design decisions were made in support of the goals of the 332 architecture and the security requirements: 334 - Architecture 335 An architecture should be defined which identifies the 336 conceptual boundaries between the documents. Subsystems should 337 be defined which describe the abstract services provided by 338 specific portions of an SNMP framework. Abstract service 339 interfaces, as described by service primitives, define the 340 abstract boundaries between documents, and the abstract 341 services that are provided by the conceptual subsystems of an 342 SNMP framework. 344 - Self-contained Documents 345 Elements of procedure plus the MIB objects which are needed for 346 processing for a specific portion of an SNMP framework should 347 be defined in the same document, and as much as possible, 348 should not be referenced in other documents. This allows pieces 349 to be designed and documented as independent and self-contained 350 parts, which is consistent with the general SNMP MIB module 351 approach. As portions of SNMP change over time, the documents 352 describing other portions of SNMP are not directly impacted. 353 This modularity allows, for example, Security Models, 354 authentication and privacy mechanisms, and message formats to 355 be upgraded and supplemented as the need arises. The self- 356 contained documents can move along the standards track on 357 different time-lines. 359 - Threats 360 The Security Models in the Security Subsystem SHOULD protect 361 against the principal threats: modification of information, 362 masquerade, message stream modification and disclosure. They 363 do not need to protect against denial of service and traffic 364 analysis. 366 - Remote Configuration 367 The Security and Access Control Subsystems add a whole new set 368 of SNMP configuration parameters. The Security Subsystem also 369 requires frequent changes of secrets at the various SNMP 370 entities. To make this deployable in a large operational 371 environment, these SNMP parameters must be remotely 372 configurable. 374 - Controlled Complexity 375 It is recognized that producers of simple managed devices want 376 to keep the resources used by SNMP to a minimum. At the same 377 time, there is a need for more complex configurations which can 378 spend more resources for SNMP and thus provide more 379 functionality. The design tries to keep the competing 380 requirements of these two environments in balance and allows 381 the more complex environments to logically extend the simple 382 environment. 384 2. Documentation Overview 386 The following figure shows the set of documents that fit within the 387 SNMP Architecture. 389 +------------------------- Document Set ----------------------------+ 390 | | 391 | +----------+ +-----------------+ +----------------+ | 392 | | Document | | Applicability * | | Coexistence * | | 393 | | Roadmap | | Statement | | & Transition | | 394 | +----------+ +-----------------+ +----------------+ | 395 | | 396 | +---------------------------------------------------------------+ | 397 | | Message Handling | | 398 | | +----------------+ +-----------------+ +-----------------+ | | 399 | | | Transport | | Message | | Security | | | 400 | | | Mappings | | Processing and | | | | | 401 | | | | | Dispatcher | | | | | 402 | | +----------------+ +-----------------+ +-----------------+ | | 403 | +---------------------------------------------------------------+ | 404 | | 405 | +---------------------------------------------------------------+ | 406 | | PDU Handling | | 407 | | +----------------+ +-----------------+ +-----------------+ | | 408 | | | Protocol | | Applications | | Access | | | 409 | | | Operations | | | | Control | | | 410 | | +----------------+ +-----------------+ +-----------------+ | | 411 | +---------------------------------------------------------------+ | 412 | | 413 | +---------------------------------------------------------------+ | 414 | | Information Model | | 415 | | +--------------+ +--------------+ +---------------+ | | 416 | | | Structure of | | Textual | | Conformance | | | 417 | | | Management | | Conventions | | Statements | | | 418 | | | Information | | | | | | | 419 | | +--------------+ +--------------+ +---------------+ | | 420 | +---------------------------------------------------------------+ | 421 | | 422 | +---------------------------------------------------------------+ | 423 | | MIBs | | 424 | | +-------------+ +-------------+ +----------+ +----------+ | | 425 | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | | 426 | | | RFC1157 | | RFC1212 | | RFC14xx | | RFC19xx | | | 427 | | | format | | format | | format | | format | | | 428 | | +-------------+ +-------------+ +----------+ +----------+ | | 429 | +---------------------------------------------------------------+ | 430 | | 431 +-------------------------------------------------------------------+ 433 Those marked with an asterisk (*) are expected to be written in the 434 future. Each of these documents may be replaced or supplemented. 435 This Architecture document specifically describes how new documents 436 fit into the set of documents in the area of Message and PDU 437 handling. 439 2.1. Document Roadmap 441 One or more documents may be written to describe how sets of 442 documents taken together form specific Frameworks. The configuration 443 of document sets might change over time, so the "road map" should be 444 maintained in a document separate from the standards documents 445 themselves. 447 An example of such a roadmap is "Introduction to Version 3 of the 448 Internet-standard Network Management Framework" [SNMP-INTRO]. 450 2.2. Applicability Statement 452 SNMP is used in networks that vary widely in size and complexity, by 453 organizations that vary widely in their requirements of management. 454 Some models will be designed to address specific problems of 455 management, such as message security. 457 One or more documents may be written to describe the environments to 458 which certain versions of SNMP or models within SNMP would be 459 appropriately applied, and those to which a given model might be 460 inappropriately applied. 462 2.3. Coexistence and Transition 464 The purpose of an evolutionary architecture is to permit new models 465 to replace or supplement existing models. The interactions between 466 models could result in incompatibilities, security "holes", and other 467 undesirable effects. 469 The purpose of Coexistence documents is to detail recognized 470 anomalies and to describe required and recommended behaviors for 471 resolving the interactions between models within the architecture. 473 Coexistence documents may be prepared separately from model 474 definition documents, to describe and resolve interaction anomalies 475 between a model definition and one or more other model definitions. 477 Additionally, recommendations for transitions between models may also 478 be described, either in a coexistence document or in a separate 479 document. 481 2.4. Transport Mappings 483 SNMP messages are sent over various transports. It is the purpose of 484 Transport Mapping documents to define how the mapping between SNMP 485 and the transport is done. 487 2.5. Message Processing 489 A Message Processing Model document defines a message format, which 490 is typically identified by a version field in an SNMP message header. 491 The document may also define a MIB module for use in message 492 processing and for instrumentation of version-specific interactions. 494 An SNMP engine includes one or more Message Processing Models, and 495 thus may support sending and receiving multiple versions of SNMP 496 messages. 498 2.6. Security 500 Some environments require secure protocol interactions. Security is 501 normally applied at two different stages: 503 - in the transmission/receipt of messages, and 505 - in the processing of the contents of messages. 507 For purposes of this document, "security" refers to message-level 508 security; "access control" refers to the security applied to protocol 509 operations. 511 Authentication, encryption, and timeliness checking are common 512 functions of message level security. 514 A security document describes a Security Model, the threats against 515 which the model protects, the goals of the Security Model, the 516 protocols which it uses to meet those goals, and it may define a MIB 517 module to describe the data used during processing, and to allow the 518 remote configuration of message-level security parameters, such as 519 keys. 521 An SNMP engine may support multiple Security Models concurrently. 523 2.7. Access Control 525 During processing, it may be required to control access to managed 526 objects for operations. 528 An Access Control Model defines mechanisms to determine whether 529 access to a managed object should be allowed. An Access Control 530 Model may define a MIB module used during processing and to allow the 531 remote configuration of access control policies. 533 2.8. Protocol Operations 535 SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). It is the 536 purpose of a Protocol Operations document to define the operations of 537 the protocol with respect to the processing of the PDUs. 539 An application document defines which Protocol Operations documents 540 are supported by the application. 542 2.9. Applications 544 An SNMP entity normally includes a number of applications. 545 Applications use the services of an SNMP engine to accomplish 546 specific tasks. They coordinate the processing of management 547 information operations, and may use SNMP messages to communicate with 548 other SNMP entities. 550 Applications documents describe the purpose of an application, the 551 services required of the associated SNMP engine, and the protocol 552 operations and informational model that the application uses to 553 perform management operations. 555 An application document defines which set of documents are used to 556 specifically define the structure of management information, textual 557 conventions, conformance requirements, and operations supported by 558 the application. 560 2.10. Structure of Management Information 562 Management information is viewed as a collection of managed objects, 563 residing in a virtual information store, termed the Management 564 Information Base (MIB). Collections of related objects are defined in 565 MIB modules. 567 It is the purpose of a Structure of Management Information document 568 to establish the syntax for defining objects, modules, and other 569 elements of managed information. 571 2.11. Textual Conventions 573 When designing a MIB module, it is often useful to define new types 574 similar to those defined in the SMI, but with more precise semantics, 575 or which have special semantics associated with them. These newly 576 defined types are termed textual conventions, and may be defined in 577 separate documents, or within a MIB module. 579 2.12. Conformance Statements 581 It may be useful to define the acceptable lower-bounds of 582 implementation, along with the actual level of implementation 583 achieved. It is the purpose of the Conformance Statements document to 584 define the notation used for these purposes. 586 2.13. Management Information Base Modules 588 MIB documents describe collections of managed objects which 589 instrument some aspect of a managed node. 591 2.13.1. SNMP Instrumentation MIBs 593 An SNMP MIB document may define a collection of managed objects which 594 instrument the SNMP protocol itself. In addition, MIB modules may be 595 defined within the documents which describe portions of the SNMP 596 architecture, such as the documents for Message processing Models, 597 Security Models, etc. for the purpose of instrumenting those Models, 598 and for the purpose of allowing remote configuration of the Model. 600 2.14. SNMP Framework Documents 602 This architecture is designed to allow an orderly evolution of 603 portions of SNMP Frameworks. 605 Throughout the rest of this document, the term "subsystem" refers to 606 an abstract and incomplete specification of a portion of a Framework, 607 that is further refined by a model specification. 609 A "model" describes a specific design of a subsystem, defining 610 additional constraints and rules for conformance to the model. A 611 model is sufficiently detailed to make it possible to implement the 612 specification. 614 An "implementation" is an instantiation of a subsystem, conforming to 615 one or more specific models. 617 SNMP version 1 (SNMPv1), is the original Internet-standard Network 618 Management Framework, as described in RFCs 1155, 1157, and 1212. 620 SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the 621 SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no 622 message definition. 624 The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP 625 Framework which supplements the SNMPv2 Framework, as described in 626 RFC1901. It adds the SNMPv2c message format, which is similar to the 627 SNMPv1 message format. 629 SNMP version 3 (SNMPv3), is an extensible SNMP Framework which 630 supplements the SNMPv2 Framework, by supporting the following: 632 - a new SNMP message format, 634 - Security for Messages, 636 - Access Control, and 638 - Remote configuration of SNMP parameters. 640 Other SNMP Frameworks, i.e., other configurations of implemented 641 subsystems, are expected to also be consistent with this 642 architecture. 644 3. Elements of the Architecture 646 This section describes the various elements of the architecture and 647 how they are named. There are three kinds of naming: 649 1) the naming of entities, 651 2) the naming of identities, and 653 3) the naming of management information. 655 This architecture also defines some names for other constructs that 656 are used in the documentation. 658 3.1. The Naming of Entities 660 An SNMP entity is an implementation of this architecture. Each such 661 SNMP entity consists of an SNMP engine and one or more associated 662 applications. 664 The following figure shows details about an SNMP entity and the 665 components within it. 667 +-------------------------------------------------------------------+ 668 | SNMP entity | 669 | | 670 | +-------------------------------------------------------------+ | 671 | | SNMP engine (identified by snmpEngineID) | | 672 | | | | 673 | | +------------+ +------------+ +-----------+ +-----------+ | | 674 | | | | | | | | | | | | 675 | | | Dispatcher | | Message | | Security | | Access | | | 676 | | | | | Processing | | Subsystem | | Control | | | 677 | | | | | Subsystem | | | | Subsystem | | | 678 | | | | | | | | | | | | 679 | | +------------+ +------------+ +-----------+ +-----------+ | | 680 | | | | 681 | +-------------------------------------------------------------+ | 682 | | 683 | +-------------------------------------------------------------+ | 684 | | Application(s) | | 685 | | | | 686 | | +-------------+ +--------------+ +--------------+ | | 687 | | | Command | | Notification | | Proxy | | | 688 | | | Generator | | Receiver | | Forwarder | | | 689 | | +-------------+ +--------------+ +--------------+ | | 690 | | | | 691 | | +-------------+ +--------------+ +--------------+ | | 692 | | | Command | | Notification | | Other | | | 693 | | | Responder | | Originator | | | | | 694 | | +-------------+ +--------------+ +--------------+ | | 695 | | | | 696 | +-------------------------------------------------------------+ | 697 | | 698 +-------------------------------------------------------------------+ 700 3.1.1. SNMP engine 702 An SNMP engine provides services for sending and receiving messages, 703 authenticating and encrypting messages, and controlling access to 704 managed objects. There is a one-to-one association between an SNMP 705 engine and the SNMP entity which contains it. 707 The engine contains: 709 1) a Dispatcher, 711 2) a Message Processing Subsystem, 713 3) a Security Subsystem, and 714 4) an Access Control Subsystem. 716 3.1.1.1. snmpEngineID 718 Within an administrative domain, an snmpEngineID is the unique and 719 unambiguous identifier of an SNMP engine. Since there is a one-to-one 720 association between SNMP engines and SNMP entities, it also uniquely 721 and unambiguously identifies the SNMP entity. 723 3.1.1.2. Dispatcher 725 There is only one Dispatcher in an SNMP engine. It allows for 726 concurrent support of multiple versions of SNMP messages in the SNMP 727 engine. It does so by: 729 - sending and receiving SNMP messages to/from the network, 731 - determining the version of an SNMP message and interacting with 732 the corresponding Message Processing Model, 734 - providing an abstract interface to SNMP applications for 735 delivery of a PDU to an application. 737 - providing an abstract interface for SNMP applications that 738 allows them to send a PDU to a remote SNMP entity. 740 3.1.1.3. Message Processing Subsystem 742 The Message Processing Subsystem is responsible for preparing 743 messages for sending, and extracting data from received messages. 745 The Message Processing Subsystem potentially contains multiple 746 Message Processing Models as shown in the next figure. 748 * One or more Message Processing Models may be present. 750 +------------------------------------------------------------------+ 751 | | 752 | Message Processing Subsystem | 753 | | 754 | +------------+ +------------+ +------------+ +------------+ | 755 | | * | | * | | * | | * | | 756 | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | 757 | | Message | | Message | | Message | | Message | | 758 | | Processing | | Processing | | Processing | | Processing | | 759 | | Model | | Model | | Model | | Model | | 760 | | | | | | | | | | 761 | +------------+ +------------+ +------------+ +------------+ | 762 | | 763 +------------------------------------------------------------------+ 765 3.1.1.3.1. Message Processing Model 767 Each Message Processing Model defines the format of a particular 768 version of an SNMP message and coordinates the preparation and 769 extraction of each such version-specific message format. 771 3.1.1.4. Security Subsystem 773 The Security Subsystem provides security services such as the 774 authentication and privacy of messages and potentially contains 775 multiple Security Models as shown in the following figure 777 * One or more Security Models may be present. 779 +------------------------------------------------------------------+ 780 | | 781 | Security Subsystem | 782 | | 783 | +----------------+ +-----------------+ +-------------------+ | 784 | | * | | * | | * | | 785 | | User-Based | | Other | | Other | | 786 | | Security | | Security | | Security | | 787 | | Model | | Model | | Model | | 788 | | | | | | | | 789 | +----------------+ +-----------------+ +-------------------+ | 790 | | 791 +------------------------------------------------------------------+ 793 3.1.1.4.1. Security Model 795 A Security Model defines the threats against which it protects, the 796 goals of its services, and the security protocols used to provide 797 security services such as authentication and privacy. 799 3.1.1.4.2. Security Protocol 801 A Security Protocol defines the mechanisms, procedures, and MIB data 802 used to provide a security service such as authentication or privacy. 804 3.1.2. Access Control Subsystem 806 The Access Control Subsystem provides authorization services by means 807 of one or more (*) Access Control Models. 809 +------------------------------------------------------------------+ 810 | | 811 | Access Control Subsystem | 812 | | 813 | +---------------+ +-----------------+ +------------------+ | 814 | | * | | * | | * | | 815 | | View-Based | | Other | | Other | | 816 | | Access | | Access | | Access | | 817 | | Control | | Control | | Control | | 818 | | Model | | Model | | Model | | 819 | | | | | | | | 820 | +---------------+ +-----------------+ +------------------+ | 821 | | 822 +------------------------------------------------------------------+ 824 3.1.2.1. Access Control Model 826 An Access Control Model defines a particular access decision function 827 in order to support decisions regarding access rights. 829 3.1.3. Applications 831 There are several types of applications, including: 833 - command generators, which monitor and manipulate management 834 data, 836 - command responders, which provide access to management data, 838 - notification originators, which initiate asynchronous messages, 840 - notification receivers, which process asynchronous messages, 841 and 843 - proxy forwarders, which forward messages between entities. 845 These applications make use of the services provided by the SNMP 846 engine. 848 3.1.3.1. SNMP Manager 850 An SNMP entity containing one or more command generator and/or 851 notification receiver applications (along with their associated SNMP 852 engine) has traditionally been called an SNMP manager. 853 * One or more models may be present. 855 (traditional SNMP manager) 856 +-------------------------------------------------------------------+ 857 | +--------------+ +--------------+ +--------------+ SNMP entity | 858 | | NOTIFICATION | | NOTIFICATION | | COMMAND | | 859 | | ORIGINATOR | | RECEIVER | | GENERATOR | | 860 | | applications | | applications | | applications | | 861 | +--------------+ +--------------+ +--------------+ | 862 | ^ ^ ^ | 863 | | | | | 864 | v v v | 865 | +-------+--------+-----------------+ | 866 | ^ | 867 | | +---------------------+ +----------------+ | 868 | | | Message Processing | | Security | | 869 | Dispatcher v | Subsystem | | Subsystem | | 870 | +-------------------+ | +------------+ | | | | 871 | | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | | 872 | | | | | +------------+ | | | Other | | | 873 | | | | | +------------+ | | | Security | | | 874 | | | | +->| v2cMP * |<--->| | Model | | | 875 | | Message | | | +------------+ | | +------------+ | | 876 | | Dispatcher <--------->+ | | | | 877 | | | | | +------------+ | | +------------+ | | 878 | | | | +->| v3MP * |<--->| | User-based | | | 879 | | Transport | | | +------------+ | | | Security | | | 880 | | Mapping | | | +------------+ | | | Model | | | 881 | | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | | 882 | +-------------------+ | +------------+ | | | | 883 | ^ +---------------------+ +----------------+ | 884 | | | 885 | v | 886 +-------------------------------------------------------------------+ 887 +-----+ +-----+ +-------+ 888 | UDP | | IPX | . . . | other | 889 +-----+ +-----+ +-------+ 890 ^ ^ ^ 891 | | | 892 v v v 893 +------------------------------+ 894 | Network | 895 +------------------------------+ 897 3.1.3.2. SNMP Agent 899 An SNMP entity containing one or more command responder and/or 900 notification originator applications (along with their associated 901 SNMP engine) has traditionally been called an SNMP agent. 902 +------------------------------+ 903 | Network | 904 +------------------------------+ 905 ^ ^ ^ 906 | | | 907 v v v 908 +-----+ +-----+ +-------+ 909 | UDP | | IPX | . . . | other | 910 +-----+ +-----+ +-------+ (traditional SNMP agent) 911 +-------------------------------------------------------------------+ 912 | ^ | 913 | | +---------------------+ +----------------+ | 914 | | | Message Processing | | Security | | 915 | Dispatcher v | Subsystem | | Subsystem | | 916 | +-------------------+ | +------------+ | | | | 917 | | Transport | | +->| v1MP * |<--->| +------------+ | | 918 | | Mapping | | | +------------+ | | | Other | | | 919 | | (e.g. RFC1906) | | | +------------+ | | | Security | | | 920 | | | | +->| v2cMP * |<--->| | Model | | | 921 | | Message | | | +------------+ | | +------------+ | | 922 | | Dispatcher <--------->| +------------+ | | +------------+ | | 923 | | | | +->| v3MP * |<--->| | User-based | | | 924 | | | | | +------------+ | | | Security | | | 925 | | PDU Dispatcher | | | +------------+ | | | Model | | | 926 | +-------------------+ | +->| otherMP * |<--->| +------------+ | | 927 | ^ | +------------+ | | | | 928 | | +---------------------+ +----------------+ | 929 | v | 930 | +-------+-------------------------+---------------+ | 931 | ^ ^ ^ | 932 | | | | | 933 | v v v | 934 | +-------------+ +---------+ +--------------+ +-------------+ | 935 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | | 936 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 937 | | application | | | | applications | | application | | 938 | +-------------+ +---------+ +--------------+ +-------------+ | 939 | ^ ^ | 940 | | | | 941 | v v | 942 | +----------------------------------------------+ | 943 | | MIB instrumentation | SNMP entity | 944 +-------------------------------------------------------------------+ 946 3.2. The Naming of Identities 948 principal 949 ^ 950 | 951 | 952 +----------------------------|-------------+ 953 | SNMP engine v | 954 | +--------------+ | 955 | | | | 956 | +-----------------| securityName |---+ | 957 | | Security Model | | | | 958 | | +--------------+ | | 959 | | ^ | | 960 | | | | | 961 | | v | | 962 | | +------------------------------+ | | 963 | | | | | | 964 | | | Model | | | 965 | | | Dependent | | | 966 | | | Security ID | | | 967 | | | | | | 968 | | +------------------------------+ | | 969 | | ^ | | 970 | | | | | 971 | +-------------------------|----------+ | 972 | | | 973 | | | 974 +----------------------------|-------------+ 975 | 976 v 977 network 979 3.2.1. Principal 981 A principal is the "who" on whose behalf services are provided or 982 processing takes place. 984 A principal can be, among other things, an individual acting in a 985 particular role; a set of individuals, with each acting in a 986 particular role; an application or a set of applications; and 987 combinations thereof. 989 3.2.2. securityName 991 A securityName is a human readable string representing a principal. 992 It has a model-independent format, and can be used outside a 993 particular Security Model. 995 3.2.3. Model-dependent security ID 997 A model-dependent security ID is the model-specific representation of 998 a securityName within a particular Security Model. 1000 Model-dependent security IDs may or may not be human readable, and 1001 have a model-dependent syntax. Examples include community names, user 1002 names, and parties. 1004 The transformation of model-dependent security IDs into securityNames 1005 and vice versa is the responsibility of the relevant Security Model. 1007 3.3. The Naming of Management Information 1009 Management information resides at an SNMP entity where a Command 1010 Responder Application has local access to potentially multiple 1011 contexts. This application uses a contextEngineID equal to the 1012 snmpEngineID of its associated SNMP engine. 1014 +-----------------------------------------------------------------+ 1015 | SNMP entity (identified by snmpEngineID, example: abcd) | 1016 | | 1017 | +------------------------------------------------------------+ | 1018 | | SNMP engine (identified by snmpEngineID) | | 1019 | | | | 1020 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1021 | | | | | | | | | | | | 1022 | | | Dispatcher | | Message | | Security | | Access | | | 1023 | | | | | Processing | | Subsystem | | Control | | | 1024 | | | | | Subsystem | | | | Subsystem | | | 1025 | | | | | | | | | | | | 1026 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1027 | | | | 1028 | +------------------------------------------------------------+ | 1029 | | 1030 | +------------------------------------------------------------+ | 1031 | | Command Responder Application | | 1032 | | (contextEngineID, example: abcd) | | 1033 | | | | 1034 | | example contextNames: | | 1035 | | | | 1036 | | "bridge1" "bridge2" "" (default) | | 1037 | | --------- --------- ------------ | | 1038 | | | | | | | 1039 | +------|------------------|-------------------|--------------+ | 1040 | | | | | 1041 | +------|------------------|-------------------|--------------+ | 1042 | | MIB | instrumentation | | | | 1043 | | +---v------------+ +---v------------+ +----v-----------+ | | 1044 | | | context | | context | | context | | | 1045 | | | | | | | | | | 1046 | | | +------------+ | | +------------+ | | +------------+ | | | 1047 | | | | bridge MIB | | | | bridge MIB | | | | other MIB | | | | 1048 | | | +------------+ | | +------------+ | | +------------+ | | | 1049 | | | | | | | | | | 1050 | | | | | | | +------------+ | | | 1051 | | | | | | | | some MIB | | | | 1052 | | | | | | | +------------+ | | | 1053 | | | | | | | | | | 1054 +-----------------------------------------------------------------+ 1056 3.3.1. An SNMP Context 1058 An SNMP context, or just "context" for short, is a collection of 1059 management information accessible by an SNMP entity. An item of 1060 management information may exist in more than one context. An SNMP 1061 entity potentially has access to many contexts. 1063 Typically, there are many instances of each managed object type 1064 within a management domain. For simplicity, the method for 1065 identifying instances specified by the MIB module does not allow each 1066 instance to be distinguished amongst the set of all instances within 1067 a management domain; rather, it allows each instance to be identified 1068 only within some scope or "context", where there are multiple such 1069 contexts within the management domain. Often, a context is a 1070 physical device, or perhaps, a logical device, although a context can 1071 also encompass multiple devices, or a subset of a single device, or 1072 even a subset of multiple devices, but a context is always defined as 1073 a subset of a single SNMP entity. Thus, in order to identify an 1074 individual item of management information within the management 1075 domain, its contextName and contextEngineID must be identified in 1076 addition to its object type and its instance. 1078 For example, the managed object type ifDescr [RFC2233], is defined as 1079 the description of a network interface. To identify the description 1080 of device-X's first network interface, four pieces of information are 1081 needed: the snmpEngineID of the SNMP entity which provides access to 1082 the management information at device-X, the contextName (device-X), 1083 the managed object type (ifDescr), and the instance ("1"). 1085 Each context has (at least) one unique identification within the 1086 management domain. The same item of management information can exist 1087 in multiple contexts. An item of management information may have 1088 multiple unique identifications. This occurs when an item of 1089 management information exists in multiple contexts, and this also 1090 occurs when a context has multiple unique identifications. 1092 The combination of a contextEngineID and a contextName unambiguously 1093 identifies a context within an administrative domain; note that there 1094 may be multiple unique combinations of contextEngineID and 1095 contextName that unambiguously identify the same context. 1097 3.3.2. contextEngineID 1099 Within an administrative domain, a contextEngineID uniquely 1100 identifies an SNMP entity that may realize an instance of a context 1101 with a particular contextName. 1103 3.3.3. contextName 1105 A contextName is used to name a context. Each contextName MUST be 1106 unique within an SNMP entity. 1108 3.3.4. scopedPDU 1110 A scopedPDU is a block of data containing a contextEngineID, a 1111 contextName, and a PDU. 1113 The PDU is an SNMP Protocol Data Unit containing information named in 1114 the context which is unambiguously identified within an 1115 administrative domain by the combination of the contextEngineID and 1116 the contextName. See, for example, RFC1905 for more information about 1117 SNMP PDUs. 1119 3.4. Other Constructs 1121 3.4.1. maxSizeResponseScopedPDU 1123 The maxSizeResponseScopedPDU is the maximum size of a scopedPDU to be 1124 included in a response message. Note that the size of a scopedPDU 1125 does not include the size of the SNMP message header. 1127 3.4.2. Local Configuration Datastore 1129 The subsystems, models, and applications within an SNMP entity may 1130 need to retain their own sets of configuration information. 1132 Portions of the configuration information may be accessible as 1133 managed objects. 1135 The collection of these sets of information is referred to as an 1136 entity's Local Configuration Datastore (LCD). 1138 3.4.3. securityLevel 1140 This architecture recognizes three levels of security: 1142 - without authentication and without privacy (noAuthNoPriv) 1144 - with authentication but without privacy (authNoPriv) 1146 - with authentication and with privacy (authPriv) 1148 These three values are ordered such that noAuthNoPriv is less than 1149 authNoPriv and authNoPriv is less than authPriv. 1151 Every message has an associated securityLevel. All Subsystems 1152 (Message Processing, Security, Access Control) and applications are 1153 REQUIRED to either supply a value of securityLevel or to abide by the 1154 supplied value of securityLevel while processing the message and its 1155 contents. 1157 4. Abstract Service Interfaces 1159 Abstract service interfaces have been defined to describe the 1160 conceptual interfaces between the various subsystems within an SNMP 1161 entity. 1163 These abstract service interfaces are defined by a set of primitives 1164 that define the services provided and the abstract data elements that 1165 are to be passed when the services are invoked. This section lists 1166 the primitives that have been defined for the various subsystems. 1168 4.1. Dispatcher Primitives 1170 The Dispatcher typically provides services to the SNMP applications 1171 via its PDU Dispatcher. This section describes the primitives 1172 provided by the PDU Dispatcher. 1174 4.1.1. Generate Outgoing Request or Notification 1176 The PDU Dispatcher provides the following primitive for an 1177 application to send an SNMP Request or Notification to another SNMP 1178 entity: 1180 statusInformation = -- sendPduHandle if success 1181 -- errorIndication if failure 1182 sendPdu( 1183 IN transportDomain -- transport domain to be used 1184 IN transportAddress -- transport address to be used 1185 IN messageProcessingModel -- typically, SNMP version 1186 IN securityModel -- Security Model to use 1187 IN securityName -- on behalf of this principal 1188 IN securityLevel -- Level of Security requested 1189 IN contextEngineID -- data from/at this entity 1190 IN contextName -- data from/in this context 1191 IN pduVersion -- the version of the PDU 1192 IN PDU -- SNMP Protocol Data Unit 1193 IN expectResponse -- TRUE or FALSE 1194 ) 1196 4.1.2. Process Incoming Request or Notification PDU 1198 The PDU Dispatcher provides the following primitive to pass an 1199 incoming SNMP PDU to an application: 1201 processPdu( -- process Request/Notification PDU 1202 IN messageProcessingModel -- typically, SNMP version 1203 IN securityModel -- Security Model in use 1204 IN securityName -- on behalf of this principal 1205 IN securityLevel -- Level of Security 1206 IN contextEngineID -- data from/at this SNMP entity 1207 IN contextName -- data from/in this context 1208 IN pduVersion -- the version of the PDU 1209 IN PDU -- SNMP Protocol Data Unit 1210 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1211 IN stateReference -- reference to state information 1212 ) -- needed when sending a response 1214 4.1.3. Generate Outgoing Response 1216 The PDU Dispatcher provides the following primitive for an 1217 application to return an SNMP Response PDU to the PDU Dispatcher: 1219 returnResponsePdu( 1220 IN messageProcessingModel -- typically, SNMP version 1221 IN securityModel -- Security Model in use 1222 IN securityName -- on behalf of this principal 1223 IN securityLevel -- same as on incoming request 1224 IN contextEngineID -- data from/at this SNMP entity 1225 IN contextName -- data from/in this context 1226 IN pduVersion -- the version of the PDU 1227 IN PDU -- SNMP Protocol Data Unit 1228 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1229 IN stateReference -- reference to state information 1230 -- as presented with the request 1231 IN statusInformation -- success or errorIndication 1232 ) -- error counter OID/value if error 1234 4.1.4. Process Incoming Response PDU 1236 The PDU Dispatcher provides the following primitive to pass an 1237 incoming SNMP Response PDU to an application: 1239 processResponsePdu( -- process Response PDU 1240 IN messageProcessingModel -- typically, SNMP version 1241 IN securityModel -- Security Model in use 1242 IN securityName -- on behalf of this principal 1243 IN securityLevel -- Level of Security 1244 IN contextEngineID -- data from/at this SNMP entity 1245 IN contextName -- data from/in this context 1246 IN pduVersion -- the version of the PDU 1247 IN PDU -- SNMP Protocol Data Unit 1248 IN statusInformation -- success or errorIndication 1249 IN sendPduHandle -- handle from sendPdu 1250 ) 1252 4.1.5. Registering Responsibility for Handling SNMP PDUs 1254 Applications can register/unregister responsibility for a specific 1255 contextEngineID, for specific pduTypes, with the PDU Dispatcher 1256 according to the following primitives. The list of particular 1257 pduTypes that an application can register for is determined by the 1258 Message Processing Model(s) supported by the SNMP entity that 1259 contains the PDU Dispatcher. 1261 statusInformation = -- success or errorIndication 1262 registerContextEngineID( 1263 IN contextEngineID -- take responsibility for this one 1264 IN pduType -- the pduType(s) to be registered 1265 ) 1267 unregisterContextEngineID( 1268 IN contextEngineID -- give up responsibility for this one 1269 IN pduType -- the pduType(s) to be unregistered 1270 ) 1272 Note that realizations of the registerContextEngineID and 1273 unregisterContextEngineID abstract service interfaces may provide 1274 implementation-specific ways for applications to register/deregister 1275 responsiblity for all possible values of the contextEngineID or 1276 pduType parameters. 1278 4.2. Message Processing Subsystem Primitives 1280 The Dispatcher interacts with a Message Processing Model to process a 1281 specific version of an SNMP Message. This section describes the 1282 primitives provided by the Message Processing Subsystem. 1284 4.2.1. Prepare Outgoing SNMP Request or Notification Message 1286 The Message Processing Subsystem provides this service primitive for 1287 preparing an outgoing SNMP Request or Notification Message: 1289 statusInformation = -- success or errorIndication 1290 prepareOutgoingMessage( 1291 IN transportDomain -- transport domain to be used 1292 IN transportAddress -- transport address to be used 1293 IN messageProcessingModel -- typically, SNMP version 1294 IN securityModel -- Security Model to use 1295 IN securityName -- on behalf of this principal 1296 IN securityLevel -- Level of Security requested 1297 IN contextEngineID -- data from/at this entity 1298 IN contextName -- data from/in this context 1299 IN pduVersion -- the version of the PDU 1300 IN PDU -- SNMP Protocol Data Unit 1301 IN expectResponse -- TRUE or FALSE 1302 IN sendPduHandle -- the handle for matching 1303 -- incoming responses 1304 OUT destTransportDomain -- destination transport domain 1305 OUT destTransportAddress -- destination transport address 1306 OUT outgoingMessage -- the message to send 1307 OUT outgoingMessageLength -- its length 1308 ) 1310 4.2.2. Prepare an Outgoing SNMP Response Message 1312 The Message Processing Subsystem provides this service primitive for 1313 preparing an outgoing SNMP Response Message: 1315 result = -- SUCCESS or FAILURE 1316 prepareResponseMessage( 1317 IN messageProcessingModel -- typically, SNMP version 1318 IN securityModel -- same as on incoming request 1319 IN securityName -- same as on incoming request 1320 IN securityLevel -- same as on incoming request 1321 IN contextEngineID -- data from/at this SNMP entity 1322 IN contextName -- data from/in this context 1323 IN pduVersion -- the version of the PDU 1324 IN PDU -- SNMP Protocol Data Unit 1325 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1326 IN stateReference -- reference to state information 1327 -- as presented with the request 1328 IN statusInformation -- success or errorIndication 1329 -- error counter OID/value if error 1330 OUT destTransportDomain -- destination transport domain 1331 OUT destTransportAddress -- destination transport address 1332 OUT outgoingMessage -- the message to send 1333 OUT outgoingMessageLength -- its length 1334 ) 1336 4.2.3. Prepare Data Elements from an Incoming SNMP Message 1338 The Message Processing Subsystem provides this service primitive for 1339 preparing the abstract data elements from an incoming SNMP message: 1341 result = -- SUCCESS or errorIndication 1342 prepareDataElements( 1343 IN transportDomain -- origin transport domain 1344 IN transportAddress -- origin transport address 1345 IN wholeMsg -- as received from the network 1346 IN wholeMsgLength -- as received from the network 1347 OUT messageProcessingModel -- typically, SNMP version 1348 OUT securityModel -- Security Model to use 1349 OUT securityName -- on behalf of this principal 1350 OUT securityLevel -- Level of Security requested 1351 OUT contextEngineID -- data from/at this entity 1352 OUT contextName -- data from/in this context 1353 OUT pduVersion -- the version of the PDU 1354 OUT PDU -- SNMP Protocol Data Unit 1355 OUT pduType -- SNMP PDU type 1356 OUT sendPduHandle -- handle for matched request 1357 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU 1358 OUT statusInformation -- success or errorIndication 1359 -- error counter OID/value if error 1360 OUT stateReference -- reference to state information 1361 -- to be used for possible Response 1362 ) 1364 4.3. Access Control Subsystem Primitives 1366 Applications are the typical clients of the service(s) of the Access 1367 Control Subsystem. 1369 The following primitive is provided by the Access Control Subsystem 1370 to check if access is allowed: 1372 statusInformation = -- success or errorIndication 1373 isAccessAllowed( 1374 IN securityModel -- Security Model in use 1375 IN securityName -- principal who wants to access 1376 IN securityLevel -- Level of Security 1377 IN viewType -- read, write, or notify view 1378 IN contextName -- context containing variableName 1379 IN variableName -- OID for the managed object 1380 ) 1382 4.4. Security Subsystem Primitives 1384 The Message Processing Subsystem is the typical client of the 1385 services of the Security Subsystem. 1387 4.4.1. Generate a Request or Notification Message 1389 The Security Subsystem provides the following primitive to generate a 1390 Request or Notification message: 1392 statusInformation = 1393 generateRequestMsg( 1394 IN messageProcessingModel -- typically, SNMP version 1395 IN globalData -- message header, admin data 1396 IN maxMessageSize -- of the sending SNMP entity 1397 IN securityModel -- for the outgoing message 1398 IN securityEngineID -- authoritative SNMP entity 1399 IN securityName -- on behalf of this principal 1400 IN securityLevel -- Level of Security requested 1401 IN scopedPDU -- message (plaintext) payload 1402 OUT securityParameters -- filled in by Security Module 1403 OUT wholeMsg -- complete generated message 1404 OUT wholeMsgLength -- length of the generated message 1405 ) 1407 4.4.2. Process Incoming Message 1409 The Security Subsystem provides the following primitive to process an 1410 incoming message: 1412 statusInformation = -- errorIndication or success 1413 -- error counter OID/value if error 1414 processIncomingMsg( 1415 IN messageProcessingModel -- typically, SNMP version 1416 IN maxMessageSize -- of the sending SNMP entity 1417 IN securityParameters -- for the received message 1418 IN securityModel -- for the received message 1419 IN securityLevel -- Level of Security 1420 IN wholeMsg -- as received on the wire 1421 IN wholeMsgLength -- length as received on the wire 1422 OUT securityEngineID -- identification of the principal 1423 OUT securityName -- identification of the principal 1424 OUT scopedPDU, -- message (plaintext) payload 1425 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU 1426 OUT securityStateReference -- reference to security state 1427 ) -- information, needed for response 1429 4.4.3. Generate a Response Message 1431 The Security Subsystem provides the following primitive to generate a 1432 Response message: 1434 statusInformation = 1435 generateResponseMsg( 1436 IN messageProcessingModel -- typically, SNMP version 1437 IN globalData -- message header, admin data 1438 IN maxMessageSize -- of the sending SNMP entity 1439 IN securityModel -- for the outgoing message 1440 IN securityEngineID -- authoritative SNMP entity 1441 IN securityName -- on behalf of this principal 1442 IN securityLevel -- for the outgoing message 1443 IN scopedPDU -- message (plaintext) payload 1444 IN securityStateReference -- reference to security state 1445 -- information from original request 1446 OUT securityParameters -- filled in by Security Module 1447 OUT wholeMsg -- complete generated message 1448 OUT wholeMsgLength -- length of the generated message 1449 ) 1451 4.5. Common Primitives 1453 These primitive(s) are provided by multiple Subsystems. 1455 4.5.1. Release State Reference Information 1457 All Subsystems which pass stateReference information also provide a 1458 primitive to release the memory that holds the referenced state 1459 information: 1461 stateRelease( 1462 IN stateReference -- handle of reference to be released 1463 ) 1465 4.6. Scenario Diagrams 1467 4.6.1. Command Generator or Notification Originator 1469 This diagram shows how a Command Generator or Notification Originator 1470 application requests that a PDU be sent, and how the response is 1471 returned (asynchronously) to that application. 1473 Command Dispatcher Message Security 1474 Generator | Processing Model 1475 | | Model | 1476 | sendPdu | | | 1477 |------------------->| | | 1478 | | prepareOutgoingMessage | | 1479 : |----------------------->| | 1480 : | | generateRequestMsg | 1481 : | |-------------------->| 1482 : | | | 1483 : | |<--------------------| 1484 : | | | 1485 : |<-----------------------| | 1486 : | | | 1487 : |------------------+ | | 1488 : | Send SNMP | | | 1489 : | Request Message | | | 1490 : | to Network | | | 1491 : | v | | 1492 : : : : : 1493 : : : : : 1494 : : : : : 1495 : | | | | 1496 : | Receive SNMP | | | 1497 : | Response Message | | | 1498 : | from Network | | | 1499 : |<-----------------+ | | 1500 : | | | 1501 : | prepareDataElements | | 1502 : |----------------------->| | 1503 : | | processIncomingMsg | 1504 : | |-------------------->| 1505 : | | | 1506 : | |<--------------------| 1507 : | | | 1508 : |<-----------------------| | 1509 | processResponsePdu | | | 1510 |<-------------------| | | 1511 | | | | 1513 4.6.2. Scenario Diagram for a Command Responder Application 1515 This diagram shows how a Command Responder or Notification Receiver 1516 application registers for handling a pduType, how a PDU is dispatched 1517 to the application after a SNMP message is received, and how the 1518 Response is (asynchronously) send back to the network. 1520 Command Dispatcher Message Security 1521 Responder | Processing Model 1522 | | Model | 1523 | | | | 1524 | registerContextEngineID | | | 1525 |------------------------>| | | 1526 |<------------------------| | | | 1527 | | Receive SNMP | | | 1528 : | Message | | | 1529 : | from Network | | | 1530 : |<-------------+ | | 1531 : | | | 1532 : |prepareDataElements | | 1533 : |------------------->| | 1534 : | | processIncomingMsg | 1535 : | |------------------->| 1536 : | | | 1537 : | |<-------------------| 1538 : | | | 1539 : |<-------------------| | 1540 | processPdu | | | 1541 |<------------------------| | | 1542 | | | | 1543 : : : : 1544 : : : : 1545 | returnResponsePdu | | | 1546 |------------------------>| | | 1547 : | prepareResponseMsg | | 1548 : |------------------->| | 1549 : | |generateResponseMsg | 1550 : | |------------------->| 1551 : | | | 1552 : | |<-------------------| 1553 : | | | 1554 : |<-------------------| | 1555 : | | | 1556 : |--------------+ | | 1557 : | Send SNMP | | | 1558 : | Message | | | 1559 : | to Network | | | 1560 : | v | | 1562 5. Managed Object Definitions for SNMP Management Frameworks 1564 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN 1566 IMPORTS 1567 MODULE-IDENTITY, OBJECT-TYPE, 1568 OBJECT-IDENTITY, 1569 snmpModules FROM SNMPv2-SMI 1570 TEXTUAL-CONVENTION FROM SNMPv2-TC 1571 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 1573 snmpFrameworkMIB MODULE-IDENTITY 1574 LAST-UPDATED "9810152123Z" -- 15 October 1998 1575 ORGANIZATION "SNMPv3 Working Group" 1576 CONTACT-INFO "WG-email: snmpv3@tis.com 1577 Subscribe: majordomo@tis.com 1578 In message body: subscribe snmpv3 1580 Chair: Russ Mundy 1581 Trusted Information Systems 1582 postal: 3060 Washington Rd 1583 Glenwood MD 21738 1584 USA 1585 email: mundy@tis.com 1586 phone: +1 301-854-6889 1588 Co-editor Dave Harrington 1589 Cabletron Systems, Inc. 1590 postal: Post Office Box 5005 1591 Mail Stop: Durham 1592 35 Industrial Way 1593 Rochester, NH 03867-5005 1594 USA 1595 email: dbh@ctron.com 1596 phone: +1 603-337-7357 1598 Co-editor Randy Presuhn 1599 BMC Software, Inc. 1600 postal: 965 Stewart Drive 1601 Sunnyvale, CA 94086 1602 USA 1603 email: randy_presuhn@bmc.com 1604 phone: +1 408-616-3100 1606 Co-editor: Bert Wijnen 1607 IBM T.J. Watson Research 1608 postal: Schagen 33 1609 3461 GL Linschoten 1610 Netherlands 1611 email: wijnen@vnet.ibm.com 1612 phone: +31 348-432-794 1613 " 1614 DESCRIPTION "The SNMP Management Architecture MIB" 1615 REVISION "9810152123Z" -- 15 October 1998 1616 DESCRIPTION "The latest version of this MIB module. 1617 " 1618 REVISION "9711200000Z" -- 20 November 1997 1619 DESCRIPTION "The initial version, published in RFC 2271. 1620 " 1621 ::= { snmpModules 10 } 1623 -- Textual Conventions used in the SNMP Management Architecture *** 1625 SnmpEngineID ::= TEXTUAL-CONVENTION 1626 STATUS current 1627 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1628 Objects of this type are for identification, not for 1629 addressing, even though it is possible that an 1630 address may have been used in the generation of 1631 a specific value. 1633 The value for this object may not be all zeros or 1634 all 'ff'H or the empty (zero length) string. 1636 The initial value for this object may be configured 1637 via an operator console entry or via an algorithmic 1638 function. In the latter case, the following 1639 example algorithm is recommended. 1641 In cases where there are multiple engines on the 1642 same system, the use of this algorithm is NOT 1643 appropriate, as it would result in all of those 1644 engines ending up with the same ID value. 1646 1) The very first bit is used to indicate how the 1647 rest of the data is composed. 1649 0 - as defined by enterprise using former methods 1650 that existed before SNMPv3. See item 2 below. 1652 1 - as defined by this architecture, see item 3 1653 below. 1655 Note that this allows existing uses of the 1656 engineID (also known as AgentID [RFC1910]) to 1657 co-exist with any new uses. 1659 2) The snmpEngineID has a length of 12 octets. 1661 The first four octets are set to the binary 1662 equivalent of the agent's SNMP management 1663 private enterprise number as assigned by the 1664 Internet Assigned Numbers Authority (IANA). 1665 For example, if Acme Networks has been assigned 1666 { enterprises 696 }, the first four octets would 1667 be assigned '000002b8'H. 1669 The remaining eight octets are determined via 1670 one or more enterprise-specific methods. Such 1671 methods must be designed so as to maximize the 1672 possibility that the value of this object will 1673 be unique in the agent's administrative domain. 1674 For example, it may be the IP address of the SNMP 1675 entity, or the MAC address of one of the 1676 interfaces, with each address suitably padded 1677 with random octets. If multiple methods are 1678 defined, then it is recommended that the first 1679 octet indicate the method being used and the 1680 remaining octets be a function of the method. 1682 3) The length of the octet strings varies. 1684 The first four octets are set to the binary 1685 equivalent of the agent's SNMP management 1686 private enterprise number as assigned by the 1687 Internet Assigned Numbers Authority (IANA). 1688 For example, if Acme Networks has been assigned 1689 { enterprises 696 }, the first four octets would 1690 be assigned '000002b8'H. 1692 The very first bit is set to 1. For example, the 1693 above value for Acme Networks now changes to be 1694 '800002b8'H. 1696 The fifth octet indicates how the rest (6th and 1697 following octets) are formatted. The values for 1698 the fifth octet are: 1700 0 - reserved, unused. 1702 1 - IPv4 address (4 octets) 1703 lowest non-special IP address 1705 2 - IPv6 address (16 octets) 1706 lowest non-special IP address 1708 3 - MAC address (6 octets) 1709 lowest IEEE MAC address, canonical 1710 order 1712 4 - Text, administratively assigned 1713 Maximum remaining length 27 1715 5 - Octets, administratively assigned 1716 Maximum remaining length 27 1718 6-127 - reserved, unused 1720 127-255 - as defined by the enterprise 1721 Maximum remaining length 27 1722 " 1723 SYNTAX OCTET STRING (SIZE(5..32)) 1725 SnmpSecurityModel ::= TEXTUAL-CONVENTION 1726 STATUS current 1727 DESCRIPTION "An identifier that uniquely identifies a 1728 securityModel of the Security Subsystem within the 1729 SNMP Management Architecture. 1731 The values for securityModel are allocated as 1732 follows: 1734 - The zero value is reserved. 1735 - Values between 1 and 255, inclusive, are reserved 1736 for standards-track Security Models and are 1737 managed by the Internet Assigned Numbers Authority 1738 (IANA). 1739 - Values greater than 255 are allocated to 1740 enterprise-specific Security Models. An 1741 enterprise-specific securityModel value is defined 1742 to be: 1744 enterpriseID * 256 + security model within 1745 enterprise 1747 For example, the fourth Security Model defined by 1748 the enterprise whose enterpriseID is 1 would be 1749 260. 1751 This scheme for allocation of securityModel 1752 values allows for a maximum of 255 standards- 1753 based Security Models, and for a maximum of 1754 255 Security Models per enterprise. 1756 It is believed that the assignment of new 1757 securityModel values will be rare in practice 1758 because the larger the number of simultaneously 1759 utilized Security Models, the larger the 1760 chance that interoperability will suffer. 1761 Consequently, it is believed that such a range 1762 will be sufficient. In the unlikely event that 1763 the standards committee finds this number to be 1764 insufficient over time, an enterprise number 1765 can be allocated to obtain an additional 255 1766 possible values. 1768 Note that the most significant bit must be zero; 1769 hence, there are 23 bits allocated for various 1770 organizations to design and define non-standard 1771 securityModels. This limits the ability to 1772 define new proprietary implementations of Security 1773 Models to the first 8,388,608 enterprises. 1775 It is worthwhile to note that, in its encoded 1776 form, the securityModel value will normally 1777 require only a single byte since, in practice, 1778 the leftmost bits will be zero for most messages 1779 and sign extension is suppressed by the encoding 1780 rules. 1782 As of this writing, there are several values 1783 of securityModel defined for use with SNMP or 1784 reserved for use with supporting MIB objects. 1785 They are as follows: 1787 0 reserved for 'any' 1788 1 reserved for SNMPv1 1789 2 reserved for SNMPv2c 1790 3 User-Based Security Model (USM) 1791 " 1792 SYNTAX INTEGER(0..2147483647) 1794 SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION 1795 STATUS current 1796 DESCRIPTION "An identifier that uniquely identifies a Message 1797 Processing Model of the Message Processing 1798 Subsystem within a SNMP Management Architecture. 1800 The values for messageProcessingModel are 1801 allocated as follows: 1803 - Values between 0 and 255, inclusive, are 1804 reserved for standards-track Message Processing 1805 Models and are managed by the Internet Assigned 1806 Numbers Authority (IANA). 1807 - Values greater than 255 are allocated to 1808 enterprise-specific Message Processing Models. 1809 An enterprise messageProcessingModel value is 1810 defined to be: 1812 enterpriseID * 256 + 1813 messageProcessingModel within enterprise 1815 For example, the fourth Message Processing Model 1816 defined by the enterprise whose enterpriseID 1817 is 1 would be 260. 1819 This scheme for allocation of securityModel 1820 values allows for a maximum of 255 standards- 1821 based Message Processing Models, and for a 1822 maximum of 255 Message Processing Models per 1823 enterprise. 1825 It is believed that the assignment of new 1826 messageProcessingModel values will be rare 1827 in practice because the larger the number of 1828 simultaneously utilized Message Processing Models, 1829 the larger the chance that interoperability 1830 will suffer. It is believed that such a range 1831 will be sufficient. In the unlikely event that 1832 the standards committee finds this number to be 1833 insufficient over time, an enterprise number 1834 can be allocated to obtain an additional 256 1835 possible values. 1837 Note that the most significant bit must be zero; 1838 hence, there are 23 bits allocated for various 1839 organizations to design and define non-standard 1840 messageProcessingModels. This limits the ability 1841 to define new proprietary implementations of 1842 Message Processing Models to the first 8,388,608 1843 enterprises. 1845 It is worthwhile to note that, in its encoded 1846 form, the securityModel value will normally 1847 require only a single byte since, in practice, 1848 the leftmost bits will be zero for most messages 1849 and sign extension is suppressed by the encoding 1850 rules. 1852 As of this writing, there are several values of 1853 messageProcessingModel defined for use with SNMP. 1854 They are as follows: 1856 0 reserved for SNMPv1 1857 1 reserved for SNMPv2c 1858 2 reserved for SNMPv2u and SNMPv2* 1859 3 reserved for SNMPv3 1860 " 1861 SYNTAX INTEGER(0..2147483647) 1863 SnmpSecurityLevel ::= TEXTUAL-CONVENTION 1864 STATUS current 1865 DESCRIPTION "A Level of Security at which SNMP messages can be 1866 sent or with which operations are being processed; 1867 in particular, one of: 1869 noAuthNoPriv - without authentication and 1870 without privacy, 1871 authNoPriv - with authentication but 1872 without privacy, 1873 authPriv - with authentication and 1874 with privacy. 1876 These three values are ordered such that 1877 noAuthNoPriv is less than authNoPriv and 1878 authNoPriv is less than authPriv. 1879 " 1880 SYNTAX INTEGER { noAuthNoPriv(1), 1881 authNoPriv(2), 1882 authPriv(3) 1883 } 1885 SnmpAdminString ::= TEXTUAL-CONVENTION 1886 DISPLAY-HINT "255a" 1887 STATUS current 1888 DESCRIPTION "An octet string containing administrative 1889 information, preferably in human-readable form. 1891 To facilitate internationalization, this 1892 information is represented using the ISO/IEC 1893 IS 10646-1 character set, encoded as an octet 1894 string using the UTF-8 transformation format 1895 described in [RFC2044]. 1897 Since additional code points are added by 1898 amendments to the 10646 standard from time 1899 to time, implementations must be prepared to 1900 encounter any code point from 0x00000000 to 1901 0x7fffffff. 1903 The use of control codes should be avoided. 1905 When it is necessary to represent a newline, 1906 the control code sequence CR LF should be used. 1908 The use of leading or trailing white space should 1909 be avoided. 1911 For code points not directly supported by user 1912 interface hardware or software, an alternative 1913 means of entry and display, such as hexadecimal, 1914 may be provided. 1916 For information encoded in 7-bit US-ASCII, 1917 the UTF-8 encoding is identical to the 1918 US-ASCII encoding. 1920 Note that when this TC is used for an object that 1921 is used or envisioned to be used as an index, then 1922 a SIZE restriction MUST be specified so that the 1923 number of sub-identifiers for any object instance 1924 does not exceed the limit of 128, as defined by 1925 [RFC1905]. 1926 " 1927 SYNTAX OCTET STRING (SIZE (0..255)) 1929 -- Administrative assignments *************************************** 1931 snmpFrameworkAdmin 1932 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } 1933 snmpFrameworkMIBObjects 1934 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } 1935 snmpFrameworkMIBConformance 1936 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 1938 -- the snmpEngine Group ******************************************** 1940 snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 1942 snmpEngineID OBJECT-TYPE 1943 SYNTAX SnmpEngineID 1944 MAX-ACCESS read-only 1945 STATUS current 1946 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1948 " 1949 ::= { snmpEngine 1 } 1951 snmpEngineBoots OBJECT-TYPE 1952 SYNTAX INTEGER (1..2147483647) 1953 MAX-ACCESS read-only 1954 STATUS current 1955 DESCRIPTION "The number of times that the SNMP engine has 1956 (re-)initialized itself since snmpEngineID 1957 was last configured. 1958 " 1959 ::= { snmpEngine 2 } 1961 snmpEngineTime OBJECT-TYPE 1962 SYNTAX INTEGER (0..2147483647) 1963 UNITS "seconds" 1964 MAX-ACCESS read-only 1965 STATUS current 1966 DESCRIPTION "The number of seconds since the value of 1967 the snmpEngineBoots object last changed. 1968 When incrementing this object's value would 1969 cause it to exceed its maximum, 1970 snmpEngineBoots is incremented as if a 1971 re-initialization had occurred, and this 1972 object's value consequently reverts to zero. 1973 " 1974 ::= { snmpEngine 3 } 1976 snmpEngineMaxMessageSize OBJECT-TYPE 1977 SYNTAX INTEGER (484..2147483647) 1978 MAX-ACCESS read-only 1979 STATUS current 1980 DESCRIPTION "The maximum length in octets of an SNMP message 1981 which this SNMP engine can send or receive and 1982 process, determined as the minimum of the maximum 1983 message size values supported among all of the 1984 transports available to and supported by the engine. 1985 " 1986 ::= { snmpEngine 4 } 1988 -- Registration Points for Authentication and Privacy Protocols ** 1990 snmpAuthProtocols OBJECT-IDENTITY 1991 STATUS current 1992 DESCRIPTION "Registration point for standards-track 1993 authentication protocols used in SNMP Management 1994 Frameworks. 1996 " 1997 ::= { snmpFrameworkAdmin 1 } 1999 snmpPrivProtocols OBJECT-IDENTITY 2000 STATUS current 2001 DESCRIPTION "Registration point for standards-track privacy 2002 protocols used in SNMP Management Frameworks. 2003 " 2004 ::= { snmpFrameworkAdmin 2 } 2006 -- Conformance information ****************************************** 2008 snmpFrameworkMIBCompliances 2009 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} 2010 snmpFrameworkMIBGroups 2011 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} 2013 -- compliance statements 2015 snmpFrameworkMIBCompliance MODULE-COMPLIANCE 2016 STATUS current 2017 DESCRIPTION "The compliance statement for SNMP engines which 2018 implement the SNMP Management Framework MIB. 2019 " 2020 MODULE -- this module 2021 MANDATORY-GROUPS { snmpEngineGroup } 2023 ::= { snmpFrameworkMIBCompliances 1 } 2025 -- units of conformance 2027 snmpEngineGroup OBJECT-GROUP 2028 OBJECTS { 2029 snmpEngineID, 2030 snmpEngineBoots, 2031 snmpEngineTime, 2032 snmpEngineMaxMessageSize 2033 } 2034 STATUS current 2035 DESCRIPTION "A collection of objects for identifying and 2036 determining the configuration and current timeliness 2037 values of an SNMP engine. 2038 " 2039 ::= { snmpFrameworkMIBGroups 1 } 2041 END 2043 6. IANA Considerations 2045 This document defines two number spaces which would be administered 2046 by IANA, one for security models and another for message processing 2047 models. 2049 6.1. Security Models 2051 The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are 2052 in the range from 1 to 255 inclusive, and are reserved for standards- 2053 track Security Models. If this range should in the future prove 2054 insufficient, an enterprise number can be allocated to obtain an 2055 additional 255 possible values. 2057 As of this writing, there are several values of securityModel defined 2058 for use with SNMP or reserved for use with supporting MIB objects. 2059 They are as follows: 2060 0 reserved for 'any' 2061 1 reserved for SNMPv1 2062 2 reserved for SNMPv2c 2063 3 User-Based Security Model (USM) 2065 6.2. Message Processing Models 2067 The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by 2068 IANA are in the range 0 to 255, inclusive. Each value uniquely 2069 identifies a standards-track Message Processing Model of the Message 2070 Processing Subsystem within a SNMP Management Architecture. 2072 Should this range prove insufficient in the future, an enterprise 2073 number may be obtained for the standards committee to get an 2074 additional 256 possible values. 2076 As of this writing, there are several values of 2077 messageProcessingModel defined for use with SNMP. They are as 2078 follows: 2079 0 reserved for SNMPv1 2080 1 reserved for SNMPv2c 2081 2 reserved for SNMPv2u and SNMPv2* 2082 3 reserved for SNMPv3 2084 7. Intellectual Property 2086 The IETF takes no position regarding the validity or scope of any 2087 intellectual property or other rights that might be claimed to 2088 pertain to the implementation or use of the technology described in 2089 this document or the extent to which any license under such rights 2090 might or might not be available; neither does it represent that it 2091 has made any effort to identify any such rights. Information on the 2092 IETF's procedures with respect to rights in standards-track and 2093 standards-related documentation can be found in BCP-11. Copies of 2094 claims of rights made available for publication and any assurances of 2095 licenses to be made available, or the result of an attempt made to 2096 obtain a general license or permission for the use of such 2097 proprietary rights by implementors or users of this specification can 2098 be obtained from the IETF Secretariat. 2100 The IETF invites any interested party to bring to its attention any 2101 copyrights, patents or patent applications, or other proprietary 2102 rights which may cover technology that may be required to practice 2103 this standard. Please address the information to the IETF Executive 2104 Director. 2106 8. Acknowledgements 2108 This document is the result of the efforts of the SNMPv3 Working 2109 Group. Some special thanks are in order to the following SNMPv3 WG 2110 members: 2112 Dave Battle (SNMP Research, Inc.) 2113 Uri Blumenthal (IBM T.J. Watson Research Center) 2114 Jeff Case (SNMP Research, Inc.) 2115 John Curran (BBN) 2116 T. Max Devlin (Eltrax Systems) 2117 John Flick (Hewlett Packard) 2118 David Harrington (Cabletron Systems Inc.) 2119 N.C. Hien (IBM T.J. Watson Research Center) 2120 Dave Levi (SNMP Research, Inc.) 2121 Louis A Mamakos (UUNET Technologies Inc.) 2122 Paul Meyer (Secure Computing Corporation) 2123 Keith McCloghrie (Cisco Systems) 2124 Russ Mundy (Trusted Information Systems, Inc.) 2125 Bob Natale (ACE*COMM Corporation) 2126 Mike O'Dell (UUNET Technologies Inc.) 2127 Dave Perkins (DeskTalk) 2128 Peter Polkinghorne (Brunel University) 2129 Randy Presuhn (BMC Software, Inc.) 2130 David Reid (SNMP Research, Inc.) 2131 Shawn Routhier (Epilogue) 2132 Juergen Schoenwaelder (TU Braunschweig) 2133 Bob Stewart (Cisco Systems) 2134 Bert Wijnen (IBM T.J. Watson Research Center) 2136 The document is based on recommendations of the IETF Security and 2137 Administrative Framework Evolution for SNMP Advisory Team. Members 2138 of that Advisory Team were: 2140 David Harrington (Cabletron Systems Inc.) 2141 Jeff Johnson (Cisco Systems) 2142 David Levi (SNMP Research Inc.) 2143 John Linn (Openvision) 2144 Russ Mundy (Trusted Information Systems) chair 2145 Shawn Routhier (Epilogue) 2146 Glenn Waters (Nortel) 2147 Bert Wijnen (IBM T. J. Watson Research Center) 2149 As recommended by the Advisory Team and the SNMPv3 Working Group 2150 Charter, the design incorporates as much as practical from previous 2151 RFCs and drafts. As a result, special thanks are due to the authors 2152 of previous designs known as SNMPv2u and SNMPv2*: 2154 Jeff Case (SNMP Research, Inc.) 2155 David Harrington (Cabletron Systems Inc.) 2156 David Levi (SNMP Research, Inc.) 2157 Keith McCloghrie (Cisco Systems) 2158 Brian O'Keefe (Hewlett Packard) 2159 Marshall T. Rose (Dover Beach Consulting) 2160 Jon Saperia (BGS Systems Inc.) 2161 Steve Waldbusser (International Network Services) 2162 Glenn W. Waters (Bell-Northern Research Ltd.) 2164 9. Security Considerations 2166 This document describes how an implementation can include a Security 2167 Model to protect management messages and an Access Control Model to 2168 control access to management information. 2170 The level of security provided is determined by the specific Security 2171 Model implementation(s) and the specific Access Control Model 2172 implementation(s) used. 2174 Applications have access to data which is not secured. Applications 2175 SHOULD take reasonable steps to protect the data from disclosure. 2177 It is the responsibility of the purchaser of an implementation to 2178 ensure that: 2180 1) an implementation complies with the rules defined by this 2181 architecture, 2183 2) the Security and Access Control Models utilized satisfy the 2184 security and access control needs of the organization, 2186 3) the implementations of the Models and Applications comply with 2187 the model and application specifications, 2189 4) and the implementation protects configuration secrets from 2190 inadvertent disclosure. 2192 This document also contains a MIB definition module. None of the 2193 objects defined is writable, and the information they represent is 2194 not deemed to be particularly sensitive. However, if they are deemed 2195 sensitive in a particular environment, access to them should be 2196 restricted through the use of appropriately configured Security and 2197 Access Control models. 2199 10. References 2201 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 2202 of Management Information for TCP/IP-based internets", STD 16, RFC 2203 1155, May 1990. 2205 [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The 2206 Simple Network Management Protocol", STD 15, RFC 1157, University 2207 of Tennessee at Knoxville, Performance Systems s International, 2208 Performance International, and the MIT Laboratory for Computer 2209 Science, May 1990. 2211 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 2212 16, RFC 1212, March 1991. 2214 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2215 M., and S. Waldbusser, "Introduction to Community-based SNMPv2", 2216 RFC 1901, January 1996. 2218 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2219 M. and S. Waldbusser, "Structure of Management Information for 2220 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2221 RFC 1902, January 1996. 2223 [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2224 M., and S. Waldbusser, "Textual Conventions for Version 2 of the 2225 Simple Network Management Protocol (SNMPv2)", RFC 1903, January 2226 1996. 2228 [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2229 M., and S. Waldbusser, "Conformance Statements for Version 2 of 2230 the Simple Network Management Protocol (SNMPv2)", RFC 1904, 2231 January 1996. 2233 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2234 M. and S. Waldbusser, "Protocol Operations for Version 2 of the 2235 Simple Network Management Protocol (SNMPv2)", RFC 1905, January 2236 1996. 2238 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2239 M. and S. Waldbusser, "Transport Mappings for Version 2 of the 2240 Simple Network Management Protocol (SNMPv2)", RFC 1906, January 2241 1996. 2243 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2244 M. and S. Waldbusser, "Management Information Base for Version 2 2245 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 2246 January 1996. 2248 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2249 M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 2250 of the SNMP-standard Network Management Framework", RFC 1908, 2251 January 1996. 2253 [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure 2254 for SNMPv2", RFC 1909, February 1996. 2256 [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", 2257 RFC 1910, February 1996. 2259 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2260 RFC 2279, January, 1998. 2262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2263 Requirement Levels", BCP 14, RFC 2119, March 1997. 2265 [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in the 2266 IETF Standards Process", BCP 11, RFC 2028, October 1996. 2268 [SNMP-MPD] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 2269 "Message Processing and Dispatching for the Simple Network 2270 Management Protocol (SNMP)", , 2271 August, 1998. 2273 [SNMP-USM] Blumenthal, U., and B. Wijnen, "The User-Based Security 2274 Model for Version 3 of the Simple Network Management Protocol 2275 (SNMPv3)", , August 1998. 2277 [SNMP-ACM] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 2278 Access Control Model for the Simple Network Management Protocol 2279 (SNMP)", , August 1998. 2281 [SNMP-APPL] Levi, D. B., Meyer, P., and B. Stewart, "SNMPv3 2282 Applications", , November 1997. 2284 [SNMP-INTRO] Case, J., Mundy, R., Partain, D., and B. Stewart, 2285 "Introduction to Version 3 of the Internet-standard Network 2286 Management Framework", , August 2287 1998. 2289 [RFC2233] McCloghrie, K., and F. Kastenholz. "The Interfaces Group 2290 MIB using SMIv2", RFC 2233, November 1997. 2292 11. Editor's Addresses 2294 Bert Wijnen 2295 IBM T.J. Watson Research 2296 Schagen 33 2297 3461 GL Linschoten 2298 Netherlands 2300 Phone: +31 348-432-794 2301 EMail: wijnen@vnet.ibm.com 2303 Dave Harrington 2304 Cabletron Systems, Inc 2305 Post Office Box 5005 2306 Mail Stop: Durham 2307 35 Industrial Way 2308 Rochester, NH 03867-5005 2309 USA 2311 Phone: +1 603-337-7357 2312 EMail: dbh@ctron.com 2314 Randy Presuhn 2315 BMC Software, Inc. 2316 965 Stewart Drive 2317 Sunnyvale, CA 94086 2318 USA 2320 Phone: +1 408-616-3100 2321 Fax: +1 408-616-3101 2322 EMail: randy_presuhn@bmc.com 2324 APPENDIX A 2326 A. Guidelines for Model Designers 2328 This appendix describes guidelines for designers of models which are 2329 expected to fit into the architecture defined in this document. 2331 SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to 2332 provide trivial authentication and access control. SNMPv1 and SNMPv2c 2333 Frameworks can coexist with Frameworks designed according to this 2334 architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks 2335 could be designed to meet the requirements of this architecture, but 2336 this document does not provide guidelines for that coexistence. 2338 Within any subsystem model, there should be no reference to any 2339 specific model of another subsystem, or to data defined by a specific 2340 model of another subsystem. 2342 Transfer of data between the subsystems is deliberately described as 2343 a fixed set of abstract data elements and primitive functions which 2344 can be overloaded to satisfy the needs of multiple model definitions. 2346 Documents which define models to be used within this architecture 2347 SHOULD use the standard primitives between subsystems, possibly 2348 defining specific mechanisms for converting the abstract data 2349 elements into model-usable formats. This constraint exists to allow 2350 subsystem and model documents to be written recognizing common 2351 borders of the subsystem and model. Vendors are not constrained to 2352 recognize these borders in their implementations. 2354 The architecture defines certain standard services to be provided 2355 between subsystems, and the architecture defines abstract service 2356 interfaces to request these services. 2358 Each model definition for a subsystem SHOULD support the standard 2359 service interfaces, but whether, or how, or how well, it performs the 2360 service is dependent on the model definition. 2362 A.1. Security Model Design Requirements 2364 A.1.1. Threats 2366 A document describing a Security Model MUST describe how the model 2367 protects against the threats described under "Security Requirements 2368 of this Architecture", section 1.4. 2370 A.1.2. Security Processing 2372 Received messages MUST be validated by a Model of the Security 2373 Subsystem. Validation includes authentication and privacy processing 2374 if needed, but it is explicitly allowed to send messages which do not 2375 require authentication or privacy. 2377 A received message contains a specified securityLevel to be used 2378 during processing. All messages requiring privacy MUST also require 2379 authentication. 2381 A Security Model specifies rules by which authentication and privacy 2382 are to be done. A model may define mechanisms to provide additional 2383 security features, but the model definition is constrained to using 2384 (possibly a subset of) the abstract data elements defined in this 2385 document for transferring data between subsystems. 2387 Each Security Model may allow multiple security protocols to be used 2388 concurrently within an implementation of the model. Each Security 2389 Model defines how to determine which protocol to use, given the 2390 securityLevel and the security parameters relevant to the message. 2391 Each Security Model, with its associated protocol(s) defines how the 2392 sending/receiving entities are identified, and how secrets are 2393 configured. 2395 Authentication and Privacy protocols supported by Security Models are 2396 uniquely identified using Object Identifiers. IETF standard protocols 2397 for authentication or privacy should have an identifier defined 2398 within the snmpAuthProtocols or the snmpPrivProtocols subtrees. 2399 Enterprise specific protocol identifiers should be defined within the 2400 enterprise subtree. 2402 For privacy, the Security Model defines what portion of the message 2403 is encrypted. 2405 The persistent data used for security should be SNMP-manageable, but 2406 the Security Model defines whether an instantiation of the MIB is a 2407 conformance requirement. 2409 Security Models are replaceable within the Security Subsystem. 2410 Multiple Security Model implementations may exist concurrently within 2411 an SNMP engine. The number of Security Models defined by the SNMP 2412 community should remain small to promote interoperability. 2414 A.1.3. Validate the security-stamp in a received message 2416 A Message Processing Model requests that a Security Model: 2417 - verifies that the message has not been altered, 2418 - authenticates the identification of the principal for whom the 2419 message was generated. 2420 - decrypts the message if it was encrypted. 2422 Additional requirements may be defined by the model, and additional 2423 services may be provided by the model, but the model is constrained 2424 to use the following primitives for transferring data between 2425 subsystems. Implementations are not so constrained. 2427 A Message Processing Model uses the processIncomingMsg primitive as 2428 described in section 4.4.2. 2430 A.1.4. Security MIBs 2432 Each Security Model defines the MIB module(s) required for security 2433 processing, including any MIB module(s) required for the security 2434 protocol(s) supported. The MIB module(s) SHOULD be defined 2435 concurrently with the procedures which use the MIB module(s). The 2436 MIB module(s) are subject to normal access control rules. 2438 The mapping between the model-dependent security ID and the 2439 securityName MUST be able to be determined using SNMP, if the model- 2440 dependent MIB is instantiated and if access control policy allows 2441 access. 2443 A.1.5. Cached Security Data 2445 For each message received, the Security Model caches the state 2446 information such that a Response message can be generated using the 2447 same security information, even if the Local Configuration Datastore 2448 is altered between the time of the incoming request and the outgoing 2449 response. 2451 A Message Processing Model has the responsibility for explicitly 2452 releasing the cached data if such data is no longer needed. To enable 2453 this, an abstract securityStateReference data element is passed from 2454 the Security Model to the Message Processing Model. 2456 The cached security data may be implicitly released via the 2457 generation of a response, or explicitly released by using the 2458 stateRelease primitive, as described in section 4.5.1. 2460 A.2. Message Processing Model Design Requirements 2462 An SNMP engine contains a Message Processing Subsystem which may 2463 contain multiple Message Processing Models. 2465 The Message Processing Model MUST always (conceptually) pass the 2466 complete PDU, i.e., it never forwards less than the complete list of 2467 varBinds. 2469 A.2.1. Receiving an SNMP Message from the Network 2471 Upon receipt of a message from the network, the Dispatcher in the 2472 SNMP engine determines the version of the SNMP message and interacts 2473 with the corresponding Message Processing Model to determine the 2474 abstract data elements. 2476 A Message Processing Model specifies the SNMP Message format it 2477 supports and describes how to determine the values of the abstract 2478 data elements (like msgID, msgMaxSize, msgFlags, 2479 msgSecurityParameters, securityModel, securityLevel etc). A Message 2480 Processing Model interacts with a Security Model to provide security 2481 processing for the message using the processIncomingMsg primitive, as 2482 described in section 4.4.2. 2484 A.2.2. Sending an SNMP Message to the Network 2486 The Dispatcher in the SNMP engine interacts with a Message Processing 2487 Model to prepare an outgoing message. For that it uses the following 2488 primitives: 2490 - for requests and notifications: prepareOutgoingMessage, as 2491 described in section 4.2.1. 2493 - for response messages: prepareResponseMessage, as described in 2494 section 4.2.2. 2496 A Message Processing Model, when preparing an Outgoing SNMP Message, 2497 interacts with a Security Model to secure the message. For that it 2498 uses the following primitives: 2500 - for requests and notifications: generateRequestMsg, as 2501 described in section 4.4.1. 2503 - for response messages: generateResponseMsg as described in 2504 section 4.4.3. 2506 Once the SNMP message is prepared by a Message Processing Model, 2507 the Dispatcher sends the message to the desired address using the 2508 appropriate transport. 2510 A.3. Application Design Requirements 2512 Within an application, there may be an explicit binding to a specific 2513 SNMP message version, i.e., a specific Message Processing Model, and 2514 to a specific Access Control Model, but there should be no reference 2515 to any data defined by a specific Message Processing Model or Access 2516 Control Model. 2518 Within an application, there should be no reference to any specific 2519 Security Model, or any data defined by a specific Security Model. 2521 An application determines whether explicit or implicit access control 2522 should be applied to the operation, and, if access control is needed, 2523 which Access Control Model should be used. 2525 An application has the responsibility to define any MIB module(s) 2526 used to provide application-specific services. 2528 Applications interact with the SNMP engine to initiate messages, 2529 receive responses, receive asynchronous messages, and send responses. 2531 A.3.1. Applications that Initiate Messages 2533 Applications may request that the SNMP engine send messages 2534 containing SNMP commands or notifications using the sendPdu primitive 2535 as described in section 4.1.1. 2537 If it is desired that a message be sent to multiple targets, it is 2538 the responsibility of the application to provide the iteration. 2540 The SNMP engine assumes necessary access control has been applied to 2541 the PDU, and provides no access control services. 2543 The SNMP engine looks at the "expectResponse" parameter, and if a 2544 response is expected, then the appropriate information is cached such 2545 that a later response can be associated to this message, and can then 2546 be returned to the application. A sendPduHandle is returned to the 2547 application so it can later correspond the response with this message 2548 as well. 2550 A.3.2. Applications that Receive Responses 2552 The SNMP engine matches the incoming response messages to outstanding 2553 messages sent by this SNMP engine, and forwards the response to the 2554 associated application using the processResponsePdu primitive, as 2555 described in section 4.1.4. 2557 A.3.3. Applications that Receive Asynchronous Messages 2559 When an SNMP engine receives a message that is not the response to a 2560 request from this SNMP engine, it must determine to which application 2561 the message should be given. 2563 An Application that wishes to receive asynchronous messages registers 2564 itself with the engine using the primitive registerContextEngineID as 2565 described in section 4.1.5. 2567 An Application that wishes to stop receiving asynchronous messages 2568 should unregister itself with the SNMP engine using the primitive 2569 unregisterContextEngineID as described in section 4.1.5. 2571 Only one registration per combination of PDU type and contextEngineID 2572 is permitted at the same time. Duplicate registrations are ignored. 2573 An errorIndication will be returned to the application that attempts 2574 to duplicate a registration. 2576 All asynchronously received messages containing a registered 2577 combination of PDU type and contextEngineID are sent to the 2578 application which registered to support that combination. 2580 The engine forwards the PDU to the registered application, using the 2581 processPdu primitive, as described in section 4.1.2. 2583 A.3.4. Applications that Send Responses 2585 Request operations require responses. An application sends a 2586 response via the returnResponsePdu primitive, as described in section 2587 4.1.3. 2589 The contextEngineID, contextName, securityModel, securityName, 2590 securityLevel, and stateReference parameters are from the initial 2591 processPdu primitive. The PDU and statusInformation are the results 2592 of processing. 2594 A.4. Access Control Model Design Requirements 2596 An Access Control Model determines whether the specified securityName 2597 is allowed to perform the requested operation on a specified managed 2598 object. The Access Control Model specifies the rules by which access 2599 control is determined. 2601 The persistent data used for access control should be manageable 2602 using SNMP, but the Access Control Model defines whether an 2603 instantiation of the MIB is a conformance requirement. 2605 The Access Control Model must provide the primitive isAccessAllowed. 2607 B. Issues 2609 The issues list will be deleted when it is time to publish as an RFC. 2611 B.1. Open Issues 2613 - Need to update acknowledgement section. 2615 - we need a mechanism for a manager to be able to discover what 2616 securityModels are supported by a particular implementation 2617 Proposed resolution: trial and error appears to the preferred 2618 method. The need for a mechanism may be revisited when future 2619 security models are defined. 2621 - Are additional clarifications of the SnmpEngineID textual 2622 convention needed? The working group discussion on this topic was 2623 extensive. 2625 B.2. Change Log 2627 These are the major ways in which this draft differs from RFC 2628 2271. 2630 - Updated draft identifier to keep distinct from the series of 2631 drafts leading to RFC 2271, based on Cynthia Clark's messages 2632 regarding VACM and USM. 2634 - Updated draft location information per Cynthia Clark's 2635 instructions. 2637 - Added note clarifying that the SnmpEngineID textual convention 2638 is used for naming, rather than addressing, even though there 2639 are situations where its value may have been generated from an 2640 address. 2642 - Clarified snmpEngineBoots and snmpEngineTime to be consistent 2643 with other documents and working group agreement. 2645 - Incremental update of References section. 2647 - Updated editors' contact information. 2649 - Updated reference to UTF-8 RFC. 2651 - Added reference for SNMPv3 Intro document. 2653 - Added IANA Considerations section. 2655 C. Full Copyright Statement 2657 Copyright (C) The Internet Society (1998). All Rights Reserved. 2659 This document and translations of it may be copied and furnished to 2660 others, and derivative works that comment on or otherwise explain it 2661 or assist in its implementation may be prepared, copied, published 2662 and distributed, in whole or in part, without restriction of any 2663 kind, provided that the above copyright notice and this paragraph are 2664 included on all such copies and derivative works. However, this 2665 document itself may not be modified in any way, such as by removing 2666 the copyright notice or references to the Internet Society or other 2667 Internet organizations, except as needed for the purpose of 2668 developing Internet standards in which case the procedures for 2669 copyrights defined in the Internet Standards process must be 2670 followed, or as required to translate it into languages other than 2671 English. 2673 The limited permissions granted above are perpetual and will not be 2674 revoked by the Internet Society or its successors or assigns. 2676 This document and the information contained herein is provided on an 2677 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2678 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2679 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2680 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2681 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.