idnits 2.17.1 draft-ietf-snmpv3-arch-v2-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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. ** There are 37 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 230 has weird spacing: '...es with comma...' == Line 990 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 (3 October 2001) is 8212 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: 'SNMP-COEX' is mentioned on line 486, but not defined == Unused Reference: 'RFC1155' is defined on line 2327, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 2331, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 2335, but no explicit reference was found in the text == Unused Reference: 'RFC1901' is defined on line 2338, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 2342, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 2346, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 2350, but no explicit reference was found in the text == Unused Reference: 'RFC-TMM' is defined on line 2359, but no explicit reference was found in the text == Unused Reference: 'RFC-MIB' is defined on line 2365, but no explicit reference was found in the text == Unused Reference: 'RFC-COEX' is defined on line 2418, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 2375, but no explicit reference was found in the text == Unused Reference: 'BCP-11' is defined on line 2387, but no explicit reference was found in the text == Unused Reference: 'SNMP-MPD' is defined on line 2394, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 2399, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 2405, but no explicit reference was found in the text == Unused Reference: 'RFC-APPL' is defined on line 2410, 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-PROTO' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TMM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-MIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-COEX' ** 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' ** Obsolete normative reference: RFC 2574 (ref. 'SNMP-USM') (Obsoleted by RFC 3414) -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-APPL' ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) Summary: 12 errors (**), 0 flaws (~~), 21 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Harrington 3 Will Obsolete: 2571 Enterasys Networks 4 R. Presuhn 5 BMC Software, Inc. 6 B. Wijnen 7 Lucent Technologies 8 3 October 2001 10 An Architecture for Describing 11 SNMP Management Frameworks 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This document describes an architecture for describing SNMP 40 Management Frameworks. The architecture is designed to be modular to 41 allow the evolution of the SNMP protocol standards over time. The 42 major portions of the architecture are an SNMP engine containing a 43 Message Processing Subsystem, a Security Subsystem and an Access 44 Control Subsystem, and possibly multiple SNMP applications which 45 provide specific functional processing of management data. 47 Table of Contents 49 1. Introduction ................................................ 5 50 1.1. Overview .................................................. 5 51 1.2. SNMP ...................................................... 5 52 1.3. Goals of this Architecture ................................ 6 53 1.4. Security Requirements of this Architecture ................ 7 54 1.5. Design Decisions .......................................... 8 55 2. Documentation Overview ...................................... 10 56 2.1. Document Roadmap .......................................... 11 57 2.2. Applicability Statement ................................... 11 58 2.3. Coexistence and Transition ................................ 11 59 2.4. Transport Mappings ........................................ 12 60 2.5. Message Processing ........................................ 12 61 2.6. Security .................................................. 12 62 2.7. Access Control ............................................ 13 63 2.8. Protocol Operations ....................................... 13 64 2.9. Applications .............................................. 14 65 2.10. Structure of Management Information ...................... 14 66 2.11. Textual Conventions ...................................... 15 67 2.12. Conformance Statements ................................... 15 68 2.13. Management Information Base Modules ...................... 15 69 2.13.1. SNMP Instrumentation MIBs .............................. 15 70 2.14. SNMP Framework Documents ................................. 15 71 3. Elements of the Architecture ................................ 16 72 3.1. The Naming of Entities .................................... 17 73 3.1.1. SNMP engine ............................................. 17 74 3.1.1.1. snmpEngineID .......................................... 18 75 3.1.1.2. Dispatcher ............................................ 18 76 3.1.1.3. Message Processing Subsystem .......................... 19 77 3.1.1.3.1. Message Processing Model ............................ 19 78 3.1.1.4. Security Subsystem .................................... 20 79 3.1.1.4.1. Security Model ...................................... 20 80 3.1.1.4.2. Security Protocol ................................... 20 81 3.1.2. Access Control Subsystem ................................ 21 82 3.1.2.1. Access Control Model .................................. 21 83 3.1.3. Applications ............................................ 21 84 3.1.3.1. SNMP Manager .......................................... 22 85 3.1.3.2. SNMP Agent ............................................ 23 86 3.2. The Naming of Identities .................................. 25 87 3.2.1. Principal ............................................... 25 88 3.2.2. securityName ............................................ 25 89 3.2.3. Model-dependent security ID ............................. 26 90 3.3. The Naming of Management Information ...................... 27 91 3.3.1. An SNMP Context ......................................... 28 92 3.3.2. contextEngineID ......................................... 29 93 3.3.3. contextName ............................................. 29 94 3.3.4. scopedPDU ............................................... 30 95 3.4. Other Constructs .......................................... 30 96 3.4.1. maxSizeResponseScopedPDU ................................ 30 97 3.4.2. Local Configuration Datastore ........................... 30 98 3.4.3. securityLevel ........................................... 30 99 4. Abstract Service Interfaces ................................. 31 100 4.1. Dispatcher Primitives ..................................... 31 101 4.1.1. Generate Outgoing Request or Notification ............... 31 102 4.1.2. Process Incoming Request or Notification PDU ............ 31 103 4.1.3. Generate Outgoing Response .............................. 33 104 4.1.4. Process Incoming Response PDU ........................... 33 105 4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 33 106 4.2. Message Processing Subsystem Primitives ................... 34 107 4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 34 108 4.2.2. Prepare an Outgoing SNMP Response Message ............... 35 109 4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 36 110 4.3. Access Control Subsystem Primitives ....................... 36 111 4.4. Security Subsystem Primitives ............................. 37 112 4.4.1. Generate a Request or Notification Message .............. 37 113 4.4.2. Process Incoming Message ................................ 37 114 4.4.3. Generate a Response Message ............................. 38 115 4.5. Common Primitives ......................................... 38 116 4.5.1. Release State Reference Information ..................... 38 117 4.6. Scenario Diagrams ......................................... 39 118 4.6.1. Command Generator or Notification Originator ............ 39 119 4.6.2. Scenario Diagram for a Command Responder Application .... 40 120 5. Managed Object Definitions for SNMP Management Frameworks ... 41 121 6. IANA Considerations ......................................... 51 122 6.1. Security Models ........................................... 52 123 6.2. Message Processing Models ................................. 52 124 6.3. SnmpEngineID Formats ...................................... 52 125 7. Intellectual Property ....................................... 52 126 8. Acknowledgements ............................................ 53 127 9. Security Considerations ..................................... 54 128 10. References ................................................. 55 129 11. Editor's Addresses ......................................... 58 130 A. Guidelines for Model Designers .............................. 59 131 A.1. Security Model Design Requirements ........................ 59 132 A.1.1. Threats ................................................. 59 133 A.1.2. Security Processing ..................................... 60 134 A.1.3. Validate the security-stamp in a received message ....... 60 135 A.1.4. Security MIBs ........................................... 61 136 A.1.5. Cached Security Data .................................... 61 137 A.2. Message Processing Model Design Requirements .............. 61 138 A.2.1. Receiving an SNMP Message from the Network .............. 62 139 A.2.2. Sending an SNMP Message to the Network .................. 62 140 A.3. Application Design Requirements ........................... 63 141 A.3.1. Applications that Initiate Messages ..................... 63 142 A.3.2. Applications that Receive Responses ..................... 63 143 A.3.3. Applications that Receive Asynchronous Messages ......... 64 144 A.3.4. Applications that Send Responses ........................ 64 145 A.4. Access Control Model Design Requirements .................. 64 146 B. Issues ...................................................... 65 147 B.1. Open Issues ............................................... 65 148 B.2. Change Log ................................................ 65 149 C. Full Copyright Statement .................................... 65 151 1. Introduction 153 1.1. Overview 155 This document defines a vocabulary for describing SNMP Management 156 Frameworks, and an architecture for describing the major portions of 157 SNMP Management Frameworks. 159 This document does not provide a general introduction to SNMP. Other 160 documents and books can provide a much better introduction to SNMP. 161 Nor does this document provide a history of SNMP. That also can be 162 found in books and other documents. 164 Section 1 describes the purpose, goals, and design decisions of this 165 architecture. 167 Section 2 describes various types of documents which define (elements 168 of) SNMP Frameworks, and how they fit into this architecture. It also 169 provides a minimal road map to the documents which have previously 170 defined SNMP frameworks. 172 Section 3 details the vocabulary of this architecture and its pieces. 173 This section is important for understanding the remaining sections, 174 and for understanding documents which are written to fit within this 175 architecture. 177 Section 4 describes the primitives used for the abstract service 178 interfaces between the various subsystems, models and applications 179 within this architecture. 181 Section 5 defines a collection of managed objects used to instrument 182 SNMP entities within this architecture. 184 Sections 6, 7, 8, 9, 10 and 11 are administrative in nature. 186 Appendix A contains guidelines for designers of Models which are 187 expected to fit within this architecture. 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119]. 193 1.2. SNMP 195 An SNMP management system contains: 197 - several (potentially many) nodes, each with an SNMP entity 198 containing command responder and notification originator 199 applications, which have access to management instrumentation 200 (traditionally called agents); 202 - at least one SNMP entity containing command generator and/or 203 notification receiver applications (traditionally called a 204 manager) and, 206 - a management protocol, used to convey management information 207 between the SNMP entities. 209 SNMP entities executing command generator and notification receiver 210 applications monitor and control managed elements. Managed elements 211 are devices such as hosts, routers, terminal servers, etc., which are 212 monitored and controlled via access to their management information. 214 It is the purpose of this document to define an architecture which 215 can evolve to realize effective management in a variety of 216 configurations and environments. The architecture has been designed 217 to meet the needs of implementations of: 219 - minimal SNMP entities with command responder and/or 220 notification originator applications (traditionally called SNMP 221 agents), 223 - SNMP entities with proxy forwarder applications (traditionally 224 called SNMP proxy agents), 226 - command line driven SNMP entities with command generator and/or 227 notification receiver applications (traditionally called SNMP 228 command line managers), 230 - SNMP entities with command generator and/or notification 231 receiver, plus command responder and/or notification originator 232 applications (traditionally called SNMP mid-level managers or 233 dual-role entities), 235 - SNMP entities with command generator and/or notification 236 receiver and possibly other types of applications for managing 237 a potentially very large number of managed nodes (traditionally 238 called (network) management stations). 240 1.3. Goals of this Architecture 242 This architecture was driven by the following goals: 244 - Use existing materials as much as possible. It is heavily based 245 on previous work, informally known as SNMPv2u and SNMPv2*, 246 based in turn on SNMPv2p. 248 - Address the need for secure SET support, which is considered 249 the most important deficiency in SNMPv1 and SNMPv2c. 251 - Make it possible to move portions of the architecture forward 252 in the standards track, even if consensus has not been reached 253 on all pieces. 255 - Define an architecture that allows for longevity of the SNMP 256 Frameworks that have been and will be defined. 258 - Keep SNMP as simple as possible. 260 - Make it relatively inexpensive to deploy a minimal conforming 261 implementation. 263 - Make it possible to upgrade portions of SNMP as new approaches 264 become available, without disrupting an entire SNMP framework. 266 - Make it possible to support features required in large 267 networks, but make the expense of supporting a feature directly 268 related to the support of the feature. 270 1.4. Security Requirements of this Architecture 272 Several of the classical threats to network protocols are applicable 273 to the management problem and therefore would be applicable to any 274 Security Model used in an SNMP Management Framework. Other threats 275 are not applicable to the management problem. This section discusses 276 principal threats, secondary threats, and threats which are of lesser 277 importance. 279 The principal threats against which any Security Model used within 280 this architecture SHOULD provide protection are: 282 Modification of Information 283 The modification threat is the danger that some unauthorized 284 entity may alter in-transit SNMP messages generated on behalf 285 of an authorized principal in such a way as to effect 286 unauthorized management operations, including falsifying the 287 value of an object. 289 Masquerade 290 The masquerade threat is the danger that management operations 291 not authorized for some principal may be attempted by assuming 292 the identity of another principal that has the appropriate 293 authorizations. 295 Secondary threats against which any Security Model used within this 296 architecture SHOULD provide protection are: 298 Message Stream Modification 299 The SNMP protocol is typically based upon a connectionless 300 transport service which may operate over any subnetwork 301 service. The re-ordering, delay or replay of messages can and 302 does occur through the natural operation of many such 303 subnetwork services. The message stream modification threat is 304 the danger that messages may be maliciously re-ordered, delayed 305 or replayed to an extent which is greater than can occur 306 through the natural operation of a subnetwork service, in order 307 to effect unauthorized management operations. 309 Disclosure 310 The disclosure threat is the danger of eavesdropping on the 311 exchanges between SNMP engines. Protecting against this threat 312 may be required as a matter of local policy. 314 There are at least two threats against which a Security Model within 315 this architecture need not protect, since they are deemed to be of 316 lesser importance in this context: 318 Denial of Service 319 A Security Model need not attempt to address the broad range of 320 attacks by which service on behalf of authorized users is 321 denied. Indeed, such denial-of-service attacks are in many 322 cases indistinguishable from the type of network failures with 323 which any viable management protocol must cope as a matter of 324 course. 326 Traffic Analysis 327 A Security Model need not attempt to address traffic analysis 328 attacks. Many traffic patterns are predictable - entities may 329 be managed on a regular basis by a relatively small number of 330 management stations - and therefore there is no significant 331 advantage afforded by protecting against traffic analysis. 333 1.5. Design Decisions 335 Various design decisions were made in support of the goals of the 336 architecture and the security requirements: 338 - Architecture 339 An architecture should be defined which identifies the 340 conceptual boundaries between the documents. Subsystems should 341 be defined which describe the abstract services provided by 342 specific portions of an SNMP framework. Abstract service 343 interfaces, as described by service primitives, define the 344 abstract boundaries between documents, and the abstract 345 services that are provided by the conceptual subsystems of an 346 SNMP framework. 348 - Self-contained Documents 349 Elements of procedure plus the MIB objects which are needed for 350 processing for a specific portion of an SNMP framework should 351 be defined in the same document, and as much as possible, 352 should not be referenced in other documents. This allows pieces 353 to be designed and documented as independent and self-contained 354 parts, which is consistent with the general SNMP MIB module 355 approach. As portions of SNMP change over time, the documents 356 describing other portions of SNMP are not directly impacted. 357 This modularity allows, for example, Security Models, 358 authentication and privacy mechanisms, and message formats to 359 be upgraded and supplemented as the need arises. The self- 360 contained documents can move along the standards track on 361 different time-lines. 363 This modularity of specification is not meant to be interpreted as 364 imposing any specific requirements on implementation. 366 - Threats 367 The Security Models in the Security Subsystem SHOULD protect 368 against the principal and secondary threats: modification of 369 information, masquerade, message stream modification and 370 disclosure. They do not need to protect against denial of 371 service and traffic analysis. 373 - Remote Configuration 374 The Security and Access Control Subsystems add a whole new set 375 of SNMP configuration parameters. The Security Subsystem also 376 requires frequent changes of secrets at the various SNMP 377 entities. To make this deployable in a large operational 378 environment, these SNMP parameters must be remotely 379 configurable. 381 - Controlled Complexity 382 It is recognized that producers of simple managed devices want 383 to keep the resources used by SNMP to a minimum. At the same 384 time, there is a need for more complex configurations which can 385 spend more resources for SNMP and thus provide more 386 functionality. The design tries to keep the competing 387 requirements of these two environments in balance and allows 388 the more complex environments to logically extend the simple 389 environment. 391 2. Documentation Overview 393 The following figure shows the set of documents that fit within the 394 SNMP Architecture. 395 +------------------------- Document Set ----------------------------+ 396 | | 397 | +----------+ +-----------------+ +----------------+ | 398 | | Document | | Applicability * | | Coexistence | | 399 | | Roadmap | | Statement | | & Transition | | 400 | +----------+ +-----------------+ +----------------+ | 401 | | 402 | +---------------------------------------------------------------+ | 403 | | Message Handling | | 404 | | +----------------+ +-----------------+ +-----------------+ | | 405 | | | Transport | | Message | | Security | | | 406 | | | Mappings | | Processing and | | | | | 407 | | | | | Dispatcher | | | | | 408 | | +----------------+ +-----------------+ +-----------------+ | | 409 | +---------------------------------------------------------------+ | 410 | | 411 | +---------------------------------------------------------------+ | 412 | | PDU Handling | | 413 | | +----------------+ +-----------------+ +-----------------+ | | 414 | | | Protocol | | Applications | | Access | | | 415 | | | Operations | | | | Control | | | 416 | | +----------------+ +-----------------+ +-----------------+ | | 417 | +---------------------------------------------------------------+ | 418 | | 419 | +---------------------------------------------------------------+ | 420 | | Information Model | | 421 | | +--------------+ +--------------+ +---------------+ | | 422 | | | Structure of | | Textual | | Conformance | | | 423 | | | Management | | Conventions | | Statements | | | 424 | | | Information | | | | | | | 425 | | +--------------+ +--------------+ +---------------+ | | 426 | +---------------------------------------------------------------+ | 427 | | 428 | +---------------------------------------------------------------+ | 429 | | MIB Modules written in various formats, e.g.: | | 430 | | +----------------+ +----------------+ | | 431 | | | SMIv1 (STD 18) | | SMIv2 (STD 58) | | | 432 | | | format | | format | | | 433 | | +----------------+ +----------------+ | | 434 | +---------------------------------------------------------------+ | 435 | | 436 +-------------------------------------------------------------------+ 438 Any marked with an asterisk (*) are expected to be written in the 439 future. Each of these documents may be replaced or supplemented. 440 This Architecture document specifically describes how new documents 441 fit into the set of documents in the area of Message and PDU 442 handling. 444 2.1. Document Roadmap 446 One or more documents may be written to describe how sets of 447 documents taken together form specific Frameworks. The configuration 448 of document sets might change over time, so the "road map" should be 449 maintained in a document separate from the standards documents 450 themselves. 452 An example of such a roadmap is "Introduction to Version 3 of the 453 Internet-standard Network Management Framework" [RFC2570]. 455 2.2. Applicability Statement 457 SNMP is used in networks that vary widely in size and complexity, by 458 organizations that vary widely in their requirements of management. 459 Some models will be designed to address specific problems of 460 management, such as message security. 462 One or more documents may be written to describe the environments to 463 which certain versions of SNMP or models within SNMP would be 464 appropriately applied, and those to which a given model might be 465 inappropriately applied. 467 2.3. Coexistence and Transition 469 The purpose of an evolutionary architecture is to permit new models 470 to replace or supplement existing models. The interactions between 471 models could result in incompatibilities, security "holes", and other 472 undesirable effects. 474 The purpose of Coexistence documents is to detail recognized 475 anomalies and to describe required and recommended behaviors for 476 resolving the interactions between models within the architecture. 478 Coexistence documents may be prepared separately from model 479 definition documents, to describe and resolve interaction anomalies 480 between a model definition and one or more other model definitions. 482 Additionally, recommendations for transitions between models may also 483 be described, either in a coexistence document or in a separate 484 document. 486 One such coexistence document is [SNMP-COEX], "Coexistence between 487 Version 1, Version 2, and Version 3 of the Internet-standard Network 488 Management Framework". 490 2.4. Transport Mappings 492 SNMP messages are sent over various transports. It is the purpose of 493 Transport Mapping documents to define how the mapping between SNMP 494 and the transport is done. 496 2.5. Message Processing 498 A Message Processing Model document defines a message format, which 499 is typically identified by a version field in an SNMP message header. 500 The document may also define a MIB module for use in message 501 processing and for instrumentation of version-specific interactions. 503 An SNMP engine includes one or more Message Processing Models, and 504 thus may support sending and receiving multiple versions of SNMP 505 messages. 507 2.6. Security 509 Some environments require secure protocol interactions. Security is 510 normally applied at two different stages: 512 - in the transmission/receipt of messages, and 514 - in the processing of the contents of messages. 516 For purposes of this document, "security" refers to message-level 517 security; "access control" refers to the security applied to protocol 518 operations. 520 Authentication, encryption, and timeliness checking are common 521 functions of message level security. 523 A security document describes a Security Model, the threats against 524 which the model protects, the goals of the Security Model, the 525 protocols which it uses to meet those goals, and it may define a MIB 526 module to describe the data used during processing, and to allow the 527 remote configuration of message-level security parameters, such as 528 keys. 530 An SNMP engine may support multiple Security Models concurrently. 532 2.7. Access Control 534 During processing, it may be required to control access to managed 535 objects for operations. 537 An Access Control Model defines mechanisms to determine whether 538 access to a managed object should be allowed. An Access Control 539 Model may define a MIB module used during processing and to allow the 540 remote configuration of access control policies. 542 2.8. Protocol Operations 544 SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). SNMP 545 PDUs define the operations performed by the receiving SNMP engine. 546 It is the purpose of a Protocol Operations document to define the 547 operations of the protocol with respect to the processing of the 548 PDUs. Every PDU belongs to one or more of the PDU classes defined 549 below: 551 1) Read Class: 553 The Read Class contains protocol operations that retrieve 554 management information. For example, RFC -PROTO defines the 555 following protocol operations for the Read Class: GetRequest- 556 PDU, GetNextRequest-PDU, and GetBulkRequest-PDU. 558 2) Write Class: 560 The Write Class contains protocol operations which attempt to 561 modify management information. For example, RFC -PROTO defines 562 the following protocol operation for the Write Class: 563 SetRequest-PDU. 565 3) Response Class: 567 The Response Class contains protocol operations which are sent 568 in response to a previous request. For example, RFC -PROTO 569 defines the following for the Response Class: Response-PDU, 570 Report-PDU. 572 4) Notification Class: 574 The Notification Class contains protocol operations which send 575 a notification to a notification receiver application. For 576 example, RFC -PROTO defines the following operations for the 577 Notification Class: Trapv2-PDU, InformRequest-PDU. 579 5) Internal Class: 581 The Internal Class contains protocol operations which are 582 exchanged internally between SNMP engines. For example, RFC 583 -PROTO defines the following operation for the Internal Class: 584 Report-PDU. 586 The preceding five classifications are based on the functional 587 properties of a PDU. It is also useful to classify PDUs based on 588 whether a response is expected: 590 6) Confirmed Class: 592 The Confirmed Class contains all protocol operations which 593 cause the receiving SNMP engine to send back a response. For 594 example, RFC -PROTO defines the following operations for the 595 Confirmed Class: GetRequest-PDU, GetNextRequest-PDU, 596 GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU. 598 7) Unconfirmed Class: 600 The Unconfirmed Class contains all protocol operations which 601 are not acknowledged. For example, RFC -PROTO defines the 602 following operations for the Unconfirmed Class: Report-PDU, 603 Trapv2-PDU, and GetResponse-PDU. 605 An application document defines which Protocol Operations are 606 supported by the application. 608 2.9. Applications 610 An SNMP entity normally includes a number of applications. 611 Applications use the services of an SNMP engine to accomplish 612 specific tasks. They coordinate the processing of management 613 information operations, and may use SNMP messages to communicate with 614 other SNMP entities. 616 An applications document describes the purpose of an application, the 617 services required of the associated SNMP engine, and the protocol 618 operations and informational model that the application uses to 619 perform management operations. 621 An application document defines which set of documents are used to 622 specifically define the structure of management information, textual 623 conventions, conformance requirements, and operations supported by 624 the application. 626 2.10. Structure of Management Information 628 Management information is viewed as a collection of managed objects, 629 residing in a virtual information store, termed the Management 630 Information Base (MIB). Collections of related objects are defined in 631 MIB modules. 633 It is the purpose of a Structure of Management Information document 634 to establish the notation for defining objects, modules, and other 635 elements of managed information. 637 2.11. Textual Conventions 639 When designing a MIB module, it is often useful to define new types 640 similar to those defined in the SMI, but with more precise semantics, 641 or which have special semantics associated with them. These newly 642 defined types are termed textual conventions, and may be defined in 643 separate documents, or within a MIB module. 645 2.12. Conformance Statements 647 It may be useful to define the acceptable lower-bounds of 648 implementation, along with the actual level of implementation 649 achieved. It is the purpose of the Conformance Statements document to 650 define the notation used for these purposes. 652 2.13. Management Information Base Modules 654 MIB documents describe collections of managed objects which 655 instrument some aspect of a managed node. 657 2.13.1. SNMP Instrumentation MIBs 659 An SNMP MIB document may define a collection of managed objects which 660 instrument the SNMP protocol itself. In addition, MIB modules may be 661 defined within the documents which describe portions of the SNMP 662 architecture, such as the documents for Message processing Models, 663 Security Models, etc. for the purpose of instrumenting those Models, 664 and for the purpose of allowing their remote configuration. 666 2.14. SNMP Framework Documents 668 This architecture is designed to allow an orderly evolution of 669 portions of SNMP Frameworks. 671 Throughout the rest of this document, the term "subsystem" refers to 672 an abstract and incomplete specification of a portion of a Framework, 673 that is further refined by a model specification. 675 A "model" describes a specific design of a subsystem, defining 676 additional constraints and rules for conformance to the model. A 677 model is sufficiently detailed to make it possible to implement the 678 specification. 680 An "implementation" is an instantiation of a subsystem, conforming to 681 one or more specific models. 683 SNMP version 1 (SNMPv1), is the original Internet-standard Network 684 Management Framework, as described in RFCs 1155, 1157, and 1212. 686 SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the 687 SNMPv1 Framework. It is described in STD 58, RFCs 2578, 2579, 2580, 688 and RFCs -PROTO--MIB. SNMPv2 has no message definition. 690 The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP 691 Framework which supplements the SNMPv2 Framework, as described in RFC 692 1901. It adds the SNMPv2c message format, which is similar to the 693 SNMPv1 message format. 695 SNMP version 3 (SNMPv3), is an extensible SNMP Framework which 696 supplements the SNMPv2 Framework, by supporting the following: 698 - a new SNMP message format, 700 - Security for Messages, 702 - Access Control, and 704 - Remote configuration of SNMP parameters. 706 Other SNMP Frameworks, i.e., other configurations of implemented 707 subsystems, are expected to also be consistent with this 708 architecture. 710 3. Elements of the Architecture 712 This section describes the various elements of the architecture and 713 how they are named. There are three kinds of naming: 715 1) the naming of entities, 717 2) the naming of identities, and 719 3) the naming of management information. 721 This architecture also defines some names for other constructs that 722 are used in the documentation. 724 3.1. The Naming of Entities 726 An SNMP entity is an implementation of this architecture. Each such 727 SNMP entity consists of an SNMP engine and one or more associated 728 applications. 730 The following figure shows details about an SNMP entity and the 731 components within it. 733 +-------------------------------------------------------------------+ 734 | SNMP entity | 735 | | 736 | +-------------------------------------------------------------+ | 737 | | SNMP engine (identified by snmpEngineID) | | 738 | | | | 739 | | +------------+ +------------+ +-----------+ +-----------+ | | 740 | | | | | | | | | | | | 741 | | | Dispatcher | | Message | | Security | | Access | | | 742 | | | | | Processing | | Subsystem | | Control | | | 743 | | | | | Subsystem | | | | Subsystem | | | 744 | | | | | | | | | | | | 745 | | +------------+ +------------+ +-----------+ +-----------+ | | 746 | | | | 747 | +-------------------------------------------------------------+ | 748 | | 749 | +-------------------------------------------------------------+ | 750 | | Application(s) | | 751 | | | | 752 | | +-------------+ +--------------+ +--------------+ | | 753 | | | Command | | Notification | | Proxy | | | 754 | | | Generator | | Receiver | | Forwarder | | | 755 | | +-------------+ +--------------+ +--------------+ | | 756 | | | | 757 | | +-------------+ +--------------+ +--------------+ | | 758 | | | Command | | Notification | | Other | | | 759 | | | Responder | | Originator | | | | | 760 | | +-------------+ +--------------+ +--------------+ | | 761 | | | | 762 | +-------------------------------------------------------------+ | 763 | | 764 +-------------------------------------------------------------------+ 766 3.1.1. SNMP engine 768 An SNMP engine provides services for sending and receiving messages, 769 authenticating and encrypting messages, and controlling access to 770 managed objects. There is a one-to-one association between an SNMP 771 engine and the SNMP entity which contains it. 773 The engine contains: 775 1) a Dispatcher, 777 2) a Message Processing Subsystem, 779 3) a Security Subsystem, and 781 4) an Access Control Subsystem. 783 3.1.1.1. snmpEngineID 785 Within an administrative domain, an snmpEngineID is the unique and 786 unambiguous identifier of an SNMP engine. Since there is a one-to-one 787 association between SNMP engines and SNMP entities, it also uniquely 788 and unambiguously identifies the SNMP entity within that 789 administrative domain. Note that it is possible for SNMP entities in 790 different administrative domains to have the same value for 791 snmpEngineID. Federation of administrative domains may necessitate 792 assignment of new values. 794 3.1.1.2. Dispatcher 796 There is only one Dispatcher in an SNMP engine. It allows for 797 concurrent support of multiple versions of SNMP messages in the SNMP 798 engine. It does so by: 800 - sending and receiving SNMP messages to/from the network, 802 - determining the version of an SNMP message and interacting with 803 the corresponding Message Processing Model, 805 - providing an abstract interface to SNMP applications for 806 delivery of a PDU to an application. 808 - providing an abstract interface for SNMP applications that 809 allows them to send a PDU to a remote SNMP entity. 811 3.1.1.3. Message Processing Subsystem 813 The Message Processing Subsystem is responsible for preparing 814 messages for sending, and extracting data from received messages. 816 The Message Processing Subsystem potentially contains multiple 817 Message Processing Models as shown in the next figure. 819 * One or more Message Processing Models may be present. 821 +------------------------------------------------------------------+ 822 | | 823 | Message Processing Subsystem | 824 | | 825 | +------------+ +------------+ +------------+ +------------+ | 826 | | * | | * | | * | | * | | 827 | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | 828 | | Message | | Message | | Message | | Message | | 829 | | Processing | | Processing | | Processing | | Processing | | 830 | | Model | | Model | | Model | | Model | | 831 | | | | | | | | | | 832 | +------------+ +------------+ +------------+ +------------+ | 833 | | 834 +------------------------------------------------------------------+ 836 3.1.1.3.1. Message Processing Model 838 Each Message Processing Model defines the format of a particular 839 version of an SNMP message and coordinates the preparation and 840 extraction of each such version-specific message format. 842 3.1.1.4. Security Subsystem 844 The Security Subsystem provides security services such as the 845 authentication and privacy of messages and potentially contains 846 multiple Security Models as shown in the following figure 848 * One or more Security Models may be present. 850 +------------------------------------------------------------------+ 851 | | 852 | Security Subsystem | 853 | | 854 | +----------------+ +-----------------+ +-------------------+ | 855 | | * | | * | | * | | 856 | | User-Based | | Other | | Other | | 857 | | Security | | Security | | Security | | 858 | | Model | | Model | | Model | | 859 | | | | | | | | 860 | +----------------+ +-----------------+ +-------------------+ | 861 | | 862 +------------------------------------------------------------------+ 864 3.1.1.4.1. Security Model 866 A Security Model specifies the threats against which it protects, the 867 goals of its services, and the security protocols used to provide 868 security services such as authentication and privacy. 870 3.1.1.4.2. Security Protocol 872 A Security Protocol specifies the mechanisms, procedures, and MIB 873 objects used to provide a security service such as authentication or 874 privacy. 876 3.1.2. Access Control Subsystem 878 The Access Control Subsystem provides authorization services by means 879 of one or more (*) Access Control Models. 881 +------------------------------------------------------------------+ 882 | | 883 | Access Control Subsystem | 884 | | 885 | +---------------+ +-----------------+ +------------------+ | 886 | | * | | * | | * | | 887 | | View-Based | | Other | | Other | | 888 | | Access | | Access | | Access | | 889 | | Control | | Control | | Control | | 890 | | Model | | Model | | Model | | 891 | | | | | | | | 892 | +---------------+ +-----------------+ +------------------+ | 893 | | 894 +------------------------------------------------------------------+ 896 3.1.2.1. Access Control Model 898 An Access Control Model defines a particular access decision function 899 in order to support decisions regarding access rights. 901 3.1.3. Applications 903 There are several types of applications, including: 905 - command generators, which monitor and manipulate management 906 data, 908 - command responders, which provide access to management data, 910 - notification originators, which initiate asynchronous messages, 912 - notification receivers, which process asynchronous messages, 913 and 915 - proxy forwarders, which forward messages between entities. 917 These applications make use of the services provided by the SNMP 918 engine. 920 3.1.3.1. SNMP Manager 922 An SNMP entity containing one or more command generator and/or 923 notification receiver applications (along with their associated SNMP 924 engine) has traditionally been called an SNMP manager. 925 * One or more models may be present. 927 (traditional SNMP manager) 928 +-------------------------------------------------------------------+ 929 | +--------------+ +--------------+ +--------------+ SNMP entity | 930 | | NOTIFICATION | | NOTIFICATION | | COMMAND | | 931 | | ORIGINATOR | | RECEIVER | | GENERATOR | | 932 | | applications | | applications | | applications | | 933 | +--------------+ +--------------+ +--------------+ | 934 | ^ ^ ^ | 935 | | | | | 936 | v v v | 937 | +-------+--------+-----------------+ | 938 | ^ | 939 | | +---------------------+ +----------------+ | 940 | | | Message Processing | | Security | | 941 | Dispatcher v | Subsystem | | Subsystem | | 942 | +-------------------+ | +------------+ | | | | 943 | | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | | 944 | | | | | +------------+ | | | Other | | | 945 | | | | | +------------+ | | | Security | | | 946 | | | | +->| v2cMP * |<--->| | Model | | | 947 | | Message | | | +------------+ | | +------------+ | | 948 | | Dispatcher <--------->+ | | | | 949 | | | | | +------------+ | | +------------+ | | 950 | | | | +->| v3MP * |<--->| | User-based | | | 951 | | Transport | | | +------------+ | | | Security | | | 952 | | Mapping | | | +------------+ | | | Model | | | 953 | | (e.g RFC-TMM) | | +->| otherMP * |<--->| +------------+ | | 954 | +-------------------+ | +------------+ | | | | 955 | ^ +---------------------+ +----------------+ | 956 | | | 957 | v | 958 +-------------------------------------------------------------------+ 959 +-----+ +-----+ +-------+ 960 | UDP | | IPX | . . . | other | 961 +-----+ +-----+ +-------+ 962 ^ ^ ^ 963 | | | 964 v v v 965 +------------------------------+ 966 | Network | 967 +------------------------------+ 969 3.1.3.2. SNMP Agent 971 An SNMP entity containing one or more command responder and/or 972 notification originator applications (along with their associated 973 SNMP engine) has traditionally been called an SNMP agent. 975 * One or more models may be present. 977 +------------------------------+ 978 | Network | 979 +------------------------------+ 980 ^ ^ ^ 981 | | | 982 v v v 983 +-----+ +-----+ +-------+ 984 | UDP | | IPX | . . . | other | 985 +-----+ +-----+ +-------+ (traditional SNMP agent) 986 +-------------------------------------------------------------------+ 987 | ^ | 988 | | +---------------------+ +----------------+ | 989 | | | Message Processing | | Security | | 990 | Dispatcher v | Subsystem | | Subsystem | | 991 | +-------------------+ | +------------+ | | | | 992 | | Transport | | +->| v1MP * |<--->| +------------+ | | 993 | | Mapping | | | +------------+ | | | Other | | | 994 | | (e.g. RFC-TMM) | | | +------------+ | | | Security | | | 995 | | | | +->| v2cMP * |<--->| | Model | | | 996 | | Message | | | +------------+ | | +------------+ | | 997 | | Dispatcher <--------->| +------------+ | | +------------+ | | 998 | | | | +->| v3MP * |<--->| | User-based | | | 999 | | | | | +------------+ | | | Security | | | 1000 | | PDU Dispatcher | | | +------------+ | | | Model | | | 1001 | +-------------------+ | +->| otherMP * |<--->| +------------+ | | 1002 | ^ | +------------+ | | | | 1003 | | +---------------------+ +----------------+ | 1004 | v | 1005 | +-------+-------------------------+---------------+ | 1006 | ^ ^ ^ | 1007 | | | | | 1008 | v v v | 1009 | +-------------+ +---------+ +--------------+ +-------------+ | 1010 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 1011 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 1012 | | application | | | | applications | | application | | 1013 | +-------------+ +---------+ +--------------+ +-------------+ | 1014 | ^ ^ | 1015 | | | | 1016 | v v | 1017 | +----------------------------------------------+ | 1018 | | MIB instrumentation | SNMP entity | 1019 +-------------------------------------------------------------------+ 1021 3.2. The Naming of Identities 1023 principal 1024 ^ 1025 | 1026 | 1027 +----------------------------|-------------+ 1028 | SNMP engine v | 1029 | +--------------+ | 1030 | | | | 1031 | +-----------------| securityName |---+ | 1032 | | Security Model | | | | 1033 | | +--------------+ | | 1034 | | ^ | | 1035 | | | | | 1036 | | v | | 1037 | | +------------------------------+ | | 1038 | | | | | | 1039 | | | Model | | | 1040 | | | Dependent | | | 1041 | | | Security ID | | | 1042 | | | | | | 1043 | | +------------------------------+ | | 1044 | | ^ | | 1045 | | | | | 1046 | +-------------------------|----------+ | 1047 | | | 1048 | | | 1049 +----------------------------|-------------+ 1050 | 1051 v 1052 network 1054 3.2.1. Principal 1056 A principal is the "who" on whose behalf services are provided or 1057 processing takes place. 1059 A principal can be, among other things, an individual acting in a 1060 particular role; a set of individuals, with each acting in a 1061 particular role; an application or a set of applications; and 1062 combinations thereof. 1064 3.2.2. securityName 1066 A securityName is a human readable string representing a principal. 1067 It has a model-independent format, and can be used outside a 1068 particular Security Model. 1070 3.2.3. Model-dependent security ID 1072 A model-dependent security ID is the model-specific representation of 1073 a securityName within a particular Security Model. 1075 Model-dependent security IDs may or may not be human readable, and 1076 have a model-dependent syntax. Examples include community names, and 1077 user names. 1079 The transformation of model-dependent security IDs into securityNames 1080 and vice versa is the responsibility of the relevant Security Model. 1082 3.3. The Naming of Management Information 1084 Management information resides at an SNMP entity where a Command 1085 Responder Application has local access to potentially multiple 1086 contexts. This application uses a contextEngineID equal to the 1087 snmpEngineID of its associated SNMP engine. 1089 +-----------------------------------------------------------------+ 1090 | SNMP entity (identified by snmpEngineID, for example: | 1091 | '800002b804616263'H (enterpise 696, string "abc") | 1092 | | 1093 | +------------------------------------------------------------+ | 1094 | | SNMP engine (identified by snmpEngineID) | | 1095 | | | | 1096 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1097 | | | | | | | | | | | | 1098 | | | Dispatcher | | Message | | Security | | Access | | | 1099 | | | | | Processing | | Subsystem | | Control | | | 1100 | | | | | Subsystem | | | | Subsystem | | | 1101 | | | | | | | | | | | | 1102 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1103 | | | | 1104 | +------------------------------------------------------------+ | 1105 | | 1106 | +------------------------------------------------------------+ | 1107 | | Command Responder Application | | 1108 | | (contextEngineID, example: '800002b804616263'H) | | ! 1109 | | | | 1110 | | example contextNames: | | 1111 | | | | 1112 | | "bridge1" "bridge2" "" (default) | | 1113 | | --------- --------- ------------ | | 1114 | | | | | | | 1115 | +------|------------------|-------------------|--------------+ | 1116 | | | | | 1117 | +------|------------------|-------------------|--------------+ | 1118 | | MIB | instrumentation | | | | 1119 | | +---v------------+ +---v------------+ +----v-----------+ | | 1120 | | | context | | context | | context | | | 1121 | | | | | | | | | | 1122 | | | +------------+ | | +------------+ | | +------------+ | | | 1123 | | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | | 1124 | | | +------------+ | | +------------+ | | +------------+ | | | 1125 | | | | | | | | | | 1126 | | | | | | | +------------+ | | | 1127 | | | | | | | | other MIB | | | | 1128 | | | | | | | +------------+ | | | 1129 | | | | | | | | | | 1130 +-----------------------------------------------------------------+ 1132 3.3.1. An SNMP Context 1134 An SNMP context, or just "context" for short, is a collection of 1135 management information accessible by an SNMP entity. An item of 1136 management information may exist in more than one context. An SNMP 1137 entity potentially has access to many contexts. 1139 Typically, there are many instances of each managed object type 1140 within a management domain. For simplicity, the method for 1141 identifying instances specified by the MIB module does not allow each 1142 instance to be distinguished amongst the set of all instances within 1143 a management domain; rather, it allows each instance to be identified 1144 only within some scope or "context", where there are multiple such 1145 contexts within the management domain. Often, a context is a 1146 physical device, or perhaps, a logical device, although a context can 1147 also encompass multiple devices, or a subset of a single device, or 1148 even a subset of multiple devices, but a context is always defined as 1149 a subset of a single SNMP entity. Thus, in order to identify an 1150 individual item of management information within the management 1151 domain, its contextName and contextEngineID must be identified in 1152 addition to its object type and its instance. 1154 For example, the managed object type ifDescr [RFC2863], is defined as 1155 the description of a network interface. To identify the description 1156 of device-X's first network interface, four pieces of information are 1157 needed: the snmpEngineID of the SNMP entity which provides access to 1158 the management information at device-X, the contextName (device-X), 1159 the managed object type (ifDescr), and the instance ("1"). 1161 Each context has (at least) one unique identification within the 1162 management domain. The same item of management information can exist 1163 in multiple contexts. An item of management information may have 1164 multiple unique identifications. This occurs when an item of 1165 management information exists in multiple contexts, and this also 1166 occurs when a context has multiple unique identifications. 1168 The combination of a contextEngineID and a contextName unambiguously 1169 identifies a context within an administrative domain; note that there 1170 may be multiple unique combinations of contextEngineID and 1171 contextName that unambiguously identify the same context. 1173 3.3.2. contextEngineID 1175 Within an administrative domain, a contextEngineID uniquely 1176 identifies an SNMP entity that may realize an instance of a context 1177 with a particular contextName. 1179 3.3.3. contextName 1181 A contextName is used to name a context. Each contextName MUST be 1182 unique within an SNMP entity. 1184 3.3.4. scopedPDU 1186 A scopedPDU is a block of data containing a contextEngineID, a 1187 contextName, and a PDU. 1189 The PDU is an SNMP Protocol Data Unit containing information named in 1190 the context which is unambiguously identified within an 1191 administrative domain by the combination of the contextEngineID and 1192 the contextName. See, for example, RFC-PROTO for more information 1193 about SNMP PDUs. 1195 3.4. Other Constructs 1197 3.4.1. maxSizeResponseScopedPDU 1199 The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that 1200 a PDU's sender would be willing to accept. Note that the size of a 1201 scopedPDU does not include the size of the SNMP message header. 1203 3.4.2. Local Configuration Datastore 1205 The subsystems, models, and applications within an SNMP entity may 1206 need to retain their own sets of configuration information. 1208 Portions of the configuration information may be accessible as 1209 managed objects. 1211 The collection of these sets of information is referred to as an 1212 entity's Local Configuration Datastore (LCD). 1214 3.4.3. securityLevel 1216 This architecture recognizes three levels of security: 1218 - without authentication and without privacy (noAuthNoPriv) 1220 - with authentication but without privacy (authNoPriv) 1222 - with authentication and with privacy (authPriv) 1224 These three values are ordered such that noAuthNoPriv is less than 1225 authNoPriv and authNoPriv is less than authPriv. 1227 Every message has an associated securityLevel. All Subsystems 1228 (Message Processing, Security, Access Control) and applications are 1229 REQUIRED to either supply a value of securityLevel or to abide by the 1230 supplied value of securityLevel while processing the message and its 1231 contents. 1233 4. Abstract Service Interfaces 1235 Abstract service interfaces have been defined to describe the 1236 conceptual interfaces between the various subsystems within an SNMP 1237 entity. The abstract service interfaces are intended to help clarify 1238 the externally observable behavior of SNMP entities, and are not 1239 intended to constrain the structure or organization of 1240 implementations in any way. Most specifically, they should not be 1241 interpreted as APIs or as requirements statements for APIs. 1243 These abstract service interfaces are defined by a set of primitives 1244 that define the services provided and the abstract data elements that 1245 are to be passed when the services are invoked. This section lists 1246 the primitives that have been defined for the various subsystems. 1248 4.1. Dispatcher Primitives 1250 The Dispatcher typically provides services to the SNMP applications 1251 via its PDU Dispatcher. This section describes the primitives 1252 provided by the PDU Dispatcher. 1254 4.1.1. Generate Outgoing Request or Notification 1256 The PDU Dispatcher provides the following primitive for an 1257 application to send an SNMP Request or Notification to another SNMP 1258 entity: 1260 statusInformation = -- sendPduHandle if success 1261 -- errorIndication if failure 1262 sendPdu( 1263 IN transportDomain -- transport domain to be used 1264 IN transportAddress -- transport address to be used 1265 IN messageProcessingModel -- typically, SNMP version 1266 IN securityModel -- Security Model to use 1267 IN securityName -- on behalf of this principal 1268 IN securityLevel -- Level of Security requested 1269 IN contextEngineID -- data from/at this entity 1270 IN contextName -- data from/in this context 1271 IN pduVersion -- the version of the PDU 1272 IN PDU -- SNMP Protocol Data Unit 1273 IN expectResponse -- TRUE or FALSE 1274 ) 1276 4.1.2. Process Incoming Request or Notification PDU 1278 The PDU Dispatcher provides the following primitive to pass an 1279 incoming SNMP PDU to an application: 1281 processPdu( -- process Request/Notification PDU 1282 IN messageProcessingModel -- typically, SNMP version 1283 IN securityModel -- Security Model in use 1284 IN securityName -- on behalf of this principal 1285 IN securityLevel -- Level of Security 1286 IN contextEngineID -- data from/at this SNMP entity 1287 IN contextName -- data from/in this context 1288 IN pduVersion -- the version of the PDU 1289 IN PDU -- SNMP Protocol Data Unit 1290 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1291 IN stateReference -- reference to state information 1292 ) -- needed when sending a response 1294 4.1.3. Generate Outgoing Response 1296 The PDU Dispatcher provides the following primitive for an 1297 application to return an SNMP Response PDU to the PDU Dispatcher: 1299 result = -- SUCCESS or FAILURE 1300 returnResponsePdu( 1301 IN messageProcessingModel -- typically, SNMP version 1302 IN securityModel -- Security Model in use 1303 IN securityName -- on behalf of this principal 1304 IN securityLevel -- same as on incoming request 1305 IN contextEngineID -- data from/at this SNMP entity 1306 IN contextName -- data from/in this context 1307 IN pduVersion -- the version of the PDU 1308 IN PDU -- SNMP Protocol Data Unit 1309 IN maxSizeResponseScopedPDU -- maximum size sender can accept 1310 IN stateReference -- reference to state information 1311 -- as presented with the request 1312 IN statusInformation -- success or errorIndication 1313 ) -- error counter OID/value if error 1315 4.1.4. Process Incoming Response PDU 1317 The PDU Dispatcher provides the following primitive to pass an 1318 incoming SNMP Response PDU to an application: 1320 processResponsePdu( -- process Response PDU 1321 IN messageProcessingModel -- typically, SNMP version 1322 IN securityModel -- Security Model in use 1323 IN securityName -- on behalf of this principal 1324 IN securityLevel -- Level of Security 1325 IN contextEngineID -- data from/at this SNMP entity 1326 IN contextName -- data from/in this context 1327 IN pduVersion -- the version of the PDU 1328 IN PDU -- SNMP Protocol Data Unit 1329 IN statusInformation -- success or errorIndication 1330 IN sendPduHandle -- handle from sendPdu 1331 ) 1333 4.1.5. Registering Responsibility for Handling SNMP PDUs 1335 Applications can register/unregister responsibility for a specific 1336 contextEngineID, for specific pduTypes, with the PDU Dispatcher 1337 according to the following primitives. The list of particular 1338 pduTypes that an application can register for is determined by the 1339 Message Processing Model(s) supported by the SNMP entity that 1340 contains the PDU Dispatcher. 1342 statusInformation = -- success or errorIndication 1343 registerContextEngineID( 1344 IN contextEngineID -- take responsibility for this one 1345 IN pduType -- the pduType(s) to be registered 1346 ) 1348 unregisterContextEngineID( 1349 IN contextEngineID -- give up responsibility for this one 1350 IN pduType -- the pduType(s) to be unregistered 1351 ) 1353 Note that realizations of the registerContextEngineID and 1354 unregisterContextEngineID abstract service interfaces may provide 1355 implementation-specific ways for applications to register/deregister 1356 responsibility for all possible values of the contextEngineID or 1357 pduType parameters. 1359 4.2. Message Processing Subsystem Primitives 1361 The Dispatcher interacts with a Message Processing Model to process a 1362 specific version of an SNMP Message. This section describes the 1363 primitives provided by the Message Processing Subsystem. 1365 4.2.1. Prepare Outgoing SNMP Request or Notification Message 1367 The Message Processing Subsystem provides this service primitive for 1368 preparing an outgoing SNMP Request or Notification Message: 1370 statusInformation = -- success or errorIndication 1371 prepareOutgoingMessage( 1372 IN transportDomain -- transport domain to be used 1373 IN transportAddress -- transport address to be used 1374 IN messageProcessingModel -- typically, SNMP version 1375 IN securityModel -- Security Model to use 1376 IN securityName -- on behalf of this principal 1377 IN securityLevel -- Level of Security requested 1378 IN contextEngineID -- data from/at this entity 1379 IN contextName -- data from/in this context 1380 IN pduVersion -- the version of the PDU 1381 IN PDU -- SNMP Protocol Data Unit 1382 IN expectResponse -- TRUE or FALSE 1383 IN sendPduHandle -- the handle for matching 1384 -- incoming responses 1385 OUT destTransportDomain -- destination transport domain 1386 OUT destTransportAddress -- destination transport address 1387 OUT outgoingMessage -- the message to send 1388 OUT outgoingMessageLength -- its length 1389 ) 1391 4.2.2. Prepare an Outgoing SNMP Response Message 1393 The Message Processing Subsystem provides this service primitive for 1394 preparing an outgoing SNMP Response Message: 1396 result = -- SUCCESS or FAILURE 1397 prepareResponseMessage( 1398 IN messageProcessingModel -- typically, SNMP version 1399 IN securityModel -- same as on incoming request 1400 IN securityName -- same as on incoming request 1401 IN securityLevel -- same as on incoming request 1402 IN contextEngineID -- data from/at this SNMP entity 1403 IN contextName -- data from/in this context 1404 IN pduVersion -- the version of the PDU 1405 IN PDU -- SNMP Protocol Data Unit 1406 IN maxSizeResponseScopedPDU -- maximum size able to accept 1407 IN stateReference -- reference to state information 1408 -- as presented with the request 1409 IN statusInformation -- success or errorIndication 1410 -- error counter OID/value if error 1411 OUT destTransportDomain -- destination transport domain 1412 OUT destTransportAddress -- destination transport address 1413 OUT outgoingMessage -- the message to send 1414 OUT outgoingMessageLength -- its length 1415 ) 1417 4.2.3. Prepare Data Elements from an Incoming SNMP Message 1419 The Message Processing Subsystem provides this service primitive for 1420 preparing the abstract data elements from an incoming SNMP message: 1422 result = -- SUCCESS or errorIndication 1423 prepareDataElements( 1424 IN transportDomain -- origin transport domain 1425 IN transportAddress -- origin transport address 1426 IN wholeMsg -- as received from the network 1427 IN wholeMsgLength -- as received from the network 1428 OUT messageProcessingModel -- typically, SNMP version 1429 OUT securityModel -- Security Model to use 1430 OUT securityName -- on behalf of this principal 1431 OUT securityLevel -- Level of Security requested 1432 OUT contextEngineID -- data from/at this entity 1433 OUT contextName -- data from/in this context 1434 OUT pduVersion -- the version of the PDU 1435 OUT PDU -- SNMP Protocol Data Unit 1436 OUT pduType -- SNMP PDU type 1437 OUT sendPduHandle -- handle for matched request 1438 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1439 OUT statusInformation -- success or errorIndication 1440 -- error counter OID/value if error 1441 OUT stateReference -- reference to state information 1442 -- to be used for possible Response 1443 ) 1445 4.3. Access Control Subsystem Primitives 1447 Applications are the typical clients of the service(s) of the Access 1448 Control Subsystem. 1450 The following primitive is provided by the Access Control Subsystem 1451 to check if access is allowed: 1453 statusInformation = -- success or errorIndication 1454 isAccessAllowed( 1455 IN securityModel -- Security Model in use 1456 IN securityName -- principal who wants to access 1457 IN securityLevel -- Level of Security 1458 IN viewType -- read, write, or notify view 1459 IN contextName -- context containing variableName 1460 IN variableName -- OID for the managed object 1461 ) 1463 4.4. Security Subsystem Primitives 1465 The Message Processing Subsystem is the typical client of the 1466 services of the Security Subsystem. 1468 4.4.1. Generate a Request or Notification Message 1470 The Security Subsystem provides the following primitive to generate a 1471 Request or Notification message: 1473 statusInformation = 1474 generateRequestMsg( 1475 IN messageProcessingModel -- typically, SNMP version 1476 IN globalData -- message header, admin data 1477 IN maxMessageSize -- of the sending SNMP entity 1478 IN securityModel -- for the outgoing message 1479 IN securityEngineID -- authoritative SNMP entity 1480 IN securityName -- on behalf of this principal 1481 IN securityLevel -- Level of Security requested 1482 IN scopedPDU -- message (plaintext) payload 1483 OUT securityParameters -- filled in by Security Module 1484 OUT wholeMsg -- complete generated message 1485 OUT wholeMsgLength -- length of the generated message 1486 ) 1488 4.4.2. Process Incoming Message 1490 The Security Subsystem provides the following primitive to process an 1491 incoming message: 1493 statusInformation = -- errorIndication or success 1494 -- error counter OID/value if error 1495 processIncomingMsg( 1496 IN messageProcessingModel -- typically, SNMP version 1497 IN maxMessageSize -- of the sending SNMP entity 1498 IN securityParameters -- for the received message 1499 IN securityModel -- for the received message 1500 IN securityLevel -- Level of Security 1501 IN wholeMsg -- as received on the wire 1502 IN wholeMsgLength -- length as received on the wire 1503 OUT securityEngineID -- authoritative SNMP entity ! 1504 OUT securityName -- identification of the principal 1505 OUT scopedPDU, -- message (plaintext) payload 1506 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 1507 OUT securityStateReference -- reference to security state 1508 ) -- information, needed for response 1510 4.4.3. Generate a Response Message 1512 The Security Subsystem provides the following primitive to generate a 1513 Response message: 1515 statusInformation = 1516 generateResponseMsg( 1517 IN messageProcessingModel -- typically, SNMP version 1518 IN globalData -- message header, admin data 1519 IN maxMessageSize -- of the sending SNMP entity 1520 IN securityModel -- for the outgoing message 1521 IN securityEngineID -- authoritative SNMP entity 1522 IN securityName -- on behalf of this principal 1523 IN securityLevel -- for the outgoing message 1524 IN scopedPDU -- message (plaintext) payload 1525 IN securityStateReference -- reference to security state 1526 -- information from original request 1527 OUT securityParameters -- filled in by Security Module 1528 OUT wholeMsg -- complete generated message 1529 OUT wholeMsgLength -- length of the generated message 1530 ) 1532 4.5. Common Primitives 1534 These primitive(s) are provided by multiple Subsystems. 1536 4.5.1. Release State Reference Information 1538 All Subsystems which pass stateReference information also provide a 1539 primitive to release the memory that holds the referenced state 1540 information: 1542 stateRelease( 1543 IN stateReference -- handle of reference to be released 1544 ) 1546 4.6. Scenario Diagrams 1548 4.6.1. Command Generator or Notification Originator 1550 This diagram shows how a Command Generator or Notification Originator 1551 application requests that a PDU be sent, and how the response is 1552 returned (asynchronously) to that application. 1554 Command Dispatcher Message Security 1555 Generator | Processing Model 1556 | | Model | 1557 | sendPdu | | | 1558 |------------------->| | | 1559 | | prepareOutgoingMessage | | 1560 : |----------------------->| | 1561 : | | generateRequestMsg | 1562 : | |-------------------->| 1563 : | | | 1564 : | |<--------------------| 1565 : | | | 1566 : |<-----------------------| | 1567 : | | | 1568 : |------------------+ | | 1569 : | Send SNMP | | | 1570 : | Request Message | | | 1571 : | to Network | | | 1572 : | v | | 1573 : : : : : 1574 : : : : : 1575 : : : : : 1576 : | | | | 1577 : | Receive SNMP | | | 1578 : | Response Message | | | 1579 : | from Network | | | 1580 : |<-----------------+ | | 1581 : | | | 1582 : | prepareDataElements | | 1583 : |----------------------->| | 1584 : | | processIncomingMsg | 1585 : | |-------------------->| 1586 : | | | 1587 : | |<--------------------| 1588 : | | | 1589 : |<-----------------------| | 1590 | processResponsePdu | | | 1591 |<-------------------| | | 1592 | | | | 1594 4.6.2. Scenario Diagram for a Command Responder Application 1596 This diagram shows how a Command Responder or Notification Receiver 1597 application registers for handling a pduType, how a PDU is dispatched 1598 to the application after an SNMP message is received, and how the 1599 Response is (asynchronously) send back to the network. 1601 Command Dispatcher Message Security 1602 Responder | Processing Model 1603 | | Model | 1604 | | | | 1605 | registerContextEngineID | | | 1606 |------------------------>| | | 1607 |<------------------------| | | | 1608 | | Receive SNMP | | | 1609 : | Message | | | 1610 : | from Network | | | 1611 : |<-------------+ | | 1612 : | | | 1613 : |prepareDataElements | | 1614 : |------------------->| | 1615 : | | processIncomingMsg | 1616 : | |------------------->| 1617 : | | | 1618 : | |<-------------------| 1619 : | | | 1620 : |<-------------------| | 1621 | processPdu | | | 1622 |<------------------------| | | 1623 | | | | 1624 : : : : 1625 : : : : 1626 | returnResponsePdu | | | 1627 |------------------------>| | | 1628 : | prepareResponseMsg | | 1629 : |------------------->| | 1630 : | |generateResponseMsg | 1631 : | |------------------->| 1632 : | | | 1633 : | |<-------------------| 1634 : | | | 1635 : |<-------------------| | 1636 : | | | 1637 : |--------------+ | | 1638 : | Send SNMP | | | 1639 : | Message | | | 1640 : | to Network | | | 1641 : | v | | 1643 5. Managed Object Definitions for SNMP Management Frameworks 1645 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN 1647 IMPORTS 1648 MODULE-IDENTITY, OBJECT-TYPE, 1649 OBJECT-IDENTITY, 1650 snmpModules FROM SNMPv2-SMI 1651 TEXTUAL-CONVENTION FROM SNMPv2-TC 1652 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 1654 snmpFrameworkMIB MODULE-IDENTITY 1655 LAST-UPDATED "200110040532Z" 1656 ORGANIZATION "SNMPv3 Working Group" 1657 CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com 1658 Subscribe: snmpv3-request@lists.tislabs.com 1660 Co-Chair: Russ Mundy 1661 NAI Labs, 1662 Network Associates, Inc. 1663 postal: 3060 Washington Rd. 1664 Glenwood, MD 21738 1665 USA 1666 EMail: mundy@tislabs.com 1667 phone: +1 301-854-6889 1669 Co-Chair & 1670 Co-editor: David Harrington 1671 Enterasys Networks 1672 postal: 35 Industrial Way 1673 P. O. Box 5005 1674 Rochester, New Hampshire 03866-5005 1675 USA 1676 EMail: dbh@enterasys.com 1677 phone: +1 603-337-2614 1679 Co-editor: Randy Presuhn 1680 BMC Software, Inc. 1681 postal: 2141 North First Street 1682 San Jose, California 95131 1683 USA 1684 EMail: randy_presuhn@bmc.com 1685 phone: +1 408-546-1006 1686 Co-editor: Bert Wijnen 1687 Lucent Technologies 1688 postal: Schagen 33 1689 3461 GL Linschoten 1690 Netherlands 1691 EMail: bwijnen@lucent.com 1692 phone: +31 348-680-485 1693 " 1694 DESCRIPTION "The SNMP Management Architecture MIB" 1695 REVISION "200110040532Z" 1696 DESCRIPTION 1697 "This revision of this MIB module was published as 1698 . 1699 " 1700 REVISION "9901190000Z" -- 19 January 1999 1701 DESCRIPTION "Updated editors' addresses, fixed typos. 1702 Published as RFC 2571. 1703 " 1704 REVISION "9711200000Z" -- 20 November 1997 1705 DESCRIPTION "The initial version, published in RFC 2271. 1706 " 1707 ::= { snmpModules 10 } 1709 -- Textual Conventions used in the SNMP Management Architecture *** 1711 SnmpEngineID ::= TEXTUAL-CONVENTION 1712 STATUS current 1713 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1714 Objects of this type are for identification, not for 1715 addressing, even though it is possible that an 1716 address may have been used in the generation of 1717 a specific value. 1719 The value for this object may not be all zeros or 1720 all 'ff'H or the empty (zero length) string. 1722 The initial value for this object may be configured 1723 via an operator console entry or via an algorithmic 1724 function. In the latter case, the following 1725 example algorithm is recommended. 1727 In cases where there are multiple engines on the 1728 same system, the use of this algorithm is NOT 1729 appropriate, as it would result in all of those 1730 engines ending up with the same ID value. 1732 1) The very first bit is used to indicate how the 1733 rest of the data is composed. 1735 0 - as defined by enterprise using former methods 1736 that existed before SNMPv3. See item 2 below. 1738 1 - as defined by this architecture, see item 3 1739 below. 1741 Note that this allows existing uses of the 1742 engineID (also known as AgentID [RFC1910]) to 1743 co-exist with any new uses. 1745 2) The snmpEngineID has a length of 12 octets. 1747 The first four octets are set to the binary 1748 equivalent of the agent's SNMP management 1749 private enterprise number as assigned by the 1750 Internet Assigned Numbers Authority (IANA). 1751 For example, if Acme Networks has been assigned 1752 { enterprises 696 }, the first four octets would 1753 be assigned '000002b8'H. 1755 The remaining eight octets are determined via 1756 one or more enterprise-specific methods. Such 1757 methods must be designed so as to maximize the 1758 possibility that the value of this object will 1759 be unique in the agent's administrative domain. 1760 For example, it may be the IP address of the SNMP 1761 entity, or the MAC address of one of the 1762 interfaces, with each address suitably padded 1763 with random octets. If multiple methods are 1764 defined, then it is recommended that the first 1765 octet indicate the method being used and the 1766 remaining octets be a function of the method. 1768 3) The length of the octet string varies. 1770 The first four octets are set to the binary 1771 equivalent of the agent's SNMP management 1772 private enterprise number as assigned by the 1773 Internet Assigned Numbers Authority (IANA). 1774 For example, if Acme Networks has been assigned 1775 { enterprises 696 }, the first four octets would 1776 be assigned '000002b8'H. 1778 The very first bit is set to 1. For example, the 1779 above value for Acme Networks now changes to be 1780 '800002b8'H. 1782 The fifth octet indicates how the rest (6th and 1783 following octets) are formatted. The values for 1784 the fifth octet are: 1786 0 - reserved, unused. 1788 1 - IPv4 address (4 octets) 1789 lowest non-special IP address 1791 2 - IPv6 address (16 octets) 1792 lowest non-special IP address 1794 3 - MAC address (6 octets) 1795 lowest IEEE MAC address, canonical 1796 order 1798 4 - Text, administratively assigned 1799 Maximum remaining length 27 1801 5 - Octets, administratively assigned 1802 Maximum remaining length 27 1804 6-127 - reserved, unused 1806 128-255 - as defined by the enterprise ! 1807 Maximum remaining length 27 1808 " 1809 SYNTAX OCTET STRING (SIZE(5..32)) 1811 SnmpSecurityModel ::= TEXTUAL-CONVENTION 1812 STATUS current 1813 DESCRIPTION "An identifier that uniquely identifies a 1814 Security Model of the Security Subsystem within 1815 this SNMP Management Architecture. 1817 The values for securityModel are allocated as 1818 follows: 1820 - The zero value does not identify any particular 1821 security model. 1823 - Values between 1 and 255, inclusive, are reserved 1824 for standards-track Security Models and are 1825 managed by the Internet Assigned Numbers Authority 1826 (IANA). 1827 - Values greater than 255 are allocated to 1828 enterprise-specific Security Models. An 1829 enterprise-specific securityModel value is defined 1830 to be: 1832 enterpriseID * 256 + security model within 1833 enterprise 1835 For example, the fourth Security Model defined by 1836 the enterprise whose enterpriseID is 1 would be 1837 259. ! 1839 This scheme for allocation of securityModel 1840 values allows for a maximum of 255 standards- 1841 based Security Models, and for a maximum of 1842 256 Security Models per enterprise. ! 1844 It is believed that the assignment of new 1845 securityModel values will be rare in practice 1846 because the larger the number of simultaneously 1847 utilized Security Models, the larger the 1848 chance that interoperability will suffer. 1849 Consequently, it is believed that such a range 1850 will be sufficient. In the unlikely event that 1851 the standards committee finds this number to be 1852 insufficient over time, an enterprise number 1853 can be allocated to obtain an additional 256 ! 1854 possible values. ! 1856 Note that the most significant bit must be zero; ! 1857 hence, there are 23 bits allocated for various ! 1858 organizations to design and define non-standard ! 1859 securityModels. This limits the ability to ! 1860 define new proprietary implementations of Security ! 1861 Models to the first 8,388,608 enterprises. ! 1863 It is worthwhile to note that, in its encoded ! 1864 form, the securityModel value will normally ! 1865 require only a single byte since, in practice, ! 1866 the leftmost bits will be zero for most messages ! 1867 and sign extension is suppressed by the encoding ! 1868 rules. ! 1870 As of this writing, there are several values ! 1871 of securityModel defined for use with SNMP or ! 1872 reserved for use with supporting MIB objects. ! 1873 They are as follows: ! 1875 0 reserved for 'any' ! 1876 1 reserved for SNMPv1 ! 1877 2 reserved for SNMPv2c ! 1878 3 User-Based Security Model (USM) ! 1879 " ! 1880 SYNTAX INTEGER(0 .. 2147483647) ! 1882 SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION ! 1883 STATUS current ! 1884 DESCRIPTION "An identifier that uniquely identifies a Message ! 1885 Processing Model of the Message Processing ! 1886 Subsystem within this SNMP Management Architecture. 1888 The values for messageProcessingModel are 1889 allocated as follows: 1891 - Values between 0 and 255, inclusive, are 1892 reserved for standards-track Message Processing 1893 Models and are managed by the Internet Assigned 1894 Numbers Authority (IANA). 1896 - Values greater than 255 are allocated to 1897 enterprise-specific Message Processing Models. 1898 An enterprise messageProcessingModel value is 1899 defined to be: 1901 enterpriseID * 256 + 1902 messageProcessingModel within enterprise 1904 For example, the fourth Message Processing Model 1905 defined by the enterprise whose enterpriseID 1906 is 1 would be 259. ! 1908 This scheme for allocating messageProcessingModel 1909 values allows for a maximum of 255 standards- 1910 based Message Processing Models, and for a 1911 maximum of 256 Message Processing Models per ! 1912 enterprise. 1914 It is believed that the assignment of new 1915 messageProcessingModel values will be rare 1916 in practice because the larger the number of 1917 simultaneously utilized Message Processing Models, 1918 the larger the chance that interoperability 1919 will suffer. It is believed that such a range 1920 will be sufficient. In the unlikely event that 1921 the standards committee finds this number to be 1922 insufficient over time, an enterprise number 1923 can be allocated to obtain an additional 256 1924 possible values. 1926 Note that the most significant bit must be zero; 1927 hence, there are 23 bits allocated for various 1928 organizations to design and define non-standard 1929 messageProcessingModels. This limits the ability 1930 to define new proprietary implementations of 1931 Message Processing Models to the first 8,388,608 1932 enterprises. 1934 It is worthwhile to note that, in its encoded 1935 form, the messageProcessingModel value will 1936 normally require only a single byte since, in 1937 practice, the leftmost bits will be zero for 1938 most messages and sign extension is suppressed 1939 by the encoding rules. 1941 As of this writing, there are several values of 1942 messageProcessingModel defined for use with SNMP. 1943 They are as follows: 1945 0 reserved for SNMPv1 1946 1 reserved for SNMPv2c 1947 2 reserved for SNMPv2u and SNMPv2* 1948 3 reserved for SNMPv3 1949 " 1950 SYNTAX INTEGER(0 .. 2147483647) 1952 SnmpSecurityLevel ::= TEXTUAL-CONVENTION 1953 STATUS current 1954 DESCRIPTION "A Level of Security at which SNMP messages can be 1955 sent or with which operations are being processed; 1956 in particular, one of: 1958 noAuthNoPriv - without authentication and 1959 without privacy, 1960 authNoPriv - with authentication but 1961 without privacy, 1962 authPriv - with authentication and 1963 with privacy. 1965 These three values are ordered such that 1966 noAuthNoPriv is less than authNoPriv and 1967 authNoPriv is less than authPriv. 1968 " 1969 SYNTAX INTEGER { noAuthNoPriv(1), 1970 authNoPriv(2), 1971 authPriv(3) 1972 } 1974 SnmpAdminString ::= TEXTUAL-CONVENTION 1975 DISPLAY-HINT "255t" ! 1976 STATUS current 1977 DESCRIPTION "An octet string containing administrative 1978 information, preferably in human-readable form. 1980 To facilitate internationalization, this 1981 information is represented using the ISO/IEC 1982 IS 10646-1 character set, encoded as an octet 1983 string using the UTF-8 transformation format 1984 described in [RFC2279]. 1986 Since additional code points are added by 1987 amendments to the 10646 standard from time 1988 to time, implementations must be prepared to 1989 encounter any code point from 0x00000000 to 1990 0x7fffffff. Byte sequences that do not 1991 correspond to the valid UTF-8 encoding of a 1992 code point or are outside this range are 1993 prohibited. 1995 The use of control codes should be avoided. 1997 When it is necessary to represent a newline, 1998 the control code sequence CR LF should be used. 2000 The use of leading or trailing white space should 2001 be avoided. 2003 For code points not directly supported by user 2004 interface hardware or software, an alternative 2005 means of entry and display, such as hexadecimal, 2006 may be provided. 2008 For information encoded in 7-bit US-ASCII, 2009 the UTF-8 encoding is identical to the 2010 US-ASCII encoding. 2012 UTF-8 may require multiple bytes to represent a 2013 single character / code point; thus the length 2014 of this object in octets may be different from 2015 the number of characters encoded. Similarly, 2016 size constraints refer to the number of encoded 2017 octets, not the number of characters represented 2018 by an encoding. 2020 Note that when this TC is used for an object that 2021 is used or envisioned to be used as an index, then 2022 a SIZE restriction MUST be specified so that the 2023 number of sub-identifiers for any object instance 2024 does not exceed the limit of 128, as defined by 2025 [RFC-PROTO]. 2027 Note that the size of an SnmpAdminString object is 2028 measured in octets, not characters. 2029 " 2030 SYNTAX OCTET STRING (SIZE (0..255)) 2032 -- Administrative assignments *************************************** 2034 snmpFrameworkAdmin 2035 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } 2036 snmpFrameworkMIBObjects 2037 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } 2038 snmpFrameworkMIBConformance 2039 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 2041 -- the snmpEngine Group ******************************************** 2043 snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 2045 snmpEngineID OBJECT-TYPE 2046 SYNTAX SnmpEngineID 2047 MAX-ACCESS read-only 2048 STATUS current 2049 DESCRIPTION "An SNMP engine's administratively-unique identifier. 2051 This information SHOULD be stored in non-volatile 2052 storage so that it remains constant across 2053 re-initializations of the SNMP engine. 2054 " 2055 ::= { snmpEngine 1 } 2057 snmpEngineBoots OBJECT-TYPE 2058 SYNTAX INTEGER (1..2147483647) 2059 MAX-ACCESS read-only 2060 STATUS current 2061 DESCRIPTION "The number of times that the SNMP engine has 2062 (re-)initialized itself since snmpEngineID 2063 was last configured. 2064 " 2065 ::= { snmpEngine 2 } 2067 snmpEngineTime OBJECT-TYPE 2068 SYNTAX INTEGER (0..2147483647) 2069 UNITS "seconds" 2070 MAX-ACCESS read-only 2071 STATUS current 2072 DESCRIPTION "The number of seconds since the value of 2073 the snmpEngineBoots object last changed. 2074 When incrementing this object's value would 2075 cause it to exceed its maximum, 2076 snmpEngineBoots is incremented as if a 2077 re-initialization had occurred, and this 2078 object's value consequently reverts to zero. 2079 " 2080 ::= { snmpEngine 3 } 2082 snmpEngineMaxMessageSize OBJECT-TYPE 2083 SYNTAX INTEGER (484..2147483647) 2084 MAX-ACCESS read-only 2085 STATUS current 2086 DESCRIPTION "The maximum length in octets of an SNMP message 2087 which this SNMP engine can send or receive and 2088 process, determined as the minimum of the maximum 2089 message size values supported among all of the 2090 transports available to and supported by the engine. 2091 " 2092 ::= { snmpEngine 4 } 2094 -- Registration Points for Authentication and Privacy Protocols ** 2096 snmpAuthProtocols OBJECT-IDENTITY 2097 STATUS current 2098 DESCRIPTION "Registration point for standards-track 2099 authentication protocols used in SNMP Management 2100 Frameworks. 2101 " 2102 ::= { snmpFrameworkAdmin 1 } 2104 snmpPrivProtocols OBJECT-IDENTITY 2105 STATUS current 2106 DESCRIPTION "Registration point for standards-track privacy 2107 protocols used in SNMP Management Frameworks. 2108 " 2109 ::= { snmpFrameworkAdmin 2 } 2111 -- Conformance information ****************************************** 2113 snmpFrameworkMIBCompliances 2114 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} 2115 snmpFrameworkMIBGroups 2116 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} 2118 -- compliance statements 2120 snmpFrameworkMIBCompliance MODULE-COMPLIANCE 2121 STATUS current 2122 DESCRIPTION "The compliance statement for SNMP engines which 2123 implement the SNMP Management Framework MIB. 2124 " 2125 MODULE -- this module 2126 MANDATORY-GROUPS { snmpEngineGroup } 2128 ::= { snmpFrameworkMIBCompliances 1 } 2130 -- units of conformance 2132 snmpEngineGroup OBJECT-GROUP 2133 OBJECTS { 2134 snmpEngineID, 2135 snmpEngineBoots, 2136 snmpEngineTime, 2137 snmpEngineMaxMessageSize 2138 } 2139 STATUS current 2140 DESCRIPTION "A collection of objects for identifying and 2141 determining the configuration and current timeliness 2142 values of an SNMP engine. 2143 " 2144 ::= { snmpFrameworkMIBGroups 1 } 2146 END 2148 6. IANA Considerations 2150 This document defines three number spaces administered by IANA, one 2151 for security models, another for message processing models, and a 2152 third for SnmpEngineID formats. 2154 6.1. Security Models 2156 The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are 2157 in the range from 0 to 255 inclusive, and are reserved for standards- 2158 track Security Models. If this range should in the future prove 2159 insufficient, an enterprise number can be allocated to obtain an 2160 additional 256 possible values. ! 2162 As of this writing, there are several values of securityModel defined 2163 for use with SNMP or reserved for use with supporting MIB objects. 2164 They are as follows: 2165 0 reserved for 'any' 2166 1 reserved for SNMPv1 2167 2 reserved for SNMPv2c 2168 3 User-Based Security Model (USM) 2170 6.2. Message Processing Models 2172 The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by 2173 IANA are in the range 0 to 255, inclusive. Each value uniquely 2174 identifies a standards-track Message Processing Model of the Message 2175 Processing Subsystem within the SNMP Management Architecture. 2177 Should this range prove insufficient in the future, an enterprise 2178 number may be obtained for the standards committee to get an 2179 additional 256 possible values. 2181 As of this writing, there are several values of 2182 messageProcessingModel defined for use with SNMP. They are as 2183 follows: 2184 0 reserved for SNMPv1 2185 1 reserved for SNMPv2c 2186 2 reserved for SNMPv2u and SNMPv2* 2187 3 reserved for SNMPv3 2189 6.3. SnmpEngineID Formats 2191 The SnmpEngineID TEXTUAL-CONVENTION's fifth octet contains a format 2192 identifier. The values managed by IANA are in the range 6 to 127, 2193 inclusive. Each value uniquely identifies a standards-track 2194 SnmpEngineID format. 2196 7. Intellectual Property 2198 The IETF takes no position regarding the validity or scope of any 2199 intellectual property or other rights that might be claimed to 2200 pertain to the implementation or use of the technology described in 2201 this document or the extent to which any license under such rights 2202 might or might not be available; neither does it represent that it 2203 has made any effort to identify any such rights. Information on the 2204 IETF's procedures with respect to rights in standards-track and 2205 standards-related documentation can be found in BCP-11. Copies of 2206 claims of rights made available for publication and any assurances of 2207 licenses to be made available, or the result of an attempt made to 2208 obtain a general license or permission for the use of such 2209 proprietary rights by implementors or users of this specification can 2210 be obtained from the IETF Secretariat. 2212 The IETF invites any interested party to bring to its attention any 2213 copyrights, patents or patent applications, or other proprietary 2214 rights which may cover technology that may be required to practice 2215 this standard. Please address the information to the IETF Executive 2216 Director. 2218 8. Acknowledgements 2220 This document is the result of the efforts of the SNMPv3 Working 2221 Group. Some special thanks are in order to the following SNMPv3 WG 2222 members: 2224 Harald Tveit Alvestrand (Maxware) 2225 Dave Battle (SNMP Research, Inc.) 2226 Alan Beard (Disney Worldwide Services) 2227 Paul Berrevoets (SWI Systemware/Halcyon Inc.) 2228 Martin Bjorklund (Ericsson) 2229 Uri Blumenthal (IBM T.J. Watson Research Center) 2230 Jeff Case (SNMP Research, Inc.) 2231 John Curran (BBN) 2232 Mike Daniele (Compaq Computer Corporation) 2233 T. Max Devlin (Eltrax Systems) 2234 John Flick (Hewlett Packard) 2235 Rob Frye (MCI) 2236 Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) 2237 David Harrington (Cabletron Systems Inc.) 2238 Lauren Heintz (BMC Software, Inc.) 2239 N.C. Hien (IBM T.J. Watson Research Center) 2240 Michael Kirkham (InterWorking Labs, Inc.) 2241 Dave Levi (SNMP Research, Inc.) 2242 Louis A Mamakos (UUNET Technologies Inc.) 2243 Joe Marzot (Nortel Networks) 2244 Paul Meyer (Secure Computing Corporation) 2245 Keith McCloghrie (Cisco Systems) 2246 Bob Moore (IBM) 2247 Russ Mundy (TIS Labs at Network Associates) 2248 Bob Natale (ACE*COMM Corporation) 2249 Mike O'Dell (UUNET Technologies Inc.) 2250 Dave Perkins (DeskTalk) 2251 Peter Polkinghorne (Brunel University) 2252 Randy Presuhn (BMC Software, Inc.) 2253 David Reeder (TIS Labs at Network Associates) 2254 David Reid (SNMP Research, Inc.) 2255 Aleksey Romanov (Quality Quorum) 2256 Shawn Routhier (Epilogue) 2257 Juergen Schoenwaelder (TU Braunschweig) 2258 Bob Stewart (Cisco Systems) 2259 Mike Thatcher (Independent Consultant) 2260 Bert Wijnen (IBM T.J. Watson Research Center) 2262 The document is based on recommendations of the IETF Security and 2263 Administrative Framework Evolution for SNMP Advisory Team. Members 2264 of that Advisory Team were: 2266 David Harrington (Cabletron Systems Inc.) 2267 Jeff Johnson (Cisco Systems) 2268 David Levi (SNMP Research Inc.) 2269 John Linn (Openvision) 2270 Russ Mundy (Trusted Information Systems) chair 2271 Shawn Routhier (Epilogue) 2272 Glenn Waters (Nortel) 2273 Bert Wijnen (IBM T. J. Watson Research Center) 2275 As recommended by the Advisory Team and the SNMPv3 Working Group 2276 Charter, the design incorporates as much as practical from previous 2277 RFCs and drafts. As a result, special thanks are due to the authors 2278 of previous designs known as SNMPv2u and SNMPv2*: 2280 Jeff Case (SNMP Research, Inc.) 2281 David Harrington (Cabletron Systems Inc.) 2282 David Levi (SNMP Research, Inc.) 2283 Keith McCloghrie (Cisco Systems) 2284 Brian O'Keefe (Hewlett Packard) 2285 Marshall T. Rose (Dover Beach Consulting) 2286 Jon Saperia (BGS Systems Inc.) 2287 Steve Waldbusser (International Network Services) 2288 Glenn W. Waters (Bell-Northern Research Ltd.) 2290 9. Security Considerations 2292 This document describes how an implementation can include a Security 2293 Model to protect management messages and an Access Control Model to 2294 control access to management information. 2296 The level of security provided is determined by the specific Security 2297 Model implementation(s) and the specific Access Control Model 2298 implementation(s) used. 2300 Applications have access to data which is not secured. Applications 2301 SHOULD take reasonable steps to protect the data from disclosure. 2303 It is the responsibility of the purchaser of an implementation to 2304 ensure that: 2306 1) an implementation complies with the rules defined by this 2307 architecture, 2309 2) the Security and Access Control Models utilized satisfy the 2310 security and access control needs of the organization, 2312 3) the implementations of the Models and Applications comply with 2313 the model and application specifications, 2315 4) and the implementation protects configuration secrets from 2316 inadvertent disclosure. 2318 This document also contains a MIB definition module. None of the 2319 objects defined is writable, and the information they represent is 2320 not deemed to be particularly sensitive. However, if they are deemed 2321 sensitive in a particular environment, access to them should be 2322 restricted through the use of appropriately configured Security and 2323 Access Control models. 2325 10. References 2327 [RFC1155] Rose, M. and K. McCloghrie, "Structure and 2328 Identification of Management Information for 2329 TCP/IP-based internets", STD 16, RFC 1155, May 1990. 2331 [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The 2332 Simple Network Management Protocol", STD 15, RFC 1157, 2333 May 1990. 2335 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", 2336 STD 16, RFC 1212, March 1991. 2338 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2339 Rose, M. and S. Waldbusser, "Introduction to 2340 Community-based SNMPv2", RFC 1901, January 1996. 2342 [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 2343 "Structure of Management Information Version 2 (SMIv2)", 2344 STD 58, RFC 2578, April 1999. 2346 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2347 "Textual Conventions for SMIv2", STD 58, RFC 2579, April 2348 1999. 2350 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2351 "Conformance Statements for SMIv2", STD 58, RFC 2580, 2352 April 1999. 2354 [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 2355 Waldbusser, "Protocol Operations for the Simple Network 2356 Management Protocol", 2357 , October 2001. 2359 [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 2360 Waldbusser, "Transport Mappings for the Simple Network 2361 Management Protocol", 2362 , October 2363 2001. 2365 [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. 2366 Waldbusser, "Management Information Base for the Simple 2367 Network Management Protocol", 2368 , October 2001. 2370 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 2371 "Coexistence between Version 1, Version 2, and Version 3 2372 of the Internet-standard Network Management Framework", 2373 , October 2001. 2375 [RFC1909] McCloghrie, K., Editor, "An Administrative 2376 Infrastructure for SNMPv2", RFC 1909, February 1996. 2378 [RFC1910] Waters, G., Editor, "User-based Security Model for 2379 SNMPv2", RFC 1910, February 1996. 2381 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 2382 10646", RFC 2279, January, 1998. 2384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2385 Requirement Levels", BCP 14, RFC 2119, March 1997. 2387 [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in 2388 the IETF Standards Process", BCP 11, RFC 2028, October 2389 1996. 2391 [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group 2392 MIB." RFC 2863, June 2000. 2394 [SNMP-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, 2395 "Message Processing and Dispatching for the Simple 2396 Network Management Protocol (SNMP)", 2397 , October 2001. 2399 [SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 2400 Model for Version 3 of the Simple Network Management 2401 Protocol (SNMPv3)", 2402 , October 2403 2001. 2405 [SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 2406 Access Control Model for the Simple Network Management 2407 Protocol (SNMP)", , 2408 October 2001. 2410 [RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP 2411 Applications", , 2412 October 2001. 2414 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 2415 "Introduction to Version 3 of the Internet-standard 2416 Network Management Framework", RFC 2570, January 1999. 2418 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 2419 "Coexistence between Version 1, Version 2, and Version 3 2420 of the Internet-standard Network Management Framework", 2421 , October 2001. 2423 11. Editor's Addresses 2425 Bert Wijnen 2426 Lucent Technologies 2427 Schagen 33 2428 3461 GL Linschoten 2429 Netherlands 2431 Phone: +31 348-680-485 2432 EMail: bwijnen@lucent.com 2434 David Harrington 2435 Enterasys Networks 2436 Post Office Box 5005 2437 35 Industrial Way 2438 Rochester, New Hampshire 03866-5005 2439 USA 2441 Phone: +1 603-337-2614 2442 EMail: dbh@enterasys.com 2444 Randy Presuhn 2445 BMC Software, Inc. 2446 2141 North First Street 2447 San Jose, California 95131 2448 USA 2450 Phone: +1 408-546-1006 2451 Fax: +1 408-965-0359 2452 EMail: randy_presuhn@bmc.com 2454 APPENDIX A 2456 A. Guidelines for Model Designers 2458 This appendix describes guidelines for designers of models which are 2459 expected to fit into the architecture defined in this document. 2461 SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to 2462 provide trivial authentication and access control. SNMPv1 and SNMPv2c 2463 Frameworks can coexist with Frameworks designed according to this 2464 architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks 2465 could be designed to meet the requirements of this architecture, but 2466 this document does not provide guidelines for that coexistence. 2468 Within any subsystem model, there should be no reference to any 2469 specific model of another subsystem, or to data defined by a specific 2470 model of another subsystem. 2472 Transfer of data between the subsystems is deliberately described as 2473 a fixed set of abstract data elements and primitive functions which 2474 can be overloaded to satisfy the needs of multiple model definitions. 2476 Documents which define models to be used within this architecture 2477 SHOULD use the standard primitives between subsystems, possibly 2478 defining specific mechanisms for converting the abstract data 2479 elements into model-usable formats. This constraint exists to allow 2480 subsystem and model documents to be written recognizing common 2481 borders of the subsystem and model. Vendors are not constrained to 2482 recognize these borders in their implementations. 2484 The architecture defines certain standard services to be provided 2485 between subsystems, and the architecture defines abstract service 2486 interfaces to request these services. 2488 Each model definition for a subsystem SHOULD support the standard 2489 service interfaces, but whether, or how, or how well, it performs the 2490 service is dependent on the model definition. 2492 A.1. Security Model Design Requirements 2494 A.1.1. Threats 2496 A document describing a Security Model MUST describe how the model 2497 protects against the threats described under "Security Requirements 2498 of this Architecture", section 1.4. 2500 A.1.2. Security Processing 2502 Received messages MUST be validated by a Model of the Security 2503 Subsystem. Validation includes authentication and privacy processing 2504 if needed, but it is explicitly allowed to send messages which do not 2505 require authentication or privacy. 2507 A received message contains a specified securityLevel to be used 2508 during processing. All messages requiring privacy MUST also require 2509 authentication. 2511 A Security Model specifies rules by which authentication and privacy 2512 are to be done. A model may define mechanisms to provide additional 2513 security features, but the model definition is constrained to using 2514 (possibly a subset of) the abstract data elements defined in this 2515 document for transferring data between subsystems. 2517 Each Security Model may allow multiple security protocols to be used 2518 concurrently within an implementation of the model. Each Security 2519 Model defines how to determine which protocol to use, given the 2520 securityLevel and the security parameters relevant to the message. 2521 Each Security Model, with its associated protocol(s) defines how the 2522 sending/receiving entities are identified, and how secrets are 2523 configured. 2525 Authentication and Privacy protocols supported by Security Models are 2526 uniquely identified using Object Identifiers. IETF standard protocols 2527 for authentication or privacy should have an identifier defined 2528 within the snmpAuthProtocols or the snmpPrivProtocols subtrees. 2529 Enterprise specific protocol identifiers should be defined within the 2530 enterprise subtree. 2532 For privacy, the Security Model defines what portion of the message 2533 is encrypted. 2535 The persistent data used for security should be SNMP-manageable, but 2536 the Security Model defines whether an instantiation of the MIB is a 2537 conformance requirement. 2539 Security Models are replaceable within the Security Subsystem. 2540 Multiple Security Model implementations may exist concurrently within 2541 an SNMP engine. The number of Security Models defined by the SNMP 2542 community should remain small to promote interoperability. 2544 A.1.3. Validate the security-stamp in a received message 2546 A Message Processing Model requests that a Security Model: 2548 - verifies that the message has not been altered, 2550 - authenticates the identification of the principal for whom the 2551 message was generated. 2553 - decrypts the message if it was encrypted. 2555 Additional requirements may be defined by the model, and additional 2556 services may be provided by the model, but the model is constrained 2557 to use the following primitives for transferring data between 2558 subsystems. Implementations are not so constrained. 2560 A Message Processing Model uses the processIncomingMsg primitive as 2561 described in section 4.4.2. 2563 A.1.4. Security MIBs 2565 Each Security Model defines the MIB module(s) required for security 2566 processing, including any MIB module(s) required for the security 2567 protocol(s) supported. The MIB module(s) SHOULD be defined 2568 concurrently with the procedures which use the MIB module(s). The 2569 MIB module(s) are subject to normal access control rules. 2571 The mapping between the model-dependent security ID and the 2572 securityName MUST be able to be determined using SNMP, if the model- 2573 dependent MIB is instantiated and if access control policy allows 2574 access. 2576 A.1.5. Cached Security Data 2578 For each message received, the Security Model caches the state 2579 information such that a Response message can be generated using the 2580 same security information, even if the Local Configuration Datastore 2581 is altered between the time of the incoming request and the outgoing 2582 response. 2584 A Message Processing Model has the responsibility for explicitly 2585 releasing the cached data if such data is no longer needed. To enable 2586 this, an abstract securityStateReference data element is passed from 2587 the Security Model to the Message Processing Model. 2589 The cached security data may be implicitly released via the 2590 generation of a response, or explicitly released by using the 2591 stateRelease primitive, as described in section 4.5.1. 2593 A.2. Message Processing Model Design Requirements 2595 An SNMP engine contains a Message Processing Subsystem which may 2596 contain multiple Message Processing Models. 2598 The Message Processing Model MUST always (conceptually) pass the 2599 complete PDU, i.e., it never forwards less than the complete list of 2600 varBinds. 2602 A.2.1. Receiving an SNMP Message from the Network 2604 Upon receipt of a message from the network, the Dispatcher in the 2605 SNMP engine determines the version of the SNMP message and interacts 2606 with the corresponding Message Processing Model to determine the 2607 abstract data elements. 2609 A Message Processing Model specifies the SNMP Message format it 2610 supports and describes how to determine the values of the abstract 2611 data elements (like msgID, msgMaxSize, msgFlags, 2612 msgSecurityParameters, securityModel, securityLevel etc). A Message 2613 Processing Model interacts with a Security Model to provide security 2614 processing for the message using the processIncomingMsg primitive, as 2615 described in section 4.4.2. 2617 A.2.2. Sending an SNMP Message to the Network 2619 The Dispatcher in the SNMP engine interacts with a Message Processing 2620 Model to prepare an outgoing message. For that it uses the following 2621 primitives: 2623 - for requests and notifications: prepareOutgoingMessage, as 2624 described in section 4.2.1. 2626 - for response messages: prepareResponseMessage, as described in 2627 section 4.2.2. 2629 A Message Processing Model, when preparing an Outgoing SNMP Message, 2630 interacts with a Security Model to secure the message. For that it 2631 uses the following primitives: 2633 - for requests and notifications: generateRequestMsg, as 2634 described in section 4.4.1. 2636 - for response messages: generateResponseMsg as described in 2637 section 4.4.3. 2639 Once the SNMP message is prepared by a Message Processing Model, 2640 the Dispatcher sends the message to the desired address using the 2641 appropriate transport. 2643 A.3. Application Design Requirements 2645 Within an application, there may be an explicit binding to a specific 2646 SNMP message version, i.e., a specific Message Processing Model, and 2647 to a specific Access Control Model, but there should be no reference 2648 to any data defined by a specific Message Processing Model or Access 2649 Control Model. 2651 Within an application, there should be no reference to any specific 2652 Security Model, or any data defined by a specific Security Model. 2654 An application determines whether explicit or implicit access control 2655 should be applied to the operation, and, if access control is needed, 2656 which Access Control Model should be used. 2658 An application has the responsibility to define any MIB module(s) 2659 used to provide application-specific services. 2661 Applications interact with the SNMP engine to initiate messages, 2662 receive responses, receive asynchronous messages, and send responses. 2664 A.3.1. Applications that Initiate Messages 2666 Applications may request that the SNMP engine send messages 2667 containing SNMP commands or notifications using the sendPdu primitive 2668 as described in section 4.1.1. 2670 If it is desired that a message be sent to multiple targets, it is 2671 the responsibility of the application to provide the iteration. 2673 The SNMP engine assumes necessary access control has been applied to 2674 the PDU, and provides no access control services. 2676 The SNMP engine looks at the "expectResponse" parameter, and if a 2677 response is expected, then the appropriate information is cached such 2678 that a later response can be associated to this message, and can then 2679 be returned to the application. A sendPduHandle is returned to the 2680 application so it can later correspond the response with this message 2681 as well. 2683 A.3.2. Applications that Receive Responses 2685 The SNMP engine matches the incoming response messages to outstanding 2686 messages sent by this SNMP engine, and forwards the response to the 2687 associated application using the processResponsePdu primitive, as 2688 described in section 4.1.4. 2690 A.3.3. Applications that Receive Asynchronous Messages 2692 When an SNMP engine receives a message that is not the response to a 2693 request from this SNMP engine, it must determine to which application 2694 the message should be given. 2696 An Application that wishes to receive asynchronous messages registers 2697 itself with the engine using the primitive registerContextEngineID as 2698 described in section 4.1.5. 2700 An Application that wishes to stop receiving asynchronous messages 2701 should unregister itself with the SNMP engine using the primitive 2702 unregisterContextEngineID as described in section 4.1.5. 2704 Only one registration per combination of PDU type and contextEngineID 2705 is permitted at the same time. Duplicate registrations are ignored. 2706 An errorIndication will be returned to the application that attempts 2707 to duplicate a registration. 2709 All asynchronously received messages containing a registered 2710 combination of PDU type and contextEngineID are sent to the 2711 application which registered to support that combination. 2713 The engine forwards the PDU to the registered application, using the 2714 processPdu primitive, as described in section 4.1.2. 2716 A.3.4. Applications that Send Responses 2718 Request operations require responses. An application sends a 2719 response via the returnResponsePdu primitive, as described in section 2720 4.1.3. 2722 The contextEngineID, contextName, securityModel, securityName, 2723 securityLevel, and stateReference parameters are from the initial 2724 processPdu primitive. The PDU and statusInformation are the results 2725 of processing. 2727 A.4. Access Control Model Design Requirements 2729 An Access Control Model determines whether the specified securityName 2730 is allowed to perform the requested operation on a specified managed 2731 object. The Access Control Model specifies the rules by which access 2732 control is determined. 2734 The persistent data used for access control should be manageable 2735 using SNMP, but the Access Control Model defines whether an 2736 instantiation of the MIB is a conformance requirement. 2738 The Access Control Model must provide the primitive isAccessAllowed. 2740 B. Issues 2742 This section will be deleted when it is time to publish as an RFC. 2744 B.1. Open Issues 2746 These are the issues that remain to be resolved. 2748 B.2. Change Log 2750 These are the major ways in which this draft differs from RFC 2571. 2752 - Updated WG mailing list address. 2754 - Added working group co-chair. 2756 - Corrected typo in description of SnmpEngineID that led to range 2757 overlap for 127. 2759 - Updated copyright dates. 2761 - Changed "255a" to "255t" in definition of SnmpAdminString to 2762 align with current SMI. 2764 - Reworded "reserved" for value zero in DESCRIPTION of 2765 SnmpSecurityModel. 2767 - Updated editors' addresses. 2769 - Updated references. 2771 - Corrected typo / reference in document overview figure. 2773 - The algorithm for allocating security models should give 256 2774 per enterprise block, rather than 255. 2776 - The example engine ID of "abcd" is not legal. Replaced with 2778 - Added clarification that engine ID should persist across re- 2779 initializations. 2781 C. Full Copyright Statement 2783 Copyright (C) The Internet Society (2001). All Rights Reserved. 2785 This document and translations of it may be copied and furnished to 2786 others, and derivative works that comment on or otherwise explain it 2787 or assist in its implementation may be prepared, copied, published 2788 and distributed, in whole or in part, without restriction of any 2789 kind, provided that the above copyright notice and this paragraph are 2790 included on all such copies and derivative works. However, this 2791 document itself may not be modified in any way, such as by removing 2792 the copyright notice or references to the Internet Society or other 2793 Internet organizations, except as needed for the purpose of 2794 developing Internet standards in which case the procedures for 2795 copyrights defined in the Internet Standards process must be 2796 followed, or as required to translate it into languages other than 2797 English. 2799 The limited permissions granted above are perpetual and will not be 2800 revoked by the Internet Society or its successors or assigns. 2802 This document and the information contained herein is provided on an 2803 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2804 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2805 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2806 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2807 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2809 Acknowledgement 2811 Funding for the RFC Editor function is currently provided by the 2812 Internet Society.