idnits 2.17.1 draft-ietf-snmpv3-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 228 has weird spacing: '...es with comma...' == Line 976 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 (17 November 1998) is 9292 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 2275, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 2279, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 2285, but no explicit reference was found in the text == Unused Reference: 'RFC1901' is defined on line 2288, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 2292, but no explicit reference was found in the text == Unused Reference: 'RFC1903' is defined on line 2297, but no explicit reference was found in the text == Unused Reference: 'RFC1904' is defined on line 2302, but no explicit reference was found in the text == Unused Reference: 'RFC1906' is defined on line 2312, but no explicit reference was found in the text == Unused Reference: 'RFC1907' is defined on line 2317, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 2322, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 2327, but no explicit reference was found in the text == Unused Reference: 'BCP-11' is defined on line 2339, but no explicit reference was found in the text == Unused Reference: 'SNMP-MPD' is defined on line 2342, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 2347, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 2351, but no explicit reference was found in the text == Unused Reference: 'SNMP-APPL' is defined on line 2355, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (Obsoleted by RFC 2576) ** Downref: Normative reference to an Historic RFC: RFC 1909 ** Downref: Normative reference to an Historic RFC: RFC 1910 ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2028 (ref. 'BCP-11') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-MPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-USM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-APPL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-INTRO' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-COEX' ** Obsolete normative reference: RFC 2233 (Obsoleted by RFC 2863) Summary: 21 errors (**), 0 flaws (~~), 20 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Harrington 3 Will Obsolete: 2271 Cabletron Systems, Inc. 4 R. Presuhn 5 BMC Software, Inc. 6 B. Wijnen 7 IBM T. J. Watson Research 8 17 November 1998 10 An Architecture for Describing 11 SNMP Management Frameworks 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 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 To view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Copyright Notice 34 Copyright (C) The Internet Society (1998). 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 ...................................... 9 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 ............................................ 12 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 .................................... 16 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 ............ 29 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 7. Intellectual Property ....................................... 50 124 8. Acknowledgements ............................................ 50 125 9. Security Considerations ..................................... 51 126 10. References ................................................. 52 127 11. Editor's Addresses ......................................... 55 128 A. Guidelines for Model Designers .............................. 56 129 A.1. Security Model Design Requirements ........................ 56 130 A.1.1. Threats ................................................. 56 131 A.1.2. Security Processing ..................................... 57 132 A.1.3. Validate the security-stamp in a received message ....... 57 133 A.1.4. Security MIBs ........................................... 58 134 A.1.5. Cached Security Data .................................... 58 135 A.2. Message Processing Model Design Requirements .............. 58 136 A.2.1. Receiving an SNMP Message from the Network .............. 59 137 A.2.2. Sending an SNMP Message to the Network .................. 59 138 A.3. Application Design Requirements ........................... 59 139 A.3.1. Applications that Initiate Messages ..................... 60 140 A.3.2. Applications that Receive Responses ..................... 60 141 A.3.3. Applications that Receive Asynchronous Messages ......... 60 142 A.3.4. Applications that Send Responses ........................ 61 143 A.4. Access Control Model Design Requirements .................. 61 144 B. Issues ...................................................... 62 145 B.1. Open Issues ............................................... 62 146 B.2. Change Log ................................................ 62 147 C. Full Copyright Statement .................................... 63 149 1. Introduction 151 1.1. Overview 153 This document defines a vocabulary for describing SNMP Management 154 Frameworks, and an architecture for describing the major portions of 155 SNMP Management Frameworks. 157 This document does not provide a general introduction to SNMP. Other 158 documents and books can provide a much better introduction to SNMP. 159 Nor does this document provide a history of SNMP. That also can be 160 found in books and other documents. 162 Section 1 describes the purpose, goals, and design decisions of this 163 architecture. 165 Section 2 describes various types of documents which define (elements 166 of) SNMP Frameworks, and how they fit into this architecture. It also 167 provides a minimal road map to the documents which have previously 168 defined SNMP frameworks. 170 Section 3 details the vocabulary of this architecture and its pieces. 171 This section is important for understanding the remaining sections, 172 and for understanding documents which are written to fit within this 173 architecture. 175 Section 4 describes the primitives used for the abstract service 176 interfaces between the various subsystems, models and applications 177 within this architecture. 179 Section 5 defines a collection of managed objects used to instrument 180 SNMP entities within this architecture. 182 Sections 6, 7, 8, 9, 10 and 11 are administrative in nature. 184 Appendix A contains guidelines for designers of Models which are 185 expected to fit within this architecture. 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 1.2. SNMP 193 An SNMP management system contains: 195 - several (potentially many) nodes, each with an SNMP entity 196 containing command responder and notification originator 197 applications, which have access to management instrumentation 198 (traditionally called agents); 200 - at least one SNMP entity containing command generator and/or 201 notification receiver applications (traditionally called a 202 manager) and, 204 - a management protocol, used to convey management information 205 between the SNMP entities. 207 SNMP entities executing command generator and notification receiver 208 applications monitor and control managed elements. Managed elements 209 are devices such as hosts, routers, terminal servers, etc., which are 210 monitored and controlled via access to their management information. 212 It is the purpose of this document to define an architecture which 213 can evolve to realize effective management in a variety of 214 configurations and environments. The architecture has been designed 215 to meet the needs of implementations of: 217 - minimal SNMP entities with command responder and/or 218 notification originator applications (traditionally called SNMP 219 agents), 221 - SNMP entities with proxy forwarder applications (traditionally 222 called SNMP proxy agents), 224 - command line driven SNMP entities with command generator and/or 225 notification receiver applications (traditionally called SNMP 226 command line managers), 228 - SNMP entities with command generator and/or notification 229 receiver, plus command responder and/or notification originator 230 applications (traditionally called SNMP mid-level managers or 231 dual-role entities), 233 - SNMP entities with command generator and/or notification 234 receiver and possibly other types of applications for managing 235 a potentially very large number of managed nodes (traditionally 236 called (network) management stations). 238 1.3. Goals of this Architecture 240 This architecture was driven by the following goals: 242 - Use existing materials as much as possible. It is heavily based 243 on previous work, informally known as SNMPv2u and SNMPv2*. 245 - Address the need for secure SET support, which is considered 246 the most important deficiency in SNMPv1 and SNMPv2c. 248 - Make it possible to move portions of the architecture forward 249 in the standards track, even if consensus has not been reached 250 on all pieces. 252 - Define an architecture that allows for longevity of the SNMP 253 Frameworks that have been and will be defined. 255 - Keep SNMP as simple as possible. 257 - Make it relatively inexpensive to deploy a minimal conforming 258 implementation. 260 - Make it possible to upgrade portions of SNMP as new approaches 261 become available, without disrupting an entire SNMP framework. 263 - Make it possible to support features required in large 264 networks, but make the expense of supporting a feature directly 265 related to the support of the feature. 267 1.4. Security Requirements of this Architecture 269 Several of the classical threats to network protocols are applicable 270 to the management problem and therefore would be applicable to any 271 Security Model used in an SNMP Management Framework. Other threats 272 are not applicable to the management problem. This section discusses 273 principal threats, secondary threats, and threats which are of lesser 274 importance. 276 The principal threats against which any Security Model used within 277 this architecture SHOULD provide protection are: 279 Modification of Information 280 The modification threat is the danger that some unauthorized 281 SNMP entity may alter in-transit SNMP messages generated on 282 behalf of an authorized principal in such a way as to effect 283 unauthorized management operations, including falsifying the 284 value of an object. 286 Masquerade 287 The masquerade threat is the danger that management operations 288 not authorized for some principal may be attempted by assuming 289 the identity of another principal that has the appropriate 290 authorizations. 292 Secondary threats against which any Security Model used within this 293 architecture SHOULD provide protection are: 295 Message Stream Modification 296 The SNMP protocol is typically based upon a connectionless 297 transport service which may operate over any subnetwork 298 service. The re-ordering, delay or replay of messages can and 299 does occur through the natural operation of many such 300 subnetwork services. The message stream modification threat is 301 the danger that messages may be maliciously re-ordered, delayed 302 or replayed to an extent which is greater than can occur 303 through the natural operation of a subnetwork service, in order 304 to effect unauthorized management operations. 306 Disclosure 307 The disclosure threat is the danger of eavesdropping on the 308 exchanges between SNMP engines. Protecting against this threat 309 may be required as a matter of local policy. 311 There are at least two threats against which a Security Model within 312 this architecture need not protect, since they are deemed to be of 313 lesser importance in this context: 315 Denial of Service 316 A Security Model need not attempt to address the broad range of 317 attacks by which service on behalf of authorized users is 318 denied. Indeed, such denial-of-service attacks are in many 319 cases indistinguishable from the type of network failures with 320 which any viable management protocol must cope as a matter of 321 course. 323 Traffic Analysis 324 A Security Model need not attempt to address traffic analysis 325 attacks. Many traffic patterns are predictable - entities may 326 be managed on a regular basis by a relatively small number of 327 management stations - and therefore there is no significant 328 advantage afforded by protecting against traffic analysis. 330 1.5. Design Decisions 332 Various design decisions were made in support of the goals of the 333 architecture and the security requirements: 335 - Architecture 336 An architecture should be defined which identifies the 337 conceptual boundaries between the documents. Subsystems should 338 be defined which describe the abstract services provided by 339 specific portions of an SNMP framework. Abstract service 340 interfaces, as described by service primitives, define the 341 abstract boundaries between documents, and the abstract 342 services that are provided by the conceptual subsystems of an 343 SNMP framework. 345 - Self-contained Documents 346 Elements of procedure plus the MIB objects which are needed for 347 processing for a specific portion of an SNMP framework should 348 be defined in the same document, and as much as possible, 349 should not be referenced in other documents. This allows pieces 350 to be designed and documented as independent and self-contained 351 parts, which is consistent with the general SNMP MIB module 352 approach. As portions of SNMP change over time, the documents 353 describing other portions of SNMP are not directly impacted. 354 This modularity allows, for example, Security Models, 355 authentication and privacy mechanisms, and message formats to 356 be upgraded and supplemented as the need arises. The self- 357 contained documents can move along the standards track on 358 different time-lines. 360 - Threats 361 The Security Models in the Security Subsystem SHOULD protect 362 against the principal threats: modification of information, 363 masquerade, message stream modification and disclosure. They 364 do not need to protect against denial of service and traffic 365 analysis. 367 - Remote Configuration 368 The Security and Access Control Subsystems add a whole new set 369 of SNMP configuration parameters. The Security Subsystem also 370 requires frequent changes of secrets at the various SNMP 371 entities. To make this deployable in a large operational 372 environment, these SNMP parameters must be remotely 373 configurable. 375 - Controlled Complexity 376 It is recognized that producers of simple managed devices want 377 to keep the resources used by SNMP to a minimum. At the same 378 time, there is a need for more complex configurations which can 379 spend more resources for SNMP and thus provide more 380 functionality. The design tries to keep the competing 381 requirements of these two environments in balance and allows 382 the more complex environments to logically extend the simple 383 environment. 385 2. Documentation Overview 387 The following figure shows the set of documents that fit within the 388 SNMP Architecture. 390 +------------------------- Document Set ----------------------------+ 391 | | 392 | +----------+ +-----------------+ +----------------+ | 393 | | Document | | Applicability * | | Coexistence * | | 394 | | Roadmap | | Statement | | & Transition | | 395 | +----------+ +-----------------+ +----------------+ | 396 | | 397 | +---------------------------------------------------------------+ | 398 | | Message Handling | | 399 | | +----------------+ +-----------------+ +-----------------+ | | 400 | | | Transport | | Message | | Security | | | 401 | | | Mappings | | Processing and | | | | | 402 | | | | | Dispatcher | | | | | 403 | | +----------------+ +-----------------+ +-----------------+ | | 404 | +---------------------------------------------------------------+ | 405 | | 406 | +---------------------------------------------------------------+ | 407 | | PDU Handling | | 408 | | +----------------+ +-----------------+ +-----------------+ | | 409 | | | Protocol | | Applications | | Access | | | 410 | | | Operations | | | | Control | | | 411 | | +----------------+ +-----------------+ +-----------------+ | | 412 | +---------------------------------------------------------------+ | 413 | | 414 | +---------------------------------------------------------------+ | 415 | | Information Model | | 416 | | +--------------+ +--------------+ +---------------+ | | 417 | | | Structure of | | Textual | | Conformance | | | 418 | | | Management | | Conventions | | Statements | | | 419 | | | Information | | | | | | | 420 | | +--------------+ +--------------+ +---------------+ | | 421 | +---------------------------------------------------------------+ | 422 | | 423 | +---------------------------------------------------------------+ | 424 | | MIBs | | 425 | | +-------------+ +-------------+ +----------+ +----------+ | | 426 | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | | 427 | | | RFC1157 | | RFC1212 | | RFC14xx | | RFC19xx | | | 428 | | | format | | format | | format | | format | | | 429 | | +-------------+ +-------------+ +----------+ +----------+ | | 430 | +---------------------------------------------------------------+ | 431 | | 432 +-------------------------------------------------------------------+ 434 Those marked with an asterisk (*) are expected to be written in the 435 future. Each of these documents may be replaced or supplemented. 436 This Architecture document specifically describes how new documents 437 fit into the set of documents in the area of Message and PDU 438 handling. 440 2.1. Document Roadmap 442 One or more documents may be written to describe how sets of 443 documents taken together form specific Frameworks. The configuration 444 of document sets might change over time, so the "road map" should be 445 maintained in a document separate from the standards documents 446 themselves. 448 An example of such a roadmap is "Introduction to Version 3 of the 449 Internet-standard Network Management Framework" [SNMP-INTRO]. 451 2.2. Applicability Statement 453 SNMP is used in networks that vary widely in size and complexity, by 454 organizations that vary widely in their requirements of management. 455 Some models will be designed to address specific problems of 456 management, such as message security. 458 One or more documents may be written to describe the environments to 459 which certain versions of SNMP or models within SNMP would be 460 appropriately applied, and those to which a given model might be 461 inappropriately applied. 463 2.3. Coexistence and Transition 465 The purpose of an evolutionary architecture is to permit new models 466 to replace or supplement existing models. The interactions between 467 models could result in incompatibilities, security "holes", and other 468 undesirable effects. 470 The purpose of Coexistence documents is to detail recognized 471 anomalies and to describe required and recommended behaviors for 472 resolving the interactions between models within the architecture. 474 Coexistence documents may be prepared separately from model 475 definition documents, to describe and resolve interaction anomalies 476 between a model definition and one or more other model definitions. 478 Additionally, recommendations for transitions between models may also 479 be described, either in a coexistence document or in a separate 480 document. 482 One such coexistance document is [SNMP-COEX], "Coexistence between 483 Version 1, Version 2, and Version 3 of the Internet-standard Network 484 Management Framework". 486 2.4. Transport Mappings 488 SNMP messages are sent over various transports. It is the purpose of 489 Transport Mapping documents to define how the mapping between SNMP 490 and the transport is done. 492 2.5. Message Processing 494 A Message Processing Model document defines a message format, which 495 is typically identified by a version field in an SNMP message header. 496 The document may also define a MIB module for use in message 497 processing and for instrumentation of version-specific interactions. 499 An SNMP engine includes one or more Message Processing Models, and 500 thus may support sending and receiving multiple versions of SNMP 501 messages. 503 2.6. Security 505 Some environments require secure protocol interactions. Security is 506 normally applied at two different stages: 508 - in the transmission/receipt of messages, and 510 - in the processing of the contents of messages. 512 For purposes of this document, "security" refers to message-level 513 security; "access control" refers to the security applied to protocol 514 operations. 516 Authentication, encryption, and timeliness checking are common 517 functions of message level security. 519 A security document describes a Security Model, the threats against 520 which the model protects, the goals of the Security Model, the 521 protocols which it uses to meet those goals, and it may define a MIB 522 module to describe the data used during processing, and to allow the 523 remote configuration of message-level security parameters, such as 524 keys. 526 An SNMP engine may support multiple Security Models concurrently. 528 2.7. Access Control 530 During processing, it may be required to control access to managed 531 objects for operations. 533 An Access Control Model defines mechanisms to determine whether 534 access to a managed object should be allowed. An Access Control 535 Model may define a MIB module used during processing and to allow the 536 remote configuration of access control policies. 538 2.8. Protocol Operations 540 SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). SNMP 541 PDUs define the operations performed by the receiving SNMP engine. 542 It is the purpose of a Protocol Operations document to define the 543 operations of the protocol with respect to the processing of the 544 PDUs. Every PDU belongs to one or more of the PDU classes defined 545 below: 547 1) Read Class: 549 The Read Class contains protocol operations that retrieve 550 management information. For example, RFC 1905 defines the 551 following protocol operations for the Read Class: GetRequest- 552 PDU, GetNextRequest-PDU, and GetBulkRequest-PDU. 554 2) Write Class: 556 The Write Class contains protocol operations which attempt to 557 modify management information. For example, RFC 1905 defines 558 the following protocol operation for the Write Class: 559 SetRequest-PDU. 561 3) Response Class: 563 The Response Class contains protocol operations which are sent 564 in response to a previous request. For example, RFC 1905 565 defines the following for the Response Class: Response-PDU. 567 4) Notification Class: 569 The Notification Class contains protocol operations which send 570 a notification to a notification receiver application. For 571 example, RFC 1905 defines the following operations for the 572 Notification Class: Trapv2-PDU, InformRequest-PDU. 574 5) Internal Class: 576 The Internal Class contains protocol operations which are 577 exchanged internally between SNMP engines. For example, RFC 578 1905 defines the following operations for the Internal Class: 579 Report-PDU. 581 The preceding five classifications are based on the functional 582 properties of a PDU. It is also useful to classify PDUs based on 583 whether a response is expected: 585 6) Confirmed Class: 587 The Confirmed Class contains all protocol operations which 588 cause the receiving SNMP engine to send back a response. For 589 example, RFC 1905 defines the following operations for the 590 Confirmed Class: GetRequest-PDU, GetNextRequest-PDU, 591 GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU. 593 7) Unconfirmed Class: 595 The Unconfirmed Class contains all protocol operations which 596 are not acknowledged. For example, RFC 1905 defines the 597 following operations for the Unconfirmed Class: Report-PDU, 598 Trapv2-PDU. 600 An application document defines which Protocol Operations documents 601 are supported by the application. 603 2.9. Applications 605 An SNMP entity normally includes a number of applications. 606 Applications use the services of an SNMP engine to accomplish 607 specific tasks. They coordinate the processing of management 608 information operations, and may use SNMP messages to communicate with 609 other SNMP entities. 611 Applications documents describe the purpose of an application, the 612 services required of the associated SNMP engine, and the protocol 613 operations and informational model that the application uses to 614 perform management operations. 616 An application document defines which set of documents are used to 617 specifically define the structure of management information, textual 618 conventions, conformance requirements, and operations supported by 619 the application. 621 2.10. Structure of Management Information 623 Management information is viewed as a collection of managed objects, 624 residing in a virtual information store, termed the Management 625 Information Base (MIB). Collections of related objects are defined in 626 MIB modules. 628 It is the purpose of a Structure of Management Information document 629 to establish the syntax for defining objects, modules, and other 630 elements of managed information. 632 2.11. Textual Conventions 634 When designing a MIB module, it is often useful to define new types 635 similar to those defined in the SMI, but with more precise semantics, 636 or which have special semantics associated with them. These newly 637 defined types are termed textual conventions, and may be defined in 638 separate documents, or within a MIB module. 640 2.12. Conformance Statements 642 It may be useful to define the acceptable lower-bounds of 643 implementation, along with the actual level of implementation 644 achieved. It is the purpose of the Conformance Statements document to 645 define the notation used for these purposes. 647 2.13. Management Information Base Modules 649 MIB documents describe collections of managed objects which 650 instrument some aspect of a managed node. 652 2.13.1. SNMP Instrumentation MIBs 654 An SNMP MIB document may define a collection of managed objects which 655 instrument the SNMP protocol itself. In addition, MIB modules may be 656 defined within the documents which describe portions of the SNMP 657 architecture, such as the documents for Message processing Models, 658 Security Models, etc. for the purpose of instrumenting those Models, 659 and for the purpose of allowing remote configuration of the Model. 661 2.14. SNMP Framework Documents 663 This architecture is designed to allow an orderly evolution of 664 portions of SNMP Frameworks. 666 Throughout the rest of this document, the term "subsystem" refers to 667 an abstract and incomplete specification of a portion of a Framework, 668 that is further refined by a model specification. 670 A "model" describes a specific design of a subsystem, defining 671 additional constraints and rules for conformance to the model. A 672 model is sufficiently detailed to make it possible to implement the 673 specification. 675 An "implementation" is an instantiation of a subsystem, conforming to 676 one or more specific models. 678 SNMP version 1 (SNMPv1), is the original Internet-standard Network 679 Management Framework, as described in RFCs 1155, 1157, and 1212. 681 SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the 682 SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no 683 message definition. 685 The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP 686 Framework which supplements the SNMPv2 Framework, as described in 687 RFC1901. It adds the SNMPv2c message format, which is similar to the 688 SNMPv1 message format. 690 SNMP version 3 (SNMPv3), is an extensible SNMP Framework which 691 supplements the SNMPv2 Framework, by supporting the following: 693 - a new SNMP message format, 695 - Security for Messages, 697 - Access Control, and 699 - Remote configuration of SNMP parameters. 701 Other SNMP Frameworks, i.e., other configurations of implemented 702 subsystems, are expected to also be consistent with this 703 architecture. 705 3. Elements of the Architecture 707 This section describes the various elements of the architecture and 708 how they are named. There are three kinds of naming: 710 1) the naming of entities, 712 2) the naming of identities, and 714 3) the naming of management information. 716 This architecture also defines some names for other constructs that 717 are used in the documentation. 719 3.1. The Naming of Entities 721 An SNMP entity is an implementation of this architecture. Each such 722 SNMP entity consists of an SNMP engine and one or more associated 723 applications. 725 The following figure shows details about an SNMP entity and the 726 components within it. 728 +-------------------------------------------------------------------+ 729 | SNMP entity | 730 | | 731 | +-------------------------------------------------------------+ | 732 | | SNMP engine (identified by snmpEngineID) | | 733 | | | | 734 | | +------------+ +------------+ +-----------+ +-----------+ | | 735 | | | | | | | | | | | | 736 | | | Dispatcher | | Message | | Security | | Access | | | 737 | | | | | Processing | | Subsystem | | Control | | | 738 | | | | | Subsystem | | | | Subsystem | | | 739 | | | | | | | | | | | | 740 | | +------------+ +------------+ +-----------+ +-----------+ | | 741 | | | | 742 | +-------------------------------------------------------------+ | 743 | | 744 | +-------------------------------------------------------------+ | 745 | | Application(s) | | 746 | | | | 747 | | +-------------+ +--------------+ +--------------+ | | 748 | | | Command | | Notification | | Proxy | | | 749 | | | Generator | | Receiver | | Forwarder | | | 750 | | +-------------+ +--------------+ +--------------+ | | 751 | | | | 752 | | +-------------+ +--------------+ +--------------+ | | 753 | | | Command | | Notification | | Other | | | 754 | | | Responder | | Originator | | | | | 755 | | +-------------+ +--------------+ +--------------+ | | 756 | | | | 757 | +-------------------------------------------------------------+ | 758 | | 759 +-------------------------------------------------------------------+ 761 3.1.1. SNMP engine 763 An SNMP engine provides services for sending and receiving messages, 764 authenticating and encrypting messages, and controlling access to 765 managed objects. There is a one-to-one association between an SNMP 766 engine and the SNMP entity which contains it. 768 The engine contains: 770 1) a Dispatcher, 772 2) a Message Processing Subsystem, 773 3) a Security Subsystem, and 775 4) an Access Control Subsystem. 777 3.1.1.1. snmpEngineID 779 Within an administrative domain, an snmpEngineID is the unique and 780 unambiguous identifier of an SNMP engine. Since there is a one-to-one 781 association between SNMP engines and SNMP entities, it also uniquely 782 and unambiguously identifies the SNMP entity. 784 3.1.1.2. Dispatcher 786 There is only one Dispatcher in an SNMP engine. It allows for 787 concurrent support of multiple versions of SNMP messages in the SNMP 788 engine. It does so by: 790 - sending and receiving SNMP messages to/from the network, 792 - determining the version of an SNMP message and interacting with 793 the corresponding Message Processing Model, 795 - providing an abstract interface to SNMP applications for 796 delivery of a PDU to an application. 798 - providing an abstract interface for SNMP applications that 799 allows them to send a PDU to a remote SNMP entity. 801 3.1.1.3. Message Processing Subsystem 803 The Message Processing Subsystem is responsible for preparing 804 messages for sending, and extracting data from received messages. 806 The Message Processing Subsystem potentially contains multiple 807 Message Processing Models as shown in the next figure. 809 * One or more Message Processing Models may be present. 811 +------------------------------------------------------------------+ 812 | | 813 | Message Processing Subsystem | 814 | | 815 | +------------+ +------------+ +------------+ +------------+ | 816 | | * | | * | | * | | * | | 817 | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | 818 | | Message | | Message | | Message | | Message | | 819 | | Processing | | Processing | | Processing | | Processing | | 820 | | Model | | Model | | Model | | Model | | 821 | | | | | | | | | | 822 | +------------+ +------------+ +------------+ +------------+ | 823 | | 824 +------------------------------------------------------------------+ 826 3.1.1.3.1. Message Processing Model 828 Each Message Processing Model defines the format of a particular 829 version of an SNMP message and coordinates the preparation and 830 extraction of each such version-specific message format. 832 3.1.1.4. Security Subsystem 834 The Security Subsystem provides security services such as the 835 authentication and privacy of messages and potentially contains 836 multiple Security Models as shown in the following figure 838 * One or more Security Models may be present. 840 +------------------------------------------------------------------+ 841 | | 842 | Security Subsystem | 843 | | 844 | +----------------+ +-----------------+ +-------------------+ | 845 | | * | | * | | * | | 846 | | User-Based | | Other | | Other | | 847 | | Security | | Security | | Security | | 848 | | Model | | Model | | Model | | 849 | | | | | | | | 850 | +----------------+ +-----------------+ +-------------------+ | 851 | | 852 +------------------------------------------------------------------+ 854 3.1.1.4.1. Security Model 856 A Security Model defines the threats against which it protects, the 857 goals of its services, and the security protocols used to provide 858 security services such as authentication and privacy. 860 3.1.1.4.2. Security Protocol 862 A Security Protocol defines the mechanisms, procedures, and MIB data 863 used to provide a security service such as authentication or privacy. 865 3.1.2. Access Control Subsystem 867 The Access Control Subsystem provides authorization services by means 868 of one or more (*) Access Control Models. 870 +------------------------------------------------------------------+ 871 | | 872 | Access Control Subsystem | 873 | | 874 | +---------------+ +-----------------+ +------------------+ | 875 | | * | | * | | * | | 876 | | View-Based | | Other | | Other | | 877 | | Access | | Access | | Access | | 878 | | Control | | Control | | Control | | 879 | | Model | | Model | | Model | | 880 | | | | | | | | 881 | +---------------+ +-----------------+ +------------------+ | 882 | | 883 +------------------------------------------------------------------+ 885 3.1.2.1. Access Control Model 887 An Access Control Model defines a particular access decision function 888 in order to support decisions regarding access rights. 890 3.1.3. Applications 892 There are several types of applications, including: 894 - command generators, which monitor and manipulate management 895 data, 897 - command responders, which provide access to management data, 899 - notification originators, which initiate asynchronous messages, 901 - notification receivers, which process asynchronous messages, 902 and 904 - proxy forwarders, which forward messages between entities. 906 These applications make use of the services provided by the SNMP 907 engine. 909 3.1.3.1. SNMP Manager 911 An SNMP entity containing one or more command generator and/or 912 notification receiver applications (along with their associated SNMP 913 engine) has traditionally been called an SNMP manager. 914 * One or more models may be present. 916 (traditional SNMP manager) 917 +-------------------------------------------------------------------+ 918 | +--------------+ +--------------+ +--------------+ SNMP entity | 919 | | NOTIFICATION | | NOTIFICATION | | COMMAND | | 920 | | ORIGINATOR | | RECEIVER | | GENERATOR | | 921 | | applications | | applications | | applications | | 922 | +--------------+ +--------------+ +--------------+ | 923 | ^ ^ ^ | 924 | | | | | 925 | v v v | 926 | +-------+--------+-----------------+ | 927 | ^ | 928 | | +---------------------+ +----------------+ | 929 | | | Message Processing | | Security | | 930 | Dispatcher v | Subsystem | | Subsystem | | 931 | +-------------------+ | +------------+ | | | | 932 | | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | | 933 | | | | | +------------+ | | | Other | | | 934 | | | | | +------------+ | | | Security | | | 935 | | | | +->| v2cMP * |<--->| | Model | | | 936 | | Message | | | +------------+ | | +------------+ | | 937 | | Dispatcher <--------->+ | | | | 938 | | | | | +------------+ | | +------------+ | | 939 | | | | +->| v3MP * |<--->| | User-based | | | 940 | | Transport | | | +------------+ | | | Security | | | 941 | | Mapping | | | +------------+ | | | Model | | | 942 | | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | | 943 | +-------------------+ | +------------+ | | | | 944 | ^ +---------------------+ +----------------+ | 945 | | | 946 | v | 947 +-------------------------------------------------------------------+ 948 +-----+ +-----+ +-------+ 949 | UDP | | IPX | . . . | other | 950 +-----+ +-----+ +-------+ 951 ^ ^ ^ 952 | | | 953 v v v 954 +------------------------------+ 955 | Network | 956 +------------------------------+ 958 3.1.3.2. SNMP Agent 960 An SNMP entity containing one or more command responder and/or 961 notification originator applications (along with their associated 962 SNMP engine) has traditionally been called an SNMP agent. 963 +------------------------------+ 964 | Network | 965 +------------------------------+ 966 ^ ^ ^ 967 | | | 968 v v v 969 +-----+ +-----+ +-------+ 970 | UDP | | IPX | . . . | other | 971 +-----+ +-----+ +-------+ (traditional SNMP agent) 972 +-------------------------------------------------------------------+ 973 | ^ | 974 | | +---------------------+ +----------------+ | 975 | | | Message Processing | | Security | | 976 | Dispatcher v | Subsystem | | Subsystem | | 977 | +-------------------+ | +------------+ | | | | 978 | | Transport | | +->| v1MP * |<--->| +------------+ | | 979 | | Mapping | | | +------------+ | | | Other | | | 980 | | (e.g. RFC1906) | | | +------------+ | | | Security | | | 981 | | | | +->| v2cMP * |<--->| | Model | | | 982 | | Message | | | +------------+ | | +------------+ | | 983 | | Dispatcher <--------->| +------------+ | | +------------+ | | 984 | | | | +->| v3MP * |<--->| | User-based | | | 985 | | | | | +------------+ | | | Security | | | 986 | | PDU Dispatcher | | | +------------+ | | | Model | | | 987 | +-------------------+ | +->| otherMP * |<--->| +------------+ | | 988 | ^ | +------------+ | | | | 989 | | +---------------------+ +----------------+ | 990 | v | 991 | +-------+-------------------------+---------------+ | 992 | ^ ^ ^ | 993 | | | | | 994 | v v v | 995 | +-------------+ +---------+ +--------------+ +-------------+ | 996 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | | 997 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 998 | | application | | | | applications | | application | | 999 | +-------------+ +---------+ +--------------+ +-------------+ | 1000 | ^ ^ | 1001 | | | | 1002 | v v | 1003 | +----------------------------------------------+ | 1004 | | MIB instrumentation | SNMP entity | 1005 +-------------------------------------------------------------------+ 1007 3.2. The Naming of Identities 1009 principal 1010 ^ 1011 | 1012 | 1013 +----------------------------|-------------+ 1014 | SNMP engine v | 1015 | +--------------+ | 1016 | | | | 1017 | +-----------------| securityName |---+ | 1018 | | Security Model | | | | 1019 | | +--------------+ | | 1020 | | ^ | | 1021 | | | | | 1022 | | v | | 1023 | | +------------------------------+ | | 1024 | | | | | | 1025 | | | Model | | | 1026 | | | Dependent | | | 1027 | | | Security ID | | | 1028 | | | | | | 1029 | | +------------------------------+ | | 1030 | | ^ | | 1031 | | | | | 1032 | +-------------------------|----------+ | 1033 | | | 1034 | | | 1035 +----------------------------|-------------+ 1036 | 1037 v 1038 network 1040 3.2.1. Principal 1042 A principal is the "who" on whose behalf services are provided or 1043 processing takes place. 1045 A principal can be, among other things, an individual acting in a 1046 particular role; a set of individuals, with each acting in a 1047 particular role; an application or a set of applications; and 1048 combinations thereof. 1050 3.2.2. securityName 1052 A securityName is a human readable string representing a principal. 1053 It has a model-independent format, and can be used outside a 1054 particular Security Model. 1056 3.2.3. Model-dependent security ID 1058 A model-dependent security ID is the model-specific representation of 1059 a securityName within a particular Security Model. 1061 Model-dependent security IDs may or may not be human readable, and 1062 have a model-dependent syntax. Examples include community names, user 1063 names, and parties. 1065 The transformation of model-dependent security IDs into securityNames 1066 and vice versa is the responsibility of the relevant Security Model. 1068 3.3. The Naming of Management Information 1070 Management information resides at an SNMP entity where a Command 1071 Responder Application has local access to potentially multiple 1072 contexts. This application uses a contextEngineID equal to the 1073 snmpEngineID of its associated SNMP engine. 1075 +-----------------------------------------------------------------+ 1076 | SNMP entity (identified by snmpEngineID, example: abcd) | 1077 | | 1078 | +------------------------------------------------------------+ | 1079 | | SNMP engine (identified by snmpEngineID) | | 1080 | | | | 1081 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1082 | | | | | | | | | | | | 1083 | | | Dispatcher | | Message | | Security | | Access | | | 1084 | | | | | Processing | | Subsystem | | Control | | | 1085 | | | | | Subsystem | | | | Subsystem | | | 1086 | | | | | | | | | | | | 1087 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1088 | | | | 1089 | +------------------------------------------------------------+ | 1090 | | 1091 | +------------------------------------------------------------+ | 1092 | | Command Responder Application | | 1093 | | (contextEngineID, example: abcd) | | 1094 | | | | 1095 | | example contextNames: | | 1096 | | | | 1097 | | "bridge1" "bridge2" "" (default) | | 1098 | | --------- --------- ------------ | | 1099 | | | | | | | 1100 | +------|------------------|-------------------|--------------+ | 1101 | | | | | 1102 | +------|------------------|-------------------|--------------+ | 1103 | | MIB | instrumentation | | | | 1104 | | +---v------------+ +---v------------+ +----v-----------+ | | 1105 | | | context | | context | | context | | | 1106 | | | | | | | | | | 1107 | | | +------------+ | | +------------+ | | +------------+ | | | 1108 | | | | bridge MIB | | | | bridge MIB | | | | other MIB | | | | 1109 | | | +------------+ | | +------------+ | | +------------+ | | | 1110 | | | | | | | | | | 1111 | | | | | | | +------------+ | | | 1112 | | | | | | | | some MIB | | | | 1113 | | | | | | | +------------+ | | | 1114 | | | | | | | | | | 1115 +-----------------------------------------------------------------+ 1117 3.3.1. An SNMP Context 1119 An SNMP context, or just "context" for short, is a collection of 1120 management information accessible by an SNMP entity. An item of 1121 management information may exist in more than one context. An SNMP 1122 entity potentially has access to many contexts. 1124 Typically, there are many instances of each managed object type 1125 within a management domain. For simplicity, the method for 1126 identifying instances specified by the MIB module does not allow each 1127 instance to be distinguished amongst the set of all instances within 1128 a management domain; rather, it allows each instance to be identified 1129 only within some scope or "context", where there are multiple such 1130 contexts within the management domain. Often, a context is a 1131 physical device, or perhaps, a logical device, although a context can 1132 also encompass multiple devices, or a subset of a single device, or 1133 even a subset of multiple devices, but a context is always defined as 1134 a subset of a single SNMP entity. Thus, in order to identify an 1135 individual item of management information within the management 1136 domain, its contextName and contextEngineID must be identified in 1137 addition to its object type and its instance. 1139 For example, the managed object type ifDescr [RFC2233], is defined as 1140 the description of a network interface. To identify the description 1141 of device-X's first network interface, four pieces of information are 1142 needed: the snmpEngineID of the SNMP entity which provides access to 1143 the management information at device-X, the contextName (device-X), 1144 the managed object type (ifDescr), and the instance ("1"). 1146 Each context has (at least) one unique identification within the 1147 management domain. The same item of management information can exist 1148 in multiple contexts. An item of management information may have 1149 multiple unique identifications. This occurs when an item of 1150 management information exists in multiple contexts, and this also 1151 occurs when a context has multiple unique identifications. 1153 The combination of a contextEngineID and a contextName unambiguously 1154 identifies a context within an administrative domain; note that there 1155 may be multiple unique combinations of contextEngineID and 1156 contextName that unambiguously identify the same context. 1158 3.3.2. contextEngineID 1160 Within an administrative domain, a contextEngineID uniquely 1161 identifies an SNMP entity that may realize an instance of a context 1162 with a particular contextName. 1164 3.3.3. contextName 1166 A contextName is used to name a context. Each contextName MUST be 1167 unique within an SNMP entity. 1169 3.3.4. scopedPDU 1171 A scopedPDU is a block of data containing a contextEngineID, a 1172 contextName, and a PDU. 1174 The PDU is an SNMP Protocol Data Unit containing information named in 1175 the context which is unambiguously identified within an 1176 administrative domain by the combination of the contextEngineID and 1177 the contextName. See, for example, RFC1905 for more information about 1178 SNMP PDUs. 1180 3.4. Other Constructs 1182 3.4.1. maxSizeResponseScopedPDU 1184 The maxSizeResponseScopedPDU is the maximum size of a scopedPDU to be 1185 included in a response message. Note that the size of a scopedPDU 1186 does not include the size of the SNMP message header. 1188 3.4.2. Local Configuration Datastore 1190 The subsystems, models, and applications within an SNMP entity may 1191 need to retain their own sets of configuration information. 1193 Portions of the configuration information may be accessible as 1194 managed objects. 1196 The collection of these sets of information is referred to as an 1197 entity's Local Configuration Datastore (LCD). 1199 3.4.3. securityLevel 1201 This architecture recognizes three levels of security: 1203 - without authentication and without privacy (noAuthNoPriv) 1205 - with authentication but without privacy (authNoPriv) 1207 - with authentication and with privacy (authPriv) 1209 These three values are ordered such that noAuthNoPriv is less than 1210 authNoPriv and authNoPriv is less than authPriv. 1212 Every message has an associated securityLevel. All Subsystems 1213 (Message Processing, Security, Access Control) and applications are 1214 REQUIRED to either supply a value of securityLevel or to abide by the 1215 supplied value of securityLevel while processing the message and its 1216 contents. 1218 4. Abstract Service Interfaces 1220 Abstract service interfaces have been defined to describe the 1221 conceptual interfaces between the various subsystems within an SNMP 1222 entity. 1224 These abstract service interfaces are defined by a set of primitives 1225 that define the services provided and the abstract data elements that 1226 are to be passed when the services are invoked. This section lists 1227 the primitives that have been defined for the various subsystems. 1229 4.1. Dispatcher Primitives 1231 The Dispatcher typically provides services to the SNMP applications 1232 via its PDU Dispatcher. This section describes the primitives 1233 provided by the PDU Dispatcher. 1235 4.1.1. Generate Outgoing Request or Notification 1237 The PDU Dispatcher provides the following primitive for an 1238 application to send an SNMP Request or Notification to another SNMP 1239 entity: 1241 statusInformation = -- sendPduHandle if success 1242 -- errorIndication if failure 1243 sendPdu( 1244 IN transportDomain -- transport domain to be used 1245 IN transportAddress -- transport address to be used 1246 IN messageProcessingModel -- typically, SNMP version 1247 IN securityModel -- Security Model to use 1248 IN securityName -- on behalf of this principal 1249 IN securityLevel -- Level of Security requested 1250 IN contextEngineID -- data from/at this entity 1251 IN contextName -- data from/in this context 1252 IN pduVersion -- the version of the PDU 1253 IN PDU -- SNMP Protocol Data Unit 1254 IN expectResponse -- TRUE or FALSE 1255 ) 1257 4.1.2. Process Incoming Request or Notification PDU 1259 The PDU Dispatcher provides the following primitive to pass an 1260 incoming SNMP PDU to an application: 1262 processPdu( -- process Request/Notification PDU 1263 IN messageProcessingModel -- typically, SNMP version 1264 IN securityModel -- Security Model in use 1265 IN securityName -- on behalf of this principal 1266 IN securityLevel -- Level of Security 1267 IN contextEngineID -- data from/at this SNMP entity 1268 IN contextName -- data from/in this context 1269 IN pduVersion -- the version of the PDU 1270 IN PDU -- SNMP Protocol Data Unit 1271 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1272 IN stateReference -- reference to state information 1273 ) -- needed when sending a response 1275 4.1.3. Generate Outgoing Response 1277 The PDU Dispatcher provides the following primitive for an 1278 application to return an SNMP Response PDU to the PDU Dispatcher: 1280 returnResponsePdu( 1281 IN messageProcessingModel -- typically, SNMP version 1282 IN securityModel -- Security Model in use 1283 IN securityName -- on behalf of this principal 1284 IN securityLevel -- same as on incoming request 1285 IN contextEngineID -- data from/at this SNMP entity 1286 IN contextName -- data from/in this context 1287 IN pduVersion -- the version of the PDU 1288 IN PDU -- SNMP Protocol Data Unit 1289 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1290 IN stateReference -- reference to state information 1291 -- as presented with the request 1292 IN statusInformation -- success or errorIndication 1293 ) -- error counter OID/value if error 1295 4.1.4. Process Incoming Response PDU 1297 The PDU Dispatcher provides the following primitive to pass an 1298 incoming SNMP Response PDU to an application: 1300 processResponsePdu( -- process Response PDU 1301 IN messageProcessingModel -- typically, SNMP version 1302 IN securityModel -- Security Model in use 1303 IN securityName -- on behalf of this principal 1304 IN securityLevel -- Level of Security 1305 IN contextEngineID -- data from/at this SNMP entity 1306 IN contextName -- data from/in this context 1307 IN pduVersion -- the version of the PDU 1308 IN PDU -- SNMP Protocol Data Unit 1309 IN statusInformation -- success or errorIndication 1310 IN sendPduHandle -- handle from sendPdu 1311 ) 1313 4.1.5. Registering Responsibility for Handling SNMP PDUs 1315 Applications can register/unregister responsibility for a specific 1316 contextEngineID, for specific pduTypes, with the PDU Dispatcher 1317 according to the following primitives. The list of particular 1318 pduTypes that an application can register for is determined by the 1319 Message Processing Model(s) supported by the SNMP entity that 1320 contains the PDU Dispatcher. 1322 statusInformation = -- success or errorIndication 1323 registerContextEngineID( 1324 IN contextEngineID -- take responsibility for this one 1325 IN pduType -- the pduType(s) to be registered 1326 ) 1328 unregisterContextEngineID( 1329 IN contextEngineID -- give up responsibility for this one 1330 IN pduType -- the pduType(s) to be unregistered 1331 ) 1333 Note that realizations of the registerContextEngineID and 1334 unregisterContextEngineID abstract service interfaces may provide 1335 implementation-specific ways for applications to register/deregister 1336 responsiblity for all possible values of the contextEngineID or 1337 pduType parameters. 1339 4.2. Message Processing Subsystem Primitives 1341 The Dispatcher interacts with a Message Processing Model to process a 1342 specific version of an SNMP Message. This section describes the 1343 primitives provided by the Message Processing Subsystem. 1345 4.2.1. Prepare Outgoing SNMP Request or Notification Message 1347 The Message Processing Subsystem provides this service primitive for 1348 preparing an outgoing SNMP Request or Notification Message: 1350 statusInformation = -- success or errorIndication 1351 prepareOutgoingMessage( 1352 IN transportDomain -- transport domain to be used 1353 IN transportAddress -- transport address to be used 1354 IN messageProcessingModel -- typically, SNMP version 1355 IN securityModel -- Security Model to use 1356 IN securityName -- on behalf of this principal 1357 IN securityLevel -- Level of Security requested 1358 IN contextEngineID -- data from/at this entity 1359 IN contextName -- data from/in this context 1360 IN pduVersion -- the version of the PDU 1361 IN PDU -- SNMP Protocol Data Unit 1362 IN expectResponse -- TRUE or FALSE 1363 IN sendPduHandle -- the handle for matching 1364 -- incoming responses 1365 OUT destTransportDomain -- destination transport domain 1366 OUT destTransportAddress -- destination transport address 1367 OUT outgoingMessage -- the message to send 1368 OUT outgoingMessageLength -- its length 1369 ) 1371 4.2.2. Prepare an Outgoing SNMP Response Message 1373 The Message Processing Subsystem provides this service primitive for 1374 preparing an outgoing SNMP Response Message: 1376 result = -- SUCCESS or FAILURE 1377 prepareResponseMessage( 1378 IN messageProcessingModel -- typically, SNMP version 1379 IN securityModel -- same as on incoming request 1380 IN securityName -- same as on incoming request 1381 IN securityLevel -- same as on incoming request 1382 IN contextEngineID -- data from/at this SNMP entity 1383 IN contextName -- data from/in this context 1384 IN pduVersion -- the version of the PDU 1385 IN PDU -- SNMP Protocol Data Unit 1386 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1387 IN stateReference -- reference to state information 1388 -- as presented with the request 1389 IN statusInformation -- success or errorIndication 1390 -- error counter OID/value if error 1391 OUT destTransportDomain -- destination transport domain 1392 OUT destTransportAddress -- destination transport address 1393 OUT outgoingMessage -- the message to send 1394 OUT outgoingMessageLength -- its length 1395 ) 1397 4.2.3. Prepare Data Elements from an Incoming SNMP Message 1399 The Message Processing Subsystem provides this service primitive for 1400 preparing the abstract data elements from an incoming SNMP message: 1402 result = -- SUCCESS or errorIndication 1403 prepareDataElements( 1404 IN transportDomain -- origin transport domain 1405 IN transportAddress -- origin transport address 1406 IN wholeMsg -- as received from the network 1407 IN wholeMsgLength -- as received from the network 1408 OUT messageProcessingModel -- typically, SNMP version 1409 OUT securityModel -- Security Model to use 1410 OUT securityName -- on behalf of this principal 1411 OUT securityLevel -- Level of Security requested 1412 OUT contextEngineID -- data from/at this entity 1413 OUT contextName -- data from/in this context 1414 OUT pduVersion -- the version of the PDU 1415 OUT PDU -- SNMP Protocol Data Unit 1416 OUT pduType -- SNMP PDU type 1417 OUT sendPduHandle -- handle for matched request 1418 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU 1419 OUT statusInformation -- success or errorIndication 1420 -- error counter OID/value if error 1421 OUT stateReference -- reference to state information 1422 -- to be used for possible Response 1423 ) 1425 4.3. Access Control Subsystem Primitives 1427 Applications are the typical clients of the service(s) of the Access 1428 Control Subsystem. 1430 The following primitive is provided by the Access Control Subsystem 1431 to check if access is allowed: 1433 statusInformation = -- success or errorIndication 1434 isAccessAllowed( 1435 IN securityModel -- Security Model in use 1436 IN securityName -- principal who wants to access 1437 IN securityLevel -- Level of Security 1438 IN viewType -- read, write, or notify view 1439 IN contextName -- context containing variableName 1440 IN variableName -- OID for the managed object 1441 ) 1443 4.4. Security Subsystem Primitives 1445 The Message Processing Subsystem is the typical client of the 1446 services of the Security Subsystem. 1448 4.4.1. Generate a Request or Notification Message 1450 The Security Subsystem provides the following primitive to generate a 1451 Request or Notification message: 1453 statusInformation = 1454 generateRequestMsg( 1455 IN messageProcessingModel -- typically, SNMP version 1456 IN globalData -- message header, admin data 1457 IN maxMessageSize -- of the sending SNMP entity 1458 IN securityModel -- for the outgoing message 1459 IN securityEngineID -- authoritative SNMP entity 1460 IN securityName -- on behalf of this principal 1461 IN securityLevel -- Level of Security requested 1462 IN scopedPDU -- message (plaintext) payload 1463 OUT securityParameters -- filled in by Security Module 1464 OUT wholeMsg -- complete generated message 1465 OUT wholeMsgLength -- length of the generated message 1466 ) 1468 4.4.2. Process Incoming Message 1470 The Security Subsystem provides the following primitive to process an 1471 incoming message: 1473 statusInformation = -- errorIndication or success 1474 -- error counter OID/value if error 1475 processIncomingMsg( 1476 IN messageProcessingModel -- typically, SNMP version 1477 IN maxMessageSize -- of the sending SNMP entity 1478 IN securityParameters -- for the received message 1479 IN securityModel -- for the received message 1480 IN securityLevel -- Level of Security 1481 IN wholeMsg -- as received on the wire 1482 IN wholeMsgLength -- length as received on the wire 1483 OUT securityEngineID -- identification of the principal 1484 OUT securityName -- identification of the principal 1485 OUT scopedPDU, -- message (plaintext) payload 1486 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU 1487 OUT securityStateReference -- reference to security state 1488 ) -- information, needed for response 1490 4.4.3. Generate a Response Message 1492 The Security Subsystem provides the following primitive to generate a 1493 Response message: 1495 statusInformation = 1496 generateResponseMsg( 1497 IN messageProcessingModel -- typically, SNMP version 1498 IN globalData -- message header, admin data 1499 IN maxMessageSize -- of the sending SNMP entity 1500 IN securityModel -- for the outgoing message 1501 IN securityEngineID -- authoritative SNMP entity 1502 IN securityName -- on behalf of this principal 1503 IN securityLevel -- for the outgoing message 1504 IN scopedPDU -- message (plaintext) payload 1505 IN securityStateReference -- reference to security state 1506 -- information from original request 1507 OUT securityParameters -- filled in by Security Module 1508 OUT wholeMsg -- complete generated message 1509 OUT wholeMsgLength -- length of the generated message 1510 ) 1512 4.5. Common Primitives 1514 These primitive(s) are provided by multiple Subsystems. 1516 4.5.1. Release State Reference Information 1518 All Subsystems which pass stateReference information also provide a 1519 primitive to release the memory that holds the referenced state 1520 information: 1522 stateRelease( 1523 IN stateReference -- handle of reference to be released 1524 ) 1526 4.6. Scenario Diagrams 1528 4.6.1. Command Generator or Notification Originator 1530 This diagram shows how a Command Generator or Notification Originator 1531 application requests that a PDU be sent, and how the response is 1532 returned (asynchronously) to that application. 1534 Command Dispatcher Message Security 1535 Generator | Processing Model 1536 | | Model | 1537 | sendPdu | | | 1538 |------------------->| | | 1539 | | prepareOutgoingMessage | | 1540 : |----------------------->| | 1541 : | | generateRequestMsg | 1542 : | |-------------------->| 1543 : | | | 1544 : | |<--------------------| 1545 : | | | 1546 : |<-----------------------| | 1547 : | | | 1548 : |------------------+ | | 1549 : | Send SNMP | | | 1550 : | Request Message | | | 1551 : | to Network | | | 1552 : | v | | 1553 : : : : : 1554 : : : : : 1555 : : : : : 1556 : | | | | 1557 : | Receive SNMP | | | 1558 : | Response Message | | | 1559 : | from Network | | | 1560 : |<-----------------+ | | 1561 : | | | 1562 : | prepareDataElements | | 1563 : |----------------------->| | 1564 : | | processIncomingMsg | 1565 : | |-------------------->| 1566 : | | | 1567 : | |<--------------------| 1568 : | | | 1569 : |<-----------------------| | 1570 | processResponsePdu | | | 1571 |<-------------------| | | 1572 | | | | 1574 4.6.2. Scenario Diagram for a Command Responder Application 1576 This diagram shows how a Command Responder or Notification Receiver 1577 application registers for handling a pduType, how a PDU is dispatched 1578 to the application after a SNMP message is received, and how the 1579 Response is (asynchronously) send back to the network. 1581 Command Dispatcher Message Security 1582 Responder | Processing Model 1583 | | Model | 1584 | | | | 1585 | registerContextEngineID | | | 1586 |------------------------>| | | 1587 |<------------------------| | | | 1588 | | Receive SNMP | | | 1589 : | Message | | | 1590 : | from Network | | | 1591 : |<-------------+ | | 1592 : | | | 1593 : |prepareDataElements | | 1594 : |------------------->| | 1595 : | | processIncomingMsg | 1596 : | |------------------->| 1597 : | | | 1598 : | |<-------------------| 1599 : | | | 1600 : |<-------------------| | 1601 | processPdu | | | 1602 |<------------------------| | | 1603 | | | | 1604 : : : : 1605 : : : : 1606 | returnResponsePdu | | | 1607 |------------------------>| | | 1608 : | prepareResponseMsg | | 1609 : |------------------->| | 1610 : | |generateResponseMsg | 1611 : | |------------------->| 1612 : | | | 1613 : | |<-------------------| 1614 : | | | 1615 : |<-------------------| | 1616 : | | | 1617 : |--------------+ | | 1618 : | Send SNMP | | | 1619 : | Message | | | 1620 : | to Network | | | 1621 : | v | | 1623 5. Managed Object Definitions for SNMP Management Frameworks 1625 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN 1627 IMPORTS 1628 MODULE-IDENTITY, OBJECT-TYPE, 1629 OBJECT-IDENTITY, 1630 snmpModules FROM SNMPv2-SMI 1631 TEXTUAL-CONVENTION FROM SNMPv2-TC 1632 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 1634 snmpFrameworkMIB MODULE-IDENTITY 1635 LAST-UPDATED "9811171915Z" -- 17 November 1998 1636 ORGANIZATION "SNMPv3 Working Group" 1637 CONTACT-INFO "WG-email: snmpv3@tis.com 1638 Subscribe: majordomo@tis.com 1639 In message body: subscribe snmpv3 1641 Chair: Russ Mundy 1642 Trusted Information Systems 1643 postal: 3060 Washington Rd 1644 Glenwood MD 21738 1645 USA 1646 email: mundy@tis.com 1647 phone: +1 301-854-6889 1649 Co-editor Dave Harrington 1650 Cabletron Systems, Inc. 1651 postal: Post Office Box 5005 1652 Mail Stop: Durham 1653 35 Industrial Way 1654 Rochester, NH 03867-5005 1655 USA 1656 email: dbh@ctron.com 1657 phone: +1 603-337-7357 1659 Co-editor Randy Presuhn 1660 BMC Software, Inc. 1661 postal: 965 Stewart Drive 1662 Sunnyvale, CA 94086 1663 USA 1664 email: randy_presuhn@bmc.com 1665 phone: +1 408-616-3100 1667 Co-editor: Bert Wijnen 1668 IBM T.J. Watson Research 1669 postal: Schagen 33 1670 3461 GL Linschoten 1671 Netherlands 1672 email: wijnen@vnet.ibm.com 1673 phone: +31 348-432-794 1674 " 1675 DESCRIPTION "The SNMP Management Architecture MIB" 1676 REVISION "9811171915Z" -- 17 November 1998 1677 DESCRIPTION "The latest version of this MIB module. 1678 " 1679 REVISION "9711200000Z" -- 20 November 1997 1680 DESCRIPTION "The initial version, published in RFC 2271. 1681 " 1682 ::= { snmpModules 10 } 1684 -- Textual Conventions used in the SNMP Management Architecture *** 1686 SnmpEngineID ::= TEXTUAL-CONVENTION 1687 STATUS current 1688 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1689 Objects of this type are for identification, not for 1690 addressing, even though it is possible that an 1691 address may have been used in the generation of 1692 a specific value. 1694 The value for this object may not be all zeros or 1695 all 'ff'H or the empty (zero length) string. 1697 The initial value for this object may be configured 1698 via an operator console entry or via an algorithmic 1699 function. In the latter case, the following 1700 example algorithm is recommended. 1702 In cases where there are multiple engines on the 1703 same system, the use of this algorithm is NOT 1704 appropriate, as it would result in all of those 1705 engines ending up with the same ID value. 1707 1) The very first bit is used to indicate how the 1708 rest of the data is composed. 1710 0 - as defined by enterprise using former methods 1711 that existed before SNMPv3. See item 2 below. 1713 1 - as defined by this architecture, see item 3 1714 below. 1716 Note that this allows existing uses of the 1717 engineID (also known as AgentID [RFC1910]) to 1718 co-exist with any new uses. 1720 2) The snmpEngineID has a length of 12 octets. 1722 The first four octets are set to the binary 1723 equivalent of the agent's SNMP management 1724 private enterprise number as assigned by the 1725 Internet Assigned Numbers Authority (IANA). 1726 For example, if Acme Networks has been assigned 1727 { enterprises 696 }, the first four octets would 1728 be assigned '000002b8'H. 1730 The remaining eight octets are determined via 1731 one or more enterprise-specific methods. Such 1732 methods must be designed so as to maximize the 1733 possibility that the value of this object will 1734 be unique in the agent's administrative domain. 1735 For example, it may be the IP address of the SNMP 1736 entity, or the MAC address of one of the 1737 interfaces, with each address suitably padded 1738 with random octets. If multiple methods are 1739 defined, then it is recommended that the first 1740 octet indicate the method being used and the 1741 remaining octets be a function of the method. 1743 3) The length of the octet strings varies. 1745 The first four octets are set to the binary 1746 equivalent of the agent's SNMP management 1747 private enterprise number as assigned by the 1748 Internet Assigned Numbers Authority (IANA). 1749 For example, if Acme Networks has been assigned 1750 { enterprises 696 }, the first four octets would 1751 be assigned '000002b8'H. 1753 The very first bit is set to 1. For example, the 1754 above value for Acme Networks now changes to be 1755 '800002b8'H. 1757 The fifth octet indicates how the rest (6th and 1758 following octets) are formatted. The values for 1759 the fifth octet are: 1761 0 - reserved, unused. 1763 1 - IPv4 address (4 octets) 1764 lowest non-special IP address 1766 2 - IPv6 address (16 octets) 1767 lowest non-special IP address 1769 3 - MAC address (6 octets) 1770 lowest IEEE MAC address, canonical 1771 order 1773 4 - Text, administratively assigned 1774 Maximum remaining length 27 1776 5 - Octets, administratively assigned 1777 Maximum remaining length 27 1779 6-127 - reserved, unused 1781 127-255 - as defined by the enterprise 1782 Maximum remaining length 27 1783 " 1784 SYNTAX OCTET STRING (SIZE(5..32)) 1786 SnmpSecurityModel ::= TEXTUAL-CONVENTION 1787 STATUS current 1788 DESCRIPTION "An identifier that uniquely identifies a 1789 securityModel of the Security Subsystem within the 1790 SNMP Management Architecture. 1792 The values for securityModel are allocated as 1793 follows: 1795 - The zero value is reserved. 1796 - Values between 1 and 255, inclusive, are reserved 1797 for standards-track Security Models and are 1798 managed by the Internet Assigned Numbers Authority 1799 (IANA). 1800 - Values greater than 255 are allocated to 1801 enterprise-specific Security Models. An 1802 enterprise-specific securityModel value is defined 1803 to be: 1805 enterpriseID * 256 + security model within 1806 enterprise 1808 For example, the fourth Security Model defined by 1809 the enterprise whose enterpriseID is 1 would be 1810 260. 1812 This scheme for allocation of securityModel 1813 values allows for a maximum of 255 standards- 1814 based Security Models, and for a maximum of 1815 255 Security Models per enterprise. 1817 It is believed that the assignment of new 1818 securityModel values will be rare in practice 1819 because the larger the number of simultaneously 1820 utilized Security Models, the larger the 1821 chance that interoperability will suffer. 1822 Consequently, it is believed that such a range 1823 will be sufficient. In the unlikely event that 1824 the standards committee finds this number to be 1825 insufficient over time, an enterprise number 1826 can be allocated to obtain an additional 255 1827 possible values. 1829 Note that the most significant bit must be zero; 1830 hence, there are 23 bits allocated for various 1831 organizations to design and define non-standard 1832 securityModels. This limits the ability to 1833 define new proprietary implementations of Security 1834 Models to the first 8,388,608 enterprises. 1836 It is worthwhile to note that, in its encoded 1837 form, the securityModel value will normally 1838 require only a single byte since, in practice, 1839 the leftmost bits will be zero for most messages 1840 and sign extension is suppressed by the encoding 1841 rules. 1843 As of this writing, there are several values 1844 of securityModel defined for use with SNMP or 1845 reserved for use with supporting MIB objects. 1846 They are as follows: 1848 0 reserved for 'any' 1849 1 reserved for SNMPv1 1850 2 reserved for SNMPv2c 1851 3 User-Based Security Model (USM) 1852 " 1853 SYNTAX INTEGER(0..2147483647) 1855 SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION 1856 STATUS current 1857 DESCRIPTION "An identifier that uniquely identifies a Message 1858 Processing Model of the Message Processing 1859 Subsystem within a SNMP Management Architecture. 1861 The values for messageProcessingModel are 1862 allocated as follows: 1864 - Values between 0 and 255, inclusive, are 1865 reserved for standards-track Message Processing 1866 Models and are managed by the Internet Assigned 1867 Numbers Authority (IANA). 1868 - Values greater than 255 are allocated to 1869 enterprise-specific Message Processing Models. 1870 An enterprise messageProcessingModel value is 1871 defined to be: 1873 enterpriseID * 256 + 1874 messageProcessingModel within enterprise 1876 For example, the fourth Message Processing Model 1877 defined by the enterprise whose enterpriseID 1878 is 1 would be 260. 1880 This scheme for allocation of securityModel 1881 values allows for a maximum of 255 standards- 1882 based Message Processing Models, and for a 1883 maximum of 255 Message Processing Models per 1884 enterprise. 1886 It is believed that the assignment of new 1887 messageProcessingModel values will be rare 1888 in practice because the larger the number of 1889 simultaneously utilized Message Processing Models, 1890 the larger the chance that interoperability 1891 will suffer. It is believed that such a range 1892 will be sufficient. In the unlikely event that 1893 the standards committee finds this number to be 1894 insufficient over time, an enterprise number 1895 can be allocated to obtain an additional 256 1896 possible values. 1898 Note that the most significant bit must be zero; 1899 hence, there are 23 bits allocated for various 1900 organizations to design and define non-standard 1901 messageProcessingModels. This limits the ability 1902 to define new proprietary implementations of 1903 Message Processing Models to the first 8,388,608 1904 enterprises. 1906 It is worthwhile to note that, in its encoded 1907 form, the securityModel value will normally 1908 require only a single byte since, in practice, 1909 the leftmost bits will be zero for most messages 1910 and sign extension is suppressed by the encoding 1911 rules. 1913 As of this writing, there are several values of 1914 messageProcessingModel defined for use with SNMP. 1915 They are as follows: 1917 0 reserved for SNMPv1 1918 1 reserved for SNMPv2c 1919 2 reserved for SNMPv2u and SNMPv2* 1920 3 reserved for SNMPv3 1921 " 1922 SYNTAX INTEGER(0..2147483647) 1924 SnmpSecurityLevel ::= TEXTUAL-CONVENTION 1925 STATUS current 1926 DESCRIPTION "A Level of Security at which SNMP messages can be 1927 sent or with which operations are being processed; 1928 in particular, one of: 1930 noAuthNoPriv - without authentication and 1931 without privacy, 1932 authNoPriv - with authentication but 1933 without privacy, 1934 authPriv - with authentication and 1935 with privacy. 1937 These three values are ordered such that 1938 noAuthNoPriv is less than authNoPriv and 1939 authNoPriv is less than authPriv. 1940 " 1941 SYNTAX INTEGER { noAuthNoPriv(1), 1942 authNoPriv(2), 1943 authPriv(3) 1944 } 1946 SnmpAdminString ::= TEXTUAL-CONVENTION 1947 DISPLAY-HINT "255a" 1948 STATUS current 1949 DESCRIPTION "An octet string containing administrative 1950 information, preferably in human-readable form. 1952 To facilitate internationalization, this 1953 information is represented using the ISO/IEC 1954 IS 10646-1 character set, encoded as an octet 1955 string using the UTF-8 transformation format 1956 described in [RFC2279]. 1958 Since additional code points are added by 1959 amendments to the 10646 standard from time 1960 to time, implementations must be prepared to 1961 encounter any code point from 0x00000000 to 1962 0x7fffffff. Byte sequences that do not 1963 correspond to the valid UTF-8 encoding of a 1964 code point or are outside this range are 1965 prohibited. 1967 The use of control codes should be avoided. 1969 When it is necessary to represent a newline, 1970 the control code sequence CR LF should be used. 1972 The use of leading or trailing white space should 1973 be avoided. 1975 For code points not directly supported by user 1976 interface hardware or software, an alternative 1977 means of entry and display, such as hexadecimal, 1978 may be provided. 1980 For information encoded in 7-bit US-ASCII, 1981 the UTF-8 encoding is identical to the 1982 US-ASCII encoding. 1984 UTF-8 may require multiple bytes to represent a 1985 single character / code point; thus the length 1986 of this object in octets may be different from 1987 the number of characters encoded. Similarly, 1988 size constraints refer to the number of encoded 1989 octets, not the number of characters represented 1990 by an encoding. 1992 Note that when this TC is used for an object that 1993 is used or envisioned to be used as an index, then 1994 a SIZE restriction MUST be specified so that the 1995 number of sub-identifiers for any object instance 1996 does not exceed the limit of 128, as defined by 1997 [RFC1905]. 1999 Note that the size of an SnmpAdminString object is 2000 measured in octets, no characters. 2001 " 2002 SYNTAX OCTET STRING (SIZE (0..255)) 2004 -- Administrative assignments *************************************** 2006 snmpFrameworkAdmin 2007 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } 2009 snmpFrameworkMIBObjects 2010 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } 2011 snmpFrameworkMIBConformance 2012 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 2014 -- the snmpEngine Group ******************************************** 2016 snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 2018 snmpEngineID OBJECT-TYPE 2019 SYNTAX SnmpEngineID 2020 MAX-ACCESS read-only 2021 STATUS current 2022 DESCRIPTION "An SNMP engine's administratively-unique identifier. 2023 " 2024 ::= { snmpEngine 1 } 2026 snmpEngineBoots OBJECT-TYPE 2027 SYNTAX INTEGER (1..2147483647) 2028 MAX-ACCESS read-only 2029 STATUS current 2030 DESCRIPTION "The number of times that the SNMP engine has 2031 (re-)initialized itself since snmpEngineID 2032 was last configured. 2033 " 2034 ::= { snmpEngine 2 } 2036 snmpEngineTime OBJECT-TYPE 2037 SYNTAX INTEGER (0..2147483647) 2038 UNITS "seconds" 2039 MAX-ACCESS read-only 2040 STATUS current 2041 DESCRIPTION "The number of seconds since the value of 2042 the snmpEngineBoots object last changed. 2043 When incrementing this object's value would 2044 cause it to exceed its maximum, 2045 snmpEngineBoots is incremented as if a 2046 re-initialization had occurred, and this 2047 object's value consequently reverts to zero. 2048 " 2049 ::= { snmpEngine 3 } 2051 snmpEngineMaxMessageSize OBJECT-TYPE 2052 SYNTAX INTEGER (484..2147483647) 2053 MAX-ACCESS read-only 2054 STATUS current 2055 DESCRIPTION "The maximum length in octets of an SNMP message 2056 which this SNMP engine can send or receive and 2057 process, determined as the minimum of the maximum 2058 message size values supported among all of the 2059 transports available to and supported by the engine. 2060 " 2061 ::= { snmpEngine 4 } 2063 -- Registration Points for Authentication and Privacy Protocols ** 2065 snmpAuthProtocols OBJECT-IDENTITY 2066 STATUS current 2067 DESCRIPTION "Registration point for standards-track 2068 authentication protocols used in SNMP Management 2069 Frameworks. 2070 " 2071 ::= { snmpFrameworkAdmin 1 } 2073 snmpPrivProtocols OBJECT-IDENTITY 2074 STATUS current 2075 DESCRIPTION "Registration point for standards-track privacy 2076 protocols used in SNMP Management Frameworks. 2077 " 2078 ::= { snmpFrameworkAdmin 2 } 2080 -- Conformance information ****************************************** 2082 snmpFrameworkMIBCompliances 2083 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} 2084 snmpFrameworkMIBGroups 2085 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} 2087 -- compliance statements 2089 snmpFrameworkMIBCompliance MODULE-COMPLIANCE 2090 STATUS current 2091 DESCRIPTION "The compliance statement for SNMP engines which 2092 implement the SNMP Management Framework MIB. 2093 " 2094 MODULE -- this module 2095 MANDATORY-GROUPS { snmpEngineGroup } 2097 ::= { snmpFrameworkMIBCompliances 1 } 2099 -- units of conformance 2101 snmpEngineGroup OBJECT-GROUP 2102 OBJECTS { 2103 snmpEngineID, 2104 snmpEngineBoots, 2105 snmpEngineTime, 2106 snmpEngineMaxMessageSize 2107 } 2108 STATUS current 2109 DESCRIPTION "A collection of objects for identifying and 2110 determining the configuration and current timeliness 2111 values of an SNMP engine. 2112 " 2113 ::= { snmpFrameworkMIBGroups 1 } 2115 END 2117 6. IANA Considerations 2119 This document defines two number spaces which would be administered 2120 by IANA, one for security models and another for message processing 2121 models. 2123 6.1. Security Models 2125 The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are 2126 in the range from 1 to 255 inclusive, and are reserved for standards- 2127 track Security Models. If this range should in the future prove 2128 insufficient, an enterprise number can be allocated to obtain an 2129 additional 255 possible values. 2131 As of this writing, there are several values of securityModel defined 2132 for use with SNMP or reserved for use with supporting MIB objects. 2133 They are as follows: 2134 0 reserved for 'any' 2135 1 reserved for SNMPv1 2136 2 reserved for SNMPv2c 2137 3 User-Based Security Model (USM) 2139 6.2. Message Processing Models 2141 The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by 2142 IANA are in the range 0 to 255, inclusive. Each value uniquely 2143 identifies a standards-track Message Processing Model of the Message 2144 Processing Subsystem within a SNMP Management Architecture. 2146 Should this range prove insufficient in the future, an enterprise 2147 number may be obtained for the standards committee to get an 2148 additional 256 possible values. 2150 As of this writing, there are several values of 2151 messageProcessingModel defined for use with SNMP. They are as 2152 follows: 2153 0 reserved for SNMPv1 2154 1 reserved for SNMPv2c 2155 2 reserved for SNMPv2u and SNMPv2* 2156 3 reserved for SNMPv3 2158 7. Intellectual Property 2160 The IETF takes no position regarding the validity or scope of any 2161 intellectual property or other rights that might be claimed to 2162 pertain to the implementation or use of the technology described in 2163 this document or the extent to which any license under such rights 2164 might or might not be available; neither does it represent that it 2165 has made any effort to identify any such rights. Information on the 2166 IETF's procedures with respect to rights in standards-track and 2167 standards-related documentation can be found in BCP-11. Copies of 2168 claims of rights made available for publication and any assurances of 2169 licenses to be made available, or the result of an attempt made to 2170 obtain a general license or permission for the use of such 2171 proprietary rights by implementors or users of this specification can 2172 be obtained from the IETF Secretariat. 2174 The IETF invites any interested party to bring to its attention any 2175 copyrights, patents or patent applications, or other proprietary 2176 rights which may cover technology that may be required to practice 2177 this standard. Please address the information to the IETF Executive 2178 Director. 2180 8. Acknowledgements 2182 This document is the result of the efforts of the SNMPv3 Working 2183 Group. Some special thanks are in order to the following SNMPv3 WG 2184 members: 2186 Dave Battle (SNMP Research, Inc.) 2187 Uri Blumenthal (IBM T.J. Watson Research Center) 2188 Jeff Case (SNMP Research, Inc.) 2189 John Curran (BBN) 2190 T. Max Devlin (Eltrax Systems) 2191 John Flick (Hewlett Packard) 2192 David Harrington (Cabletron Systems Inc.) 2193 N.C. Hien (IBM T.J. Watson Research Center) 2194 Dave Levi (SNMP Research, Inc.) 2195 Louis A Mamakos (UUNET Technologies Inc.) 2196 Paul Meyer (Secure Computing Corporation) 2197 Keith McCloghrie (Cisco Systems) 2198 Russ Mundy (Trusted Information Systems, Inc.) 2199 Bob Natale (ACE*COMM Corporation) 2200 Mike O'Dell (UUNET Technologies Inc.) 2201 Dave Perkins (DeskTalk) 2202 Peter Polkinghorne (Brunel University) 2203 Randy Presuhn (BMC Software, Inc.) 2204 David Reid (SNMP Research, Inc.) 2205 Shawn Routhier (Epilogue) 2206 Juergen Schoenwaelder (TU Braunschweig) 2207 Bob Stewart (Cisco Systems) 2208 Bert Wijnen (IBM T.J. Watson Research Center) 2210 The document is based on recommendations of the IETF Security and 2211 Administrative Framework Evolution for SNMP Advisory Team. Members 2212 of that Advisory Team were: 2214 David Harrington (Cabletron Systems Inc.) 2215 Jeff Johnson (Cisco Systems) 2216 David Levi (SNMP Research Inc.) 2217 John Linn (Openvision) 2218 Russ Mundy (Trusted Information Systems) chair 2219 Shawn Routhier (Epilogue) 2220 Glenn Waters (Nortel) 2221 Bert Wijnen (IBM T. J. Watson Research Center) 2223 As recommended by the Advisory Team and the SNMPv3 Working Group 2224 Charter, the design incorporates as much as practical from previous 2225 RFCs and drafts. As a result, special thanks are due to the authors 2226 of previous designs known as SNMPv2u and SNMPv2*: 2228 Jeff Case (SNMP Research, Inc.) 2229 David Harrington (Cabletron Systems Inc.) 2230 David Levi (SNMP Research, Inc.) 2231 Keith McCloghrie (Cisco Systems) 2232 Brian O'Keefe (Hewlett Packard) 2233 Marshall T. Rose (Dover Beach Consulting) 2234 Jon Saperia (BGS Systems Inc.) 2235 Steve Waldbusser (International Network Services) 2236 Glenn W. Waters (Bell-Northern Research Ltd.) 2238 9. Security Considerations 2240 This document describes how an implementation can include a Security 2241 Model to protect management messages and an Access Control Model to 2242 control access to management information. 2244 The level of security provided is determined by the specific Security 2245 Model implementation(s) and the specific Access Control Model 2246 implementation(s) used. 2248 Applications have access to data which is not secured. Applications 2249 SHOULD take reasonable steps to protect the data from disclosure. 2251 It is the responsibility of the purchaser of an implementation to 2252 ensure that: 2254 1) an implementation complies with the rules defined by this 2255 architecture, 2257 2) the Security and Access Control Models utilized satisfy the 2258 security and access control needs of the organization, 2260 3) the implementations of the Models and Applications comply with 2261 the model and application specifications, 2263 4) and the implementation protects configuration secrets from 2264 inadvertent disclosure. 2266 This document also contains a MIB definition module. None of the 2267 objects defined is writable, and the information they represent is 2268 not deemed to be particularly sensitive. However, if they are deemed 2269 sensitive in a particular environment, access to them should be 2270 restricted through the use of appropriately configured Security and 2271 Access Control models. 2273 10. References 2275 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 2276 of Management Information for TCP/IP-based internets", STD 16, RFC 2277 1155, May 1990. 2279 [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The 2280 Simple Network Management Protocol", STD 15, RFC 1157, University 2281 of Tennessee at Knoxville, Performance Systems s International, 2282 Performance International, and the MIT Laboratory for Computer 2283 Science, May 1990. 2285 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 2286 16, RFC 1212, March 1991. 2288 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2289 M., and S. Waldbusser, "Introduction to Community-based SNMPv2", 2290 RFC 1901, January 1996. 2292 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2293 M. and S. Waldbusser, "Structure of Management Information for 2294 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2295 RFC 1902, January 1996. 2297 [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2298 M., and S. Waldbusser, "Textual Conventions for Version 2 of the 2299 Simple Network Management Protocol (SNMPv2)", RFC 1903, January 2300 1996. 2302 [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2303 M., and S. Waldbusser, "Conformance Statements for Version 2 of 2304 the Simple Network Management Protocol (SNMPv2)", RFC 1904, 2305 January 1996. 2307 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2308 M. and S. Waldbusser, "Protocol Operations for Version 2 of the 2309 Simple Network Management Protocol (SNMPv2)", RFC 1905, January 2310 1996. 2312 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2313 M. and S. Waldbusser, "Transport Mappings for Version 2 of the 2314 Simple Network Management Protocol (SNMPv2)", RFC 1906, January 2315 1996. 2317 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2318 M. and S. Waldbusser, "Management Information Base for Version 2 2319 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 2320 January 1996. 2322 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2323 M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 2324 of the SNMP-standard Network Management Framework", RFC 1908, 2325 January 1996. 2327 [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure 2328 for SNMPv2", RFC 1909, February 1996. 2330 [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", 2331 RFC 1910, February 1996. 2333 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2334 RFC 2279, January, 1998. 2336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2337 Requirement Levels", BCP 14, RFC 2119, March 1997. 2339 [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in the 2340 IETF Standards Process", BCP 11, RFC 2028, October 1996. 2342 [SNMP-MPD] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 2343 "Message Processing and Dispatching for the Simple Network 2344 Management Protocol (SNMP)", , 2345 November, 1998. 2347 [SNMP-USM] Blumenthal, U., and B. Wijnen, "The User-Based Security 2348 Model for Version 3 of the Simple Network Management Protocol 2349 (SNMPv3)", , October 1998. 2351 [SNMP-ACM] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 2352 Access Control Model for the Simple Network Management Protocol 2353 (SNMP)", , October 1998. 2355 [SNMP-APPL] Levi, D. B., Meyer, P., and B. Stewart, "SNMPv3 2356 Applications", , September 1998. 2358 [SNMP-INTRO] Case, J., Mundy, R., Partain, D., and B. Stewart, 2359 "Introduction to Version 3 of the Internet-standard Network 2360 Management Framework", , October 2361 1998. 2363 [SNMP-COEX] Frye, R., Levi, D., and B. Wijnen, "Coexistence between 2364 Version 1, Version 2, and Version 3 of the Internet-standard 2365 Network Management Framework", , 2366 November, 1998. 2368 [RFC2233] McCloghrie, K., and F. Kastenholz. "The Interfaces Group 2369 MIB using SMIv2", RFC 2233, November 1997. 2371 11. Editor's Addresses 2373 Bert Wijnen 2374 IBM T.J. Watson Research 2375 Schagen 33 2376 3461 GL Linschoten 2377 Netherlands 2379 Phone: +31 348-432-794 2380 EMail: wijnen@vnet.ibm.com 2382 Dave Harrington 2383 Cabletron Systems, Inc 2384 Post Office Box 5005 2385 Mail Stop: Durham 2386 35 Industrial Way 2387 Rochester, NH 03867-5005 2388 USA 2390 Phone: +1 603-337-7357 2391 EMail: dbh@ctron.com 2393 Randy Presuhn 2394 BMC Software, Inc. 2395 965 Stewart Drive 2396 Sunnyvale, CA 94086 2397 USA 2399 Phone: +1 408-616-3100 2400 Fax: +1 408-616-3101 2401 EMail: randy_presuhn@bmc.com 2403 APPENDIX A 2405 A. Guidelines for Model Designers 2407 This appendix describes guidelines for designers of models which are 2408 expected to fit into the architecture defined in this document. 2410 SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to 2411 provide trivial authentication and access control. SNMPv1 and SNMPv2c 2412 Frameworks can coexist with Frameworks designed according to this 2413 architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks 2414 could be designed to meet the requirements of this architecture, but 2415 this document does not provide guidelines for that coexistence. 2417 Within any subsystem model, there should be no reference to any 2418 specific model of another subsystem, or to data defined by a specific 2419 model of another subsystem. 2421 Transfer of data between the subsystems is deliberately described as 2422 a fixed set of abstract data elements and primitive functions which 2423 can be overloaded to satisfy the needs of multiple model definitions. 2425 Documents which define models to be used within this architecture 2426 SHOULD use the standard primitives between subsystems, possibly 2427 defining specific mechanisms for converting the abstract data 2428 elements into model-usable formats. This constraint exists to allow 2429 subsystem and model documents to be written recognizing common 2430 borders of the subsystem and model. Vendors are not constrained to 2431 recognize these borders in their implementations. 2433 The architecture defines certain standard services to be provided 2434 between subsystems, and the architecture defines abstract service 2435 interfaces to request these services. 2437 Each model definition for a subsystem SHOULD support the standard 2438 service interfaces, but whether, or how, or how well, it performs the 2439 service is dependent on the model definition. 2441 A.1. Security Model Design Requirements 2443 A.1.1. Threats 2445 A document describing a Security Model MUST describe how the model 2446 protects against the threats described under "Security Requirements 2447 of this Architecture", section 1.4. 2449 A.1.2. Security Processing 2451 Received messages MUST be validated by a Model of the Security 2452 Subsystem. Validation includes authentication and privacy processing 2453 if needed, but it is explicitly allowed to send messages which do not 2454 require authentication or privacy. 2456 A received message contains a specified securityLevel to be used 2457 during processing. All messages requiring privacy MUST also require 2458 authentication. 2460 A Security Model specifies rules by which authentication and privacy 2461 are to be done. A model may define mechanisms to provide additional 2462 security features, but the model definition is constrained to using 2463 (possibly a subset of) the abstract data elements defined in this 2464 document for transferring data between subsystems. 2466 Each Security Model may allow multiple security protocols to be used 2467 concurrently within an implementation of the model. Each Security 2468 Model defines how to determine which protocol to use, given the 2469 securityLevel and the security parameters relevant to the message. 2470 Each Security Model, with its associated protocol(s) defines how the 2471 sending/receiving entities are identified, and how secrets are 2472 configured. 2474 Authentication and Privacy protocols supported by Security Models are 2475 uniquely identified using Object Identifiers. IETF standard protocols 2476 for authentication or privacy should have an identifier defined 2477 within the snmpAuthProtocols or the snmpPrivProtocols subtrees. 2478 Enterprise specific protocol identifiers should be defined within the 2479 enterprise subtree. 2481 For privacy, the Security Model defines what portion of the message 2482 is encrypted. 2484 The persistent data used for security should be SNMP-manageable, but 2485 the Security Model defines whether an instantiation of the MIB is a 2486 conformance requirement. 2488 Security Models are replaceable within the Security Subsystem. 2489 Multiple Security Model implementations may exist concurrently within 2490 an SNMP engine. The number of Security Models defined by the SNMP 2491 community should remain small to promote interoperability. 2493 A.1.3. Validate the security-stamp in a received message 2495 A Message Processing Model requests that a Security Model: 2496 - verifies that the message has not been altered, 2497 - authenticates the identification of the principal for whom the 2498 message was generated. 2499 - decrypts the message if it was encrypted. 2501 Additional requirements may be defined by the model, and additional 2502 services may be provided by the model, but the model is constrained 2503 to use the following primitives for transferring data between 2504 subsystems. Implementations are not so constrained. 2506 A Message Processing Model uses the processIncomingMsg primitive as 2507 described in section 4.4.2. 2509 A.1.4. Security MIBs 2511 Each Security Model defines the MIB module(s) required for security 2512 processing, including any MIB module(s) required for the security 2513 protocol(s) supported. The MIB module(s) SHOULD be defined 2514 concurrently with the procedures which use the MIB module(s). The 2515 MIB module(s) are subject to normal access control rules. 2517 The mapping between the model-dependent security ID and the 2518 securityName MUST be able to be determined using SNMP, if the model- 2519 dependent MIB is instantiated and if access control policy allows 2520 access. 2522 A.1.5. Cached Security Data 2524 For each message received, the Security Model caches the state 2525 information such that a Response message can be generated using the 2526 same security information, even if the Local Configuration Datastore 2527 is altered between the time of the incoming request and the outgoing 2528 response. 2530 A Message Processing Model has the responsibility for explicitly 2531 releasing the cached data if such data is no longer needed. To enable 2532 this, an abstract securityStateReference data element is passed from 2533 the Security Model to the Message Processing Model. 2535 The cached security data may be implicitly released via the 2536 generation of a response, or explicitly released by using the 2537 stateRelease primitive, as described in section 4.5.1. 2539 A.2. Message Processing Model Design Requirements 2541 An SNMP engine contains a Message Processing Subsystem which may 2542 contain multiple Message Processing Models. 2544 The Message Processing Model MUST always (conceptually) pass the 2545 complete PDU, i.e., it never forwards less than the complete list of 2546 varBinds. 2548 A.2.1. Receiving an SNMP Message from the Network 2550 Upon receipt of a message from the network, the Dispatcher in the 2551 SNMP engine determines the version of the SNMP message and interacts 2552 with the corresponding Message Processing Model to determine the 2553 abstract data elements. 2555 A Message Processing Model specifies the SNMP Message format it 2556 supports and describes how to determine the values of the abstract 2557 data elements (like msgID, msgMaxSize, msgFlags, 2558 msgSecurityParameters, securityModel, securityLevel etc). A Message 2559 Processing Model interacts with a Security Model to provide security 2560 processing for the message using the processIncomingMsg primitive, as 2561 described in section 4.4.2. 2563 A.2.2. Sending an SNMP Message to the Network 2565 The Dispatcher in the SNMP engine interacts with a Message Processing 2566 Model to prepare an outgoing message. For that it uses the following 2567 primitives: 2569 - for requests and notifications: prepareOutgoingMessage, as 2570 described in section 4.2.1. 2572 - for response messages: prepareResponseMessage, as described in 2573 section 4.2.2. 2575 A Message Processing Model, when preparing an Outgoing SNMP Message, 2576 interacts with a Security Model to secure the message. For that it 2577 uses the following primitives: 2579 - for requests and notifications: generateRequestMsg, as 2580 described in section 4.4.1. 2582 - for response messages: generateResponseMsg as described in 2583 section 4.4.3. 2585 Once the SNMP message is prepared by a Message Processing Model, 2586 the Dispatcher sends the message to the desired address using the 2587 appropriate transport. 2589 A.3. Application Design Requirements 2591 Within an application, there may be an explicit binding to a specific 2592 SNMP message version, i.e., a specific Message Processing Model, and 2593 to a specific Access Control Model, but there should be no reference 2594 to any data defined by a specific Message Processing Model or Access 2595 Control Model. 2597 Within an application, there should be no reference to any specific 2598 Security Model, or any data defined by a specific Security Model. 2600 An application determines whether explicit or implicit access control 2601 should be applied to the operation, and, if access control is needed, 2602 which Access Control Model should be used. 2604 An application has the responsibility to define any MIB module(s) 2605 used to provide application-specific services. 2607 Applications interact with the SNMP engine to initiate messages, 2608 receive responses, receive asynchronous messages, and send responses. 2610 A.3.1. Applications that Initiate Messages 2612 Applications may request that the SNMP engine send messages 2613 containing SNMP commands or notifications using the sendPdu primitive 2614 as described in section 4.1.1. 2616 If it is desired that a message be sent to multiple targets, it is 2617 the responsibility of the application to provide the iteration. 2619 The SNMP engine assumes necessary access control has been applied to 2620 the PDU, and provides no access control services. 2622 The SNMP engine looks at the "expectResponse" parameter, and if a 2623 response is expected, then the appropriate information is cached such 2624 that a later response can be associated to this message, and can then 2625 be returned to the application. A sendPduHandle is returned to the 2626 application so it can later correspond the response with this message 2627 as well. 2629 A.3.2. Applications that Receive Responses 2631 The SNMP engine matches the incoming response messages to outstanding 2632 messages sent by this SNMP engine, and forwards the response to the 2633 associated application using the processResponsePdu primitive, as 2634 described in section 4.1.4. 2636 A.3.3. Applications that Receive Asynchronous Messages 2638 When an SNMP engine receives a message that is not the response to a 2639 request from this SNMP engine, it must determine to which application 2640 the message should be given. 2642 An Application that wishes to receive asynchronous messages registers 2643 itself with the engine using the primitive registerContextEngineID as 2644 described in section 4.1.5. 2646 An Application that wishes to stop receiving asynchronous messages 2647 should unregister itself with the SNMP engine using the primitive 2648 unregisterContextEngineID as described in section 4.1.5. 2650 Only one registration per combination of PDU type and contextEngineID 2651 is permitted at the same time. Duplicate registrations are ignored. 2652 An errorIndication will be returned to the application that attempts 2653 to duplicate a registration. 2655 All asynchronously received messages containing a registered 2656 combination of PDU type and contextEngineID are sent to the 2657 application which registered to support that combination. 2659 The engine forwards the PDU to the registered application, using the 2660 processPdu primitive, as described in section 4.1.2. 2662 A.3.4. Applications that Send Responses 2664 Request operations require responses. An application sends a 2665 response via the returnResponsePdu primitive, as described in section 2666 4.1.3. 2668 The contextEngineID, contextName, securityModel, securityName, 2669 securityLevel, and stateReference parameters are from the initial 2670 processPdu primitive. The PDU and statusInformation are the results 2671 of processing. 2673 A.4. Access Control Model Design Requirements 2675 An Access Control Model determines whether the specified securityName 2676 is allowed to perform the requested operation on a specified managed 2677 object. The Access Control Model specifies the rules by which access 2678 control is determined. 2680 The persistent data used for access control should be manageable 2681 using SNMP, but the Access Control Model defines whether an 2682 instantiation of the MIB is a conformance requirement. 2684 The Access Control Model must provide the primitive isAccessAllowed. 2686 B. Issues 2688 The issues list will be deleted when it is time to publish as an RFC. 2690 B.1. Open Issues 2692 - Need to update acknowledgement section. 2694 - we need a mechanism for a manager to be able to discover what 2695 securityModels are supported by a particular implementation 2696 Proposed resolution: trial and error appears to the preferred 2697 method. The need for a mechanism may be revisited when future 2698 security models are defined. 2700 - Are additional clarifications of the SnmpEngineID textual 2701 convention needed? The working group discussion on this topic was 2702 extensive. 2704 B.2. Change Log 2706 These are the major ways in which this draft differs from RFC 2271. 2708 - Updated draft identifier to keep distinct from the series of 2709 drafts leading to RFC 2271, based on Cynthia Clark's messages 2710 regarding VACM and USM. 2712 - Updated draft location information per Cynthia Clark's 2713 instructions. 2715 - Added note clarifying that the SnmpEngineID textual convention 2716 is used for naming, rather than addressing, even though there 2717 are situations where its value may have been generated from an 2718 address. 2720 - Clarified snmpEngineBoots and snmpEngineTime to be consistent 2721 with other documents and working group agreement. 2723 - Incremental update of References section. 2725 - Updated editors' contact information. 2727 - Updated reference to UTF-8 RFC. 2729 - Added reference for SNMPv3 Intro document. 2731 - Added IANA Considerations section. 2733 - Added reference to coexistance document. 2735 - Clarified PDU class description to void coupling to RFC 1905 2736 any more than is necessary. 2738 - additional clarification to SnmpAdminString. 2740 C. Full Copyright Statement 2742 Copyright (C) The Internet Society (1998). All Rights Reserved. 2744 This document and translations of it may be copied and furnished to 2745 others, and derivative works that comment on or otherwise explain it 2746 or assist in its implementation may be prepared, copied, published 2747 and distributed, in whole or in part, without restriction of any 2748 kind, provided that the above copyright notice and this paragraph are 2749 included on all such copies and derivative works. However, this 2750 document itself may not be modified in any way, such as by removing 2751 the copyright notice or references to the Internet Society or other 2752 Internet organizations, except as needed for the purpose of 2753 developing Internet standards in which case the procedures for 2754 copyrights defined in the Internet Standards process must be 2755 followed, or as required to translate it into languages other than 2756 English. 2758 The limited permissions granted above are perpetual and will not be 2759 revoked by the Internet Society or its successors or assigns. 2761 This document and the information contained herein is provided on an 2762 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2763 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2764 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2765 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2766 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.