idnits 2.17.1 draft-ietf-snmpv3-arch-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 229 has weird spacing: '...es with comma...' == Line 986 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 (10 February 1999) is 9205 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) == Unused Reference: 'RFC1155' is defined on line 2311, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 2315, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 2321, but no explicit reference was found in the text == Unused Reference: 'RFC1901' is defined on line 2324, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 2328, but no explicit reference was found in the text == Unused Reference: 'RFC1903' is defined on line 2333, but no explicit reference was found in the text == Unused Reference: 'RFC1904' is defined on line 2338, but no explicit reference was found in the text == Unused Reference: 'RFC1906' is defined on line 2348, but no explicit reference was found in the text == Unused Reference: 'RFC1907' is defined on line 2353, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 2358, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 2363, but no explicit reference was found in the text == Unused Reference: 'BCP-11' is defined on line 2375, but no explicit reference was found in the text == Unused Reference: 'SNMP-MPD' is defined on line 2381, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 2386, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 2390, but no explicit reference was found in the text == Unused Reference: 'SNMP-APPL' is defined on line 2394, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (Obsoleted by RFC 2576) ** Downref: Normative reference to an Historic RFC: RFC 1909 ** Downref: Normative reference to an Historic RFC: RFC 1910 ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2028 (ref. 'BCP-11') (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 2233 (Obsoleted by RFC 2863) -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-MPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-USM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-APPL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-INTRO' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-COEX' Summary: 18 errors (**), 0 flaws (~~), 20 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Harrington 2 Will Obsolete: 2271 Cabletron Systems, Inc. 3 R. Presuhn 4 BMC Software, Inc. 5 B. Wijnen 6 IBM T. J. Watson Research 7 10 February 1999 9 An Architecture for Describing 10 SNMP Management Frameworks 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 Abstract 38 This document describes an architecture for describing SNMP 39 Management Frameworks. The architecture is designed to be modular to 40 allow the evolution of the SNMP protocol standards over time. The 41 major portions of the architecture are an SNMP engine containing a 42 Message Processing Subsystem, a Security Subsystem and an Access 43 Control Subsystem, and possibly multiple SNMP applications which 44 provide specific functional processing of management data. 46 Table of Contents 48 1. Introduction ................................................ 5 49 1.1. Overview .................................................. 5 50 1.2. SNMP ...................................................... 5 51 1.3. Goals of this Architecture ................................ 6 52 1.4. Security Requirements of this Architecture ................ 7 53 1.5. Design Decisions .......................................... 8 54 2. Documentation Overview ...................................... 10 55 2.1. Document Roadmap .......................................... 11 56 2.2. Applicability Statement ................................... 11 57 2.3. Coexistence and Transition ................................ 11 58 2.4. Transport Mappings ........................................ 12 59 2.5. Message Processing ........................................ 12 60 2.6. Security .................................................. 12 61 2.7. Access Control ............................................ 13 62 2.8. Protocol Operations ....................................... 13 63 2.9. Applications .............................................. 14 64 2.10. Structure of Management Information ...................... 14 65 2.11. Textual Conventions ...................................... 15 66 2.12. Conformance Statements ................................... 15 67 2.13. Management Information Base Modules ...................... 15 68 2.13.1. SNMP Instrumentation MIBs .............................. 15 69 2.14. SNMP Framework Documents ................................. 15 70 3. Elements of the Architecture ................................ 16 71 3.1. The Naming of Entities .................................... 17 72 3.1.1. SNMP engine ............................................. 17 73 3.1.1.1. snmpEngineID .......................................... 18 74 3.1.1.2. Dispatcher ............................................ 18 75 3.1.1.3. Message Processing Subsystem .......................... 19 76 3.1.1.3.1. Message Processing Model ............................ 19 77 3.1.1.4. Security Subsystem .................................... 20 78 3.1.1.4.1. Security Model ...................................... 20 79 3.1.1.4.2. Security Protocol ................................... 20 80 3.1.2. Access Control Subsystem ................................ 21 81 3.1.2.1. Access Control Model .................................. 21 82 3.1.3. Applications ............................................ 21 83 3.1.3.1. SNMP Manager .......................................... 22 84 3.1.3.2. SNMP Agent ............................................ 23 85 3.2. The Naming of Identities .................................. 24 86 3.2.1. Principal ............................................... 24 87 3.2.2. securityName ............................................ 24 88 3.2.3. Model-dependent security ID ............................. 25 89 3.3. The Naming of Management Information ...................... 26 90 3.3.1. An SNMP Context ......................................... 27 91 3.3.2. contextEngineID ......................................... 27 92 3.3.3. contextName ............................................. 28 93 3.3.4. scopedPDU ............................................... 28 94 3.4. Other Constructs .......................................... 28 95 3.4.1. maxSizeResponseScopedPDU ................................ 28 96 3.4.2. Local Configuration Datastore ........................... 28 97 3.4.3. securityLevel ........................................... 28 98 4. Abstract Service Interfaces ................................. 29 99 4.1. Dispatcher Primitives ..................................... 29 100 4.1.1. Generate Outgoing Request or Notification ............... 29 101 4.1.2. Process Incoming Request or Notification PDU ............ 30 102 4.1.3. Generate Outgoing Response .............................. 31 103 4.1.4. Process Incoming Response PDU ........................... 31 104 4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 31 105 4.2. Message Processing Subsystem Primitives ................... 32 106 4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 32 107 4.2.2. Prepare an Outgoing SNMP Response Message ............... 33 108 4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 34 109 4.3. Access Control Subsystem Primitives ....................... 34 110 4.4. Security Subsystem Primitives ............................. 35 111 4.4.1. Generate a Request or Notification Message .............. 35 112 4.4.2. Process Incoming Message ................................ 35 113 4.4.3. Generate a Response Message ............................. 36 114 4.5. Common Primitives ......................................... 36 115 4.5.1. Release State Reference Information ..................... 36 116 4.6. Scenario Diagrams ......................................... 37 117 4.6.1. Command Generator or Notification Originator ............ 37 118 4.6.2. Scenario Diagram for a Command Responder Application .... 38 119 5. Managed Object Definitions for SNMP Management Frameworks ... 39 120 6. IANA Considerations ......................................... 49 121 6.1. Security Models ........................................... 49 122 6.2. Message Processing Models ................................. 49 123 6.3. SnmpEngineID Formats ...................................... 50 124 7. Intellectual Property ....................................... 50 125 8. Acknowledgements ............................................ 50 126 9. Security Considerations ..................................... 52 127 10. References ................................................. 52 128 11. Editor's Addresses ......................................... 55 129 A. Guidelines for Model Designers .............................. 56 130 A.1. Security Model Design Requirements ........................ 56 131 A.1.1. Threats ................................................. 56 132 A.1.2. Security Processing ..................................... 57 133 A.1.3. Validate the security-stamp in a received message ....... 57 134 A.1.4. Security MIBs ........................................... 58 135 A.1.5. Cached Security Data .................................... 58 136 A.2. Message Processing Model Design Requirements .............. 58 137 A.2.1. Receiving an SNMP Message from the Network .............. 59 138 A.2.2. Sending an SNMP Message to the Network .................. 59 139 A.3. Application Design Requirements ........................... 59 140 A.3.1. Applications that Initiate Messages ..................... 60 141 A.3.2. Applications that Receive Responses ..................... 60 142 A.3.3. Applications that Receive Asynchronous Messages ......... 60 143 A.3.4. Applications that Send Responses ........................ 61 144 A.4. Access Control Model Design Requirements .................. 61 145 B. Issues ...................................................... 62 146 B.1. Open Issues ............................................... 62 147 B.2. Change Log ................................................ 62 148 C. Full Copyright Statement .................................... 63 150 1. Introduction 152 1.1. Overview 154 This document defines a vocabulary for describing SNMP Management 155 Frameworks, and an architecture for describing the major portions of 156 SNMP Management Frameworks. 158 This document does not provide a general introduction to SNMP. Other 159 documents and books can provide a much better introduction to SNMP. 160 Nor does this document provide a history of SNMP. That also can be 161 found in books and other documents. 163 Section 1 describes the purpose, goals, and design decisions of this 164 architecture. 166 Section 2 describes various types of documents which define (elements 167 of) SNMP Frameworks, and how they fit into this architecture. It also 168 provides a minimal road map to the documents which have previously 169 defined SNMP frameworks. 171 Section 3 details the vocabulary of this architecture and its pieces. 172 This section is important for understanding the remaining sections, 173 and for understanding documents which are written to fit within this 174 architecture. 176 Section 4 describes the primitives used for the abstract service 177 interfaces between the various subsystems, models and applications 178 within this architecture. 180 Section 5 defines a collection of managed objects used to instrument 181 SNMP entities within this architecture. 183 Sections 6, 7, 8, 9, 10 and 11 are administrative in nature. 185 Appendix A contains guidelines for designers of Models which are 186 expected to fit within this architecture. 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 1.2. SNMP 194 An SNMP management system contains: 196 - several (potentially many) nodes, each with an SNMP entity 197 containing command responder and notification originator 198 applications, which have access to management instrumentation 199 (traditionally called agents); 201 - at least one SNMP entity containing command generator and/or 202 notification receiver applications (traditionally called a 203 manager) and, 205 - a management protocol, used to convey management information 206 between the SNMP entities. 208 SNMP entities executing command generator and notification receiver 209 applications monitor and control managed elements. Managed elements 210 are devices such as hosts, routers, terminal servers, etc., which are 211 monitored and controlled via access to their management information. 213 It is the purpose of this document to define an architecture which 214 can evolve to realize effective management in a variety of 215 configurations and environments. The architecture has been designed 216 to meet the needs of implementations of: 218 - minimal SNMP entities with command responder and/or 219 notification originator applications (traditionally called SNMP 220 agents), 222 - SNMP entities with proxy forwarder applications (traditionally 223 called SNMP proxy agents), 225 - command line driven SNMP entities with command generator and/or 226 notification receiver applications (traditionally called SNMP 227 command line managers), 229 - SNMP entities with command generator and/or notification 230 receiver, plus command responder and/or notification originator 231 applications (traditionally called SNMP mid-level managers or 232 dual-role entities), 234 - SNMP entities with command generator and/or notification 235 receiver and possibly other types of applications for managing 236 a potentially very large number of managed nodes (traditionally 237 called (network) management stations). 239 1.3. Goals of this Architecture 241 This architecture was driven by the following goals: 243 - Use existing materials as much as possible. It is heavily based 244 on previous work, informally known as SNMPv2u and SNMPv2*, 245 based in turn on SNMPv2p. 247 - Address the need for secure SET support, which is considered 248 the most important deficiency in SNMPv1 and SNMPv2c. 250 - Make it possible to move portions of the architecture forward 251 in the standards track, even if consensus has not been reached 252 on all pieces. 254 - Define an architecture that allows for longevity of the SNMP 255 Frameworks that have been and will be defined. 257 - Keep SNMP as simple as possible. 259 - Make it relatively inexpensive to deploy a minimal conforming 260 implementation. 262 - Make it possible to upgrade portions of SNMP as new approaches 263 become available, without disrupting an entire SNMP framework. 265 - Make it possible to support features required in large 266 networks, but make the expense of supporting a feature directly 267 related to the support of the feature. 269 1.4. Security Requirements of this Architecture 271 Several of the classical threats to network protocols are applicable 272 to the management problem and therefore would be applicable to any 273 Security Model used in an SNMP Management Framework. Other threats 274 are not applicable to the management problem. This section discusses 275 principal threats, secondary threats, and threats which are of lesser 276 importance. 278 The principal threats against which any Security Model used within 279 this architecture SHOULD provide protection are: 281 Modification of Information 282 The modification threat is the danger that some unauthorized 283 entity may alter in-transit SNMP messages generated on behalf 284 of an authorized principal in such a way as to effect 285 unauthorized management operations, including falsifying the 286 value of an object. 288 Masquerade 289 The masquerade threat is the danger that management operations 290 not authorized for some principal may be attempted by assuming 291 the identity of another principal that has the appropriate 292 authorizations. 294 Secondary threats against which any Security Model used within this 295 architecture SHOULD provide protection are: 297 Message Stream Modification 298 The SNMP protocol is typically based upon a connectionless 299 transport service which may operate over any subnetwork 300 service. The re-ordering, delay or replay of messages can and 301 does occur through the natural operation of many such 302 subnetwork services. The message stream modification threat is 303 the danger that messages may be maliciously re-ordered, delayed 304 or replayed to an extent which is greater than can occur 305 through the natural operation of a subnetwork service, in order 306 to effect unauthorized management operations. 308 Disclosure 309 The disclosure threat is the danger of eavesdropping on the 310 exchanges between SNMP engines. Protecting against this threat 311 may be required as a matter of local policy. 313 There are at least two threats against which a Security Model within 314 this architecture need not protect, since they are deemed to be of 315 lesser importance in this context: 317 Denial of Service 318 A Security Model need not attempt to address the broad range of 319 attacks by which service on behalf of authorized users is 320 denied. Indeed, such denial-of-service attacks are in many 321 cases indistinguishable from the type of network failures with 322 which any viable management protocol must cope as a matter of 323 course. 325 Traffic Analysis 326 A Security Model need not attempt to address traffic analysis 327 attacks. Many traffic patterns are predictable - entities may 328 be managed on a regular basis by a relatively small number of 329 management stations - and therefore there is no significant 330 advantage afforded by protecting against traffic analysis. 332 1.5. Design Decisions 334 Various design decisions were made in support of the goals of the 335 architecture and the security requirements: 337 - Architecture 338 An architecture should be defined which identifies the 339 conceptual boundaries between the documents. Subsystems should 340 be defined which describe the abstract services provided by 341 specific portions of an SNMP framework. Abstract service 342 interfaces, as described by service primitives, define the 343 abstract boundaries between documents, and the abstract 344 services that are provided by the conceptual subsystems of an 345 SNMP framework. 347 - Self-contained Documents 348 Elements of procedure plus the MIB objects which are needed for 349 processing for a specific portion of an SNMP framework should 350 be defined in the same document, and as much as possible, 351 should not be referenced in other documents. This allows pieces 352 to be designed and documented as independent and self-contained 353 parts, which is consistent with the general SNMP MIB module 354 approach. As portions of SNMP change over time, the documents 355 describing other portions of SNMP are not directly impacted. 356 This modularity allows, for example, Security Models, 357 authentication and privacy mechanisms, and message formats to 358 be upgraded and supplemented as the need arises. The self- 359 contained documents can move along the standards track on 360 different time-lines. 362 This modularity of specification is not meant to be interpreted as 363 imposing any specific requirements on implementation. 365 - Threats 366 The Security Models in the Security Subsystem SHOULD protect 367 against the principal and secondary threats: modification of 368 information, masquerade, message stream modification and 369 disclosure. They do not need to protect against denial of 370 service and traffic analysis. 372 - Remote Configuration 373 The Security and Access Control Subsystems add a whole new set 374 of SNMP configuration parameters. The Security Subsystem also 375 requires frequent changes of secrets at the various SNMP 376 entities. To make this deployable in a large operational 377 environment, these SNMP parameters must be remotely 378 configurable. 380 - Controlled Complexity 381 It is recognized that producers of simple managed devices want 382 to keep the resources used by SNMP to a minimum. At the same 383 time, there is a need for more complex configurations which can 384 spend more resources for SNMP and thus provide more 385 functionality. The design tries to keep the competing 386 requirements of these two environments in balance and allows 387 the more complex environments to logically extend the simple 388 environment. 390 2. Documentation Overview 392 The following figure shows the set of documents that fit within the 393 SNMP Architecture. 394 +------------------------- Document Set ----------------------------+ 395 | | 396 | +----------+ +-----------------+ +----------------+ | 397 | | Document | | Applicability * | | Coexistence | | 398 | | Roadmap | | Statement | | & Transition | | 399 | +----------+ +-----------------+ +----------------+ | 400 | | 401 | +---------------------------------------------------------------+ | 402 | | Message Handling | | 403 | | +----------------+ +-----------------+ +-----------------+ | | 404 | | | Transport | | Message | | Security | | | 405 | | | Mappings | | Processing and | | | | | 406 | | | | | Dispatcher | | | | | 407 | | +----------------+ +-----------------+ +-----------------+ | | 408 | +---------------------------------------------------------------+ | 409 | | 410 | +---------------------------------------------------------------+ | 411 | | PDU Handling | | 412 | | +----------------+ +-----------------+ +-----------------+ | | 413 | | | Protocol | | Applications | | Access | | | 414 | | | Operations | | | | Control | | | 415 | | +----------------+ +-----------------+ +-----------------+ | | 416 | +---------------------------------------------------------------+ | 417 | | 418 | +---------------------------------------------------------------+ | 419 | | Information Model | | 420 | | +--------------+ +--------------+ +---------------+ | | 421 | | | Structure of | | Textual | | Conformance | | | 422 | | | Management | | Conventions | | Statements | | | 423 | | | Information | | | | | | | 424 | | +--------------+ +--------------+ +---------------+ | | 425 | +---------------------------------------------------------------+ | 426 | | 427 | +---------------------------------------------------------------+ | 428 | | MIB Modules written in various formats, e.g.: | | 429 | | +-------------+ +-------------+ +----------+ +----------+ | | 430 | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | | 431 | | | RFC 1157 | | RFC 1212 | | RFC 14xx | | RFC 19xx | | | 432 | | | format | | format | | format | | format | | | 433 | | +-------------+ +-------------+ +----------+ +----------+ | | 434 | +---------------------------------------------------------------+ | 435 | | 436 +-------------------------------------------------------------------+ 437 Those marked with an asterisk (*) are expected to be written in the 438 future. Each of these documents may be replaced or supplemented. 439 This Architecture document specifically describes how new documents 440 fit into the set of documents in the area of Message and PDU 441 handling. 443 2.1. Document Roadmap 445 One or more documents may be written to describe how sets of 446 documents taken together form specific Frameworks. The configuration 447 of document sets might change over time, so the "road map" should be 448 maintained in a document separate from the standards documents 449 themselves. 451 An example of such a roadmap is "Introduction to Version 3 of the 452 Internet-standard Network Management Framework" [SNMP-INTRO]. 454 2.2. Applicability Statement 456 SNMP is used in networks that vary widely in size and complexity, by 457 organizations that vary widely in their requirements of management. 458 Some models will be designed to address specific problems of 459 management, such as message security. 461 One or more documents may be written to describe the environments to 462 which certain versions of SNMP or models within SNMP would be 463 appropriately applied, and those to which a given model might be 464 inappropriately applied. 466 2.3. Coexistence and Transition 468 The purpose of an evolutionary architecture is to permit new models 469 to replace or supplement existing models. The interactions between 470 models could result in incompatibilities, security "holes", and other 471 undesirable effects. 473 The purpose of Coexistence documents is to detail recognized 474 anomalies and to describe required and recommended behaviors for 475 resolving the interactions between models within the architecture. 477 Coexistence documents may be prepared separately from model 478 definition documents, to describe and resolve interaction anomalies 479 between a model definition and one or more other model definitions. 481 Additionally, recommendations for transitions between models may also 482 be described, either in a coexistence document or in a separate 483 document. 485 One such coexistance document is [SNMP-COEX], "Coexistence between 486 Version 1, Version 2, and Version 3 of the Internet-standard Network 487 Management Framework". 489 2.4. Transport Mappings 491 SNMP messages are sent over various transports. It is the purpose of 492 Transport Mapping documents to define how the mapping between SNMP 493 and the transport is done. 495 2.5. Message Processing 497 A Message Processing Model document defines a message format, which 498 is typically identified by a version field in an SNMP message header. 499 The document may also define a MIB module for use in message 500 processing and for instrumentation of version-specific interactions. 502 An SNMP engine includes one or more Message Processing Models, and 503 thus may support sending and receiving multiple versions of SNMP 504 messages. 506 2.6. Security 508 Some environments require secure protocol interactions. Security is 509 normally applied at two different stages: 511 - in the transmission/receipt of messages, and 513 - in the processing of the contents of messages. 515 For purposes of this document, "security" refers to message-level 516 security; "access control" refers to the security applied to protocol 517 operations. 519 Authentication, encryption, and timeliness checking are common 520 functions of message level security. 522 A security document describes a Security Model, the threats against 523 which the model protects, the goals of the Security Model, the 524 protocols which it uses to meet those goals, and it may define a MIB 525 module to describe the data used during processing, and to allow the 526 remote configuration of message-level security parameters, such as 527 keys. 529 An SNMP engine may support multiple Security Models concurrently. 531 2.7. Access Control 533 During processing, it may be required to control access to managed 534 objects for operations. 536 An Access Control Model defines mechanisms to determine whether 537 access to a managed object should be allowed. An Access Control 538 Model may define a MIB module used during processing and to allow the 539 remote configuration of access control policies. 541 2.8. Protocol Operations 543 SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). SNMP 544 PDUs define the operations performed by the receiving SNMP engine. 545 It is the purpose of a Protocol Operations document to define the 546 operations of the protocol with respect to the processing of the 547 PDUs. Every PDU belongs to one or more of the PDU classes defined 548 below: 550 1) Read Class: 552 The Read Class contains protocol operations that retrieve 553 management information. For example, RFC 1905 defines the 554 following protocol operations for the Read Class: GetRequest- 555 PDU, GetNextRequest-PDU, and GetBulkRequest-PDU. 557 2) Write Class: 559 The Write Class contains protocol operations which attempt to 560 modify management information. For example, RFC 1905 defines 561 the following protocol operation for the Write Class: 562 SetRequest-PDU. 564 3) Response Class: 566 The Response Class contains protocol operations which are sent 567 in response to a previous request. For example, RFC 1905 568 defines the following for the Response Class: Response-PDU, 569 Report-PDU. 571 4) Notification Class: 573 The Notification Class contains protocol operations which send 574 a notification to a notification receiver application. For 575 example, RFC 1905 defines the following operations for the 576 Notification Class: Trapv2-PDU, InformRequest-PDU. 578 5) Internal Class: 580 The Internal Class contains protocol operations which are 581 exchanged internally between SNMP engines. For example, RFC 582 1905 defines the following operations for the Internal Class: 583 Report-PDU. 585 The preceding five classifications are based on the functional 586 properties of a PDU. It is also useful to classify PDUs based on 587 whether a response is expected: 589 6) Confirmed Class: 591 The Confirmed Class contains all protocol operations which 592 cause the receiving SNMP engine to send back a response. For 593 example, RFC 1905 defines the following operations for the 594 Confirmed Class: GetRequest-PDU, GetNextRequest-PDU, 595 GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU. 597 7) Unconfirmed Class: 599 The Unconfirmed Class contains all protocol operations which 600 are not acknowledged. For example, RFC 1905 defines the 601 following operations for the Unconfirmed Class: Report-PDU, 602 Trapv2-PDU, and GetResponse-PDU. 604 An application document defines which Protocol Operations are 605 supported by the application. 607 2.9. Applications 609 An SNMP entity normally includes a number of applications. 610 Applications use the services of an SNMP engine to accomplish 611 specific tasks. They coordinate the processing of management 612 information operations, and may use SNMP messages to communicate with 613 other SNMP entities. 615 Applications documents describe the purpose of an application, the 616 services required of the associated SNMP engine, and the protocol 617 operations and informational model that the application uses to 618 perform management operations. 620 An application document defines which set of documents are used to 621 specifically define the structure of management information, textual 622 conventions, conformance requirements, and operations supported by 623 the application. 625 2.10. Structure of Management Information 627 Management information is viewed as a collection of managed objects, 628 residing in a virtual information store, termed the Management 629 Information Base (MIB). Collections of related objects are defined in 630 MIB modules. 632 It is the purpose of a Structure of Management Information document 633 to establish the notation for defining objects, modules, and other 634 elements of managed information. 636 2.11. Textual Conventions 638 When designing a MIB module, it is often useful to define new types 639 similar to those defined in the SMI, but with more precise semantics, 640 or which have special semantics associated with them. These newly 641 defined types are termed textual conventions, and may be defined in 642 separate documents, or within a MIB module. 644 2.12. Conformance Statements 646 It may be useful to define the acceptable lower-bounds of 647 implementation, along with the actual level of implementation 648 achieved. It is the purpose of the Conformance Statements document to 649 define the notation used for these purposes. 651 2.13. Management Information Base Modules 653 MIB documents describe collections of managed objects which 654 instrument some aspect of a managed node. 656 2.13.1. SNMP Instrumentation MIBs 658 An SNMP MIB document may define a collection of managed objects which 659 instrument the SNMP protocol itself. In addition, MIB modules may be 660 defined within the documents which describe portions of the SNMP 661 architecture, such as the documents for Message processing Models, 662 Security Models, etc. for the purpose of instrumenting those Models, 663 and for the purpose of allowing remote configuration of the Model. 665 2.14. SNMP Framework Documents 667 This architecture is designed to allow an orderly evolution of 668 portions of SNMP Frameworks. 670 Throughout the rest of this document, the term "subsystem" refers to 671 an abstract and incomplete specification of a portion of a Framework, 672 that is further refined by a model specification. 674 A "model" describes a specific design of a subsystem, defining 675 additional constraints and rules for conformance to the model. A 676 model is sufficiently detailed to make it possible to implement the 677 specification. 679 An "implementation" is an instantiation of a subsystem, conforming to 680 one or more specific models. 682 SNMP version 1 (SNMPv1), is the original Internet-standard Network 683 Management Framework, as described in RFCs 1155, 1157, and 1212. 685 SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the 686 SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no 687 message definition. 689 The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP 690 Framework which supplements the SNMPv2 Framework, as described in RFC 691 1901. It adds the SNMPv2c message format, which is similar to the 692 SNMPv1 message format. 694 SNMP version 3 (SNMPv3), is an extensible SNMP Framework which 695 supplements the SNMPv2 Framework, by supporting the following: 697 - a new SNMP message format, 699 - Security for Messages, 701 - Access Control, and 703 - Remote configuration of SNMP parameters. 705 Other SNMP Frameworks, i.e., other configurations of implemented 706 subsystems, are expected to also be consistent with this 707 architecture. 709 3. Elements of the Architecture 711 This section describes the various elements of the architecture and 712 how they are named. There are three kinds of naming: 714 1) the naming of entities, 716 2) the naming of identities, and 718 3) the naming of management information. 720 This architecture also defines some names for other constructs that 721 are used in the documentation. 723 3.1. The Naming of Entities 725 An SNMP entity is an implementation of this architecture. Each such 726 SNMP entity consists of an SNMP engine and one or more associated 727 applications. 729 The following figure shows details about an SNMP entity and the 730 components within it. 732 +-------------------------------------------------------------------+ 733 | SNMP entity | 734 | | 735 | +-------------------------------------------------------------+ | 736 | | SNMP engine (identified by snmpEngineID) | | 737 | | | | 738 | | +------------+ +------------+ +-----------+ +-----------+ | | 739 | | | | | | | | | | | | 740 | | | Dispatcher | | Message | | Security | | Access | | | 741 | | | | | Processing | | Subsystem | | Control | | | 742 | | | | | Subsystem | | | | Subsystem | | | 743 | | | | | | | | | | | | 744 | | +------------+ +------------+ +-----------+ +-----------+ | | 745 | | | | 746 | +-------------------------------------------------------------+ | 747 | | 748 | +-------------------------------------------------------------+ | 749 | | Application(s) | | 750 | | | | 751 | | +-------------+ +--------------+ +--------------+ | | 752 | | | Command | | Notification | | Proxy | | | 753 | | | Generator | | Receiver | | Forwarder | | | 754 | | +-------------+ +--------------+ +--------------+ | | 755 | | | | 756 | | +-------------+ +--------------+ +--------------+ | | 757 | | | Command | | Notification | | Other | | | 758 | | | Responder | | Originator | | | | | 759 | | +-------------+ +--------------+ +--------------+ | | 760 | | | | 761 | +-------------------------------------------------------------+ | 762 | | 763 +-------------------------------------------------------------------+ 765 3.1.1. SNMP engine 767 An SNMP engine provides services for sending and receiving messages, 768 authenticating and encrypting messages, and controlling access to 769 managed objects. There is a one-to-one association between an SNMP 770 engine and the SNMP entity which contains it. 772 The engine contains: 774 1) a Dispatcher, 776 2) a Message Processing Subsystem, 778 3) a Security Subsystem, and 780 4) an Access Control Subsystem. 782 3.1.1.1. snmpEngineID 784 Within an administrative domain, an snmpEngineID is the unique and 785 unambiguous identifier of an SNMP engine. Since there is a one-to-one 786 association between SNMP engines and SNMP entities, it also uniquely 787 and unambiguously identifies the SNMP entity within that 788 administrative domain. Note that it is possible for SNMP entities in 789 different administrative domains to have the same value for 790 snmpEngineID. Federation of administrative domains may necessitate 791 assignment of new values. 793 3.1.1.2. Dispatcher 795 There is only one Dispatcher in an SNMP engine. It allows for 796 concurrent support of multiple versions of SNMP messages in the SNMP 797 engine. It does so by: 799 - sending and receiving SNMP messages to/from the network, 801 - determining the version of an SNMP message and interacting with 802 the corresponding Message Processing Model, 804 - providing an abstract interface to SNMP applications for 805 delivery of a PDU to an application. 807 - providing an abstract interface for SNMP applications that 808 allows them to send a PDU to a remote SNMP entity. 810 3.1.1.3. Message Processing Subsystem 812 The Message Processing Subsystem is responsible for preparing 813 messages for sending, and extracting data from received messages. 815 The Message Processing Subsystem potentially contains multiple 816 Message Processing Models as shown in the next figure. 818 * One or more Message Processing Models may be present. 820 +------------------------------------------------------------------+ 821 | | 822 | Message Processing Subsystem | 823 | | 824 | +------------+ +------------+ +------------+ +------------+ | 825 | | * | | * | | * | | * | | 826 | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | 827 | | Message | | Message | | Message | | Message | | 828 | | Processing | | Processing | | Processing | | Processing | | 829 | | Model | | Model | | Model | | Model | | 830 | | | | | | | | | | 831 | +------------+ +------------+ +------------+ +------------+ | 832 | | 833 +------------------------------------------------------------------+ 835 3.1.1.3.1. Message Processing Model 837 Each Message Processing Model defines the format of a particular 838 version of an SNMP message and coordinates the preparation and 839 extraction of each such version-specific message format. 841 3.1.1.4. Security Subsystem 843 The Security Subsystem provides security services such as the 844 authentication and privacy of messages and potentially contains 845 multiple Security Models as shown in the following figure 847 * One or more Security Models may be present. 849 +------------------------------------------------------------------+ 850 | | 851 | Security Subsystem | 852 | | 853 | +----------------+ +-----------------+ +-------------------+ | 854 | | * | | * | | * | | 855 | | User-Based | | Other | | Other | | 856 | | Security | | Security | | Security | | 857 | | Model | | Model | | Model | | 858 | | | | | | | | 859 | +----------------+ +-----------------+ +-------------------+ | 860 | | 861 +------------------------------------------------------------------+ 863 3.1.1.4.1. Security Model 865 A Security Model specifies the threats against which it protects, the 866 goals of its services, and the security protocols used to provide 867 security services such as authentication and privacy. 869 3.1.1.4.2. Security Protocol 871 A Security Protocol specifies the mechanisms, procedures, and MIB 872 objects used to provide a security service such as authentication or 873 privacy. 875 3.1.2. Access Control Subsystem 877 The Access Control Subsystem provides authorization services by means 878 of one or more (*) Access Control Models. 880 +------------------------------------------------------------------+ 881 | | 882 | Access Control Subsystem | 883 | | 884 | +---------------+ +-----------------+ +------------------+ | 885 | | * | | * | | * | | 886 | | View-Based | | Other | | Other | | 887 | | Access | | Access | | Access | | 888 | | Control | | Control | | Control | | 889 | | Model | | Model | | Model | | 890 | | | | | | | | 891 | +---------------+ +-----------------+ +------------------+ | 892 | | 893 +------------------------------------------------------------------+ 895 3.1.2.1. Access Control Model 897 An Access Control Model defines a particular access decision function 898 in order to support decisions regarding access rights. 900 3.1.3. Applications 902 There are several types of applications, including: 904 - command generators, which monitor and manipulate management 905 data, 907 - command responders, which provide access to management data, 909 - notification originators, which initiate asynchronous messages, 911 - notification receivers, which process asynchronous messages, 912 and 914 - proxy forwarders, which forward messages between entities. 916 These applications make use of the services provided by the SNMP 917 engine. 919 3.1.3.1. SNMP Manager 921 An SNMP entity containing one or more command generator and/or 922 notification receiver applications (along with their associated SNMP 923 engine) has traditionally been called an SNMP manager. 924 * One or more models may be present. 926 (traditional SNMP manager) 927 +-------------------------------------------------------------------+ 928 | +--------------+ +--------------+ +--------------+ SNMP entity | 929 | | NOTIFICATION | | NOTIFICATION | | COMMAND | | 930 | | ORIGINATOR | | RECEIVER | | GENERATOR | | 931 | | applications | | applications | | applications | | 932 | +--------------+ +--------------+ +--------------+ | 933 | ^ ^ ^ | 934 | | | | | 935 | v v v | 936 | +-------+--------+-----------------+ | 937 | ^ | 938 | | +---------------------+ +----------------+ | 939 | | | Message Processing | | Security | | 940 | Dispatcher v | Subsystem | | Subsystem | | 941 | +-------------------+ | +------------+ | | | | 942 | | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | | 943 | | | | | +------------+ | | | Other | | | 944 | | | | | +------------+ | | | Security | | | 945 | | | | +->| v2cMP * |<--->| | Model | | | 946 | | Message | | | +------------+ | | +------------+ | | 947 | | Dispatcher <--------->+ | | | | 948 | | | | | +------------+ | | +------------+ | | 949 | | | | +->| v3MP * |<--->| | User-based | | | 950 | | Transport | | | +------------+ | | | Security | | | 951 | | Mapping | | | +------------+ | | | Model | | | 952 | | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | | 953 | +-------------------+ | +------------+ | | | | 954 | ^ +---------------------+ +----------------+ | 955 | | | 956 | v | 957 +-------------------------------------------------------------------+ 958 +-----+ +-----+ +-------+ 959 | UDP | | IPX | . . . | other | 960 +-----+ +-----+ +-------+ 961 ^ ^ ^ 962 | | | 963 v v v 964 +------------------------------+ 965 | Network | 966 +------------------------------+ 968 3.1.3.2. SNMP Agent 970 An SNMP entity containing one or more command responder and/or 971 notification originator applications (along with their associated 972 SNMP engine) has traditionally been called an SNMP agent. 973 +------------------------------+ 974 | Network | 975 +------------------------------+ 976 ^ ^ ^ 977 | | | 978 v v v 979 +-----+ +-----+ +-------+ 980 | UDP | | IPX | . . . | other | 981 +-----+ +-----+ +-------+ (traditional SNMP agent) 982 +-------------------------------------------------------------------+ 983 | ^ | 984 | | +---------------------+ +----------------+ | 985 | | | Message Processing | | Security | | 986 | Dispatcher v | Subsystem | | Subsystem | | 987 | +-------------------+ | +------------+ | | | | 988 | | Transport | | +->| v1MP * |<--->| +------------+ | | 989 | | Mapping | | | +------------+ | | | Other | | | 990 | | (e.g. RFC1906) | | | +------------+ | | | Security | | | 991 | | | | +->| v2cMP * |<--->| | Model | | | 992 | | Message | | | +------------+ | | +------------+ | | 993 | | Dispatcher <--------->| +------------+ | | +------------+ | | 994 | | | | +->| v3MP * |<--->| | User-based | | | 995 | | | | | +------------+ | | | Security | | | 996 | | PDU Dispatcher | | | +------------+ | | | Model | | | 997 | +-------------------+ | +->| otherMP * |<--->| +------------+ | | 998 | ^ | +------------+ | | | | 999 | | +---------------------+ +----------------+ | 1000 | v | 1001 | +-------+-------------------------+---------------+ | 1002 | ^ ^ ^ | 1003 | | | | | 1004 | v v v | 1005 | +-------------+ +---------+ +--------------+ +-------------+ | 1006 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | | 1007 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 1008 | | application | | | | applications | | application | | 1009 | +-------------+ +---------+ +--------------+ +-------------+ | 1010 | ^ ^ | 1011 | | | | 1012 | v v | 1013 | +----------------------------------------------+ | 1014 | | MIB instrumentation | SNMP entity | 1015 +-------------------------------------------------------------------+ 1017 3.2. The Naming of Identities 1019 principal 1020 ^ 1021 | 1022 | 1023 +----------------------------|-------------+ 1024 | SNMP engine v | 1025 | +--------------+ | 1026 | | | | 1027 | +-----------------| securityName |---+ | 1028 | | Security Model | | | | 1029 | | +--------------+ | | 1030 | | ^ | | 1031 | | | | | 1032 | | v | | 1033 | | +------------------------------+ | | 1034 | | | | | | 1035 | | | Model | | | 1036 | | | Dependent | | | 1037 | | | Security ID | | | 1038 | | | | | | 1039 | | +------------------------------+ | | 1040 | | ^ | | 1041 | | | | | 1042 | +-------------------------|----------+ | 1043 | | | 1044 | | | 1045 +----------------------------|-------------+ 1046 | 1047 v 1048 network 1050 3.2.1. Principal 1052 A principal is the "who" on whose behalf services are provided or 1053 processing takes place. 1055 A principal can be, among other things, an individual acting in a 1056 particular role; a set of individuals, with each acting in a 1057 particular role; an application or a set of applications; and 1058 combinations thereof. 1060 3.2.2. securityName 1062 A securityName is a human readable string representing a principal. 1063 It has a model-independent format, and can be used outside a 1064 particular Security Model. 1066 3.2.3. Model-dependent security ID 1068 A model-dependent security ID is the model-specific representation of 1069 a securityName within a particular Security Model. 1071 Model-dependent security IDs may or may not be human readable, and 1072 have a model-dependent syntax. Examples include community names, and 1073 user names. 1075 The transformation of model-dependent security IDs into securityNames 1076 and vice versa is the responsibility of the relevant Security Model. 1078 3.3. The Naming of Management Information 1080 Management information resides at an SNMP entity where a Command 1081 Responder Application has local access to potentially multiple 1082 contexts. This application uses a contextEngineID equal to the 1083 snmpEngineID of its associated SNMP engine. 1085 +-----------------------------------------------------------------+ 1086 | SNMP entity (identified by snmpEngineID, example: abcd) | 1087 | | 1088 | +------------------------------------------------------------+ | 1089 | | SNMP engine (identified by snmpEngineID) | | 1090 | | | | 1091 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1092 | | | | | | | | | | | | 1093 | | | Dispatcher | | Message | | Security | | Access | | | 1094 | | | | | Processing | | Subsystem | | Control | | | 1095 | | | | | Subsystem | | | | Subsystem | | | 1096 | | | | | | | | | | | | 1097 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1098 | | | | 1099 | +------------------------------------------------------------+ | 1100 | | 1101 | +------------------------------------------------------------+ | 1102 | | Command Responder Application | | 1103 | | (contextEngineID, example: abcd) | | 1104 | | | | 1105 | | example contextNames: | | 1106 | | | | 1107 | | "bridge1" "bridge2" "" (default) | | 1108 | | --------- --------- ------------ | | 1109 | | | | | | | 1110 | +------|------------------|-------------------|--------------+ | 1111 | | | | | 1112 | +------|------------------|-------------------|--------------+ | 1113 | | MIB | instrumentation | | | | 1114 | | +---v------------+ +---v------------+ +----v-----------+ | | 1115 | | | context | | context | | context | | | 1116 | | | | | | | | | | 1117 | | | +------------+ | | +------------+ | | +------------+ | | | 1118 | | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | | 1119 | | | +------------+ | | +------------+ | | +------------+ | | | 1120 | | | | | | | | | | 1121 | | | | | | | +------------+ | | | 1122 | | | | | | | | other MIB | | | | 1123 | | | | | | | +------------+ | | | 1124 | | | | | | | | | | 1125 +-----------------------------------------------------------------+ 1127 3.3.1. An SNMP Context 1129 An SNMP context, or just "context" for short, is a collection of 1130 management information accessible by an SNMP entity. An item of 1131 management information may exist in more than one context. An SNMP 1132 entity potentially has access to many contexts. 1134 Typically, there are many instances of each managed object type 1135 within a management domain. For simplicity, the method for 1136 identifying instances specified by the MIB module does not allow each 1137 instance to be distinguished amongst the set of all instances within 1138 a management domain; rather, it allows each instance to be identified 1139 only within some scope or "context", where there are multiple such 1140 contexts within the management domain. Often, a context is a 1141 physical device, or perhaps, a logical device, although a context can 1142 also encompass multiple devices, or a subset of a single device, or 1143 even a subset of multiple devices, but a context is always defined as 1144 a subset of a single SNMP entity. Thus, in order to identify an 1145 individual item of management information within the management 1146 domain, its contextName and contextEngineID must be identified in 1147 addition to its object type and its instance. 1149 For example, the managed object type ifDescr [RFC2233], is defined as 1150 the description of a network interface. To identify the description 1151 of device-X's first network interface, four pieces of information are 1152 needed: the snmpEngineID of the SNMP entity which provides access to 1153 the management information at device-X, the contextName (device-X), 1154 the managed object type (ifDescr), and the instance ("1"). 1156 Each context has (at least) one unique identification within the 1157 management domain. The same item of management information can exist 1158 in multiple contexts. An item of management information may have 1159 multiple unique identifications. This occurs when an item of 1160 management information exists in multiple contexts, and this also 1161 occurs when a context has multiple unique identifications. 1163 The combination of a contextEngineID and a contextName unambiguously 1164 identifies a context within an administrative domain; note that there 1165 may be multiple unique combinations of contextEngineID and 1166 contextName that unambiguously identify the same context. 1168 3.3.2. contextEngineID 1170 Within an administrative domain, a contextEngineID uniquely 1171 identifies an SNMP entity that may realize an instance of a context 1172 with a particular contextName. 1174 3.3.3. contextName 1176 A contextName is used to name a context. Each contextName MUST be 1177 unique within an SNMP entity. 1179 3.3.4. scopedPDU 1181 A scopedPDU is a block of data containing a contextEngineID, a 1182 contextName, and a PDU. 1184 The PDU is an SNMP Protocol Data Unit containing information named in 1185 the context which is unambiguously identified within an 1186 administrative domain by the combination of the contextEngineID and 1187 the contextName. See, for example, RFC1905 for more information about 1188 SNMP PDUs. 1190 3.4. Other Constructs 1192 3.4.1. maxSizeResponseScopedPDU 1194 The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that 1195 a PDU's sender would be willing to accept. Note that the size of a 1196 scopedPDU does not include the size of the SNMP message header. 1198 3.4.2. Local Configuration Datastore 1200 The subsystems, models, and applications within an SNMP entity may 1201 need to retain their own sets of configuration information. 1203 Portions of the configuration information may be accessible as 1204 managed objects. 1206 The collection of these sets of information is referred to as an 1207 entity's Local Configuration Datastore (LCD). 1209 3.4.3. securityLevel 1211 This architecture recognizes three levels of security: 1213 - without authentication and without privacy (noAuthNoPriv) 1215 - with authentication but without privacy (authNoPriv) 1217 - with authentication and with privacy (authPriv) 1219 These three values are ordered such that noAuthNoPriv is less than 1220 authNoPriv and authNoPriv is less than authPriv. 1222 Every message has an associated securityLevel. All Subsystems 1223 (Message Processing, Security, Access Control) and applications are 1224 REQUIRED to either supply a value of securityLevel or to abide by the 1225 supplied value of securityLevel while processing the message and its 1226 contents. 1228 4. Abstract Service Interfaces 1230 Abstract service interfaces have been defined to describe the 1231 conceptual interfaces between the various subsystems within an SNMP 1232 entity. The abstract service interfaces are intended to help clarify 1233 the externally observable behavior of SNMP entities, and are not 1234 intended to constrain the structure or organization of 1235 implementations in any way. Most specifically, they should not be 1236 interpreted as APIs or as requirements statements for APIs. 1238 These abstract service interfaces are defined by a set of primitives 1239 that define the services provided and the abstract data elements that 1240 are to be passed when the services are invoked. This section lists 1241 the primitives that have been defined for the various subsystems. 1243 4.1. Dispatcher Primitives 1245 The Dispatcher typically provides services to the SNMP applications 1246 via its PDU Dispatcher. This section describes the primitives 1247 provided by the PDU Dispatcher. 1249 4.1.1. Generate Outgoing Request or Notification 1251 The PDU Dispatcher provides the following primitive for an 1252 application to send an SNMP Request or Notification to another SNMP 1253 entity: 1255 statusInformation = -- sendPduHandle if success 1256 -- errorIndication if failure 1257 sendPdu( 1258 IN transportDomain -- transport domain to be used 1259 IN transportAddress -- transport address to be used 1260 IN messageProcessingModel -- typically, SNMP version 1261 IN securityModel -- Security Model to use 1262 IN securityName -- on behalf of this principal 1263 IN securityLevel -- Level of Security requested 1264 IN contextEngineID -- data from/at this entity 1265 IN contextName -- data from/in this context 1266 IN pduVersion -- the version of the PDU 1267 IN PDU -- SNMP Protocol Data Unit 1268 IN expectResponse -- TRUE or FALSE 1269 ) 1271 4.1.2. Process Incoming Request or Notification PDU 1273 The PDU Dispatcher provides the following primitive to pass an 1274 incoming SNMP PDU to an application: 1276 processPdu( -- process Request/Notification PDU 1277 IN messageProcessingModel -- typically, SNMP version 1278 IN securityModel -- Security Model in use 1279 IN securityName -- on behalf of this principal 1280 IN securityLevel -- Level of Security 1281 IN contextEngineID -- data from/at this SNMP entity 1282 IN contextName -- data from/in this context 1283 IN pduVersion -- the version of the PDU 1284 IN PDU -- SNMP Protocol Data Unit 1285 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1286 IN stateReference -- reference to state information 1287 ) -- needed when sending a response 1289 4.1.3. Generate Outgoing Response 1291 The PDU Dispatcher provides the following primitive for an 1292 application to return an SNMP Response PDU to the PDU Dispatcher: 1294 result = -- SUCCESS or FAILURE 1295 returnResponsePdu( 1296 IN messageProcessingModel -- typically, SNMP version 1297 IN securityModel -- Security Model in use 1298 IN securityName -- on behalf of this principal 1299 IN securityLevel -- same as on incoming request 1300 IN contextEngineID -- data from/at this SNMP entity 1301 IN contextName -- data from/in this context 1302 IN pduVersion -- the version of the PDU 1303 IN PDU -- SNMP Protocol Data Unit 1304 IN maxSizeResponseScopedPDU -- maximum size sender can accept 1305 IN stateReference -- reference to state information 1306 -- as presented with the request 1307 IN statusInformation -- success or errorIndication 1308 ) -- error counter OID/value if error 1310 4.1.4. Process Incoming Response PDU 1312 The PDU Dispatcher provides the following primitive to pass an 1313 incoming SNMP Response PDU to an application: 1315 processResponsePdu( -- process Response PDU 1316 IN messageProcessingModel -- typically, SNMP version 1317 IN securityModel -- Security Model in use 1318 IN securityName -- on behalf of this principal 1319 IN securityLevel -- Level of Security 1320 IN contextEngineID -- data from/at this SNMP entity 1321 IN contextName -- data from/in this context 1322 IN pduVersion -- the version of the PDU 1323 IN PDU -- SNMP Protocol Data Unit 1324 IN statusInformation -- success or errorIndication 1325 IN sendPduHandle -- handle from sendPdu 1326 ) 1328 4.1.5. Registering Responsibility for Handling SNMP PDUs 1330 Applications can register/unregister responsibility for a specific 1331 contextEngineID, for specific pduTypes, with the PDU Dispatcher 1332 according to the following primitives. The list of particular 1333 pduTypes that an application can register for is determined by the 1334 Message Processing Model(s) supported by the SNMP entity that 1335 contains the PDU Dispatcher. 1337 statusInformation = -- success or errorIndication 1338 registerContextEngineID( 1339 IN contextEngineID -- take responsibility for this one 1340 IN pduType -- the pduType(s) to be registered 1341 ) 1343 unregisterContextEngineID( 1344 IN contextEngineID -- give up responsibility for this one 1345 IN pduType -- the pduType(s) to be unregistered 1346 ) 1348 Note that realizations of the registerContextEngineID and 1349 unregisterContextEngineID abstract service interfaces may provide 1350 implementation-specific ways for applications to register/deregister 1351 responsibility for all possible values of the contextEngineID or 1352 pduType parameters. 1354 4.2. Message Processing Subsystem Primitives 1356 The Dispatcher interacts with a Message Processing Model to process a 1357 specific version of an SNMP Message. This section describes the 1358 primitives provided by the Message Processing Subsystem. 1360 4.2.1. Prepare Outgoing SNMP Request or Notification Message 1362 The Message Processing Subsystem provides this service primitive for 1363 preparing an outgoing SNMP Request or Notification Message: 1365 statusInformation = -- success or errorIndication 1366 prepareOutgoingMessage( 1367 IN transportDomain -- transport domain to be used 1368 IN transportAddress -- transport address to be used 1369 IN messageProcessingModel -- typically, SNMP version 1370 IN securityModel -- Security Model to use 1371 IN securityName -- on behalf of this principal 1372 IN securityLevel -- Level of Security requested 1373 IN contextEngineID -- data from/at this entity 1374 IN contextName -- data from/in this context 1375 IN pduVersion -- the version of the PDU 1376 IN PDU -- SNMP Protocol Data Unit 1377 IN expectResponse -- TRUE or FALSE 1378 IN sendPduHandle -- the handle for matching 1379 -- incoming responses 1380 OUT destTransportDomain -- destination transport domain 1381 OUT destTransportAddress -- destination transport address 1382 OUT outgoingMessage -- the message to send 1383 OUT outgoingMessageLength -- its length 1384 ) 1386 4.2.2. Prepare an Outgoing SNMP Response Message 1388 The Message Processing Subsystem provides this service primitive for 1389 preparing an outgoing SNMP Response Message: 1391 result = -- SUCCESS or FAILURE 1392 prepareResponseMessage( 1393 IN messageProcessingModel -- typically, SNMP version 1394 IN securityModel -- same as on incoming request 1395 IN securityName -- same as on incoming request 1396 IN securityLevel -- same as on incoming request 1397 IN contextEngineID -- data from/at this SNMP entity 1398 IN contextName -- data from/in this context 1399 IN pduVersion -- the version of the PDU 1400 IN PDU -- SNMP Protocol Data Unit 1401 IN maxSizeResponseScopedPDU -- maximum size able to accept 1402 IN stateReference -- reference to state information 1403 -- as presented with the request 1404 IN statusInformation -- success or errorIndication 1405 -- error counter OID/value if error 1406 OUT destTransportDomain -- destination transport domain 1407 OUT destTransportAddress -- destination transport address 1408 OUT outgoingMessage -- the message to send 1409 OUT outgoingMessageLength -- its length 1410 ) 1412 4.2.3. Prepare Data Elements from an Incoming SNMP Message 1414 The Message Processing Subsystem provides this service primitive for 1415 preparing the abstract data elements from an incoming SNMP message: 1417 result = -- SUCCESS or errorIndication 1418 prepareDataElements( 1419 IN transportDomain -- origin transport domain 1420 IN transportAddress -- origin transport address 1421 IN wholeMsg -- as received from the network 1422 IN wholeMsgLength -- as received from the network 1423 OUT messageProcessingModel -- typically, SNMP version 1424 OUT securityModel -- Security Model to use 1425 OUT securityName -- on behalf of this principal 1426 OUT securityLevel -- Level of Security requested 1427 OUT contextEngineID -- data from/at this entity 1428 OUT contextName -- data from/in this context 1429 OUT pduVersion -- the version of the PDU 1430 OUT PDU -- SNMP Protocol Data Unit 1431 OUT pduType -- SNMP PDU type 1432 OUT sendPduHandle -- handle for matched request 1433 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1434 OUT statusInformation -- success or errorIndication 1435 -- error counter OID/value if error 1436 OUT stateReference -- reference to state information 1437 -- to be used for possible Response 1438 ) 1440 4.3. Access Control Subsystem Primitives 1442 Applications are the typical clients of the service(s) of the Access 1443 Control Subsystem. 1445 The following primitive is provided by the Access Control Subsystem 1446 to check if access is allowed: 1448 statusInformation = -- success or errorIndication 1449 isAccessAllowed( 1450 IN securityModel -- Security Model in use 1451 IN securityName -- principal who wants to access 1452 IN securityLevel -- Level of Security 1453 IN viewType -- read, write, or notify view 1454 IN contextName -- context containing variableName 1455 IN variableName -- OID for the managed object 1456 ) 1458 4.4. Security Subsystem Primitives 1460 The Message Processing Subsystem is the typical client of the 1461 services of the Security Subsystem. 1463 4.4.1. Generate a Request or Notification Message 1465 The Security Subsystem provides the following primitive to generate a 1466 Request or Notification message: 1468 statusInformation = 1469 generateRequestMsg( 1470 IN messageProcessingModel -- typically, SNMP version 1471 IN globalData -- message header, admin data 1472 IN maxMessageSize -- of the sending SNMP entity 1473 IN securityModel -- for the outgoing message 1474 IN securityEngineID -- authoritative SNMP entity 1475 IN securityName -- on behalf of this principal 1476 IN securityLevel -- Level of Security requested 1477 IN scopedPDU -- message (plaintext) payload 1478 OUT securityParameters -- filled in by Security Module 1479 OUT wholeMsg -- complete generated message 1480 OUT wholeMsgLength -- length of the generated message 1481 ) 1483 4.4.2. Process Incoming Message 1485 The Security Subsystem provides the following primitive to process an 1486 incoming message: 1488 statusInformation = -- errorIndication or success 1489 -- error counter OID/value if error 1490 processIncomingMsg( 1491 IN messageProcessingModel -- typically, SNMP version 1492 IN maxMessageSize -- of the sending SNMP entity 1493 IN securityParameters -- for the received message 1494 IN securityModel -- for the received message 1495 IN securityLevel -- Level of Security 1496 IN wholeMsg -- as received on the wire 1497 IN wholeMsgLength -- length as received on the wire 1498 OUT securityEngineID -- identification of the principal 1499 OUT securityName -- identification of the principal 1500 OUT scopedPDU, -- message (plaintext) payload 1501 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 1502 OUT securityStateReference -- reference to security state 1503 ) -- information, needed for response 1505 4.4.3. Generate a Response Message 1507 The Security Subsystem provides the following primitive to generate a 1508 Response message: 1510 statusInformation = 1511 generateResponseMsg( 1512 IN messageProcessingModel -- typically, SNMP version 1513 IN globalData -- message header, admin data 1514 IN maxMessageSize -- of the sending SNMP entity 1515 IN securityModel -- for the outgoing message 1516 IN securityEngineID -- authoritative SNMP entity 1517 IN securityName -- on behalf of this principal 1518 IN securityLevel -- for the outgoing message 1519 IN scopedPDU -- message (plaintext) payload 1520 IN securityStateReference -- reference to security state 1521 -- information from original request 1522 OUT securityParameters -- filled in by Security Module 1523 OUT wholeMsg -- complete generated message 1524 OUT wholeMsgLength -- length of the generated message 1525 ) 1527 4.5. Common Primitives 1529 These primitive(s) are provided by multiple Subsystems. 1531 4.5.1. Release State Reference Information 1533 All Subsystems which pass stateReference information also provide a 1534 primitive to release the memory that holds the referenced state 1535 information: 1537 stateRelease( 1538 IN stateReference -- handle of reference to be released 1539 ) 1541 4.6. Scenario Diagrams 1543 4.6.1. Command Generator or Notification Originator 1545 This diagram shows how a Command Generator or Notification Originator 1546 application requests that a PDU be sent, and how the response is 1547 returned (asynchronously) to that application. 1549 Command Dispatcher Message Security 1550 Generator | Processing Model 1551 | | Model | 1552 | sendPdu | | | 1553 |------------------->| | | 1554 | | prepareOutgoingMessage | | 1555 : |----------------------->| | 1556 : | | generateRequestMsg | 1557 : | |-------------------->| 1558 : | | | 1559 : | |<--------------------| 1560 : | | | 1561 : |<-----------------------| | 1562 : | | | 1563 : |------------------+ | | 1564 : | Send SNMP | | | 1565 : | Request Message | | | 1566 : | to Network | | | 1567 : | v | | 1568 : : : : : 1569 : : : : : 1570 : : : : : 1571 : | | | | 1572 : | Receive SNMP | | | 1573 : | Response Message | | | 1574 : | from Network | | | 1575 : |<-----------------+ | | 1576 : | | | 1577 : | prepareDataElements | | 1578 : |----------------------->| | 1579 : | | processIncomingMsg | 1580 : | |-------------------->| 1581 : | | | 1582 : | |<--------------------| 1583 : | | | 1584 : |<-----------------------| | 1585 | processResponsePdu | | | 1586 |<-------------------| | | 1587 | | | | 1589 4.6.2. Scenario Diagram for a Command Responder Application 1591 This diagram shows how a Command Responder or Notification Receiver 1592 application registers for handling a pduType, how a PDU is dispatched 1593 to the application after a SNMP message is received, and how the 1594 Response is (asynchronously) send back to the network. 1596 Command Dispatcher Message Security 1597 Responder | Processing Model 1598 | | Model | 1599 | | | | 1600 | registerContextEngineID | | | 1601 |------------------------>| | | 1602 |<------------------------| | | | 1603 | | Receive SNMP | | | 1604 : | Message | | | 1605 : | from Network | | | 1606 : |<-------------+ | | 1607 : | | | 1608 : |prepareDataElements | | 1609 : |------------------->| | 1610 : | | processIncomingMsg | 1611 : | |------------------->| 1612 : | | | 1613 : | |<-------------------| 1614 : | | | 1615 : |<-------------------| | 1616 | processPdu | | | 1617 |<------------------------| | | 1618 | | | | 1619 : : : : 1620 : : : : 1621 | returnResponsePdu | | | 1622 |------------------------>| | | 1623 : | prepareResponseMsg | | 1624 : |------------------->| | 1625 : | |generateResponseMsg | 1626 : | |------------------->| 1627 : | | | 1628 : | |<-------------------| 1629 : | | | 1630 : |<-------------------| | 1631 : | | | 1632 : |--------------+ | | 1633 : | Send SNMP | | | 1634 : | Message | | | 1635 : | to Network | | | 1636 : | v | | 1638 5. Managed Object Definitions for SNMP Management Frameworks 1640 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN 1642 IMPORTS 1643 MODULE-IDENTITY, OBJECT-TYPE, 1644 OBJECT-IDENTITY, 1645 snmpModules FROM SNMPv2-SMI 1646 TEXTUAL-CONVENTION FROM SNMPv2-TC 1647 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 1649 snmpFrameworkMIB MODULE-IDENTITY 1650 LAST-UPDATED "9901190000Z" -- 19 January 1999 1651 ORGANIZATION "SNMPv3 Working Group" 1652 CONTACT-INFO "WG-EMail: snmpv3@tis.com 1653 Subscribe: majordomo@tis.com 1654 In message body: subscribe snmpv3 1656 Chair: Russ Mundy 1657 TIS Labs at Network Associates 1658 postal: 3060 Washington Rd 1659 Glenwood MD 21738 1660 USA 1661 EMail: mundy@tis.com 1662 phone: +1 301-854-6889 1664 Co-editor Dave Harrington 1665 Cabletron Systems, Inc. 1666 postal: Post Office Box 5005 1667 Mail Stop: Durham 1668 35 Industrial Way 1669 Rochester, NH 03867-5005 1670 USA 1671 EMail: dbh@ctron.com 1672 phone: +1 603-337-7357 1674 Co-editor Randy Presuhn 1675 BMC Software, Inc. 1676 postal: 965 Stewart Drive 1677 Sunnyvale, CA 94086 1678 USA 1679 EMail: randy_presuhn@bmc.com 1680 phone: +1 408-616-3100 1682 Co-editor: Bert Wijnen 1683 IBM T.J. Watson Research 1684 postal: Schagen 33 1685 3461 GL Linschoten 1686 Netherlands 1687 EMail: wijnen@vnet.ibm.com 1688 phone: +31 348-432-794 1689 " 1690 DESCRIPTION "The SNMP Management Architecture MIB" 1691 REVISION "9901190000Z" -- 19 January 1999 1692 DESCRIPTION "Updated editors' addresses, fixed typos. 1693 " 1694 REVISION "9711200000Z" -- 20 November 1997 1695 DESCRIPTION "The initial version, published in RFC 2271. 1696 " 1697 ::= { snmpModules 10 } 1699 -- Textual Conventions used in the SNMP Management Architecture *** 1701 SnmpEngineID ::= TEXTUAL-CONVENTION 1702 STATUS current 1703 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1704 Objects of this type are for identification, not for 1705 addressing, even though it is possible that an 1706 address may have been used in the generation of 1707 a specific value. 1709 The value for this object may not be all zeros or 1710 all 'ff'H or the empty (zero length) string. 1712 The initial value for this object may be configured 1713 via an operator console entry or via an algorithmic 1714 function. In the latter case, the following 1715 example algorithm is recommended. 1717 In cases where there are multiple engines on the 1718 same system, the use of this algorithm is NOT 1719 appropriate, as it would result in all of those 1720 engines ending up with the same ID value. 1722 1) The very first bit is used to indicate how the 1723 rest of the data is composed. 1725 0 - as defined by enterprise using former methods 1726 that existed before SNMPv3. See item 2 below. 1728 1 - as defined by this architecture, see item 3 1729 below. 1731 Note that this allows existing uses of the 1732 engineID (also known as AgentID [RFC1910]) to 1733 co-exist with any new uses. 1735 2) The snmpEngineID has a length of 12 octets. 1737 The first four octets are set to the binary 1738 equivalent of the agent's SNMP management 1739 private enterprise number as assigned by the 1740 Internet Assigned Numbers Authority (IANA). 1741 For example, if Acme Networks has been assigned 1742 { enterprises 696 }, the first four octets would 1743 be assigned '000002b8'H. 1745 The remaining eight octets are determined via 1746 one or more enterprise-specific methods. Such 1747 methods must be designed so as to maximize the 1748 possibility that the value of this object will 1749 be unique in the agent's administrative domain. 1750 For example, it may be the IP address of the SNMP 1751 entity, or the MAC address of one of the 1752 interfaces, with each address suitably padded 1753 with random octets. If multiple methods are 1754 defined, then it is recommended that the first 1755 octet indicate the method being used and the 1756 remaining octets be a function of the method. 1758 3) The length of the octet strings varies. 1760 The first four octets are set to the binary 1761 equivalent of the agent's SNMP management 1762 private enterprise number as assigned by the 1763 Internet Assigned Numbers Authority (IANA). 1764 For example, if Acme Networks has been assigned 1765 { enterprises 696 }, the first four octets would 1766 be assigned '000002b8'H. 1768 The very first bit is set to 1. For example, the 1769 above value for Acme Networks now changes to be 1770 '800002b8'H. 1772 The fifth octet indicates how the rest (6th and 1773 following octets) are formatted. The values for 1774 the fifth octet are: 1776 0 - reserved, unused. 1778 1 - IPv4 address (4 octets) 1779 lowest non-special IP address 1781 2 - IPv6 address (16 octets) 1782 lowest non-special IP address 1784 3 - MAC address (6 octets) 1785 lowest IEEE MAC address, canonical 1786 order 1788 4 - Text, administratively assigned 1789 Maximum remaining length 27 1791 5 - Octets, administratively assigned 1792 Maximum remaining length 27 1794 6-127 - reserved, unused 1796 127-255 - as defined by the enterprise 1797 Maximum remaining length 27 1798 " 1799 SYNTAX OCTET STRING (SIZE(5..32)) 1801 SnmpSecurityModel ::= TEXTUAL-CONVENTION 1802 STATUS current 1803 DESCRIPTION "An identifier that uniquely identifies a 1804 securityModel of the Security Subsystem within the 1805 SNMP Management Architecture. 1807 The values for securityModel are allocated as 1808 follows: 1810 - The zero value is reserved. 1811 - Values between 1 and 255, inclusive, are reserved 1812 for standards-track Security Models and are 1813 managed by the Internet Assigned Numbers Authority 1814 (IANA). 1815 - Values greater than 255 are allocated to 1816 enterprise-specific Security Models. An 1817 enterprise-specific securityModel value is defined 1818 to be: 1820 enterpriseID * 256 + security model within 1821 enterprise 1823 For example, the fourth Security Model defined by 1824 the enterprise whose enterpriseID is 1 would be 1825 260. 1827 This scheme for allocation of securityModel 1828 values allows for a maximum of 255 standards- 1829 based Security Models, and for a maximum of 1830 255 Security Models per enterprise. 1832 It is believed that the assignment of new 1833 securityModel values will be rare in practice 1834 because the larger the number of simultaneously 1835 utilized Security Models, the larger the 1836 chance that interoperability will suffer. 1837 Consequently, it is believed that such a range 1838 will be sufficient. In the unlikely event that 1839 the standards committee finds this number to be 1840 insufficient over time, an enterprise number 1841 can be allocated to obtain an additional 255 1842 possible values. 1844 Note that the most significant bit must be zero; 1845 hence, there are 23 bits allocated for various 1846 organizations to design and define non-standard 1847 securityModels. This limits the ability to 1848 define new proprietary implementations of Security 1849 Models to the first 8,388,608 enterprises. 1851 It is worthwhile to note that, in its encoded 1852 form, the securityModel value will normally 1853 require only a single byte since, in practice, 1854 the leftmost bits will be zero for most messages 1855 and sign extension is suppressed by the encoding 1856 rules. 1858 As of this writing, there are several values 1859 of securityModel defined for use with SNMP or 1860 reserved for use with supporting MIB objects. 1861 They are as follows: 1863 0 reserved for 'any' 1864 1 reserved for SNMPv1 1865 2 reserved for SNMPv2c 1866 3 User-Based Security Model (USM) 1867 " 1868 SYNTAX INTEGER(0 .. 2147483647) 1870 SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION 1871 STATUS current 1872 DESCRIPTION "An identifier that uniquely identifies a Message 1873 Processing Model of the Message Processing 1874 Subsystem within a SNMP Management Architecture. 1876 The values for messageProcessingModel are 1877 allocated as follows: 1879 - Values between 0 and 255, inclusive, are 1880 reserved for standards-track Message Processing 1881 Models and are managed by the Internet Assigned 1882 Numbers Authority (IANA). 1884 - Values greater than 255 are allocated to 1885 enterprise-specific Message Processing Models. 1886 An enterprise messageProcessingModel value is 1887 defined to be: 1889 enterpriseID * 256 + 1890 messageProcessingModel within enterprise 1892 For example, the fourth Message Processing Model 1893 defined by the enterprise whose enterpriseID 1894 is 1 would be 260. 1896 This scheme for allocating messageProcessingModel 1897 values allows for a maximum of 255 standards- 1898 based Message Processing Models, and for a 1899 maximum of 255 Message Processing Models per 1900 enterprise. 1902 It is believed that the assignment of new 1903 messageProcessingModel values will be rare 1904 in practice because the larger the number of 1905 simultaneously utilized Message Processing Models, 1906 the larger the chance that interoperability 1907 will suffer. It is believed that such a range 1908 will be sufficient. In the unlikely event that 1909 the standards committee finds this number to be 1910 insufficient over time, an enterprise number 1911 can be allocated to obtain an additional 256 1912 possible values. 1914 Note that the most significant bit must be zero; 1915 hence, there are 23 bits allocated for various 1916 organizations to design and define non-standard 1917 messageProcessingModels. This limits the ability 1918 to define new proprietary implementations of 1919 Message Processing Models to the first 8,388,608 1920 enterprises. 1922 It is worthwhile to note that, in its encoded 1923 form, the messageProcessingModel value will 1924 normally require only a single byte since, in 1925 practice, the leftmost bits will be zero for 1926 most messages and sign extension is suppressed 1927 by the encoding rules. 1929 As of this writing, there are several values of 1930 messageProcessingModel defined for use with SNMP. 1931 They are as follows: 1933 0 reserved for SNMPv1 1934 1 reserved for SNMPv2c 1935 2 reserved for SNMPv2u and SNMPv2* 1936 3 reserved for SNMPv3 1937 " 1938 SYNTAX INTEGER(0 .. 2147483647) 1940 SnmpSecurityLevel ::= TEXTUAL-CONVENTION 1941 STATUS current 1942 DESCRIPTION "A Level of Security at which SNMP messages can be 1943 sent or with which operations are being processed; 1944 in particular, one of: 1946 noAuthNoPriv - without authentication and 1947 without privacy, 1948 authNoPriv - with authentication but 1949 without privacy, 1950 authPriv - with authentication and 1951 with privacy. 1953 These three values are ordered such that 1954 noAuthNoPriv is less than authNoPriv and 1955 authNoPriv is less than authPriv. 1956 " 1957 SYNTAX INTEGER { noAuthNoPriv(1), 1958 authNoPriv(2), 1959 authPriv(3) 1960 } 1962 SnmpAdminString ::= TEXTUAL-CONVENTION 1963 DISPLAY-HINT "255a" 1964 STATUS current 1965 DESCRIPTION "An octet string containing administrative 1966 information, preferably in human-readable form. 1968 To facilitate internationalization, this 1969 information is represented using the ISO/IEC 1970 IS 10646-1 character set, encoded as an octet 1971 string using the UTF-8 transformation format 1972 described in [RFC2279]. 1974 Since additional code points are added by 1975 amendments to the 10646 standard from time 1976 to time, implementations must be prepared to 1977 encounter any code point from 0x00000000 to 1978 0x7fffffff. Byte sequences that do not 1979 correspond to the valid UTF-8 encoding of a 1980 code point or are outside this range are 1981 prohibited. 1983 The use of control codes should be avoided. 1985 When it is necessary to represent a newline, 1986 the control code sequence CR LF should be used. 1988 The use of leading or trailing white space should 1989 be avoided. 1991 For code points not directly supported by user 1992 interface hardware or software, an alternative 1993 means of entry and display, such as hexadecimal, 1994 may be provided. 1996 For information encoded in 7-bit US-ASCII, 1997 the UTF-8 encoding is identical to the 1998 US-ASCII encoding. 2000 UTF-8 may require multiple bytes to represent a 2001 single character / code point; thus the length 2002 of this object in octets may be different from 2003 the number of characters encoded. Similarly, 2004 size constraints refer to the number of encoded 2005 octets, not the number of characters represented 2006 by an encoding. 2008 Note that when this TC is used for an object that 2009 is used or envisioned to be used as an index, then 2010 a SIZE restriction MUST be specified so that the 2011 number of sub-identifiers for any object instance 2012 does not exceed the limit of 128, as defined by 2013 [RFC1905]. 2015 Note that the size of an SnmpAdminString object is 2016 measured in octets, not characters. 2017 " 2018 SYNTAX OCTET STRING (SIZE (0..255)) 2020 -- Administrative assignments *************************************** 2022 snmpFrameworkAdmin 2023 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } 2025 snmpFrameworkMIBObjects 2026 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } 2027 snmpFrameworkMIBConformance 2028 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 2030 -- the snmpEngine Group ******************************************** 2032 snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 2034 snmpEngineID OBJECT-TYPE 2035 SYNTAX SnmpEngineID 2036 MAX-ACCESS read-only 2037 STATUS current 2038 DESCRIPTION "An SNMP engine's administratively-unique identifier. 2039 " 2040 ::= { snmpEngine 1 } 2042 snmpEngineBoots OBJECT-TYPE 2043 SYNTAX INTEGER (1..2147483647) 2044 MAX-ACCESS read-only 2045 STATUS current 2046 DESCRIPTION "The number of times that the SNMP engine has 2047 (re-)initialized itself since snmpEngineID 2048 was last configured. 2049 " 2050 ::= { snmpEngine 2 } 2052 snmpEngineTime OBJECT-TYPE 2053 SYNTAX INTEGER (0..2147483647) 2054 UNITS "seconds" 2055 MAX-ACCESS read-only 2056 STATUS current 2057 DESCRIPTION "The number of seconds since the value of 2058 the snmpEngineBoots object last changed. 2059 When incrementing this object's value would 2060 cause it to exceed its maximum, 2061 snmpEngineBoots is incremented as if a 2062 re-initialization had occurred, and this 2063 object's value consequently reverts to zero. 2064 " 2065 ::= { snmpEngine 3 } 2067 snmpEngineMaxMessageSize OBJECT-TYPE 2068 SYNTAX INTEGER (484..2147483647) 2069 MAX-ACCESS read-only 2070 STATUS current 2071 DESCRIPTION "The maximum length in octets of an SNMP message 2072 which this SNMP engine can send or receive and 2073 process, determined as the minimum of the maximum 2074 message size values supported among all of the 2075 transports available to and supported by the engine. 2076 " 2077 ::= { snmpEngine 4 } 2079 -- Registration Points for Authentication and Privacy Protocols ** 2081 snmpAuthProtocols OBJECT-IDENTITY 2082 STATUS current 2083 DESCRIPTION "Registration point for standards-track 2084 authentication protocols used in SNMP Management 2085 Frameworks. 2086 " 2087 ::= { snmpFrameworkAdmin 1 } 2089 snmpPrivProtocols OBJECT-IDENTITY 2090 STATUS current 2091 DESCRIPTION "Registration point for standards-track privacy 2092 protocols used in SNMP Management Frameworks. 2093 " 2094 ::= { snmpFrameworkAdmin 2 } 2096 -- Conformance information ****************************************** 2098 snmpFrameworkMIBCompliances 2099 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} 2100 snmpFrameworkMIBGroups 2101 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} 2103 -- compliance statements 2105 snmpFrameworkMIBCompliance MODULE-COMPLIANCE 2106 STATUS current 2107 DESCRIPTION "The compliance statement for SNMP engines which 2108 implement the SNMP Management Framework MIB. 2109 " 2110 MODULE -- this module 2111 MANDATORY-GROUPS { snmpEngineGroup } 2113 ::= { snmpFrameworkMIBCompliances 1 } 2115 -- units of conformance 2117 snmpEngineGroup OBJECT-GROUP 2118 OBJECTS { 2119 snmpEngineID, 2120 snmpEngineBoots, 2121 snmpEngineTime, 2122 snmpEngineMaxMessageSize 2123 } 2124 STATUS current 2125 DESCRIPTION "A collection of objects for identifying and 2126 determining the configuration and current timeliness 2127 values of an SNMP engine. 2128 " 2129 ::= { snmpFrameworkMIBGroups 1 } 2131 END 2133 6. IANA Considerations 2135 This document defines three number spaces administered by IANA, one 2136 for security models, another for message processing models, and a 2137 third for SnmpEngineID formats. 2139 6.1. Security Models 2141 The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are 2142 in the range from 0 to 255 inclusive, and are reserved for standards- 2143 track Security Models. If this range should in the future prove 2144 insufficient, an enterprise number can be allocated to obtain an 2145 additional 255 possible values. 2147 As of this writing, there are several values of securityModel defined 2148 for use with SNMP or reserved for use with supporting MIB objects. 2149 They are as follows: 2150 0 reserved for 'any' 2151 1 reserved for SNMPv1 2152 2 reserved for SNMPv2c 2153 3 User-Based Security Model (USM) 2155 6.2. Message Processing Models 2157 The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by 2158 IANA are in the range 0 to 255, inclusive. Each value uniquely 2159 identifies a standards-track Message Processing Model of the Message 2160 Processing Subsystem within a SNMP Management Architecture. 2162 Should this range prove insufficient in the future, an enterprise 2163 number may be obtained for the standards committee to get an 2164 additional 256 possible values. 2166 As of this writing, there are several values of 2167 messageProcessingModel defined for use with SNMP. They are as 2168 follows: 2169 0 reserved for SNMPv1 2170 1 reserved for SNMPv2c 2171 2 reserved for SNMPv2u and SNMPv2* 2172 3 reserved for SNMPv3 2174 6.3. SnmpEngineID Formats 2176 The SnmpEngineID TEXTUAL-CONVENTION's fifth octet contains a format 2177 identifier. managed by IANA are in the range 6 to 127, inclusive. 2178 Each value uniquely identifies a standards-track SnmpEngineID format. 2180 7. Intellectual Property 2182 The IETF takes no position regarding the validity or scope of any 2183 intellectual property or other rights that might be claimed to 2184 pertain to the implementation or use of the technology described in 2185 this document or the extent to which any license under such rights 2186 might or might not be available; neither does it represent that it 2187 has made any effort to identify any such rights. Information on the 2188 IETF's procedures with respect to rights in standards-track and 2189 standards-related documentation can be found in BCP-11. Copies of 2190 claims of rights made available for publication and any assurances of 2191 licenses to be made available, or the result of an attempt made to 2192 obtain a general license or permission for the use of such 2193 proprietary rights by implementors or users of this specification can 2194 be obtained from the IETF Secretariat. 2196 The IETF invites any interested party to bring to its attention any 2197 copyrights, patents or patent applications, or other proprietary 2198 rights which may cover technology that may be required to practice 2199 this standard. Please address the information to the IETF Executive 2200 Director. 2202 8. Acknowledgements 2204 This document is the result of the efforts of the SNMPv3 Working 2205 Group. Some special thanks are in order to the following SNMPv3 WG 2206 members: 2208 Harald Tveit Alvestrand (Maxware) 2209 Dave Battle (SNMP Research, Inc.) 2210 Alan Beard (Disney Worldwide Services) 2211 Paul Berrevoets (SWI Systemware/Halcyon Inc.) 2212 Martin Bjorklund (Ericsson) 2213 Uri Blumenthal (IBM T.J. Watson Research Center) 2214 Jeff Case (SNMP Research, Inc.) 2215 John Curran (BBN) 2216 Mike Daniele (Compaq Computer Corporation) 2217 T. Max Devlin (Eltrax Systems) 2218 John Flick (Hewlett Packard) 2219 Rob Frye (MCI) 2220 Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) 2221 David Harrington (Cabletron Systems Inc.) 2222 Lauren Heintz (BMC Software, Inc.) 2223 N.C. Hien (IBM T.J. Watson Research Center) 2224 Michael Kirkham (InterWorking Labs, Inc.) 2225 Dave Levi (SNMP Research, Inc.) 2226 Louis A Mamakos (UUNET Technologies Inc.) 2227 Joe Marzot (Nortel Networks) 2228 Paul Meyer (Secure Computing Corporation) 2229 Keith McCloghrie (Cisco Systems) 2230 Bob Moore (IBM) 2231 Russ Mundy (TIS Labs at Network Associates) 2232 Bob Natale (ACE*COMM Corporation) 2233 Mike O'Dell (UUNET Technologies Inc.) 2234 Dave Perkins (DeskTalk) 2235 Peter Polkinghorne (Brunel University) 2236 Randy Presuhn (BMC Software, Inc.) 2237 David Reeder (TIS Labs at Network Associates) 2238 David Reid (SNMP Research, Inc.) 2239 Aleksey Romanov (Quality Quorum) 2240 Shawn Routhier (Epilogue) 2241 Juergen Schoenwaelder (TU Braunschweig) 2242 Bob Stewart (Cisco Systems) 2243 Mike Thatcher (Independent Consultant) 2244 Bert Wijnen (IBM T.J. Watson Research Center) 2246 The document is based on recommendations of the IETF Security and 2247 Administrative Framework Evolution for SNMP Advisory Team. Members 2248 of that Advisory Team were: 2250 David Harrington (Cabletron Systems Inc.) 2251 Jeff Johnson (Cisco Systems) 2252 David Levi (SNMP Research Inc.) 2253 John Linn (Openvision) 2254 Russ Mundy (Trusted Information Systems) chair 2255 Shawn Routhier (Epilogue) 2256 Glenn Waters (Nortel) 2257 Bert Wijnen (IBM T. J. Watson Research Center) 2259 As recommended by the Advisory Team and the SNMPv3 Working Group 2260 Charter, the design incorporates as much as practical from previous 2261 RFCs and drafts. As a result, special thanks are due to the authors 2262 of previous designs known as SNMPv2u and SNMPv2*: 2264 Jeff Case (SNMP Research, Inc.) 2265 David Harrington (Cabletron Systems Inc.) 2266 David Levi (SNMP Research, Inc.) 2267 Keith McCloghrie (Cisco Systems) 2268 Brian O'Keefe (Hewlett Packard) 2269 Marshall T. Rose (Dover Beach Consulting) 2270 Jon Saperia (BGS Systems Inc.) 2271 Steve Waldbusser (International Network Services) 2272 Glenn W. Waters (Bell-Northern Research Ltd.) 2274 9. Security Considerations 2276 This document describes how an implementation can include a Security 2277 Model to protect management messages and an Access Control Model to 2278 control access to management information. 2280 The level of security provided is determined by the specific Security 2281 Model implementation(s) and the specific Access Control Model 2282 implementation(s) used. 2284 Applications have access to data which is not secured. Applications 2285 SHOULD take reasonable steps to protect the data from disclosure. 2287 It is the responsibility of the purchaser of an implementation to 2288 ensure that: 2290 1) an implementation complies with the rules defined by this 2291 architecture, 2293 2) the Security and Access Control Models utilized satisfy the 2294 security and access control needs of the organization, 2296 3) the implementations of the Models and Applications comply with 2297 the model and application specifications, 2299 4) and the implementation protects configuration secrets from 2300 inadvertent disclosure. 2302 This document also contains a MIB definition module. None of the 2303 objects defined is writable, and the information they represent is 2304 not deemed to be particularly sensitive. However, if they are deemed 2305 sensitive in a particular environment, access to them should be 2306 restricted through the use of appropriately configured Security and 2307 Access Control models. 2309 10. References 2311 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 2312 of Management Information for TCP/IP-based internets", STD 16, RFC 2313 1155, May 1990. 2315 [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The 2316 Simple Network Management Protocol", STD 15, RFC 1157, University 2317 of Tennessee at Knoxville, Performance Systems s International, 2318 Performance International, and the MIT Laboratory for Computer 2319 Science, May 1990. 2321 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 2322 16, RFC 1212, March 1991. 2324 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2325 M. and S. Waldbusser, "Introduction to Community-based SNMPv2", 2326 RFC 1901, January 1996. 2328 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2329 M. and S. Waldbusser, "Structure of Management Information for 2330 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2331 RFC 1902, January 1996. 2333 [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2334 M. and S. Waldbusser, "Textual Conventions for Version 2 of the 2335 Simple Network Management Protocol (SNMPv2)", RFC 1903, January 2336 1996. 2338 [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2339 M. and S. Waldbusser, "Conformance Statements for Version 2 of 2340 the Simple Network Management Protocol (SNMPv2)", RFC 1904, 2341 January 1996. 2343 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2344 M. and S. Waldbusser, "Protocol Operations for Version 2 of the 2345 Simple Network Management Protocol (SNMPv2)", RFC 1905, January 2346 1996. 2348 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2349 M. and S. Waldbusser, "Transport Mappings for Version 2 of the 2350 Simple Network Management Protocol (SNMPv2)", RFC 1906, January 2351 1996. 2353 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2354 M. and S. Waldbusser, "Management Information Base for Version 2 2355 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 2356 January 1996. 2358 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2359 M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 2360 of the SNMP-standard Network Management Framework", RFC 1908, 2361 January 1996. 2363 [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure 2364 for SNMPv2", RFC 1909, February 1996. 2366 [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", 2367 RFC 1910, February 1996. 2369 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2370 RFC 2279, January, 1998. 2372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2373 Requirement Levels", BCP 14, RFC 2119, March 1997. 2375 [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in the 2376 IETF Standards Process", BCP 11, RFC 2028, October 1996. 2378 [RFC2233] McCloghrie, K. and F. Kastenholz. "The Interfaces Group 2379 MIB using SMIv2", RFC 2233, November 1997. 2381 [SNMP-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, 2382 "Message Processing and Dispatching for the Simple Network 2383 Management Protocol (SNMP)", , 2384 February, 1999. 2386 [SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 2387 Model for Version 3 of the Simple Network Management Protocol 2388 (SNMPv3)", , February 1999. 2390 [SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 2391 Access Control Model for the Simple Network Management Protocol 2392 (SNMP)", , February 1999. 2394 [SNMP-APPL] Levi, D. B., Meyer, P. and B. Stewart, "SNMPv3 2395 Applications", , February 1999. 2397 [SNMP-INTRO] Case, J., Mundy, R., Partain, D. and B. Stewart, 2398 "Introduction to Version 3 of the Internet-standard Network 2399 Management Framework", , January 2400 1999. 2402 [SNMP-COEX] Frye, R., Levi, D. and B. Wijnen, "Coexistence between 2403 Version 1, Version 2, and Version 3 of the Internet-standard 2404 Network Management Framework", , 2405 January, 1999. 2407 11. Editor's Addresses 2409 Bert Wijnen 2410 IBM T.J. Watson Research 2411 Schagen 33 2412 3461 GL Linschoten 2413 Netherlands 2415 Phone: +31 348-432-794 2416 EMail: wijnen@vnet.ibm.com 2418 Dave Harrington 2419 Cabletron Systems, Inc 2420 Post Office Box 5005 2421 Mail Stop: Durham 2422 35 Industrial Way 2423 Rochester, NH 03867-5005 2424 USA 2426 Phone: +1 603-337-7357 2427 EMail: dbh@ctron.com 2429 Randy Presuhn 2430 BMC Software, Inc. 2431 965 Stewart Drive 2432 Sunnyvale, CA 94086 2433 USA 2435 Phone: +1 408-616-3100 2436 Fax: +1 408-616-3101 2437 EMail: randy_presuhn@bmc.com 2439 APPENDIX A 2441 A. Guidelines for Model Designers 2443 This appendix describes guidelines for designers of models which are 2444 expected to fit into the architecture defined in this document. 2446 SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to 2447 provide trivial authentication and access control. SNMPv1 and SNMPv2c 2448 Frameworks can coexist with Frameworks designed according to this 2449 architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks 2450 could be designed to meet the requirements of this architecture, but 2451 this document does not provide guidelines for that coexistence. 2453 Within any subsystem model, there should be no reference to any 2454 specific model of another subsystem, or to data defined by a specific 2455 model of another subsystem. 2457 Transfer of data between the subsystems is deliberately described as 2458 a fixed set of abstract data elements and primitive functions which 2459 can be overloaded to satisfy the needs of multiple model definitions. 2461 Documents which define models to be used within this architecture 2462 SHOULD use the standard primitives between subsystems, possibly 2463 defining specific mechanisms for converting the abstract data 2464 elements into model-usable formats. This constraint exists to allow 2465 subsystem and model documents to be written recognizing common 2466 borders of the subsystem and model. Vendors are not constrained to 2467 recognize these borders in their implementations. 2469 The architecture defines certain standard services to be provided 2470 between subsystems, and the architecture defines abstract service 2471 interfaces to request these services. 2473 Each model definition for a subsystem SHOULD support the standard 2474 service interfaces, but whether, or how, or how well, it performs the 2475 service is dependent on the model definition. 2477 A.1. Security Model Design Requirements 2479 A.1.1. Threats 2481 A document describing a Security Model MUST describe how the model 2482 protects against the threats described under "Security Requirements 2483 of this Architecture", section 1.4. 2485 A.1.2. Security Processing 2487 Received messages MUST be validated by a Model of the Security 2488 Subsystem. Validation includes authentication and privacy processing 2489 if needed, but it is explicitly allowed to send messages which do not 2490 require authentication or privacy. 2492 A received message contains a specified securityLevel to be used 2493 during processing. All messages requiring privacy MUST also require 2494 authentication. 2496 A Security Model specifies rules by which authentication and privacy 2497 are to be done. A model may define mechanisms to provide additional 2498 security features, but the model definition is constrained to using 2499 (possibly a subset of) the abstract data elements defined in this 2500 document for transferring data between subsystems. 2502 Each Security Model may allow multiple security protocols to be used 2503 concurrently within an implementation of the model. Each Security 2504 Model defines how to determine which protocol to use, given the 2505 securityLevel and the security parameters relevant to the message. 2506 Each Security Model, with its associated protocol(s) defines how the 2507 sending/receiving entities are identified, and how secrets are 2508 configured. 2510 Authentication and Privacy protocols supported by Security Models are 2511 uniquely identified using Object Identifiers. IETF standard protocols 2512 for authentication or privacy should have an identifier defined 2513 within the snmpAuthProtocols or the snmpPrivProtocols subtrees. 2514 Enterprise specific protocol identifiers should be defined within the 2515 enterprise subtree. 2517 For privacy, the Security Model defines what portion of the message 2518 is encrypted. 2520 The persistent data used for security should be SNMP-manageable, but 2521 the Security Model defines whether an instantiation of the MIB is a 2522 conformance requirement. 2524 Security Models are replaceable within the Security Subsystem. 2525 Multiple Security Model implementations may exist concurrently within 2526 an SNMP engine. The number of Security Models defined by the SNMP 2527 community should remain small to promote interoperability. 2529 A.1.3. Validate the security-stamp in a received message 2531 A Message Processing Model requests that a Security Model: 2532 - verifies that the message has not been altered, 2533 - authenticates the identification of the principal for whom the 2534 message was generated. 2535 - decrypts the message if it was encrypted. 2537 Additional requirements may be defined by the model, and additional 2538 services may be provided by the model, but the model is constrained 2539 to use the following primitives for transferring data between 2540 subsystems. Implementations are not so constrained. 2542 A Message Processing Model uses the processIncomingMsg primitive as 2543 described in section 4.4.2. 2545 A.1.4. Security MIBs 2547 Each Security Model defines the MIB module(s) required for security 2548 processing, including any MIB module(s) required for the security 2549 protocol(s) supported. The MIB module(s) SHOULD be defined 2550 concurrently with the procedures which use the MIB module(s). The 2551 MIB module(s) are subject to normal access control rules. 2553 The mapping between the model-dependent security ID and the 2554 securityName MUST be able to be determined using SNMP, if the model- 2555 dependent MIB is instantiated and if access control policy allows 2556 access. 2558 A.1.5. Cached Security Data 2560 For each message received, the Security Model caches the state 2561 information such that a Response message can be generated using the 2562 same security information, even if the Local Configuration Datastore 2563 is altered between the time of the incoming request and the outgoing 2564 response. 2566 A Message Processing Model has the responsibility for explicitly 2567 releasing the cached data if such data is no longer needed. To enable 2568 this, an abstract securityStateReference data element is passed from 2569 the Security Model to the Message Processing Model. 2571 The cached security data may be implicitly released via the 2572 generation of a response, or explicitly released by using the 2573 stateRelease primitive, as described in section 4.5.1. 2575 A.2. Message Processing Model Design Requirements 2577 An SNMP engine contains a Message Processing Subsystem which may 2578 contain multiple Message Processing Models. 2580 The Message Processing Model MUST always (conceptually) pass the 2581 complete PDU, i.e., it never forwards less than the complete list of 2582 varBinds. 2584 A.2.1. Receiving an SNMP Message from the Network 2586 Upon receipt of a message from the network, the Dispatcher in the 2587 SNMP engine determines the version of the SNMP message and interacts 2588 with the corresponding Message Processing Model to determine the 2589 abstract data elements. 2591 A Message Processing Model specifies the SNMP Message format it 2592 supports and describes how to determine the values of the abstract 2593 data elements (like msgID, msgMaxSize, msgFlags, 2594 msgSecurityParameters, securityModel, securityLevel etc). A Message 2595 Processing Model interacts with a Security Model to provide security 2596 processing for the message using the processIncomingMsg primitive, as 2597 described in section 4.4.2. 2599 A.2.2. Sending an SNMP Message to the Network 2601 The Dispatcher in the SNMP engine interacts with a Message Processing 2602 Model to prepare an outgoing message. For that it uses the following 2603 primitives: 2605 - for requests and notifications: prepareOutgoingMessage, as 2606 described in section 4.2.1. 2608 - for response messages: prepareResponseMessage, as described in 2609 section 4.2.2. 2611 A Message Processing Model, when preparing an Outgoing SNMP Message, 2612 interacts with a Security Model to secure the message. For that it 2613 uses the following primitives: 2615 - for requests and notifications: generateRequestMsg, as 2616 described in section 4.4.1. 2618 - for response messages: generateResponseMsg as described in 2619 section 4.4.3. 2621 Once the SNMP message is prepared by a Message Processing Model, 2622 the Dispatcher sends the message to the desired address using the 2623 appropriate transport. 2625 A.3. Application Design Requirements 2627 Within an application, there may be an explicit binding to a specific 2628 SNMP message version, i.e., a specific Message Processing Model, and 2629 to a specific Access Control Model, but there should be no reference 2630 to any data defined by a specific Message Processing Model or Access 2631 Control Model. 2633 Within an application, there should be no reference to any specific 2634 Security Model, or any data defined by a specific Security Model. 2636 An application determines whether explicit or implicit access control 2637 should be applied to the operation, and, if access control is needed, 2638 which Access Control Model should be used. 2640 An application has the responsibility to define any MIB module(s) 2641 used to provide application-specific services. 2643 Applications interact with the SNMP engine to initiate messages, 2644 receive responses, receive asynchronous messages, and send responses. 2646 A.3.1. Applications that Initiate Messages 2648 Applications may request that the SNMP engine send messages 2649 containing SNMP commands or notifications using the sendPdu primitive 2650 as described in section 4.1.1. 2652 If it is desired that a message be sent to multiple targets, it is 2653 the responsibility of the application to provide the iteration. 2655 The SNMP engine assumes necessary access control has been applied to 2656 the PDU, and provides no access control services. 2658 The SNMP engine looks at the "expectResponse" parameter, and if a 2659 response is expected, then the appropriate information is cached such 2660 that a later response can be associated to this message, and can then 2661 be returned to the application. A sendPduHandle is returned to the 2662 application so it can later correspond the response with this message 2663 as well. 2665 A.3.2. Applications that Receive Responses 2667 The SNMP engine matches the incoming response messages to outstanding 2668 messages sent by this SNMP engine, and forwards the response to the 2669 associated application using the processResponsePdu primitive, as 2670 described in section 4.1.4. 2672 A.3.3. Applications that Receive Asynchronous Messages 2674 When an SNMP engine receives a message that is not the response to a 2675 request from this SNMP engine, it must determine to which application 2676 the message should be given. 2678 An Application that wishes to receive asynchronous messages registers 2679 itself with the engine using the primitive registerContextEngineID as 2680 described in section 4.1.5. 2682 An Application that wishes to stop receiving asynchronous messages 2683 should unregister itself with the SNMP engine using the primitive 2684 unregisterContextEngineID as described in section 4.1.5. 2686 Only one registration per combination of PDU type and contextEngineID 2687 is permitted at the same time. Duplicate registrations are ignored. 2688 An errorIndication will be returned to the application that attempts 2689 to duplicate a registration. 2691 All asynchronously received messages containing a registered 2692 combination of PDU type and contextEngineID are sent to the 2693 application which registered to support that combination. 2695 The engine forwards the PDU to the registered application, using the 2696 processPdu primitive, as described in section 4.1.2. 2698 A.3.4. Applications that Send Responses 2700 Request operations require responses. An application sends a 2701 response via the returnResponsePdu primitive, as described in section 2702 4.1.3. 2704 The contextEngineID, contextName, securityModel, securityName, 2705 securityLevel, and stateReference parameters are from the initial 2706 processPdu primitive. The PDU and statusInformation are the results 2707 of processing. 2709 A.4. Access Control Model Design Requirements 2711 An Access Control Model determines whether the specified securityName 2712 is allowed to perform the requested operation on a specified managed 2713 object. The Access Control Model specifies the rules by which access 2714 control is determined. 2716 The persistent data used for access control should be manageable 2717 using SNMP, but the Access Control Model defines whether an 2718 instantiation of the MIB is a conformance requirement. 2720 The Access Control Model must provide the primitive isAccessAllowed. 2722 B. Issues 2724 The issues list will be deleted when it is time to publish as an RFC. 2726 B.1. Open Issues 2728 No open issues remain. 2730 B.2. Change Log 2732 These are the major ways in which this draft differs from RFC 2271. 2734 - Updated draft identifier to keep distinct from the series of 2735 drafts leading to RFC 2271, based on Cynthia Clark's messages 2736 regarding VACM and USM. 2738 - Updated draft location information per Cynthia Clark's 2739 instructions. 2741 - Added note clarifying that the SnmpEngineID textual convention 2742 is used for naming, rather than addressing, even though there 2743 are situations where its value may have been generated from an 2744 address. 2746 - Clarified snmpEngineBoots and snmpEngineTime to be consistent 2747 with other documents and working group agreement. 2749 - Incremental update of References section. 2751 - Updated editors' contact information. 2753 - Updated reference to UTF-8 RFC. 2755 - Added reference for SNMPv3 Intro document. 2757 - Added IANA Considerations section. 2759 - Added reference to coexistance document. 2761 - Clarified PDU class description to void coupling to RFC 1905 2762 any more than is necessary. 2764 - additional clarification to SnmpAdminString. 2766 - Are additional clarifications of the SnmpEngineID textual 2767 convention needed? The working group discussion on this topic 2768 was extensive. Answer: no, we've done enough. 2770 - we need a mechanism for a manager to be able to discover what 2771 securityModels are supported by a particular implementation 2772 Resolution: trial and error appears to the preferred method. 2773 The need for a mechanism may be revisited when future security 2774 models are defined. 2776 - Acknowledgement section updated. 2778 - New I-D boilerplate added. 2780 C. Full Copyright Statement 2782 Copyright (C) The Internet Society (1999). All Rights Reserved. 2784 This document and translations of it may be copied and furnished to 2785 others, and derivative works that comment on or otherwise explain it 2786 or assist in its implementation may be prepared, copied, published 2787 and distributed, in whole or in part, without restriction of any 2788 kind, provided that the above copyright notice and this paragraph are 2789 included on all such copies and derivative works. However, this 2790 document itself may not be modified in any way, such as by removing 2791 the copyright notice or references to the Internet Society or other 2792 Internet organizations, except as needed for the purpose of 2793 developing Internet standards in which case the procedures for 2794 copyrights defined in the Internet Standards process must be 2795 followed, or as required to translate it into languages other than 2796 English. 2798 The limited permissions granted above are perpetual and will not be 2799 revoked by the Internet Society or its successors or assigns. 2801 This document and the information contained herein is provided on an 2802 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2803 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2804 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2805 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2806 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.