idnits 2.17.1 draft-ietf-snmpv3-intro-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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. ** There are 29 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 702: '... protocol engine MUST support at least...' RFC 2119 keyword, line 703: '... An SNMPv3 protocol engine MAY support...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 952 has weird spacing: '...Hashing for M...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4-9' on line 279 -- Looks like a reference, but probably isn't: 'RFC 1901' on line 351 -- Looks like a reference, but probably isn't: 'STD 0001' on line 472 -- Looks like a reference, but probably isn't: 'RFC 2000' on line 472 == Unused Reference: '23' is defined on line 951, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '3') ** Obsolete normative reference: RFC 1902 (ref. '4') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '5') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '6') (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (ref. '7') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (ref. '8') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (ref. '9') (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (ref. '10') (Obsoleted by RFC 2576) -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1066 (ref. '12') (Obsoleted by RFC 1156) ** Downref: Normative reference to an Unknown state RFC: RFC 1052 (ref. '14') ** Obsolete normative reference: RFC 2271 (ref. '15') (Obsoleted by RFC 2571) ** Obsolete normative reference: RFC 2272 (ref. '16') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2273 (ref. '17') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2274 (ref. '18') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 2275 (ref. '19') (Obsoleted by RFC 2575) -- Possible downref: Non-RFC (?) normative reference: ref. '20' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '21') -- Possible downref: Non-RFC (?) normative reference: ref. '22' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '23') -- Possible downref: Non-RFC (?) normative reference: ref. '24' ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '25') Summary: 28 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Jeffrey D. Case 3 SNMP Research, Inc. 4 Russ Mundy 5 Trusted Information Systems, Inc. 6 David Partain 7 SNMP Research Europe 8 Bob Stewart 9 Cisco Systems 11 Introduction to Version 3 of the 12 Internet-standard Network Management Framework 14 1998/08/07 13:38:54 16 draft-ietf-snmpv3-intro-01.txt 17 1.3 -- 1998/08/07 13:38:54 19 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 To view the entire list of current Internet-Drafts, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 34 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 35 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 37 Abstract 39 The purpose of this document is to provide an overview of the third 40 version of the Internet-standard Management Framework, termed the 41 SNMP version 3 Framework (SNMPv3). This Framework is derived from 42 and builds upon both the original Internet-standard Management 43 Framework (SNMPv1) and the second Internet-standard Management 44 Framework (SNMPv2). 46 The architecture is designed to be modular to allow the evolution of 47 the Framework over time. 49 1. Introduction 51 This document is an introduction to the third version of the 52 Internet-standard Management Framework, termed the SNMP version 3 53 Management Framework (SNMPv3) and has multiple purposes. 55 First, it describes the relationship between the SNMP version 3 56 (SNMPv3) specifications and the specifications of the SNMP version 1 57 (SNMPv1) Management Framework, the SNMP version 2 (SNMPv2) Management 58 Framework, and the Community-based Administrative Framework for 59 SNMPv2. 61 Second, it provides a roadmap to the multiple documents which contain 62 the relevant specifications. 64 Third, this document provides a brief easy-to-read summary of the 65 contents of each of the relevant specification documents. 67 [Finally, this document may someday contain information regarding 68 what it means to be a compliant SNMPv3 implementation, i.e., a set of 69 applicability statements, but it does not now, and if it never does, 70 then this sentence will be deleted.] 72 This document is intentionally tutorial in nature and, as such, may 73 occasionally be "guilty" of oversimplification. In the event of a 74 conflict or contradiction between this document and the more detailed 75 documents for which this document is a roadmap, the specifications in 76 the more detailed documents shall prevail. 78 Further, the detailed documents attempt to maintain separation 79 between the various component modules in order to specify well- 80 defined interfaces between them. This roadmap document, however, 81 takes a different approach and attempts to provide an integrated view 82 of the various component modules in the interest of readability. 84 2. The Internet Standard Management Framework 86 The third version of the Internet Standard Management Framework (the 87 SNMPv3 Framework) is derived from and builds upon both the original 88 Internet-standard Management Framework (SNMPv1) and the second 89 Internet-standard Management Framework (SNMPv2). 91 All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard 92 Management Framework share the same basic structure and components. 93 Furthermore, all versions of the specifications of the Internet 94 Standard Management Framework follow the same architecture. 96 2.1 Basic Structure and Components 98 An enterprise deploying the Internet Standard Management Framework 99 contains four basic components: 101 * several (typically many) managed nodes, each with an SNMP entity 102 which provides remote access to management instrumentation 103 (traditionally called an agent); 105 * at least one SNMP entity with management applications (typically 106 called a manager), 108 * a management protocol used to convey management information 109 between the SNMP entities, and 111 * management information. 113 The management protocol is used to convey management information 114 between SNMP entities such as managers and agents. 116 This basic structure is common to all versions of the Internet 117 Standard Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3. 119 2.2 Architecture of the Internet Standard Management Framework 121 The specifications of the Internet Standard Management Framework are 122 based on a modular architecture. This framework is more than just a 123 protocol for moving data. It consists of: 125 * a data definition language, 127 * definitions of management information (the Management 128 Information Base, or MIB), 130 * a protocol definition, and 131 * security and administration. 133 Over time, as the Framework has evolved from SNMPv1, through SNMPv2, 134 to SNMPv3, the definitions of each of these architectural components 135 have become richer and more clearly defined, but the fundamental 136 architecture has remained consistent. 138 One prime motivator for this modularity was to enable the ongoing 139 evolution of the Framework as is documented in RFC 1052 [14]. When 140 originally envisioned, this capability was to be used to ease the 141 transition from SNMP-based management of internets to management 142 based on OSI protocols. To this end, the framework was architected 143 with a protocol-independent data definition language and Management 144 Information Base along with a MIB-independent protocol. This 145 separation was designed to allow the SNMP-based protocol to be 146 replaced without requiring the management information to be redefined 147 or reinstrumented. History has shown that the selection of this 148 architecture was the right decision for the wrong reason -- it turned 149 out that this architecture has eased the transition from SNMPv1 to 150 SNMPv2 and from SNMPv2 to SNMPv3 rather than easing the transition 151 away from management based on the Simple Network Management Protocol. 153 The SNMPv3 Framework builds and extends these architectural 154 principles by: 156 * building on these four basic architectural components, in some 157 cases incorporating them from the SNMPv2 Framework by reference, 158 and 160 * by using these same layering principles in the definition of new 161 capabilities in the security and administration portion of the 162 architecture. 164 Those who are familiar with the architecture of the SNMPv1 Management 165 Framework and the SNMPv2 Management Framework will find many familiar 166 concepts in the architecture of the SNMPv3 Management Framework. 167 However, in some cases, the terminology may be somewhat different. 169 3. The SNMPv1 Management Framework 171 The original Internet-standard Network Management Framework (SNMPv1) 172 is defined in the following documents: 174 * STD 16, RFC 1155 [1] which defines the Structure of Management 175 Information (SMI), the mechanisms used for describing and naming 176 objects for the purpose of management. 178 * STD 16, RFC 1212 [2] which defines a more concise description 179 mechanism for describing and naming management information objects, 180 but which is wholly consistent with the SMI. 182 * STD 15, RFC 1157 [3] which defines the Simple Network Management 183 Protocol (SNMP), the protocol used for network access to managed 184 objects and event notification. Note this document also defines an 185 initial set of event notifications. 187 Additionally, two documents are generally considered to be companions 188 to these three: 190 * STD 17, RFC 1213 [13] which contains definitions for the base 191 set of management information 193 * RFC 1215 [25] defines a concise description mechanism for 194 defining event notifications, which are called traps in the SNMPv1 195 protocol. It also specifies the generic traps from RFC 1157 in the 196 concise notation. 198 These documents describe the four parts of the first version of the 199 SNMP Framework. 201 3.1 The SNMPv1 Data Definition Language. 203 The first two and the last document describe the SNMPv1 data 204 definition language. Note that due to the initial requirement that 205 the SMI be protocol-independent, the first two SMI documents do not 206 provide a means for defining event notifications (traps). Instead, 207 the SNMP protocol document defines a few standardized event 208 notifications (generic traps) and provides a means for additional 209 event notifications to be defined. The last document specifies a 210 straight-forward approach towards defining event notifications used 211 with the SNMPv1 protocol. At the time that it was written, use of 212 traps in the Internet-standard network management framework was 213 controversial. As such, RFC 1215 was put forward with the status of 214 "Informational", which was never updated because it was believed that 215 the second version of the SNMP Framework would replace the first 216 version. Note that the SNMPv1 data definition language is sometimes 217 refered to as SMIv1. 219 3.2 Management Information. 221 The data definition language described in the first two documents was 222 first used to define the now-historic MIB-I as specified in RFC 1066 223 [12], and was subsequently used to define MIB-II as specified in RFC 224 1213 [13]. 226 Later, after the publication of MIB-II, a different approach to 227 management information definition was taken from the earlier approach 228 of having a single committee staffed by generalists work on a single 229 document to define the Internet-standard MIB. Rather, many mini-MIB 230 documents were produced in a parallel and distributed fashion by 231 groups chartered to produce a specification for a focused portion of 232 the Internet-standard MIB and staffed by personnel with expertise in 233 those particular areas ranging from various aspects of network 234 management, to system management, and application management. 236 3.3 Protocol Operations. 238 The third document, STD 15, describes the SNMPv1 protocol operations 239 performed by protocol data units (PDUs) on lists of variable bindings 240 and describes the format of SNMPv1 messages. The operators defined by 241 SNMPv1 are: get, get-next, get-response, set-request, and trap. 242 Typical layering of SNMP on a connectionless transport service is 243 also defined. 245 3.4 SNMPv1 Security and Administration. 247 STD 15 also describes an approach to security and administration. 248 Many of these concepts are carried forward into the SNMPv3 Framework. 250 The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in 251 SNMP messages between SNMP entities and distinguishes between 252 application entities and protocol entities. In SNMPv3, these are 253 renamed applications and engines, respectively. 255 The SNMPv1 Framework also introduces the concept of an authentication 256 service supporting one or more authentication schemes. In SNMPv3, 257 the concept of an authentication service is expanded to include other 258 services, such as privacy. 260 Finally, the SNMPv1 Framework introduces access control based on a 261 concept called an SNMP MIB view. The SNMPv3 Framework specifies a 262 fundamentally similar concept called view-based access control. 264 However, while the SNMPv1 Framework anticipated the definition of 265 multiple authentication schemes, it did not define any such schemes 266 other than a trivial authentication scheme based on community 267 strings. This was a known fundamental weakness in the SNMPv1 268 Framework but it was thought at that time that the definition of 269 commercial grade security might be contentious in its design and 270 difficult to get approved because "security" means many different 271 things to different people. To that end, and because some users do 272 not require strong authentication, the SNMPv1 architected an 273 authentication service as a separate block to be defined "later" and 274 the SNMPv3 Framework provides an architecture for use within that 275 block as well as a definition for its subsystems. 277 4. The SNMPv2 Management Framework 279 The SNMPv2 Management Framework is fully described in [4-9] and 280 coexistence and transition issues relating to SNMPv1 and SNMPv2 are 281 discussed in [10]. 283 SNMPv2 provides several advantages over SNMPv1, including: 285 * expanded data types (e.g., 64 bit counter) 287 * improved efficiency and performance (get-bulk operator) 289 * confirmed event notification (inform operator) 291 * richer error handling (errors and exceptions) 293 * improved sets, especially row creation and deletion 295 * fine tuning of the data definition language 297 However, the SNMPv2 Framework, as described in these documents, is 298 incomplete in that it does not meet the original design goals of the 299 SNMPv2 project. The unmet goals included provision of security and 300 administration delivering so-called "commercial grade" security with 302 * authentication: origin identification, message integrity, 303 and some aspects of replay protection; 305 * privacy: confidentiality; 307 * authorization and access control; and 309 * suitable remote configuration and administration capabilities 310 for these features. 312 The SNMPv3 Management Framework, as described in this document and 313 the companion documents, addresses these significant deficiencies. 315 5. The SNMPv3 Working Group 317 This document, and its companion documents, were produced by the 318 SNMPv3 Working Group of the Internet Engineering Task Force (IETF). 319 The SNMPv3 Working Group was chartered to prepare recommendations for 320 the next generation of SNMP. The goal of the Working Group was to 321 produce the necessary set of documents that provide a single standard 322 for the next generation of core SNMP functions. The single, most 323 critical need in the next generation is a definition of security and 324 administration that makes SNMP-based management transactions secure 325 in a way which is useful for users who wish to use SNMPv3 to manage 326 networks, the systems that make up those networks, and the 327 applications which reside on those systems, including manager-to- 328 agent, agent-to-manager, and manager-to-manager transactions. 330 In the several years prior to the chartering of the Working Group, 331 there were a number of activities aimed at incorporating security and 332 other improvements to SNMP. These efforts included: 334 * "SNMP Security" circa 1991-1992 [RFC 1351 - RFC 1353], 336 * "SMP" circa 1992-1993, 338 * "The Party-based SNMPv2" circa 1993-1995 [RFC 1441 - RFC 1452]. 340 Each of these efforts incorporated commercial grade, industrial 341 strength security including authentication, privacy, authorization, 342 view-based access control, and administration, including remote 343 configuration. 345 These efforts fed the development of the SNMPv2 Management Framework 346 as described in RFCs 1902 - 1908. However, the Framework described 347 in those RFCs had no standards-based security and administrative 348 framework of its own; rather, it was associated with multiple 349 security and administrative frameworks, including: 351 * "The Community-based SNMPv2" (SNMPv2c) [RFC 1901], 353 * "SNMPv2u" [RFCs 1909 - 1910] and 355 * "SNMPv2*." 357 SNMPv2c had the endorsement of the IETF but no security and 358 administration whereas both SNMPv2u and SNMPv2* had security but 359 lacked the endorsement of the IETF. 361 The SNMPv3 Working Group was chartered to produce a single set of 362 specifications for the next generation of SNMP, based upon a 363 convergence of the concepts and technical elements of SNMPv2u and 364 SNMPv2*, as was suggested by an advisory team which was formed to 365 provide a single recommended approach for SNMP evolution. 367 In so doing, the Working Group charter defined the following 368 objectives: 370 * accommodate the wide range of operational environments with 371 differing management demands; 373 * facilitate the need to transition from previous, multiple 374 protocols to SNMPv3; 376 * facilitate the ease of setup and maintenance activities. 378 In the initial work of the SNMPv3 Working Group, the group focused on 379 security and administration, including 381 * authentication and privacy, 383 * authorization and view-based access control, and 385 * standards-based remote configuration of the above. 387 The SNMPv3 Working Group did not "reinvent the wheel," but reused the 388 SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908. 390 The SNMPv3 Working Group produced a design based on a modular 391 architecture with evolutionary capabilities with emphasis on 392 layering. As a result, SNMPv3 is SNMPv2 plus security and 393 administration. 395 In doing so, the Working Group achieved the goal of producing a 396 single specification which has both the endorsement of the IETF and 397 security and administration. 399 6. SNMPv3 Framework Module Specifications 401 The specification of the SNMPv3 Management Framework is partitioned 402 in a modular fashion among several documents. It is the intention of 403 the SNMPv3 Working Group that, with proper care, any or all of the 404 individual documents can be revised, upgraded, or replaced as 405 requirements change, new understandings are obtained, and new 406 technologies become available. 408 Whenever feasible, the initial document set which defines the SNMPv3 409 Management Framework leverages prior investments defining and 410 implementing the SNMPv2 Management Framework by incorporating by 411 reference each of the specifications of the SNMPv2 Management 412 Framework. 414 The SNMPv3 Framework augments those specifications with 415 specifications for security and administration for SNMPv3. 417 The documents which specify the SNMPv3 Management Framework follow 418 the same architecture as those of the prior versions and can be 419 organized for expository purposes into four main categories as 420 follows: 422 * the data definition language, 424 * Management Information Base (MIB) modules, 426 * protocol operations, and 428 * security and administration. 430 The first three sets of documents are incorporated from SNMPv2. The 431 fourth set of documents are new to SNMPv3, but, as described 432 previously, build on significant prior related works. 434 6.1 Data Definition Language 436 The specifications of the data definition language includes RFC 1902, 437 "The Structure of Management Information for Version 2 of the Simple 438 Network Management Protocol (SNMPv2)" [4], and related 439 specifications. The Structure of Management Information (SMI) 440 defines fundamental data types, an object model, and the rules for 441 writing and revising MIB modules. Related specifications include RFC 442 1903 and RFC 1904. The updated data definition language is sometimes 443 refered to as SMIv2. 445 RFC 1903, "Textual Conventions for Version 2 of the Simple Network 446 Management Protocol (SNMPv2)" [5], defines an initial set of 447 shorthand abbreviations which are available for use within all MIB 448 modules for the convenience of human readers and writers. 450 RFC 1904, "Conformance Statements for Version 2 of the Simple Network 451 Management Protocol (SNMPv2)" [6], defines the format for compliance 452 statements which are used for describing requirements for agent 453 implementations and capability statements which can be used to 454 document the characteristics of particular implementations. 456 6.2 MIB Modules 458 MIB modules usually contain object definitions, may contain 459 definitions of event notifications, and sometimes include compliance 460 statements specified in terms of appropriate object and event 461 notification groups. As such, MIB modules define the management 462 information maintained by the instrumentation in managed nodes, made 463 remotely accessible by management agents, conveyed by the management 464 protocol, and manipulated by management applications. 466 MIB modules are defined according the rules defined in the documents 467 which specify the data definition language, principally the SMI as 468 supplemented by the related specifications. 470 There is a large and growing number of standards-based MIB modules, 471 as defined in the periodically updated list of standard protocols 472 [STD 0001, RFC 2000]. As of this writing, there are nearly 100 473 standards-based MIB modules with a total number of defined objects 474 approaching 10,000. In addition, there is an even larger and growing 475 number of enterprise-specific MIB modules defined unilaterally by 476 various vendors, research groups, consortia, and the like resulting 477 in an unknown and virtually uncountable number of defined objects. 479 In general, management information defined in any MIB module, 480 regardless of the version of the data definition language used, can 481 be used with any version of the protocol. For example, MIB modules 482 defined in terms of the SNMPv1 SMI (SMIv1) are compatible with the 483 SNMPv3 Management Framework and can be conveyed by the protocols 484 specified therein. Furthermore, MIB modules defined in terms of the 485 SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and 486 can be conveyed by it. However, there is one noteworthy exception: 487 the Counter64 datatype which can be defined in a MIB module defined 488 in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol 489 engine. 491 6.3 Protocol Operations and Transport Mappings 493 The specifications for the protocol operations and transport mappings 494 of the SNMPv3 Framework are incorporated by reference to the two 495 SNMPv2 Framework documents. 497 The specification for protocol operations is found in RFC 1905, 498 "Protocol Operations for Version 2 of the Simple Network Management 499 Protocol (SNMPv2)" [7]. 501 The specification of transport mappings is found in RFC 1906, 502 "Transport Mappings for Version 2 of the Simple Network Management 503 Protocol (SNMPv2)" [8]. 505 6.4 SNMPv3 Security and Administration 507 The SNMPv3 document series defined by the SNMPv3 Working Group 508 consists of six [seven] documents at this time: 510 RFC xxxx, "Introduction to the Third Version of the Internet 511 Standard Management Framework (SNMPv3)," which is this document. 513 RFC 2271, "An Architecture for Describing SNMP Management 514 Frameworks" [15], describes the overall architecture with special 515 emphasis on the architecture for security and administration. 517 RFC 2272, "Message Processing and Dispatching for the Simple 518 Network Management Protocol (SNMP)" [16], describes the possibly 519 multiple message processing models and the dispatcher portion that 520 can be a part of an SNMP protocol engine. 522 RFC 2273, "SNMPv3 Applications" [17], describes the five types of 523 applications that can be associated with an SNMPv3 engine and 524 their elements of procedure. 526 RFC 2274, "The User-Based Security Model for Version 3 of the 527 Simple Network Management Protocol (SNMPv3)" [18], describes the 528 threats, mechanisms, protocols, and supporting data used to 529 provide SNMP message-level security. 531 RFC 2275, "View-based Access Control Model for the Simple Network 532 Management Protocol (SNMP)" [19], describes how view-based access 533 control can be applied within command responder and notification 534 originator applications. 536 RFC yyyy, "SNMPv3 Coexistence and Transition" [20], does not exist 537 yet and is still in development. 539 7. Document Summaries 541 The following sections provide brief summaries of each document with 542 slightly more detail than is provided in the overviews, above. 544 7.1 Structure of Management Information 546 Management information is viewed as a collection of managed objects, 547 residing in a virtual information store, termed the Management 548 Information Base (MIB). Collections of related objects are defined 549 in MIB modules. These modules are written in the SNMP MIB module 550 language, which contains elements of OSI's Abstract Syntax Notation 551 One (ASN.1) [11] language. RFC 1902, RFC 1903, and RFC 1904 together 552 define the MIB module language, specify the base data types for 553 objects, specify a core set of short-hand specifications for data 554 types called textual conventions, and specify a few administrative 555 assignments of object identifier (OID) values. 557 The SMI is divided into three parts: module definitions, object 558 definitions, and, trap definitions. 560 (1) Module definitions are used when describing information modules. 561 An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the 562 semantics of an information module. 564 (2) Object definitions are used when describing managed objects. An 565 ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax 566 and semantics of a managed object. 568 (3) Notification definitions are used when describing unsolicited 569 transmissions of management information. An ASN.1 macro, 570 NOTIFICATION-TYPE, is used to convey concisely the syntax and 571 semantics of a notification. 573 7.1.1 Base SMI Specification 575 RFC 1902 specifies the base data types for the MIB module language, 576 which include: Integer32, enumerated integers, Unsigned32, Gauge32, 577 Counter32, Counter64, TimeTicks, OCTET STRING, OBJECT IDENTIFIER, 578 IpAddress, Opaque, and BITS. It also assigns values to several object 579 identifiers. RFC 1902 further defines the following constructs of 580 the MIB module language: 582 * IMPORTS to allow the specification of items that are used 583 in a MIB module, but defined in another MIB module. 585 * MODULE-IDENTITY to specify for a MIB module a description 586 and administrative information such as contact and revision 587 history. 589 * OBJECT-IDENTITY and OID value assignments to specify a 590 an OID value. 592 * OBJECT-TYPE to specify the data type, status, and the semantics 593 of managed objects. 595 * SEQUENCE type assignement to list the columnar objects in 596 a table. 598 * NOTIFICATION-TYPE construct to describe an event notification. 600 7.1.2 Textual Conventions 602 When designing a MIB module, it is often useful to specify in a 603 short-hand way the semantics for a set of objects with similar 604 behavior. This is done by defining a new data type using a base data 605 type specified in the SMI. Each new type has a different name, and 606 specifies a base type with more restrictive semantics. These newly 607 defined types are termed textual conventions, and are used for the 608 convenience of humans reading a MIB module and potentially by 609 "intelligent" management applications. It is the purpose of RFC 610 1903, Textual Conventions for SNMPv2 [5], to define the construct, 611 TEXTUAL-CONVENTION, of the MIB module language used to define such 612 new types and to specify an initial set of textual conventions 613 available to all MIB modules. 615 7.1.3 Conformance Statements 617 It may be useful to define the acceptable lower-bounds of 618 implementation, along with the actual level of implementation 619 achieved. It is the purpose of RFC 1904, Conformance Statements for 620 SNMPv2 [6], to define the constructs of the MIB module language used 621 for these purposes. There are two kinds of constructs: 623 (1) Compliance statements are used when describing requirements for 624 agents with respect to object and event notification definitions. 625 The MODULE-COMPLIANCE construct is used to convey concisely 626 such requirements. 628 (2) Capability statements are used when describing capabilities of 629 agents with respect to object and event notification definitions. 630 The AGENT-CAPABILITIES construct is used to convey concisely such 631 capabilities. 633 Finally, collections of related objects and collections of related 634 event notifications are grouped together to form a unit of 635 conformance. The OBJECT-GROUP construct is used to convey concisely 636 the objects in and the semantics of an object group. The 637 NOTIFICATION-GROUP construct is used to convey concisely the event 638 notifications in and the semantics of an event notification group. 640 7.2 Protocol Operations 642 The management protocol provides for the exchange of messages which 643 convey management information between the agents and the management 644 stations. The form of these messages is a message "wrapper" which 645 encapsulates a Protocol Data Unit (PDU). 647 It is the purpose of RFC 1905, Protocol Operations for SNMPv2 [7], to 648 define the operations of the protocol with respect to the sending and 649 receiving of the PDUs. 651 7.3 Transport Mappings 653 SNMP Messages may be used over a variety of protocol suites. It is 654 the purpose of RFC 1906, Transport Mappings for SNMPv2 [8], to define 655 how SNMP messages maps onto an initial set of transport domains. 656 Other mappings may be defined in the future. 658 Although several mappings are defined, the mapping onto UDP is the 659 preferred mapping. As such, to provide for the greatest level of 660 interoperability, systems which choose to deploy other mappings 661 should also provide for proxy service to the UDP mapping. 663 7.4 Protocol Instrumentation 665 It is the purpose of RFC 1907, the Management Information Base for 666 SNMPv2 document [9] to define managed objects which describe the 667 behavior of an SNMPv2 entity. 669 7.5 Architecture / Security and Administration 671 It is the purpose of RFC 2271, "SNMPv3 Architecture" [15], to define 672 an architecture for defining SNMP Management Frameworks. While 673 addressing general architectural issues, it focuses on aspects 674 related to security and administration. It defines a number of terms 675 used throughout the SNMPv3 Management Framework and, in so doing, 676 clarifies and extends the naming of 678 * engines and applications, 680 * entities (service providers such as the engines in agents 681 and managers), 683 * identities (service users), and 685 * management information, including support for multiple 686 logical contexts. 688 The document contains a small MIB module which is implemented by all 689 authoritative SNMPv3 protocol engines. 691 7.6 Message Processing and Dispatch (MPD) 693 RFC 2272, "Message Processing and Dispatching for the Simple Network 694 Management Protocol (SNMP)" [16], describes the Message Processing 695 and Dispatching for SNMP messages within the SNMP architecture. It 696 defines the procedures for dispatching potentially multiple versions 697 of SNMP messages to the proper SNMP Message Processing Models, and 698 for dispatching PDUs to SNMP applications. This document also 699 describes one Message Processing Model - the SNMPv3 Message 700 Processing Model. 702 It is expected that an SNMPv3 protocol engine MUST support at least 703 one Message Processing Model. An SNMPv3 protocol engine MAY support 704 more than one, for example in a multilingual system which provides 705 simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c. 707 7.7 SNMPv3 Applications 709 It is the purpose of RFC 2273, "SNMPv3 Applications" to describe the 710 five types of applications which can be associated with an SNMP 711 engine. They are: Command Generators, Command Responders, 712 Notification Originators, Notification Receivers, and Proxy 713 Forwarders. 715 The document also defines MIB modules for specifying targets of 716 management operations (including notifications), for notification 717 filtering, and for proxy forwarding. 719 7.8 User-based Security Model (USM) 721 RFC 2274, the "User-based Security Model (USM) for version 3 of the 722 Simple Network Management Protocol (SNMPv3)" describes the User-based 723 Security Model for SNMPv3. It defines the Elements of Procedure for 724 providing SNMP message-level security. 726 The document describes the two primary and two secondary threats 727 which are defended against by the User-based Security Model. They 728 are: modification of information, masquerade, message stream 729 modification, and [optionally] disclosure. 731 The USM utilizes MD5 [21] and the Secure Hash Algorithm [22] as keyed 732 hashing algorithms [22] for digest computation to provide data 733 integrity 735 * to directly protect against data modification attacks, 737 * to indirectly provide data origin authentication, and 739 * to defend against masquerade attacks. 741 The USM uses loosely synchronized monotonically increasing time 742 indicators to defend against certain message stream modification 743 attacks. Automatic clock synchronization mechanisms based on the 744 protocol are specified without dependence on third-party time sources 745 and concomitant security considerations. 747 The USM uses the Data Encryption Standard (DES) [24] in the cipher 748 block chaining mode (CBC) [optionally] to protect against disclosure. 750 The document also includes a MIB suitable for remotely monitoring and 751 managing the configuration parameters for the USM, including key 752 distribution and key management. 754 A single protocol entity may provide simultaneous support for 755 multiple security models as well as multiple authentication and 756 privacy protocols. All of the protocols used by the USM are based on 757 symmetric cryptography, i.e., private key mechanisms. The SNMPv3 758 architecture admits the use of public key cryptography, but as of 759 this writing, no SNMPv3 security models utilizing public key 760 cryptography have been published. 762 7.9 View-based Access Control (VACM) 764 The purpose of RFC 2275, the "View-based Access Control Model (VACM) 765 for the Simple Network Management Protocol (SNMP)" is to describe the 766 View-based Access Control Model for use in the SNMP architecture. 767 The VACM can simultaneously be associated in a single engine 768 implementation with multiple Message Processing Models and multiple 769 Security Models. 771 It is architecturally possible to have multiple, different, Access 772 Control Models active and present simultaneously in a single engine 773 implementation, but this is expected to be *_very_* rare in practice 774 and *_far_* less common than simultaneous support for multiple 775 Message Processing Models and/or multiple Security Models. 777 7.10 SNMPv3 Coexistence and Transition 778 This document does not exist yet. It needs to contain: 779 background of 2 approaches to coexistence and transition 780 multilingual approach 781 proxy approach 783 mapping functions derived from rfc 2089 but incorporated by value 784 rather than by reference in order to get these functions onto the 785 standards track and to fix up any lingering problems 787 a community-based security model consistent with the architecture 788 and containing a suitable MIB module for remote configuration thereof 789 for use by multilingual engines supporting snmpv1 and snmpv2c in 790 addition to snmpv3 792 This could be multiple documents, but it really isn't necessary to have more 793 than one and fewer are better than many. 795 8. Security Considerations 797 As this document is primarily a roadmap document, it introduces no 798 new security considerations. The reader is referred to the relevant 799 sections of each of the referenced documents for information about 800 security considerations. 802 9. Editors' Addresses 804 Jeffrey Case 805 SNMP Research, Inc. 806 3001 Kimberlin Heights Road 807 Knoxville, TN 37920-9716 808 USA 809 Phone: +1 423 573 1434 810 EMail: case@snmp.com 812 Russ Mundy 813 Trusted Information Systems 814 3060 Washington Rd 815 Glenwood, MD 21738 816 USA 817 Phone: +1 301 854 6889 818 Email: mundy@tis.com 820 David Partain 821 SNMP Research Europe 822 Teknikringen 1 823 S-583 30 Linkoping 824 Sweden 825 Phone: +46 13 21 18 81 826 Email: partain@europe.snmp.com 828 Bob Stewart 829 Cisco Systems, Inc. 830 170 West Tasman Drive 831 San Jose, CA 95134-1706 832 U.S.A. 833 Phone: +1 603 654 6923 834 EMail: bstewart@cisco.com 836 10. Full Copyright Statement 838 Copyright (C) The Internet Society (1998). All Rights Reserved. 840 This document and translations of it may be copied and furnished to 841 others, and derivative works that comment on or otherwise explain it 842 or assist in its implmentation may be prepared, copied, published and 843 distributed, in whole or in part, without restriction of any kind, 844 provided that the above copyright notice and this paragraph are 845 included on all such copies and derivative works. However, this 846 document itself may not be modified in any way, such as by removing 847 the copyright notice or references to the Internet Society or other 848 Internet organizations, except as needed for the purpose of 849 developing Internet standards in which case the procedures for 850 copyrights defined in the Internet Standards process must be 851 followed, or as required to translate it into languages other than 852 English. 854 The limited permissions granted above are perpetual and will not be 855 revoked by the Internet Society or its successors or assigns. 857 This document and the information contained herein is provided on an 858 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 859 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 860 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 861 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 862 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 864 11. References 866 [1] Rose, M., and K. McCloghrie, "Structure and Identification of 867 Management Information for TCP/IP-based internets", STD 16, RFC 868 1155, May 1990. 870 [2] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, 871 RFC 1212, March 1991. 873 [3] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 874 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 875 Systems International, MIT Laboratory for Computer Science, May 876 1990. 878 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 879 S. Waldbusser, "Structure of Management Information for Version 2 880 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 881 January 1996. 883 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 884 S. Waldbusser, "Textual Conventions for Version 2 of the Simple 885 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 887 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 888 S. Waldbusser, "Conformance Statements for Version 2 of the Simple 889 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 891 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 892 S. Waldbusser, "Protocol Operations for Version 2 of the Simple 893 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 895 [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 896 S. Waldbusser, "Transport Mappings for Version 2 of the Simple 897 Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 899 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 900 S. Waldbusser, "Management Information Base for Version 2 of the 901 Simple Network Management Protocol (SNMPv2)", RFC 1907, 902 January 1996. 904 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 905 S. Waldbusser, "Coexistence between Version 1 and Version 2 of the 906 Internet-standard Network Management Framework", RFC 1908, 907 January 1996. 909 [11] Information processing systems - Open Systems Interconnection - 910 Specification of Abstract Syntax Notation One (ASN.1), 911 International Organization for Standardization. International 912 Standard 8824, (December, 1987). 914 [12] McCloghrie, K., and M. Rose, "Management Information Base for 915 Network Management of TCP/IP-based Internets", RFC 1066, August 1988. 917 [13] McCloghrie, K., and M. Rose, "Management Information Base for 918 Network Management of TCP/IP-based internets: MIB-II, RFC 1213, 919 March 1991. 921 [14] Cerf, V., "IAB Recommendations for the Development of Internet 922 Network Management Standards", RFC 1052, April 1988. 924 [15] Harrington, D, R. Presuhn, and B. Wijnen, "An Architecture for 925 Describing SNMP Management Frameworks, RFC 2271, January, 1998. 927 [16] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message 928 Processing and Dispatching for the Simple Network Management 929 Protocol (SNMP)", RFC 2272, January 1998. 931 [17] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, 932 January 1998. 934 [18] Blumenthal, U., and B. Wijnen, "The User-Based Security Model for 935 Version 3 of the Simple Network Management Protocol (SNMPv3)", 936 RFC 2274, January 1998. 938 [19] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control 939 Model for the Simple Network Management Protocol (SNMP)", RFC 2275, 940 January 1998. 942 [20] TBD, "SNMPv3 Coexistence and Transition", RFC yyyy, Work in progress, 943 date TBD. 945 [21] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992. 947 [22] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) 948 http://csrc.nist.gov/fips/fip180-1.txt (ASCII) 949 http://csrc.nist.gov/fips/fip180-1.ps (Postscript) 951 [23] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: 952 Keyed-Hashing for Message Authentication", RFC 2104, February 953 1997. 955 [24] Data Encryption Standard, National Institute of Standards 956 and Technology. Federal Information Processing Standard (FIPS) 957 Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; 958 reaffirmed January, 1988). 960 [25] M.T. Rose, "A Convention for Defining Traps for use with the 961 SNMP", RFC 1215, March 1991.