idnits 2.17.1 draft-ietf-snmpv3-arch-00.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 225 has weird spacing: '...es with comma...' == Line 903 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 (5 August 1998) is 9389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1573' is mentioned on line 1066, but not defined ** Obsolete undefined reference: RFC 1573 (Obsoleted by RFC 2233) == Unused Reference: 'RFC1155' is defined on line 2134, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 2138, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 2144, but no explicit reference was found in the text == Unused Reference: 'RFC1901' is defined on line 2147, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 2151, but no explicit reference was found in the text == Unused Reference: 'RFC1903' is defined on line 2156, but no explicit reference was found in the text == Unused Reference: 'RFC1904' is defined on line 2161, but no explicit reference was found in the text == Unused Reference: 'RFC1906' is defined on line 2171, but no explicit reference was found in the text == Unused Reference: 'RFC1907' is defined on line 2176, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 2181, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 2186, but no explicit reference was found in the text == Unused Reference: 'BCP-11' is defined on line 2198, but no explicit reference was found in the text == Unused Reference: 'SNMP-MPD' is defined on line 2201, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 2206, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 2211, but no explicit reference was found in the text == Unused Reference: 'SNMP-APPL' is defined on line 2216, 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 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2028 (ref. 'BCP-11') (Obsoleted by RFC 9281) -- Unexpected draft version: The latest known version of draft-ietf-snmpv3-mpc is -05, but you're referring to -07. == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-usm-v2-01 == Outdated reference: A later version (-04) exists of draft-ietf-snmpv3-vacm-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-APPL' Summary: 22 errors (**), 0 flaws (~~), 23 warnings (==), 4 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 5 August 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 ........................................ 11 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 .............................................. 13 64 2.10. Structure of Management Information ...................... 13 65 2.11. Textual Conventions ...................................... 13 66 2.12. Conformance Statements ................................... 14 67 2.13. Management Information Base Modules ...................... 14 68 2.13.1. SNMP Instrumentation MIBs .............................. 14 69 2.14. SNMP Framework Documents ................................. 14 70 3. Elements of the Architecture ................................ 15 71 3.1. The Naming of Entities .................................... 15 72 3.1.1. SNMP engine ............................................. 16 73 3.1.1.1. snmpEngineID .......................................... 17 74 3.1.1.2. Dispatcher ............................................ 17 75 3.1.1.3. Message Processing Subsystem .......................... 18 76 3.1.1.3.1. Message Processing Model ............................ 18 77 3.1.1.4. Security Subsystem .................................... 19 78 3.1.1.4.1. Security Model ...................................... 19 79 3.1.1.4.2. Security Protocol ................................... 19 80 3.1.2. Access Control Subsystem ................................ 20 81 3.1.2.1. Access Control Model .................................. 20 82 3.1.3. Applications ............................................ 20 83 3.1.3.1. SNMP Manager .......................................... 21 84 3.1.3.2. SNMP Agent ............................................ 22 85 3.2. The Naming of Identities .................................. 23 86 3.2.1. Principal ............................................... 23 87 3.2.2. securityName ............................................ 23 88 3.2.3. Model-dependent security ID ............................. 24 89 3.3. The Naming of Management Information ...................... 25 90 3.3.1. An SNMP Context ......................................... 26 91 3.3.2. contextEngineID ......................................... 26 92 3.3.3. contextName ............................................. 27 93 3.3.4. scopedPDU ............................................... 27 94 3.4. Other Constructs .......................................... 27 95 3.4.1. maxSizeResponseScopedPDU ................................ 27 96 3.4.2. Local Configuration Datastore ........................... 27 97 3.4.3. securityLevel ........................................... 27 98 4. Abstract Service Interfaces ................................. 28 99 4.1. Dispatcher Primitives ..................................... 28 100 4.1.1. Generate Outgoing Request or Notification ............... 28 101 4.1.2. Process Incoming Request or Notification PDU ............ 28 102 4.1.3. Generate Outgoing Response .............................. 30 103 4.1.4. Process Incoming Response PDU ........................... 30 104 4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 30 105 4.2. Message Processing Subsystem Primitives ................... 31 106 4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 31 107 4.2.2. Prepare an Outgoing SNMP Response Message ............... 32 108 4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 33 109 4.3. Access Control Subsystem Primitives ....................... 33 110 4.4. Security Subsystem Primitives ............................. 34 111 4.4.1. Generate a Request or Notification Message .............. 34 112 4.4.2. Process Incoming Message ................................ 34 113 4.4.3. Generate a Response Message ............................. 35 114 4.5. Common Primitives ......................................... 35 115 4.5.1. Release State Reference Information ..................... 35 116 4.6. Scenario Diagrams ......................................... 36 117 4.6.1. Command Generator or Notification Originator ............ 36 118 4.6.2. Scenario Diagram for a Command Responder Application .... 37 119 5. Managed Object Definitions for SNMP Management Frameworks ... 38 120 6. Intellectual Property ....................................... 47 121 7. Acknowledgements ............................................ 48 122 8. Security Considerations ..................................... 49 123 9. References .................................................. 50 124 10. Editor's Addresses ......................................... 52 125 A. Guidelines for Model Designers .............................. 53 126 A.1. Security Model Design Requirements ........................ 53 127 A.1.1. Threats ................................................. 53 128 A.1.2. Security Processing ..................................... 54 129 A.1.3. Validate the security-stamp in a received message ....... 54 130 A.1.4. Security MIBs ........................................... 55 131 A.1.5. Cached Security Data .................................... 55 132 A.2. Message Processing Model Design Requirements .............. 55 133 A.2.1. Receiving an SNMP Message from the Network .............. 56 134 A.2.2. Sending an SNMP Message to the Network .................. 56 135 A.3. Application Design Requirements ........................... 56 136 A.3.1. Applications that Initiate Messages ..................... 57 137 A.3.2. Applications that Receive Responses ..................... 57 138 A.3.3. Applications that Receive Asynchronous Messages ......... 57 139 A.3.4. Applications that Send Responses ........................ 58 140 A.4. Access Control Model Design Requirements .................. 58 141 B. Issues ...................................................... 59 142 B.1. Open Issues ............................................... 59 143 B.2. Change Log ................................................ 59 144 C. Full Copyright Statement .................................... 59 146 1. Introduction 148 1.1. Overview 150 This document defines a vocabulary for describing SNMP Management 151 Frameworks, and an architecture for describing the major portions of 152 SNMP Management Frameworks. 154 This document does not provide a general introduction to SNMP. Other 155 documents and books can provide a much better introduction to SNMP. 156 Nor does this document provide a history of SNMP. That also can be 157 found in books and other documents. 159 Section 1 describes the purpose, goals, and design decisions of this 160 architecture. 162 Section 2 describes various types of documents which define SNMP 163 Frameworks, and how they fit into this architecture. It also provides 164 a minimal road map to the documents which have previously defined 165 SNMP frameworks. 167 Section 3 details the vocabulary of this architecture and its pieces. 168 This section is important for understanding the remaining sections, 169 and for understanding documents which are written to fit within this 170 architecture. 172 Section 4 describes the primitives used for the abstract service 173 interfaces between the various subsystems, models and applications 174 within this architecture. 176 Section 5 defines a collection of managed objects used to instrument 177 SNMP entities within this architecture. 179 Sections 6, 7, 8, and 9 are administrative in nature. 181 Appendix A contains guidelines for designers of Models which are 182 expected to fit within this architecture. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 1.2. SNMP 190 An SNMP management system contains: 192 - several (potentially many) nodes, each with an SNMP entity 193 containing command responder and notification originator 194 applications, which have access to management instrumentation 195 (traditionally called agents); 197 - at least one SNMP entity containing command generator and/or 198 notification receiver applications (traditionally called a 199 manager) and, 201 - a management protocol, used to convey management information 202 between the SNMP entities. 204 SNMP entities executing command generator and notification receiver 205 applications monitor and control managed elements. Managed elements 206 are devices such as hosts, routers, terminal servers, etc., which are 207 monitored and controlled via access to their management information. 209 It is the purpose of this document to define an architecture which 210 can evolve to realize effective management in a variety of 211 configurations and environments. The architecture has been designed 212 to meet the needs of implementations of: 214 - minimal SNMP entities with command responder and/or 215 notification originator applications (traditionally called SNMP 216 agents), 218 - SNMP entities with proxy forwarder applications (traditionally 219 called SNMP proxy agents), 221 - command line driven SNMP entities with command generator and/or 222 notification receiver applications (traditionally called SNMP 223 command line managers), 225 - SNMP entities with command generator and/or notification 226 receiver, plus command responder and/or notification originator 227 applications (traditionally called SNMP mid-level managers or 228 dual-role entities), 230 - SNMP entities with command generator and/or notification 231 receiver and possibly other types of applications for managing 232 a potentially very large number of managed nodes (traditionally 233 called (network) management stations). 235 1.3. Goals of this Architecture 237 This architecture was driven by the following goals: 239 - Use existing materials as much as possible. It is heavily based 240 on previous work, informally known as SNMPv2u and SNMPv2*. 242 - Address the need for secure SET support, which is considered 243 the most important deficiency in SNMPv1 and SNMPv2c. 245 - Make it possible to move portions of the architecture forward 246 in the standards track, even if consensus has not been reached 247 on all pieces. 249 - Define an architecture that allows for longevity of the SNMP 250 Frameworks that have been and will be defined. 252 - Keep SNMP as simple as possible. 254 - Make it relatively inexpensive to deploy a minimal conforming 255 implementation. 257 - Make it possible to upgrade portions of SNMP as new approaches 258 become available, without disrupting an entire SNMP framework. 260 - Make it possible to support features required in large 261 networks, but make the expense of supporting a feature directly 262 related to the support of the feature. 264 1.4. Security Requirements of this Architecture 266 Several of the classical threats to network protocols are applicable 267 to the management problem and therefore would be applicable to any 268 Security Model used in an SNMP Management Framework. Other threats 269 are not applicable to the management problem. This section discusses 270 principal threats, secondary threats, and threats which are of lesser 271 importance. 273 The principal threats against which any Security Model used within 274 this architecture SHOULD provide protection are: 276 Modification of Information 277 The modification threat is the danger that some unauthorized SNMP 278 entity may alter in-transit SNMP messages generated on behalf of 279 an authorized principal in such a way as to effect unauthorized 280 management operations, including falsifying the value of an 281 object. 283 Masquerade 284 The masquerade threat is the danger that management operations not 285 authorized for some principal may be attempted by assuming the 286 identity of another principal that has the appropriate 287 authorizations. 289 Message Stream Modification 290 The SNMP protocol is typically based upon a connectionless 291 transport service which may operate over any subnetwork service. 292 The re-ordering, delay or replay of messages can and does occur 293 through the natural operation of many such subnetwork services. 294 The message stream modification threat is the danger that messages 295 may be maliciously re-ordered, delayed or replayed to an extent 296 which is greater than can occur through the natural operation of a 297 subnetwork service, in order to effect unauthorized management 298 operations. 300 Disclosure 301 The disclosure threat is the danger of eavesdropping on the 302 exchanges between SNMP engines. Protecting against this threat 303 may be required as a matter of local policy. 305 There are at least two threats against which a Security Model within 306 this architecture need not protect. 308 Denial of Service 309 A Security Model need not attempt to address the broad range of 310 attacks by which service on behalf of authorized users is denied. 311 Indeed, such denial-of-service attacks are in many cases 312 indistinguishable from the type of network failures with which any 313 viable management protocol must cope as a matter of course. 315 Traffic Analysis 316 A Security Model need not attempt to address traffic analysis 317 attacks. Many traffic patterns are predictable - entities may be 318 managed on a regular basis by a relatively small number of 319 management stations - and therefore there is no significant 320 advantage afforded by protecting against traffic analysis. 322 1.5. Design Decisions 324 Various design decisions were made in support of the goals of the 325 architecture and the security requirements: 327 - Architecture 328 An architecture should be defined which identifies the 329 conceptual boundaries between the documents. Subsystems should 330 be defined which describe the abstract services provided by 331 specific portions of an SNMP framework. Abstract service 332 interfaces, as described by service primitives, define the 333 abstract boundaries between documents, and the abstract 334 services that are provided by the conceptual subsystems of an 335 SNMP framework. 337 - Self-contained Documents 338 Elements of procedure plus the MIB objects which are needed for 339 processing for a specific portion of an SNMP framework should 340 be defined in the same document, and as much as possible, 341 should not be referenced in other documents. This allows pieces 342 to be designed and documented as independent and self-contained 343 parts, which is consistent with the general SNMP MIB module 344 approach. As portions of SNMP change over time, the documents 345 describing other portions of SNMP are not directly impacted. 346 This modularity allows, for example, Security Models, 347 authentication and privacy mechanisms, and message formats to 348 be upgraded and supplemented as the need arises. The self- 349 contained documents can move along the standards track on 350 different time-lines. 352 - Threats 353 The Security Models in the Security Subsystem SHOULD protect 354 against the principal threats: modification of information, 355 masquerade, message stream modification and disclosure. They 356 do not need to protect against denial of service and traffic 357 analysis. 359 - Remote Configuration 360 The Security and Access Control Subsystems add a whole new set 361 of SNMP configuration parameters. The Security Subsystem also 362 requires frequent changes of secrets at the various SNMP 363 entities. To make this deployable in a large operational 364 environment, these SNMP parameters must be able to be remotely 365 configured. 367 - Controlled Complexity 368 It is recognized that producers of simple managed devices want 369 to keep the resources used by SNMP to a minimum. At the same 370 time, there is a need for more complex configurations which can 371 spend more resources for SNMP and thus provide more 372 functionality. The design tries to keep the competing 373 requirements of these two environments in balance and allows 374 the more complex environments to logically extend the simple 375 environment. 377 2. Documentation Overview 379 The following figure shows the set of documents that fit within the 380 SNMP Architecture. 382 +------------------------- Document Set ----------------------------+ 383 | | 384 | +------------+ +-----------------+ +----------------+ | 385 | | Document * | | Applicability * | | Coexistence * | | 386 | | Roadmap | | Statement | | & Transition | | 387 | +------------+ +-----------------+ +----------------+ | 388 | | 389 | +---------------------------------------------------------------+ | 390 | | Message Handling | | 391 | | +----------------+ +-----------------+ +-----------------+ | | 392 | | | Transport | | Message | | Security | | | 393 | | | Mappings | | Processing and | | | | | 394 | | | | | Dispatcher | | | | | 395 | | +----------------+ +-----------------+ +-----------------+ | | 396 | +---------------------------------------------------------------+ | 397 | | 398 | +---------------------------------------------------------------+ | 399 | | PDU Handling | | 400 | | +----------------+ +-----------------+ +-----------------+ | | 401 | | | Protocol | | Applications | | Access | | | 402 | | | Operations | | | | Control | | | 403 | | +----------------+ +-----------------+ +-----------------+ | | 404 | +---------------------------------------------------------------+ | 405 | | 406 | +---------------------------------------------------------------+ | 407 | | Information Model | | 408 | | +--------------+ +--------------+ +---------------+ | | 409 | | | Structure of | | Textual | | Conformance | | | 410 | | | Management | | Conventions | | Statements | | | 411 | | | Information | | | | | | | 412 | | +--------------+ +--------------+ +---------------+ | | 413 | +---------------------------------------------------------------+ | 414 | | 415 | +---------------------------------------------------------------+ | 416 | | MIBs | | 417 | | +-------------+ +-------------+ +----------+ +----------+ | | 418 | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | | 419 | | | RFC1157 | | RFC1212 | | RFC14xx | | RFC19xx | | | 420 | | | format | | format | | format | | format | | | 421 | | +-------------+ +-------------+ +----------+ +----------+ | | 422 | +---------------------------------------------------------------+ | 423 | | 424 +-------------------------------------------------------------------+ 426 Those marked with an asterisk (*) are expected to be written in the 427 future. Each of these documents may be replaced or supplemented. 428 This Architecture document specifically describes how new documents 429 fit into the set of documents in the area of Message and PDU 430 handling. 432 2.1. Document Roadmap 434 One or more documents may be written to describe how sets of 435 documents taken together form specific Frameworks. The configuration 436 of document sets might change over time, so the "road map" should be 437 maintained in a document separate from the standards documents 438 themselves. 440 2.2. Applicability Statement 442 SNMP is used in networks that vary widely in size and complexity, by 443 organizations that vary widely in their requirements of management. 444 Some models will be designed to address specific problems of 445 management, such as message security. 447 One or more documents may be written to describe the environments to 448 which certain versions of SNMP or models within SNMP would be 449 appropriately applied, and those to which a given model might be 450 inappropriately applied. 452 2.3. Coexistence and Transition 454 The purpose of an evolutionary architecture is to permit new models 455 to replace or supplement existing models. The interactions between 456 models could result in incompatibilities, security "holes", and other 457 undesirable effects. 459 The purpose of Coexistence documents is to detail recognized 460 anomalies and to describe required and recommended behaviors for 461 resolving the interactions between models within the architecture. 463 Coexistence documents may be prepared separately from model 464 definition documents, to describe and resolve interaction anomalies 465 between a model definition and one or more other model definitions. 467 Additionally, recommendations for transitions between models may also 468 be described, either in a coexistence document or in a separate 469 document. 471 2.4. Transport Mappings 473 SNMP messages are sent over various transports. It is the purpose of 474 Transport Mapping documents to define how the mapping between SNMP 475 and the transport is done. 477 2.5. Message Processing 479 A Message Processing Model document defines a message format, which 480 is typically identified by a version field in an SNMP message header. 481 The document may also define a MIB module for use in message 482 processing and for instrumentation of version-specific interactions. 484 An SNMP engine includes one or more Message Processing Models, and 485 thus may support sending and receiving multiple versions of SNMP 486 messages. 488 2.6. Security 490 Some environments require secure protocol interactions. Security is 491 normally applied at two different stages: 493 - in the transmission/receipt of messages, and 495 - in the processing of the contents of messages. 497 For purposes of this document, "security" refers to message-level 498 security; "access control" refers to the security applied to protocol 499 operations. 501 Authentication, encryption, and timeliness checking are common 502 functions of message level security. 504 A security document describes a Security Model, the threats against 505 which the model protects, the goals of the Security Model, the 506 protocols which it uses to meet those goals, and it may define a MIB 507 module to describe the data used during processing, and to allow the 508 remote configuration of message-level security parameters, such as 509 passwords. 511 An SNMP engine may support multiple Security Models concurrently. 513 2.7. Access Control 515 During processing, it may be required to control access to managed 516 objects for operations. 518 An Access Control Model defines mechanisms to determine whether 519 access to a managed object should be allowed. An Access Control 520 Model may define a MIB module used during processing and to allow the 521 remote configuration of access control policies. 523 2.8. Protocol Operations 525 SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). It is the 526 purpose of a Protocol Operations document to define the operations of 527 the protocol with respect to the processing of the PDUs. 529 An application document defines which Protocol Operations documents 530 are supported by the application. 532 2.9. Applications 534 An SNMP entity normally includes a number of applications. 535 Applications use the services of an SNMP engine to accomplish 536 specific tasks. They coordinate the processing of management 537 information operations, and may use SNMP messages to communicate with 538 other SNMP entities. 540 Applications documents describe the purpose of an application, the 541 services required of the associated SNMP engine, and the protocol 542 operations and informational model that the application uses to 543 perform management operations. 545 An application document defines which set of documents are used to 546 specifically define the structure of management information, textual 547 conventions, conformance requirements, and operations supported by 548 the application. 550 2.10. Structure of Management Information 552 Management information is viewed as a collection of managed objects, 553 residing in a virtual information store, termed the Management 554 Information Base (MIB). Collections of related objects are defined in 555 MIB modules. 557 It is the purpose of a Structure of Management Information document 558 to establish the syntax for defining objects, modules, and other 559 elements of managed information. 561 2.11. Textual Conventions 563 When designing a MIB module, it is often useful to define new types 564 similar to those defined in the SMI, but with more precise semantics, 565 or which have special semantics associated with them. These newly 566 defined types are termed textual conventions, and may defined in 567 separate documents, or within a MIB module. 569 2.12. Conformance Statements 571 It may be useful to define the acceptable lower-bounds of 572 implementation, along with the actual level of implementation 573 achieved. It is the purpose of Conformance Statements to define the 574 notation used for these purposes. 576 2.13. Management Information Base Modules 578 MIB documents describe collections of managed objects which 579 instrument some aspect of a managed node. 581 2.13.1. SNMP Instrumentation MIBs 583 An SNMP MIB document may define a collection of managed objects which 584 instrument the SNMP protocol itself. In addition, MIB modules may be 585 defined within the documents which describe portions of the SNMP 586 architecture, such as the documents for Message processing Models, 587 Security Models, etc. for the purpose of instrumenting those Models, 588 and for the purpose of allowing remote configuration of the Model. 590 2.14. SNMP Framework Documents 592 This architecture is designed to allow an orderly evolution of 593 portions of SNMP Frameworks. 595 Throughout the rest of this document, the term "subsystem" refers to 596 an abstract and incomplete specification of a portion of a Framework, 597 that is further refined by a model specification. 599 A "model" describes a specific design of a subsystem, defining 600 additional constraints and rules for conformance to the model. A 601 model is sufficiently detailed to make it possible to implement the 602 specification. 604 An "implementation" is an instantiation of a subsystem, conforming to 605 one or more specific models. 607 SNMP version 1 (SNMPv1), is the original Internet-standard Network 608 Management Framework, as described in RFCs 1155, 1157, and 1212. 610 SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the 611 SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no 612 message definition. 614 The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP 615 Framework which supplements the SNMPv2 Framework, as described in 616 RFC1901. It adds the SNMPv2c message format, which is similar to the 617 SNMPv1 message format. 619 SNMP version 3 (SNMPv3), is an extensible SNMP Framework which 620 supplements the SNMPv2 Framework, by supporting the following: 622 - a new SNMP message format, 624 - Security for Messages, and 626 - Access Control. 628 Other SNMP Frameworks, i.e., other configurations of implemented 629 subsystems, are expected to also be consistent with this 630 architecture. 632 3. Elements of the Architecture 634 This section describes the various elements of the architecture and 635 how they are named. There are three kinds of naming: 637 1) the naming of entities, 639 2) the naming of identities, and 641 3) the naming of management information. 643 This architecture also defines some names for other constructs that 644 are used in the documentation. 646 3.1. The Naming of Entities 648 An SNMP entity is an implementation of this architecture. Each such 649 SNMP entity consists of an SNMP engine and one or more associated 650 applications. 652 The following figure shows details about an SNMP entity and the 653 components within it. 655 +-------------------------------------------------------------------+ 656 | SNMP entity | 657 | | 658 | +-------------------------------------------------------------+ | 659 | | SNMP engine (identified by snmpEngineID) | | 660 | | | | 661 | | +------------+ +------------+ +-----------+ +-----------+ | | 662 | | | | | | | | | | | | 663 | | | Dispatcher | | Message | | Security | | Access | | | 664 | | | | | Processing | | Subsystem | | Control | | | 665 | | | | | Subsystem | | | | Subsystem | | | 666 | | | | | | | | | | | | 667 | | +------------+ +------------+ +-----------+ +-----------+ | | 668 | | | | 669 | +-------------------------------------------------------------+ | 670 | | 671 | +-------------------------------------------------------------+ | 672 | | Application(s) | | 673 | | | | 674 | | +-------------+ +--------------+ +--------------+ | | 675 | | | Command | | Notification | | Proxy | | | 676 | | | Generator | | Receiver | | Forwarder | | | 677 | | +-------------+ +--------------+ +--------------+ | | 678 | | | | 679 | | +-------------+ +--------------+ +--------------+ | | 680 | | | Command | | Notification | | Other | | | 681 | | | Responder | | Originator | | | | | 682 | | +-------------+ +--------------+ +--------------+ | | 683 | | | | 684 | +-------------------------------------------------------------+ | 685 | | 686 +-------------------------------------------------------------------+ 688 3.1.1. SNMP engine 690 An SNMP engine provides services for sending and receiving messages, 691 authenticating and encrypting messages, and controlling access to 692 managed objects. There is a one-to-one association between an SNMP 693 engine and the SNMP entity which contains it. 695 The engine contains: 697 1) a Dispatcher, 699 2) a Message Processing Subsystem, 701 3) a Security Subsystem, and 702 4) an Access Control Subsystem. 704 3.1.1.1. snmpEngineID 706 Within an administrative domain, an snmpEngineID is the unique and 707 unambiguous identifier of an SNMP engine. Since there is a one-to-one 708 association between SNMP engines and SNMP entities, it also uniquely 709 and unambiguously identifies the SNMP entity. 711 3.1.1.2. Dispatcher 713 There is only one Dispatcher in an SNMP engine. It allows for 714 concurrent support of multiple versions of SNMP messages in the SNMP 715 engine. It does so by: 717 - sending and receiving SNMP messages to/from the network, 719 - determining the version of an SNMP message and interacting with 720 the corresponding Message Processing Model, 722 - providing an abstract interface to SNMP applications for 723 delivery of a PDU to an application. 725 - providing an abstract interface for SNMP applications that 726 allows them to send a PDU to a remote SNMP entity. 728 3.1.1.3. Message Processing Subsystem 730 The Message Processing Subsystem is responsible for preparing 731 messages for sending, and extracting data from received messages. 733 The Message Processing Subsystem potentially contains multiple 734 Message Processing Models as shown in the next figure. 736 * One or more Message Processing Models may be present. 738 +------------------------------------------------------------------+ 739 | | 740 | Message Processing Subsystem | 741 | | 742 | +------------+ +------------+ +------------+ +------------+ | 743 | | * | | * | | * | | * | | 744 | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | 745 | | Message | | Message | | Message | | Message | | 746 | | Processing | | Processing | | Processing | | Processing | | 747 | | Model | | Model | | Model | | Model | | 748 | | | | | | | | | | 749 | +------------+ +------------+ +------------+ +------------+ | 750 | | 751 +------------------------------------------------------------------+ 753 3.1.1.3.1. Message Processing Model 755 Each Message Processing Model defines the format of a particular 756 version of an SNMP message and coordinates the preparation and 757 extraction of each such version-specific message format. 759 3.1.1.4. Security Subsystem 761 The Security Subsystem provides security services such as the 762 authentication and privacy of messages and potentially contains 763 multiple Security Models as shown in the following figure 765 * One or more Security Models may be present. 767 +------------------------------------------------------------------+ 768 | | 769 | Security Subsystem | 770 | | 771 | +----------------+ +-----------------+ +-------------------+ | 772 | | * | | * | | * | | 773 | | User-Based | | Other | | Other | | 774 | | Security | | Security | | Security | | 775 | | Model | | Model | | Model | | 776 | | | | | | | | 777 | +----------------+ +-----------------+ +-------------------+ | 778 | | 779 +------------------------------------------------------------------+ 781 3.1.1.4.1. Security Model 783 A Security Model defines the threats against which it protects, the 784 goals of its services, and the security protocols used to provide 785 security services such as authentication and privacy. 787 3.1.1.4.2. Security Protocol 789 A Security Protocol defines the mechanisms, procedures, and MIB data 790 used to provide a security service such as authentication or privacy. 792 3.1.2. Access Control Subsystem 794 The Access Control Subsystem provides authorization services by means 795 of one or more Access Control Models. 797 +------------------------------------------------------------------+ 798 | | 799 | Access Control Subsystem | 800 | | 801 | +---------------+ +-----------------+ +------------------+ | 802 | | * | | * | | * | | 803 | | View-Based | | Other | | Other | | 804 | | Access | | Access | | Access | | 805 | | Control | | Control | | Control | | 806 | | Model | | Model | | Model | | 807 | | | | | | | | 808 | +---------------+ +-----------------+ +------------------+ | 809 | | 810 +------------------------------------------------------------------+ 812 3.1.2.1. Access Control Model 814 An Access Control Model defines a particular access decision function 815 in order to support decisions regarding access rights. 817 3.1.3. Applications 819 There are several types of applications, including: 821 - command generators, which monitor and manipulate management 822 data, 824 - command responders, which provide access to management data, 826 - notification originators, which initiate asynchronous messages, 828 - notification receivers, which process asynchronous messages, 829 and 831 - proxy forwarders, which forward messages between entities. 833 These applications make use of the services provided by the SNMP 834 engine. 836 3.1.3.1. SNMP Manager 838 An SNMP entity containing one or more command generator and/or 839 notification receiver applications (along with their associated SNMP 840 engine) has traditionally been called an SNMP manager. 841 * One or more models may be present. 843 (traditional SNMP manager) 844 +-------------------------------------------------------------------+ 845 | +--------------+ +--------------+ +--------------+ SNMP entity | 846 | | NOTIFICATION | | NOTIFICATION | | COMMAND | | 847 | | ORIGINATOR | | RECEIVER | | GENERATOR | | 848 | | applications | | applications | | applications | | 849 | +--------------+ +--------------+ +--------------+ | 850 | ^ ^ ^ | 851 | | | | | 852 | v v v | 853 | +-------+--------+-----------------+ | 854 | ^ | 855 | | +---------------------+ +----------------+ | 856 | | | Message Processing | | Security | | 857 | Dispatcher v | Subsystem | | Subsystem | | 858 | +-------------------+ | +------------+ | | | | 859 | | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | | 860 | | | | | +------------+ | | | Other | | | 861 | | | | | +------------+ | | | Security | | | 862 | | | | +->| v2cMP * |<--->| | Model | | | 863 | | Message | | | +------------+ | | +------------+ | | 864 | | Dispatcher <--------->+ | | | | 865 | | | | | +------------+ | | +------------+ | | 866 | | | | +->| v3MP * |<--->| | User-based | | | 867 | | Transport | | | +------------+ | | | Security | | | 868 | | Mapping | | | +------------+ | | | Model | | | 869 | | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | | 870 | +-------------------+ | +------------+ | | | | 871 | ^ +---------------------+ +----------------+ | 872 | | | 873 | v | 874 +-------------------------------------------------------------------+ 875 +-----+ +-----+ +-------+ 876 | UDP | | IPX | . . . | other | 877 +-----+ +-----+ +-------+ 878 ^ ^ ^ 879 | | | 880 v v v 881 +------------------------------+ 882 | Network | 883 +------------------------------+ 885 3.1.3.2. SNMP Agent 887 An SNMP entity containing one or more command responder and/or 888 notification originator applications (along with their associated 889 SNMP engine) has traditionally been called an SNMP agent. 890 +------------------------------+ 891 | Network | 892 +------------------------------+ 893 ^ ^ ^ 894 | | | 895 v v v 896 +-----+ +-----+ +-------+ 897 | UDP | | IPX | . . . | other | 898 +-----+ +-----+ +-------+ (traditional SNMP agent) 899 +-------------------------------------------------------------------+ 900 | ^ | 901 | | +---------------------+ +----------------+ | 902 | | | Message Processing | | Security | | 903 | Dispatcher v | Subsystem | | Subsystem | | 904 | +-------------------+ | +------------+ | | | | 905 | | Transport | | +->| v1MP * |<--->| +------------+ | | 906 | | Mapping | | | +------------+ | | | Other | | | 907 | | (e.g. RFC1906) | | | +------------+ | | | Security | | | 908 | | | | +->| v2cMP * |<--->| | Model | | | 909 | | Message | | | +------------+ | | +------------+ | | 910 | | Dispatcher <--------->| +------------+ | | +------------+ | | 911 | | | | +->| v3MP * |<--->| | User-based | | | 912 | | | | | +------------+ | | | Security | | | 913 | | PDU Dispatcher | | | +------------+ | | | Model | | | 914 | +-------------------+ | +->| otherMP * |<--->| +------------+ | | 915 | ^ | +------------+ | | | | 916 | | +---------------------+ +----------------+ | 917 | v | 918 | +-------+-------------------------+---------------+ | 919 | ^ ^ ^ | 920 | | | | | 921 | v v v | 922 | +-------------+ +---------+ +--------------+ +-------------+ | 923 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | | 924 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 925 | | application | | | | applications | | application | | 926 | +-------------+ +---------+ +--------------+ +-------------+ | 927 | ^ ^ | 928 | | | | 929 | v v | 930 | +----------------------------------------------+ | 931 | | MIB instrumentation | SNMP entity | 932 +-------------------------------------------------------------------+ 934 3.2. The Naming of Identities 936 principal 937 ^ 938 | 939 | 940 +----------------------------|-------------+ 941 | SNMP engine v | 942 | +--------------+ | 943 | | | | 944 | +-----------------| securityName |---+ | 945 | | Security Model | | | | 946 | | +--------------+ | | 947 | | ^ | | 948 | | | | | 949 | | v | | 950 | | +------------------------------+ | | 951 | | | | | | 952 | | | Model | | | 953 | | | Dependent | | | 954 | | | Security ID | | | 955 | | | | | | 956 | | +------------------------------+ | | 957 | | ^ | | 958 | | | | | 959 | +-------------------------|----------+ | 960 | | | 961 | | | 962 +----------------------------|-------------+ 963 | 964 v 965 network 967 3.2.1. Principal 969 A principal is the "who" on whose behalf services are provided or 970 processing takes place. 972 A principal can be, among other things, an individual acting in a 973 particular role; a set of individuals, with each acting in a 974 particular role; an application or a set of applications; and 975 combinations thereof. 977 3.2.2. securityName 979 A securityName is a human readable string representing a principal. 980 It has a model-independent format, and can be used outside a 981 particular Security Model. 983 3.2.3. Model-dependent security ID 985 A model-dependent security ID is the model-specific representation of 986 a securityName within a particular Security Model. 988 Model-dependent security IDs may or may not be human readable, and 989 have a model-dependent syntax. Examples include community names, user 990 names, and parties. 992 The transformation of model-dependent security IDs into securityNames 993 and vice versa is the responsibility of the relevant Security Model. 995 3.3. The Naming of Management Information 997 Management information resides at an SNMP entity where a Command 998 Responder Application has local access to potentially multiple 999 contexts. This application uses a contextEngineID equal to the 1000 snmpEngineID of its associated SNMP engine. 1002 +-----------------------------------------------------------------+ 1003 | SNMP entity (identified by snmpEngineID, example: abcd) | 1004 | | 1005 | +------------------------------------------------------------+ | 1006 | | SNMP engine (identified by snmpEngineID) | | 1007 | | | | 1008 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1009 | | | | | | | | | | | | 1010 | | | Dispatcher | | Message | | Security | | Access | | | 1011 | | | | | Processing | | Subsystem | | Control | | | 1012 | | | | | Subsystem | | | | Subsystem | | | 1013 | | | | | | | | | | | | 1014 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1015 | | | | 1016 | +------------------------------------------------------------+ | 1017 | | 1018 | +------------------------------------------------------------+ | 1019 | | Command Responder Application | | 1020 | | (contextEngineID, example: abcd) | | 1021 | | | | 1022 | | example contextNames: | | 1023 | | | | 1024 | | "bridge1" "bridge2" "" (default) | | 1025 | | --------- --------- ------------ | | 1026 | | | | | | | 1027 | +------|------------------|-------------------|--------------+ | 1028 | | | | | 1029 | +------|------------------|-------------------|--------------+ | 1030 | | MIB | instrumentation | | | | 1031 | | +---v------------+ +---v------------+ +----v-----------+ | | 1032 | | | context | | context | | context | | | 1033 | | | | | | | | | | 1034 | | | +------------+ | | +------------+ | | +------------+ | | | 1035 | | | | bridge MIB | | | | bridge MIB | | | | other MIB | | | | 1036 | | | +------------+ | | +------------+ | | +------------+ | | | 1037 | | | | | | | | | | 1038 | | | | | | | +------------+ | | | 1039 | | | | | | | | some MIB | | | | 1040 | | | | | | | +------------+ | | | 1041 | | | | | | | | | | 1042 +-----------------------------------------------------------------+ 1044 3.3.1. An SNMP Context 1046 An SNMP context, or just "context" for short, is a collection of 1047 management information accessible by an SNMP entity. An item of 1048 management information may exist in more than one context. An SNMP 1049 entity potentially has access to many contexts. 1051 Typically, there are many instances of each managed object type 1052 within a management domain. For simplicity, the method for 1053 identifying instances specified by the MIB module does not allow each 1054 instance to be distinguished amongst the set of all instances within 1055 a management domain; rather, it allows each instance to be identified 1056 only within some scope or "context", where there are multiple such 1057 contexts within the management domain. Often, a context is a 1058 physical device, or perhaps, a logical device, although a context can 1059 also encompass multiple devices, or a subset of a single device, or 1060 even a subset of multiple devices, but a context is always defined as 1061 a subset of a single SNMP entity. Thus, in order to identify an 1062 individual item of management information within the management 1063 domain, its contextName and contextEngineID must be identified in 1064 addition to its object type and its instance. 1066 For example, the managed object type ifDescr [RFC1573], is defined as 1067 the description of a network interface. To identify the description 1068 of device-X's first network interface, four pieces of information are 1069 needed: the snmpEngineID of the SNMP entity which provides access to 1070 the management information at device-X, the contextName (device-X), 1071 the managed object type (ifDescr), and the instance ("1"). 1073 Each context has (at least) one unique identification within the 1074 management domain. The same item of management information can exist 1075 in multiple contexts. An item of management information may have 1076 multiple unique identifications. This occurs when an item of 1077 management information exists in multiple contexts, and this also 1078 occurs when a context has multiple unique identifications. 1080 The combination of a contextEngineID and a contextName unambiguously 1081 identifies a context within an administrative domain; note that there 1082 may be multiple unique combinations of contextEngineID and 1083 contextName that unambiguously identify the same context. 1085 3.3.2. contextEngineID 1087 Within an administrative domain, a contextEngineID uniquely 1088 identifies an SNMP entity that may realize an instance of a context 1089 with a particular contextName. 1091 3.3.3. contextName 1093 A contextName is used to name a context. Each contextName MUST be 1094 unique within an SNMP entity. 1096 3.3.4. scopedPDU 1098 A scopedPDU is a block of data containing a contextEngineID, a 1099 contextName, and a PDU. 1101 The PDU is an SNMP Protocol Data Unit containing information named in 1102 the context which is unambiguously identified within an 1103 administrative domain by the combination of the contextEngineID and 1104 the contextName. See, for example, RFC1905 for more information about 1105 SNMP PDUs. 1107 3.4. Other Constructs 1109 3.4.1. maxSizeResponseScopedPDU 1111 The maxSizeResponseScopedPDU is the maximum size of a scopedPDU to be 1112 included in a response message. Note that the size of a scopedPDU 1113 does not include the size of the SNMP message header. 1115 3.4.2. Local Configuration Datastore 1117 The subsystems, models, and applications within an SNMP entity may 1118 need to retain their own sets of configuration information. 1120 Portions of the configuration information may be accessible as 1121 managed objects. 1123 The collection of these sets of information is referred to as an 1124 entity's Local Configuration Datastore (LCD). 1126 3.4.3. securityLevel 1128 This architecture recognizes three levels of security: 1130 - without authentication and without privacy (noAuthNoPriv) 1132 - with authentication but without privacy (authNoPriv) 1134 - with authentication and with privacy (authPriv) 1136 These three values are ordered such that noAuthNoPriv is less than 1137 authNoPriv and authNoPriv is less than authPriv. 1139 Every message has an associated securityLevel. All Subsystems 1140 (Message Processing, Security, Access Control) and applications are 1141 required to either supply a value of securityLevel or to abide by the 1142 supplied value of securityLevel while processing the message and its 1143 contents. 1145 4. Abstract Service Interfaces 1147 Abstract service interfaces have been defined to describe the 1148 conceptual interfaces between the various subsystems within an SNMP 1149 entity. 1151 These abstract service interfaces are defined by a set of primitives 1152 that define the services provided and the abstract data elements that 1153 are to be passed when the services are invoked. This section lists 1154 the primitives that have been defined for the various subsystems. 1156 4.1. Dispatcher Primitives 1158 The Dispatcher typically provides services to the SNMP applications 1159 via its PDU Dispatcher. This section describes the primitives 1160 provided by the PDU Dispatcher. 1162 4.1.1. Generate Outgoing Request or Notification 1164 The PDU Dispatcher provides the following primitive for an 1165 application to send an SNMP Request or Notification to another SNMP 1166 entity: 1168 statusInformation = -- sendPduHandle if success 1169 -- errorIndication if failure 1170 sendPdu( 1171 IN transportDomain -- transport domain to be used 1172 IN transportAddress -- transport address to be used 1173 IN messageProcessingModel -- typically, SNMP version 1174 IN securityModel -- Security Model to use 1175 IN securityName -- on behalf of this principal 1176 IN securityLevel -- Level of Security requested 1177 IN contextEngineID -- data from/at this entity 1178 IN contextName -- data from/in this context 1179 IN pduVersion -- the version of the PDU 1180 IN PDU -- SNMP Protocol Data Unit 1181 IN expectResponse -- TRUE or FALSE 1182 ) 1184 4.1.2. Process Incoming Request or Notification PDU 1186 The PDU Dispatcher provides the following primitive to pass an 1187 incoming SNMP PDU to an application: 1189 processPdu( -- process Request/Notification PDU 1190 IN messageProcessingModel -- typically, SNMP version 1191 IN securityModel -- Security Model in use 1192 IN securityName -- on behalf of this principal 1193 IN securityLevel -- Level of Security 1194 IN contextEngineID -- data from/at this SNMP entity 1195 IN contextName -- data from/in this context 1196 IN pduVersion -- the version of the PDU 1197 IN PDU -- SNMP Protocol Data Unit 1198 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1199 IN stateReference -- reference to state information 1200 ) -- needed when sending a response 1202 4.1.3. Generate Outgoing Response 1204 The PDU Dispatcher provides the following primitive for an 1205 application to return an SNMP Response PDU to the PDU Dispatcher: 1207 returnResponsePdu( 1208 IN messageProcessingModel -- typically, SNMP version 1209 IN securityModel -- Security Model in use 1210 IN securityName -- on behalf of this principal 1211 IN securityLevel -- same as on incoming request 1212 IN contextEngineID -- data from/at this SNMP entity 1213 IN contextName -- data from/in this context 1214 IN pduVersion -- the version of the PDU 1215 IN PDU -- SNMP Protocol Data Unit 1216 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1217 IN stateReference -- reference to state information 1218 -- as presented with the request 1219 IN statusInformation -- success or errorIndication 1220 ) -- error counter OID/value if error 1222 4.1.4. Process Incoming Response PDU 1224 The PDU Dispatcher provides the following primitive to pass an 1225 incoming SNMP Response PDU to an application: 1227 processResponsePdu( -- process Response PDU 1228 IN messageProcessingModel -- typically, SNMP version 1229 IN securityModel -- Security Model in use 1230 IN securityName -- on behalf of this principal 1231 IN securityLevel -- Level of Security 1232 IN contextEngineID -- data from/at this SNMP entity 1233 IN contextName -- data from/in this context 1234 IN pduVersion -- the version of the PDU 1235 IN PDU -- SNMP Protocol Data Unit 1236 IN statusInformation -- success or errorIndication 1237 IN sendPduHandle -- handle from sendPdu 1238 ) 1240 4.1.5. Registering Responsibility for Handling SNMP PDUs 1242 Applications can register/unregister responsibility for a specific 1243 contextEngineID, for specific pduTypes, with the PDU Dispatcher 1244 according to the following primitives. The list of particular 1245 pduTypes that an application can register for is determined by the 1246 Message Processing Model(s) supported by the SNMP entity that 1247 contains the PDU Dispatcher. 1249 statusInformation = -- success or errorIndication 1250 registerContextEngineID( 1251 IN contextEngineID -- take responsibility for this one 1252 IN pduType -- the pduType(s) to be registered 1253 ) 1255 unregisterContextEngineID( 1256 IN contextEngineID -- give up responsibility for this one 1257 IN pduType -- the pduType(s) to be unregistered 1258 ) 1260 Note that realizations of the registerContextEngineID and 1261 unregisterContextEngineID abstract service interfaces may provide 1262 implementation-specific ways for applications to register/deregister 1263 responsiblity for all possible values of the contextEngineID or 1264 pduType parameters. 1266 4.2. Message Processing Subsystem Primitives 1268 The Dispatcher interacts with a Message Processing Model to process a 1269 specific version of an SNMP Message. This section describes the 1270 primitives provided by the Message Processing Subsystem. 1272 4.2.1. Prepare Outgoing SNMP Request or Notification Message 1274 The Message Processing Subsystem provides this service primitive for 1275 preparing an outgoing SNMP Request or Notification Message: 1277 statusInformation = -- success or errorIndication 1278 prepareOutgoingMessage( 1279 IN transportDomain -- transport domain to be used 1280 IN transportAddress -- transport address to be used 1281 IN messageProcessingModel -- typically, SNMP version 1282 IN securityModel -- Security Model to use 1283 IN securityName -- on behalf of this principal 1284 IN securityLevel -- Level of Security requested 1285 IN contextEngineID -- data from/at this 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 expectResponse -- TRUE or FALSE 1290 IN sendPduHandle -- the handle for matching 1291 -- incoming responses 1292 OUT destTransportDomain -- destination transport domain 1293 OUT destTransportAddress -- destination transport address 1294 OUT outgoingMessage -- the message to send 1295 OUT outgoingMessageLength -- its length 1296 ) 1298 4.2.2. Prepare an Outgoing SNMP Response Message 1300 The Message Processing Subsystem provides this service primitive for 1301 preparing an outgoing SNMP Response Message: 1303 result = -- SUCCESS or FAILURE 1304 prepareResponseMessage( 1305 IN messageProcessingModel -- typically, SNMP version 1306 IN securityModel -- same as on incoming request 1307 IN securityName -- same as on incoming request 1308 IN securityLevel -- same as on incoming request 1309 IN contextEngineID -- data from/at this SNMP entity 1310 IN contextName -- data from/in this context 1311 IN pduVersion -- the version of the PDU 1312 IN PDU -- SNMP Protocol Data Unit 1313 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1314 IN stateReference -- reference to state information 1315 -- as presented with the request 1316 IN statusInformation -- success or errorIndication 1317 -- error counter OID/value if error 1318 OUT destTransportDomain -- destination transport domain 1319 OUT destTransportAddress -- destination transport address 1320 OUT outgoingMessage -- the message to send 1321 OUT outgoingMessageLength -- its length 1322 ) 1324 4.2.3. Prepare Data Elements from an Incoming SNMP Message 1326 The Message Processing Subsystem provides this service primitive for 1327 preparing the abstract data elements from an incoming SNMP message: 1329 result = -- SUCCESS or errorIndication 1330 prepareDataElements( 1331 IN transportDomain -- origin transport domain 1332 IN transportAddress -- origin transport address 1333 IN wholeMsg -- as received from the network 1334 IN wholeMsgLength -- as received from the network 1335 OUT messageProcessingModel -- typically, SNMP version 1336 OUT securityModel -- Security Model to use 1337 OUT securityName -- on behalf of this principal 1338 OUT securityLevel -- Level of Security requested 1339 OUT contextEngineID -- data from/at this entity 1340 OUT contextName -- data from/in this context 1341 OUT pduVersion -- the version of the PDU 1342 OUT PDU -- SNMP Protocol Data Unit 1343 OUT pduType -- SNMP PDU type 1344 OUT sendPduHandle -- handle for matched request 1345 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU 1346 OUT statusInformation -- success or errorIndication 1347 -- error counter OID/value if error 1348 OUT stateReference -- reference to state information 1349 -- to be used for possible Response 1350 ) 1352 4.3. Access Control Subsystem Primitives 1354 Applications are the typical clients of the service(s) of the Access 1355 Control Subsystem. 1357 The following primitive is provided by the Access Control Subsystem 1358 to check if access is allowed: 1360 statusInformation = -- success or errorIndication 1361 isAccessAllowed( 1362 IN securityModel -- Security Model in use 1363 IN securityName -- principal who wants to access 1364 IN securityLevel -- Level of Security 1365 IN viewType -- read, write, or notify view 1366 IN contextName -- context containing variableName 1367 IN variableName -- OID for the managed object 1368 ) 1370 4.4. Security Subsystem Primitives 1372 The Message Processing Subsystem is the typical client of the 1373 services of the Security Subsystem. 1375 4.4.1. Generate a Request or Notification Message 1377 The Security Subsystem provides the following primitive to generate a 1378 Request or Notification message: 1380 statusInformation = 1381 generateRequestMsg( 1382 IN messageProcessingModel -- typically, SNMP version 1383 IN globalData -- message header, admin data 1384 IN maxMessageSize -- of the sending SNMP entity 1385 IN securityModel -- for the outgoing message 1386 IN securityEngineID -- authoritative SNMP entity 1387 IN securityName -- on behalf of this principal 1388 IN securityLevel -- Level of Security requested 1389 IN scopedPDU -- message (plaintext) payload 1390 OUT securityParameters -- filled in by Security Module 1391 OUT wholeMsg -- complete generated message 1392 OUT wholeMsgLength -- length of the generated message 1393 ) 1395 4.4.2. Process Incoming Message 1397 The Security Subsystem provides the following primitive to process an 1398 incoming message: 1400 statusInformation = -- errorIndication or success 1401 -- error counter OID/value if error 1402 processIncomingMsg( 1403 IN messageProcessingModel -- typically, SNMP version 1404 IN maxMessageSize -- of the sending SNMP entity 1405 IN securityParameters -- for the received message 1406 IN securityModel -- for the received message 1407 IN securityLevel -- Level of Security 1408 IN wholeMsg -- as received on the wire 1409 IN wholeMsgLength -- length as received on the wire 1410 OUT securityEngineID -- identification of the principal 1411 OUT securityName -- identification of the principal 1412 OUT scopedPDU, -- message (plaintext) payload 1413 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU 1414 OUT securityStateReference -- reference to security state 1415 ) -- information, needed for response 1417 4.4.3. Generate a Response Message 1419 The Security Subsystem provides the following primitive to generate a 1420 Response message: 1422 statusInformation = 1423 generateResponseMsg( 1424 IN messageProcessingModel -- typically, SNMP version 1425 IN globalData -- message header, admin data 1426 IN maxMessageSize -- of the sending SNMP entity 1427 IN securityModel -- for the outgoing message 1428 IN securityEngineID -- authoritative SNMP entity 1429 IN securityName -- on behalf of this principal 1430 IN securityLevel -- for the outgoing message 1431 IN scopedPDU -- message (plaintext) payload 1432 IN securityStateReference -- reference to security state 1433 -- information from original request 1434 OUT securityParameters -- filled in by Security Module 1435 OUT wholeMsg -- complete generated message 1436 OUT wholeMsgLength -- length of the generated message 1437 ) 1439 4.5. Common Primitives 1441 These primitive(s) are provided by multiple Subsystems. 1443 4.5.1. Release State Reference Information 1445 All Subsystems which pass stateReference information also provide a 1446 primitive to release the memory that holds the referenced state 1447 information: 1449 stateRelease( 1450 IN stateReference -- handle of reference to be released 1451 ) 1453 4.6. Scenario Diagrams 1455 4.6.1. Command Generator or Notification Originator 1457 This diagram shows how a Command Generator or Notification Originator 1458 application requests that a PDU be sent, and how the response is 1459 returned (asynchronously) to that application. 1461 Command Dispatcher Message Security 1462 Generator | Processing Model 1463 | | Model | 1464 | sendPdu | | | 1465 |------------------->| | | 1466 | | prepareOutgoingMessage | | 1467 : |----------------------->| | 1468 : | | generateRequestMsg | 1469 : | |-------------------->| 1470 : | | | 1471 : | |<--------------------| 1472 : | | | 1473 : |<-----------------------| | 1474 : | | | 1475 : |------------------+ | | 1476 : | Send SNMP | | | 1477 : | Request Message | | | 1478 : | to Network | | | 1479 : | v | | 1480 : : : : : 1481 : : : : : 1482 : : : : : 1483 : | | | | 1484 : | Receive SNMP | | | 1485 : | Response Message | | | 1486 : | from Network | | | 1487 : |<-----------------+ | | 1488 : | | | 1489 : | prepareDataElements | | 1490 : |----------------------->| | 1491 : | | processIncomingMsg | 1492 : | |-------------------->| 1493 : | | | 1494 : | |<--------------------| 1495 : | | | 1496 : |<-----------------------| | 1497 | processResponsePdu | | | 1498 |<-------------------| | | 1499 | | | | 1501 4.6.2. Scenario Diagram for a Command Responder Application 1503 This diagram shows how a Command Responder or Notification Receiver 1504 application registers for handling a pduType, how a PDU is dispatched 1505 to the application after a SNMP message is received, and how the 1506 Response is (asynchronously) send back to the network. 1508 Command Dispatcher Message Security 1509 Responder | Processing Model 1510 | | Model | 1511 | | | | 1512 | registerContextEngineID | | | 1513 |------------------------>| | | 1514 |<------------------------| | | | 1515 | | Receive SNMP | | | 1516 : | Message | | | 1517 : | from Network | | | 1518 : |<-------------+ | | 1519 : | | | 1520 : |prepareDataElements | | 1521 : |------------------->| | 1522 : | | processIncomingMsg | 1523 : | |------------------->| 1524 : | | | 1525 : | |<-------------------| 1526 : | | | 1527 : |<-------------------| | 1528 | processPdu | | | 1529 |<------------------------| | | 1530 | | | | 1531 : : : : 1532 : : : : 1533 | returnResponsePdu | | | 1534 |------------------------>| | | 1535 : | prepareResponseMsg | | 1536 : |------------------->| | 1537 : | |generateResponseMsg | 1538 : | |------------------->| 1539 : | | | 1540 : | |<-------------------| 1541 : | | | 1542 : |<-------------------| | 1543 : | | | 1544 : |--------------+ | | 1545 : | Send SNMP | | | 1546 : | Message | | | 1547 : | to Network | | | 1548 : | v | | 1550 5. Managed Object Definitions for SNMP Management Frameworks 1552 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN 1554 IMPORTS 1555 MODULE-IDENTITY, OBJECT-TYPE, 1556 OBJECT-IDENTITY, 1557 snmpModules FROM SNMPv2-SMI 1558 TEXTUAL-CONVENTION FROM SNMPv2-TC 1559 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 1561 snmpFrameworkMIB MODULE-IDENTITY 1562 LAST-UPDATED "9808052053Z" -- 05 August 1998 1563 ORGANIZATION "SNMPv3 Working Group" 1564 CONTACT-INFO "WG-email: snmpv3@tis.com 1565 Subscribe: majordomo@tis.com 1566 In message body: subscribe snmpv3 1568 Chair: Russ Mundy 1569 Trusted Information Systems 1570 postal: 3060 Washington Rd 1571 Glenwood MD 21738 1572 USA 1573 email: mundy@tis.com 1574 phone: +1 301-854-6889 1576 Co-editor Dave Harrington 1577 Cabletron Systems, Inc. 1578 postal: Post Office Box 5005 1579 Mail Stop: Durham 1580 35 Industrial Way 1581 Rochester, NH 03867-5005 1582 USA 1583 email: dbh@ctron.com 1584 phone: +1 603-337-7357 1586 Co-editor Randy Presuhn 1587 BMC Software, Inc. 1588 postal: 1190 Saratoga Avenue 1589 Suite 130 1590 San Jose, CA 95129 1591 USA 1592 email: rpresuhn@bmc.com 1593 phone: +1 408-616-3100 1595 Co-editor: Bert Wijnen 1596 IBM T.J. Watson Research 1597 postal: Schagen 33 1598 3461 GL Linschoten 1599 Netherlands 1600 email: wijnen@vnet.ibm.com 1601 phone: +31 348-432-794 1602 " 1603 DESCRIPTION "The SNMP Management Architecture MIB" 1604 ::= { snmpModules 10 } 1606 -- Textual Conventions used in the SNMP Management Architecture *** 1608 SnmpEngineID ::= TEXTUAL-CONVENTION 1609 STATUS current 1610 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1611 Objects of this type are for identification, not for 1612 addressing, even though it is possible that an 1613 address may have been used in the generation of 1614 a specific value. 1616 The value for this object may not be all zeros or 1617 all 'ff'H or the empty (zero length) string. 1619 The initial value for this object may be configured 1620 via an operator console entry or via an algorithmic 1621 function. In the latter case, the following 1622 example algorithm is recommended. 1624 In cases where there are multiple engines on the 1625 same system, the use of this algorithm is NOT 1626 appropriate, as it would result in all of those 1627 engines ending up with the same ID value. 1629 1) The very first bit is used to indicate how the 1630 rest of the data is composed. 1632 0 - as defined by enterprise using former methods 1633 that existed before SNMPv3. See item 2 below. 1635 1 - as defined by this architecture, see item 3 1636 below. 1638 Note that this allows existing uses of the 1639 engineID (also known as AgentID [RFC1910]) to 1640 co-exist with any new uses. 1642 2) The snmpEngineID has a length of 12 octets. 1644 The first four octets are set to the binary 1645 equivalent of the agent's SNMP management 1646 private enterprise number as assigned by the 1647 Internet Assigned Numbers Authority (IANA). 1648 For example, if Acme Networks has been assigned 1649 { enterprises 696 }, the first four octets would 1650 be assigned '000002b8'H. 1652 The remaining eight octets are determined via 1653 one or more enterprise-specific methods. Such 1654 methods must be designed so as to maximize the 1655 possibility that the value of this object will 1656 be unique in the agent's administrative domain. 1657 For example, it may be the IP address of the SNMP 1658 entity, or the MAC address of one of the 1659 interfaces, with each address suitably padded 1660 with random octets. If multiple methods are 1661 defined, then it is recommended that the first 1662 octet indicate the method being used and the 1663 remaining octets be a function of the method. 1665 3) The length of the octet strings varies. 1667 The first four octets are set to the binary 1668 equivalent of the agent's SNMP management 1669 private enterprise number as assigned by the 1670 Internet Assigned Numbers Authority (IANA). 1671 For example, if Acme Networks has been assigned 1672 { enterprises 696 }, the first four octets would 1673 be assigned '000002b8'H. 1675 The very first bit is set to 1. For example, the 1676 above value for Acme Networks now changes to be 1677 '800002b8'H. 1679 The fifth octet indicates how the rest (6th and 1680 following octets) are formatted. The values for 1681 the fifth octet are: 1683 0 - reserved, unused. 1685 1 - IPv4 address (4 octets) 1686 lowest non-special IP address 1688 2 - IPv6 address (16 octets) 1689 lowest non-special IP address 1691 3 - MAC address (6 octets) 1692 lowest IEEE MAC address, canonical 1693 order 1695 4 - Text, administratively assigned 1696 Maximum remaining length 27 1698 5 - Octets, administratively assigned 1699 Maximum remaining length 27 1701 6-127 - reserved, unused 1703 127-255 - as defined by the enterprise 1704 Maximum remaining length 27 1705 " 1706 SYNTAX OCTET STRING (SIZE(1..32)) 1708 SnmpSecurityModel ::= TEXTUAL-CONVENTION 1709 STATUS current 1710 DESCRIPTION "An identifier that uniquely identifies a 1711 securityModel of the Security Subsystem within the 1712 SNMP Management Architecture. 1714 The values for securityModel are allocated as 1715 follows: 1717 - The zero value is reserved. 1718 - Values between 1 and 255, inclusive, are reserved 1719 for standards-track Security Models and are 1720 managed by the Internet Assigned Numbers Authority 1721 (IANA). 1722 - Values greater than 255 are allocated to 1723 enterprise-specific Security Models. An 1724 enterprise-specific securityModel value is defined 1725 to be: 1727 enterpriseID * 256 + security model within 1728 enterprise 1730 For example, the fourth Security Model defined by 1731 the enterprise whose enterpriseID is 1 would be 1732 260. 1734 This scheme for allocation of securityModel 1735 values allows for a maximum of 255 standards- 1736 based Security Models, and for a maximum of 1737 255 Security Models per enterprise. 1739 It is believed that the assignment of new 1740 securityModel values will be rare in practice 1741 because the larger the number of simultaneously 1742 utilized Security Models, the larger the 1743 chance that interoperability will suffer. 1744 Consequently, it is believed that such a range 1745 will be sufficient. In the unlikely event that 1746 the standards committee finds this number to be 1747 insufficient over time, an enterprise number 1748 can be allocated to obtain an additional 255 1749 possible values. 1751 Note that the most significant bit must be zero; 1752 hence, there are 23 bits allocated for various 1753 organizations to design and define non-standard 1754 securityModels. This limits the ability to 1755 define new proprietary implementations of Security 1756 Models to the first 8,388,608 enterprises. 1758 It is worthwhile to note that, in its encoded 1759 form, the securityModel value will normally 1760 require only a single byte since, in practice, 1761 the leftmost bits will be zero for most messages 1762 and sign extension is suppressed by the encoding 1763 rules. 1765 As of this writing, there are several values 1766 of securityModel defined for use with SNMP or 1767 reserved for use with supporting MIB objects. 1768 They are as follows: 1770 0 reserved for 'any' 1771 1 reserved for SNMPv1 1772 2 reserved for SNMPv2c 1773 3 User-Based Security Model (USM) 1774 " 1775 SYNTAX INTEGER(0..2147483647) 1777 SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION 1778 STATUS current 1779 DESCRIPTION "An identifier that uniquely identifies a Message 1780 Processing Model of the Message Processing 1781 Subsystem within a SNMP Management Architecture. 1783 The values for messageProcessingModel are 1784 allocated as follows: 1786 - Values between 0 and 255, inclusive, are 1787 reserved for standards-track Message Processing 1788 Models and are managed by the Internet Assigned 1789 Numbers Authority (IANA). 1790 - Values greater than 255 are allocated to 1791 enterprise-specific Message Processing Models. 1792 An enterprise messageProcessingModel value is 1793 defined to be: 1795 enterpriseID * 256 + 1796 messageProcessingModel within enterprise 1798 For example, the fourth Message Processing Model 1799 defined by the enterprise whose enterpriseID 1800 is 1 would be 260. 1802 This scheme for allocation of securityModel 1803 values allows for a maximum of 255 standards- 1804 based Message Processing Models, and for a 1805 maximum of 255 Message Processing Models per 1806 enterprise. 1808 It is believed that the assignment of new 1809 messageProcessingModel values will be rare 1810 in practice because the larger the number of 1811 simultaneously utilized Message Processing Models, 1812 the larger the chance that interoperability 1813 will suffer. It is believed that such a range 1814 will be sufficient. In the unlikely event that 1815 the standards committee finds this number to be 1816 insufficient over time, an enterprise number 1817 can be allocated to obtain an additional 256 1818 possible values. 1820 Note that the most significant bit must be zero; 1821 hence, there are 23 bits allocated for various 1822 organizations to design and define non-standard 1823 messageProcessingModels. This limits the ability 1824 to define new proprietary implementations of 1825 Message Processing Models to the first 8,388,608 1826 enterprises. 1828 It is worthwhile to note that, in its encoded 1829 form, the securityModel value will normally 1830 require only a single byte since, in practice, 1831 the leftmost bits will be zero for most messages 1832 and sign extension is suppressed by the encoding 1833 rules. 1835 As of this writing, there are several values of 1836 messageProcessingModel defined for use with SNMP. 1837 They are as follows: 1839 0 reserved for SNMPv1 1840 1 reserved for SNMPv2c 1841 2 reserved for SNMPv2u and SNMPv2* 1842 3 reserved for SNMPv3 1843 " 1844 SYNTAX INTEGER(0..2147483647) 1846 SnmpSecurityLevel ::= TEXTUAL-CONVENTION 1847 STATUS current 1848 DESCRIPTION "A Level of Security at which SNMP messages can be 1849 sent or with which operations are being processed; 1850 in particular, one of: 1852 noAuthNoPriv - without authentication and 1853 without privacy, 1854 authNoPriv - with authentication but 1855 without privacy, 1856 authPriv - with authentication and 1857 with privacy. 1859 These three values are ordered such that 1860 noAuthNoPriv is less than authNoPriv and 1861 authNoPriv is less than authPriv. 1862 " 1863 SYNTAX INTEGER { noAuthNoPriv(1), 1864 authNoPriv(2), 1865 authPriv(3) 1866 } 1868 SnmpAdminString ::= TEXTUAL-CONVENTION 1869 DISPLAY-HINT "255a" 1870 STATUS current 1871 DESCRIPTION "An octet string containing administrative 1872 information, preferably in human-readable form. 1874 To facilitate internationalization, this 1875 information is represented using the ISO/IEC 1876 IS 10646-1 character set, encoded as an octet 1877 string using the UTF-8 transformation format 1878 described in [RFC2044]. 1880 Since additional code points are added by 1881 amendments to the 10646 standard from time 1882 to time, implementations must be prepared to 1883 encounter any code point from 0x00000000 to 1884 0x7fffffff. 1886 The use of control codes should be avoided. 1888 When it is necessary to represent a newline, 1889 the control code sequence CR LF should be used. 1891 The use of leading or trailing white space should 1892 be avoided. 1894 For code points not directly supported by user 1895 interface hardware or software, an alternative 1896 means of entry and display, such as hexadecimal, 1897 may be provided. 1899 For information encoded in 7-bit US-ASCII, 1900 the UTF-8 encoding is identical to the 1901 US-ASCII encoding. 1903 Note that when this TC is used for an object that 1904 is used or envisioned to be used as an index, then 1905 a SIZE restriction must be specified so that the 1906 number of sub-identifiers for any object instance 1907 does not exceed the limit of 128, as defined by 1908 [RFC1905]. 1909 " 1910 SYNTAX OCTET STRING (SIZE (0..255)) 1912 -- Administrative assignments *************************************** 1914 snmpFrameworkAdmin 1915 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } 1916 snmpFrameworkMIBObjects 1917 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } 1918 snmpFrameworkMIBConformance 1919 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 1921 -- the snmpEngine Group ******************************************** 1923 snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 1925 snmpEngineID OBJECT-TYPE 1926 SYNTAX SnmpEngineID 1927 MAX-ACCESS read-only 1928 STATUS current 1929 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1930 " 1931 ::= { snmpEngine 1 } 1933 snmpEngineBoots OBJECT-TYPE 1934 SYNTAX INTEGER (1..2147483647) 1935 MAX-ACCESS read-only 1936 STATUS current 1937 DESCRIPTION "The number of times that the SNMP engine has 1938 (re-)initialized itself since snmpEngineID 1939 was last configured. 1940 " 1941 ::= { snmpEngine 2 } 1943 snmpEngineTime OBJECT-TYPE 1944 SYNTAX INTEGER (0..2147483647) 1945 UNITS "seconds" 1946 MAX-ACCESS read-only 1947 STATUS current 1948 DESCRIPTION "The number of seconds since the value of 1949 the snmpEngineBoots object last changed. 1950 When incrementing this object's value would 1951 cause it to exceed its maximum, 1952 snmpEngineBoots is incremented as if a 1953 re-initialization had occurred, and this 1954 object's value consequently reverts to zero. 1955 " 1956 ::= { snmpEngine 3 } 1958 snmpEngineMaxMessageSize OBJECT-TYPE 1959 SYNTAX INTEGER (484..2147483647) 1960 MAX-ACCESS read-only 1961 STATUS current 1962 DESCRIPTION "The maximum length in octets of an SNMP message 1963 which this SNMP engine can send or receive and 1964 process, determined as the minimum of the maximum 1965 message size values supported among all of the 1966 transports available to and supported by the engine. 1967 " 1968 ::= { snmpEngine 4 } 1970 -- Registration Points for Authentication and Privacy Protocols ** 1972 snmpAuthProtocols OBJECT-IDENTITY 1973 STATUS current 1974 DESCRIPTION "Registration point for standards-track 1975 authentication protocols used in SNMP Management 1976 Frameworks. 1977 " 1978 ::= { snmpFrameworkAdmin 1 } 1980 snmpPrivProtocols OBJECT-IDENTITY 1981 STATUS current 1982 DESCRIPTION "Registration point for standards-track privacy 1983 protocols used in SNMP Management Frameworks. 1984 " 1985 ::= { snmpFrameworkAdmin 2 } 1987 -- Conformance information ****************************************** 1989 snmpFrameworkMIBCompliances 1990 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} 1991 snmpFrameworkMIBGroups 1992 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} 1994 -- compliance statements 1996 snmpFrameworkMIBCompliance MODULE-COMPLIANCE 1997 STATUS current 1998 DESCRIPTION "The compliance statement for SNMP engines which 1999 implement the SNMP Management Framework MIB. 2000 " 2001 MODULE -- this module 2002 MANDATORY-GROUPS { snmpEngineGroup } 2004 ::= { snmpFrameworkMIBCompliances 1 } 2006 -- units of conformance 2008 snmpEngineGroup OBJECT-GROUP 2009 OBJECTS { 2010 snmpEngineID, 2011 snmpEngineBoots, 2012 snmpEngineTime, 2013 snmpEngineMaxMessageSize 2014 } 2015 STATUS current 2016 DESCRIPTION "A collection of objects for identifying and 2017 determining the configuration and current timeliness 2018 values of an SNMP engine. 2019 " 2020 ::= { snmpFrameworkMIBGroups 1 } 2022 END 2024 6. Intellectual Property 2026 The IETF takes no position regarding the validity or scope of any 2027 intellectual property or other rights that might be claimed to 2028 pertain to the implementation or use of the technology described in 2029 this document or the extent to which any license under such rights 2030 might or might not be available; neither does it represent that it 2031 has made any effort to identify any such rights. Information on the 2032 IETF's procedures with respect to rights in standards-track and 2033 standards-related documentation can be found in BCP-11. Copies of 2034 claims of rights made available for publication and any assurances of 2035 licenses to be made available, or the result of an attempt made to 2036 obtain a general license or permission for the use of such 2037 proprietary rights by implementors or users of this specification can 2038 be obtained from the IETF Secretariat. 2040 The IETF invites any interested party to bring to its attention any 2041 copyrights, patents or patent applications, or other proprietary 2042 rights which may cover technology that may be required to practice 2043 this standard. Please address the information to the IETF Executive 2044 Director. 2046 7. Acknowledgements 2048 This document is the result of the efforts of the SNMPv3 Working 2049 Group. Some special thanks are in order to the following SNMPv3 WG 2050 members: 2052 Dave Battle (SNMP Research, Inc.) 2053 Uri Blumenthal (IBM T.J. Watson Research Center) 2054 Jeff Case (SNMP Research, Inc.) 2055 John Curran (BBN) 2056 T. Max Devlin (Hi-TECH Connections) 2057 John Flick (Hewlett Packard) 2058 David Harrington (Cabletron Systems Inc.) 2059 N.C. Hien (IBM T.J. Watson Research Center) 2060 Dave Levi (SNMP Research, Inc.) 2061 Louis A Mamakos (UUNET Technologies Inc.) 2062 Paul Meyer (Secure Computing Corporation) 2063 Keith McCloghrie (Cisco Systems) 2064 Russ Mundy (Trusted Information Systems, Inc.) 2065 Bob Natale (ACE*COMM Corporation) 2066 Mike O'Dell (UUNET Technologies Inc.) 2067 Dave Perkins (DeskTalk) 2068 Peter Polkinghorne (Brunel University) 2069 Randy Presuhn (BMC Software, Inc.) 2070 David Reid (SNMP Research, Inc.) 2071 Shawn Routhier (Epilogue) 2072 Juergen Schoenwaelder (TU Braunschweig) 2073 Bob Stewart (Cisco Systems) 2074 Bert Wijnen (IBM T.J. Watson Research Center) 2076 The document is based on recommendations of the IETF Security and 2077 Administrative Framework Evolution for SNMP Advisory Team. Members 2078 of that Advisory Team were: 2080 David Harrington (Cabletron Systems Inc.) 2081 Jeff Johnson (Cisco Systems) 2082 David Levi (SNMP Research Inc.) 2083 John Linn (Openvision) 2084 Russ Mundy (Trusted Information Systems) chair 2085 Shawn Routhier (Epilogue) 2086 Glenn Waters (Nortel) 2087 Bert Wijnen (IBM T. J. Watson Research Center) 2089 As recommended by the Advisory Team and the SNMPv3 Working Group 2090 Charter, the design incorporates as much as practical from previous 2091 RFCs and drafts. As a result, special thanks are due to the authors 2092 of previous designs known as SNMPv2u and SNMPv2*: 2094 Jeff Case (SNMP Research, Inc.) 2095 David Harrington (Cabletron Systems Inc.) 2096 David Levi (SNMP Research, Inc.) 2097 Keith McCloghrie (Cisco Systems) 2098 Brian O'Keefe (Hewlett Packard) 2099 Marshall T. Rose (Dover Beach Consulting) 2100 Jon Saperia (BGS Systems Inc.) 2101 Steve Waldbusser (International Network Services) 2102 Glenn W. Waters (Bell-Northern Research Ltd.) 2104 8. Security Considerations 2106 This document describes how an implementation can include a Security 2107 Model to protect management messages and an Access Control Model to 2108 control access to management information. 2110 The level of security provided is determined by the specific Security 2111 Model implementation(s) and the specific Access Control Model 2112 implementation(s) used. 2114 Applications have access to data which is not secured. Applications 2115 should take reasonable steps to protect the data from disclosure. 2117 It is the responsibility of the purchaser of an implementation to 2118 ensure that: 2120 1) an implementation complies with the rules defined by this 2121 architecture, 2123 2) the Security and Access Control Models utilized satisfy the 2124 security and access control needs of the organization, 2126 3) the implementations of the Models and Applications comply with 2127 the model and application specifications, 2129 4) and the implementation protects configuration secrets from 2130 inadvertent disclosure. 2132 9. References 2134 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 2135 of Management Information for TCP/IP-based internets", STD 16, RFC 2136 1155, May 1990. 2138 [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The 2139 Simple Network Management Protocol", STD 15, RFC 1157, University 2140 of Tennessee at Knoxville, Performance Systems s International, 2141 Performance International, and the MIT Laboratory for Computer 2142 Science, May 1990. 2144 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 2145 16, RFC 1212, March 1991. 2147 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2148 M., and S. Waldbusser, "Introduction to Community-based SNMPv2", 2149 RFC 1901, January 1996. 2151 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2152 M. and S. Waldbusser, "Structure of Management Information for 2153 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2154 RFC 1902, January 1996. 2156 [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2157 M., and S. Waldbusser, "Textual Conventions for Version 2 of the 2158 Simple Network Management Protocol (SNMPv2)", RFC 1903, January 2159 1996. 2161 [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2162 M., and S. Waldbusser, "Conformance Statements for Version 2 of 2163 the Simple Network Management Protocol (SNMPv2)", RFC 1904, 2164 January 1996. 2166 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2167 M. and S. Waldbusser, "Protocol Operations for Version 2 of the 2168 Simple Network Management Protocol (SNMPv2)", RFC 1905, January 2169 1996. 2171 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2172 M. and S. Waldbusser, "Transport Mappings for Version 2 of the 2173 Simple Network Management Protocol (SNMPv2)", RFC 1906, January 2174 1996. 2176 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2177 M. and S. Waldbusser, "Management Information Base for Version 2 2178 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 2179 January 1996. 2181 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 2182 M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 2183 of the SNMP-standard Network Management Framework", RFC 1908, 2184 January 1996. 2186 [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure 2187 for SNMPv2", RFC 1909, February 1996. 2189 [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", 2190 RFC 1910, February 1996. 2192 [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode and 2193 ISO 10646", RFC 2044, October 1996. 2195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2196 Requirement Levels", BCP 14, RFC 2119, March 1997. 2198 [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in the 2199 IETF Standards Process", BCP 11, RFC 2028, October 1996. 2201 [SNMP-MPD] The SNMPv3 Working Group, Case, J., Harrington, D., 2202 Presuhn, R., and B. Wijnen, "Message Processing and Dispatching 2203 for the Simple Network Management Protocol (SNMP)", 2204 draft-ietf-snmpv3-mpc-07.txt, November 1997. 2206 [SNMP-USM] The SNMPv3 Working Group, Blumenthal, U., and B. Wijnen, 2207 "The User-Based Security Model for Version 3 of the Simple Network 2208 Management Protocol (SNMPv3)", draft-ietf-snmpv3-usm-v2-01.txt, 2209 August 1998. 2211 [SNMP-ACM] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., and K. 2212 McCloghrie, "View-based Access Control Model for the Simple 2213 Network Management Protocol (SNMP)", 2214 draft-ietf-snmpv3-vacm-00.txt, August 1998. 2216 [SNMP-APPL] The SNMPv3 Working Group, Levi, D. B., Meyer, P., and B. 2217 Stewart, "SNMPv3 Applications", , 2218 November 1997. 2220 10. Editor's Addresses 2222 Bert Wijnen 2223 IBM T.J. Watson Research 2224 Schagen 33 2225 3461 GL Linschoten 2226 Netherlands 2228 Phone: +31 348-432-794 2229 EMail: wijnen@vnet.ibm.com 2231 Dave Harrington 2232 Cabletron Systems, Inc 2233 Post Office Box 5005 2234 Mail Stop: Durham 2235 35 Industrial Way 2236 Rochester, NH 03867-5005 2237 USA 2239 Phone: +1 603-337-7357 2240 EMail: dbh@ctron.com 2242 Randy Presuhn 2243 BMC Software, Inc. 2244 1190 Saratoga Avenue 2245 Suite 130 2246 San Jose, CA 95129 2247 USA 2249 Phone: +1 408-616-3100 2250 Fax: +1 408-616-3101 2251 EMail: rpresuhn@bmc.com 2253 APPENDIX A 2255 A. Guidelines for Model Designers 2257 This appendix describes guidelines for designers of models which are 2258 expected to fit into the architecture defined in this document. 2260 SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to 2261 provide trivial authentication and access control. SNMPv1 and SNMPv2c 2262 Frameworks can coexist with Frameworks designed according to this 2263 architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks 2264 could be designed to meet the requirements of this architecture, but 2265 this document does not provide guidelines for that coexistence. 2267 Within any subsystem model, there should be no reference to any 2268 specific model of another subsystem, or to data defined by a specific 2269 model of another subsystem. 2271 Transfer of data between the subsystems is deliberately described as 2272 a fixed set of abstract data elements and primitive functions which 2273 can be overloaded to satisfy the needs of multiple model definitions. 2275 Documents which define models to be used within this architecture 2276 SHOULD use the standard primitives between subsystems, possibly 2277 defining specific mechanisms for converting the abstract data 2278 elements into model-usable formats. This constraint exists to allow 2279 subsystem and model documents to be written recognizing common 2280 borders of the subsystem and model. Vendors are not constrained to 2281 recognize these borders in their implementations. 2283 The architecture defines certain standard services to be provided 2284 between subsystems, and the architecture defines abstract service 2285 interfaces to request these services. 2287 Each model definition for a subsystem SHOULD support the standard 2288 service interfaces, but whether, or how, or how well, it performs the 2289 service is dependent on the model definition. 2291 A.1. Security Model Design Requirements 2293 A.1.1. Threats 2295 A document describing a Security Model MUST describe how the model 2296 protects against the threats described under "Security Requirements 2297 of this Architecture", section 1.4. 2299 A.1.2. Security Processing 2301 Received messages MUST be validated by a Model of the Security 2302 Subsystem. Validation includes authentication and privacy processing 2303 if needed, but it is explicitly allowed to send messages which do not 2304 require authentication or privacy. 2306 A received message contains a specified securityLevel to be used 2307 during processing. All messages requiring privacy MUST also require 2308 authentication. 2310 A Security Model specifies rules by which authentication and privacy 2311 are to be done. A model may define mechanisms to provide additional 2312 security features, but the model definition is constrained to using 2313 (possibly a subset of) the abstract data elements defined in this 2314 document for transferring data between subsystems. 2316 Each Security Model may allow multiple security protocols to be used 2317 concurrently within an implementation of the model. Each Security 2318 Model defines how to determine which protocol to use, given the 2319 securityLevel and the security parameters relevant to the message. 2320 Each Security Model, with its associated protocol(s) defines how the 2321 sending/receiving entities are identified, and how secrets are 2322 configured. 2324 Authentication and Privacy protocols supported by Security Models are 2325 uniquely identified using Object Identifiers. IETF standard protocols 2326 for authentication or privacy should have an identifier defined 2327 within the snmpAuthProtocols or the snmpPrivProtocols subtrees. 2328 Enterprise specific protocol identifiers should be defined within the 2329 enterprise subtree. 2331 For privacy, the Security Model defines what portion of the message 2332 is encrypted. 2334 The persistent data used for security should be SNMP-manageable, but 2335 the Security Model defines whether an instantiation of the MIB is a 2336 conformance requirement. 2338 Security Models are replaceable within the Security Subsystem. 2339 Multiple Security Model implementations may exist concurrently within 2340 an SNMP engine. The number of Security Models defined by the SNMP 2341 community should remain small to promote interoperability. 2343 A.1.3. Validate the security-stamp in a received message 2345 A Message Processing Model requests that a Security Model: 2346 - verifies that the message has not been altered, 2347 - authenticates the identification of the principal for whom the 2348 message was generated. 2349 - decrypts the message if it was encrypted. 2351 Additional requirements may be defined by the model, and additional 2352 services may be provided by the model, but the model is constrained 2353 to use the following primitives for transferring data between 2354 subsystems. Implementations are not so constrained. 2356 A Message Processing Model uses the processMsg primitive as described 2357 in section 4.5. 2359 A.1.4. Security MIBs 2361 Each Security Model defines the MIB module(s) required for security 2362 processing, including any MIB module(s) required for the security 2363 protocol(s) supported. The MIB module(s) SHOULD be defined 2364 concurrently with the procedures which use the MIB module(s). The 2365 MIB module(s) are subject to normal access control rules. 2367 The mapping between the model-dependent security ID and the 2368 securityName MUST be able to be determined using SNMP, if the model- 2369 dependent MIB is instantiated and if access control policy allows 2370 access. 2372 A.1.5. Cached Security Data 2374 For each message received, the Security Model caches the state 2375 information such that a Response message can be generated using the 2376 same security information, even if the Local Configuration Datastore 2377 is altered between the time of the incoming request and the outgoing 2378 response. 2380 A Message Processing Model has the responsibility for explicitly 2381 releasing the cached data if such data is no longer needed. To enable 2382 this, an abstract securityStateReference data element is passed from 2383 the Security Model to the Message Processing Model. 2385 The cached security data may be implicitly released via the 2386 generation of a response, or explicitly released by using the 2387 stateRelease primitive, as described in section 4.1. 2389 A.2. Message Processing Model Design Requirements 2391 An SNMP engine contains a Message Processing Subsystem which may 2392 contain multiple Message Processing Models. 2394 The Message Processing Model MUST always (conceptually) pass the 2395 complete PDU, i.e., it never forwards less than the complete list of 2396 varBinds. 2398 A.2.1. Receiving an SNMP Message from the Network 2400 Upon receipt of a message from the network, the Dispatcher in the 2401 SNMP engine determines the version of the SNMP message and interacts 2402 with the corresponding Message Processing Model to determine the 2403 abstract data elements. 2405 A Message Processing Model specifies the SNMP Message format it 2406 supports and describes how to determine the values of the abstract 2407 data elements (like msgID, msgMaxSize, msgFlags, 2408 msgSecurityParameters, securityModel, securityLevel etc). A Message 2409 Processing Model interacts with a Security Model to provide security 2410 processing for the message using the processMsg primitive, as 2411 described in section 4.5. 2413 A.2.2. Sending an SNMP Message to the Network 2415 The Dispatcher in the SNMP engine interacts with a Message Processing 2416 Model to prepare an outgoing message. For that it uses the following 2417 primitives: 2419 - for requests and notifications: prepareOutgoingMessage, as 2420 described in section 4.4 2422 - for response messages: prepareResponseMessage, as described in 2423 section 4.4 2425 A Message Processing Model, when preparing an Outgoing SNMP Message, 2426 interacts with a Security Model to secure the message. For that it 2427 uses the following primitives: 2429 - for requests and notifications: generateRequestMsg, as 2430 described in section 4.5. 2432 - for response messages: generateResponseMsg as described in 2433 section 4.5. 2435 Once the SNMP message is prepared by a Message Processing Model, 2436 the Dispatcher sends the message to the desired address using the 2437 appropriate transport. 2439 A.3. Application Design Requirements 2441 Within an application, there may be an explicit binding to a specific 2442 SNMP message version, i.e., a specific Message Processing Model, and 2443 to a specific Access Control Model, but there should be no reference 2444 to any data defined by a specific Message Processing Model or Access 2445 Control Model. 2447 Within an application, there should be no reference to any specific 2448 Security Model, or any data defined by a specific Security Model. 2450 An application determines whether explicit or implicit access control 2451 should be applied to the operation, and, if access control is needed, 2452 which Access Control Model should be used. 2454 An application has the responsibility to define any MIB module(s) 2455 used to provide application-specific services. 2457 Applications interact with the SNMP engine to initiate messages, 2458 receive responses, receive asynchronous messages, and send responses. 2460 A.3.1. Applications that Initiate Messages 2462 Applications may request that the SNMP engine send messages 2463 containing SNMP commands or notifications using the sendPdu primitive 2464 as described in section 4.2. 2466 If it is desired that a message be sent to multiple targets, it is 2467 the responsibility of the application to provide the iteration. 2469 The SNMP engine assumes necessary access control has been applied to 2470 the PDU, and provides no access control services. 2472 The SNMP engine looks at the "expectResponse" parameter, and if a 2473 response is expected, then the appropriate information is cached such 2474 that a later response can be associated to this message, and can then 2475 be returned to the application. A sendPduHandle is returned to the 2476 application so it can later correspond the response with this message 2477 as well. 2479 A.3.2. Applications that Receive Responses 2481 The SNMP engine matches the incoming response messages to outstanding 2482 messages sent by this SNMP engine, and forwards the response to the 2483 associated application using the processResponsePdu primitive, as 2484 described in section 4.2. 2486 A.3.3. Applications that Receive Asynchronous Messages 2488 When an SNMP engine receives a message that is not the response to a 2489 request from this SNMP engine, it must determine to which application 2490 the message should be given. 2492 An Application that wishes to receive asynchronous messages registers 2493 itself with the engine using the primitive registerContextEngineID as 2494 described in section 4.2. 2496 An Application that wishes to stop receiving asynchronous messages 2497 should unregister itself with the SNMP engine using the primitive 2498 unregisterContextEngineID as described in section 4.2. 2500 Only one registration per combination of PDU type and contextEngineID 2501 is permitted at the same time. Duplicate registrations are ignored. 2502 An errorIndication will be returned to the application that attempts 2503 to duplicate a registration. 2505 All asynchronously received messages containing a registered 2506 combination of PDU type and contextEngineID are sent to the 2507 application which registered to support that combination. 2509 The engine forwards the PDU to the registered application, using the 2510 processPdu primitive, as described in section 4.2. 2512 A.3.4. Applications that Send Responses 2514 Request operations require responses. An application sends a 2515 response via the returnResponsePdu primitive, as described in section 2516 4.2. 2518 The contextEngineID, contextName, securityModel, securityName, 2519 securityLevel, and stateReference parameters are from the initial 2520 processPdu primitive. The PDU and statusInformation are the results 2521 of processing. 2523 A.4. Access Control Model Design Requirements 2525 An Access Control Model determines whether the specified securityName 2526 is allowed to perform the requested operation on a specified managed 2527 object. The Access Control Model specifies the rules by which access 2528 control is determined. 2530 The persistent data used for access control should be manageable 2531 using SNMP, but the Access Control Model defines whether an 2532 instantiation of the MIB is a conformance requirement. 2534 The Access Control Model must provide the primitive isAccessAllowed. 2536 B. Issues 2538 The issues list will be deleted when it is time to publish as an RFC. 2540 B.1. Open Issues 2542 - we need a mechanism for a manager to be able to discover what 2543 securityModels are supported by a particular implementation 2545 - Is an IANA considerations section needed? 2547 - Are additional clarifications of the SnmpEngineID textual 2548 convention needed? The working group discussion on this topic was 2549 extensive. 2551 B.2. Change Log 2553 These are the major ways in which this draft differs from RFC 2554 2271. 2556 - Updated draft identifier to keep distinct from the series of 2557 drafts leading to RFC 2271, based on Cynthia Clark's messages 2558 regarding VACM and USM. 2560 - Updated draft location information per Cynthia Clark's 2561 instructions. 2563 - Added note clarifying that the SnmpEnginID textual convention 2564 is used for naming, rather than addressing, even though there 2565 are situations where its value may have been generated from an 2566 address. 2568 - Clarified snmpEngineBoots and snmpEngineTime to be consistent 2569 with other documents and working group agreement. 2571 - Incremental update of References section. 2573 - Updated editors' contact information. 2575 C. Full Copyright Statement 2577 Copyright (C) The Internet Society (1998). All Rights Reserved. 2579 This document and translations of it may be copied and furnished to 2580 others, and derivative works that comment on or otherwise explain it 2581 or assist in its implementation may be prepared, copied, published 2582 and distributed, in whole or in part, without restriction of any 2583 kind, provided that the above copyright notice and this paragraph are 2584 included on all such copies and derivative works. However, this 2585 document itself may not be modified in any way, such as by removing 2586 the copyright notice or references to the Internet Society or other 2587 Internet organizations, except as needed for the purpose of 2588 developing Internet standards in which case the procedures for 2589 copyrights defined in the Internet Standards process must be 2590 followed, or as required to translate it into languages other than 2591 English. 2593 The limited permissions granted above are perpetual and will not be 2594 revoked by the Internet Society or its successors or assigns. 2596 This document and the information contained herein is provided on an 2597 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2598 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2599 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2600 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2601 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.