idnits 2.17.1 draft-ietf-snmpv3-intro-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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. ** There are 3 instances of too long lines in the document, the longest one being 4 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 733: '... protocol engine MUST support at least...' RFC 2119 keyword, line 734: '...NMPv3 protocol engine MAY support more...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 38 has weird spacing: '...vide an overv...' == Line 39 has weird spacing: '... third versi...' == Line 42 has weird spacing: '...and the secon...' == Line 45 has weird spacing: '...o allow the ...' == Line 982 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 314 -- Looks like a reference, but probably isn't: 'RFC 1901' on line 383 == Unused Reference: '23' is defined on line 981, 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: 27 errors (**), 0 flaws (~~), 8 warnings (==), 8 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/10/14 19:33:28 15 draft-ietf-snmpv3-intro-02.txt 16 1.6 -- 1998/10/14 19:33:28 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, and 22 its working groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 To view the entire list of current Internet-Drafts, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 33 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 34 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Abstract 38 The purpose of this document is to provide an overview of the 39 third version of the Internet-standard Management Framework, 40 termed the SNMP version 3 Framework (SNMPv3). This Framework is 41 derived from and builds upon both the original Internet-standard 42 Management Framework (SNMPv1) and the second Internet-standard 43 Management Framework (SNMPv2). 45 The architecture is designed to be modular to allow the evolu- 46 tion of the Framework over time. 48 0. Revision History: 50 Version 1.5: 1998/08/30 00:00:00 52 . incorporate final comments from russ (got both mailgrams incorporated) 54 Version 1.4: 1998/09/24 00:00:00 56 . added this revision history -- to be deleted when published as an 57 rfc 59 . removed statement about someday containing information regarding 60 compliance 62 . incorporated input from chicago ietf meeting: 63 - beef up the praise for the snmpv3 design team to address this 64 comment: 66 I think that the current draft gives bit too much 67 credit to the original designers of SNMP and sort of 68 discredits the effort of the SNMPv3 WG members as being 69 "nothing new". 71 - add table of contents 73 - fix spelling error in copyright notice 75 . reviewed mailing list and incorporated all comments there since 76 the last draft (none to incorporate not covered above) 78 . added change bars ... changed from last draft (version 1.3) -- also 79 known as draft-ietf-snmpv3-intro-01.txt 81 Open Issues 83 . section about the coex/transition document needs finality 85 1. Introduction 87 This document is an introduction to the third version of the Internet- 88 standard Management Framework, termed the SNMP version 3 Management 89 Framework (SNMPv3) and has multiple purposes. 91 First, it describes the relationship between the SNMP version 3 (SNMPv3) 92 specifications and the specifications of the SNMP version 1 (SNMPv1) 93 Management Framework, the SNMP version 2 (SNMPv2) Management Framework, 94 and the Community-based Administrative Framework for SNMPv2. 96 Second, it provides a roadmap to the multiple documents which contain 97 the relevant specifications. 99 Third, this document provides a brief easy-to-read summary of the 100 contents of each of the relevant specification documents. 102 This document is intentionally tutorial in nature and, as such, may 103 occasionally be "guilty" of oversimplification. In the event of a 104 conflict or contradiction between this document and the more detailed 105 documents for which this document is a roadmap, the specifications in 106 the more detailed documents shall prevail. 108 Further, the detailed documents attempt to maintain separation between 109 the various component modules in order to specify well-defined 110 interfaces between them. This roadmap document, however, takes a 111 different approach and attempts to provide an integrated view of the 112 various component modules in the interest of readability. 114 2. The Internet Standard Management Framework 116 The third version of the Internet Standard Management Framework (the 117 SNMPv3 Framework) is derived from and builds upon both the original 118 Internet-standard Management Framework (SNMPv1) and the second 119 Internet-standard Management Framework (SNMPv2). 121 All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard 122 Management Framework share the same basic structure and components. 123 Furthermore, all versions of the specifications of the Internet Standard 124 Management Framework follow the same architecture. 126 2.1. Basic Structure and Components 128 An enterprise deploying the Internet Standard Management Framework 129 contains four basic components: 131 * several (typically many) managed nodes, each with an SNMP entity 132 which provides remote access to management instrumentation 133 (traditionally called an agent); 135 * at least one SNMP entity with management applications (typically 136 called a manager), 138 * a management protocol used to convey management information 139 between the SNMP entities, and 141 * management information. 143 The management protocol is used to convey management information between 144 SNMP entities such as managers and agents. 146 This basic structure is common to all versions of the Internet Standard 147 Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3. 149 2.2. Architecture of the Internet Standard Management Framework 151 The specifications of the Internet Standard Management Framework are 152 based on a modular architecture. This framework is more than just a 153 protocol for moving data. It consists of: 155 * a data definition language, 156 * definitions of management information (the Management 157 Information Base, or MIB), 159 * a protocol definition, and 161 * security and administration. 163 Over time, as the Framework has evolved from SNMPv1, through SNMPv2, to 164 SNMPv3, the definitions of each of these architectural components have 165 become richer and more clearly defined, but the fundamental architecture 166 has remained consistent. 168 One prime motivator for this modularity was to enable the ongoing 169 evolution of the Framework as is documented in RFC 1052 [14]. When 170 originally envisioned, this capability was to be used to ease the 171 transition from SNMP-based management of internets to management based 172 on OSI protocols. To this end, the framework was architected with a 173 protocol-independent data definition language and Management Information 174 Base along with a MIB-independent protocol. This separation was 175 designed to allow the SNMP-based protocol to be replaced without 176 requiring the management information to be redefined or reinstrumented. 177 History has shown that the selection of this architecture was the right 178 decision for the wrong reason -- it turned out that this architecture 179 has eased the transition from SNMPv1 to SNMPv2 and from SNMPv2 to SNMPv3 180 rather than easing the transition away from management based on the 181 Simple Network Management Protocol. 183 The SNMPv3 Framework builds and extends these architectural principles 184 by: 186 * building on these four basic architectural components, in some 187 cases incorporating them from the SNMPv2 Framework by reference, 188 and 190 * by using these same layering principles in the definition of new 191 capabilities in the security and administration portion of the 192 architecture. 194 Those who are familiar with the architecture of the SNMPv1 Management 195 Framework and the SNMPv2 Management Framework will find many familiar 196 concepts in the architecture of the SNMPv3 Management Framework. 197 However, in some cases, the terminology may be somewhat different. 199 3. The SNMPv1 Management Framework 201 The original Internet-standard Network Management Framework (SNMPv1) is 202 defined in the following documents: 204 * STD 16, RFC 1155 [1] which defines the Structure of Management 205 Information (SMI), the mechanisms used for describing and naming 206 objects for the purpose of management. 208 * STD 16, RFC 1212 [2] which defines a more concise description 209 mechanism for describing and naming management information objects, 210 but which is wholly consistent with the SMI. 212 * STD 15, RFC 1157 [3] which defines the Simple Network Management 213 Protocol (SNMP), the protocol used for network access to managed 214 objects and event notification. Note this document also defines an 215 initial set of event notifications. 217 Additionally, two documents are generally considered to be companions to 218 these three: 220 * STD 17, RFC 1213 [13] which contains definitions for the base 221 set of management information 223 * RFC 1215 [25] defines a concise description mechanism for 224 defining event notifications, which are called traps in the SNMPv1 225 protocol. It also specifies the generic traps from RFC 1157 in the 226 concise notation. 228 These documents describe the four parts of the first version of the SNMP 229 Framework. 231 3.1. The SNMPv1 Data Definition Language 233 The first two and the last document describe the SNMPv1 data definition 234 language. Note that due to the initial requirement that the SMI be 235 protocol-independent, the first two SMI documents do not provide a means 236 for defining event notifications (traps). Instead, the SNMP protocol 237 document defines a few standardized event notifications (generic traps) 238 and provides a means for additional event notifications to be defined. 239 The last document specifies a straight-forward approach towards defining 240 event notifications used with the SNMPv1 protocol. At the time that it 241 was written, use of traps in the Internet-standard network management 242 framework was controversial. As such, RFC 1215 was put forward with the 243 status of "Informational", which was never updated because it was 244 believed that the second version of the SNMP Framework would replace the 245 first version. Note that the SNMPv1 data definition language is 246 sometimes refered to as SMIv1. 248 3.2. Management Information 250 The data definition language described in the first two documents was 251 first used to define the now-historic MIB-I as specified in RFC 1066 252 [12], and was subsequently used to define MIB-II as specified in RFC 253 1213 [13]. 255 Later, after the publication of MIB-II, a different approach to 256 management information definition was taken from the earlier approach of 257 having a single committee staffed by generalists work on a single 258 document to define the Internet-standard MIB. Rather, many mini-MIB 259 documents were produced in a parallel and distributed fashion by groups 260 chartered to produce a specification for a focused portion of the 261 Internet-standard MIB and staffed by personnel with expertise in those 262 particular areas ranging from various aspects of network management, to 263 system management, and application management. 265 3.3. Protocol Operations 267 The third document, STD 15, describes the SNMPv1 protocol operations 268 performed by protocol data units (PDUs) on lists of variable bindings 269 and describes the format of SNMPv1 messages. The operators defined by 270 SNMPv1 are: get, get-next, get-response, set-request, and trap. 271 Typical layering of SNMP on a connectionless transport service is also 272 defined. 274 3.4. SNMPv1 Security and Administration 276 STD 15 also describes an approach to security and administration. Many 277 of these concepts are carried forward and some, particularly security, 278 are extended by the SNMPv3 Framework. 280 The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in SNMP 281 messages between SNMP entities and distinguishes between application 282 entities and protocol entities. In SNMPv3, these are renamed 283 applications and engines, respectively. 285 The SNMPv1 Framework also introduces the concept of an authentication 286 service supporting one or more authentication schemes. In addition to 287 authentication, SNMPv3 defines the additional security capability 288 referred to as privacy. (Note: some literature from the security 289 community would describe SNMPv3 security capabilities as providing data 290 integrity, source authenticity, and confidentiality.) The modular 291 nature of the SNMPv3 Framework permits both changes and additions to the 292 security capabilities. 294 Finally, the SNMPv1 Framework introduces access control based on a 295 concept called an SNMP MIB view. The SNMPv3 Framework specifies a 296 fundamentally similar concept called view-based access control. With 297 this capability, SNMPv3 provides the means for controlling access to 298 information on managed devices. 300 However, while the SNMPv1 Framework anticipated the definition of 301 multiple authentication schemes, it did not define any such schemes 302 other than a trivial authentication scheme based on community strings. 303 This was a known fundamental weakness in the SNMPv1 Framework but it was 304 thought at that time that the definition of commercial grade security 305 might be contentious in its design and difficult to get approved because 306 "security" means many different things to different people. To that 307 end, and because some users do not require strong authentication, the 308 SNMPv1 architected an authentication service as a separate block to be 309 defined "later" and the SNMPv3 Framework provides an architecture for 310 use within that block as well as a definition for its subsystems. 312 4. The SNMPv2 Management Framework 314 The SNMPv2 Management Framework is fully described in [4-9] and 315 coexistence and transition issues relating to SNMPv1 and SNMPv2 are 316 discussed in [10]. 318 SNMPv2 provides several advantages over SNMPv1, including: 320 * expanded data types (e.g., 64 bit counter) 322 * improved efficiency and performance (get-bulk operator) 324 * confirmed event notification (inform operator) 326 * richer error handling (errors and exceptions) 327 * improved sets, especially row creation and deletion 329 * fine tuning of the data definition language 331 However, the SNMPv2 Framework, as described in these documents, is 332 incomplete in that it does not meet the original design goals of the 333 SNMPv2 project. The unmet goals included provision of security and 334 administration delivering so-called "commercial grade" security with 336 * authentication: origin identification, message integrity, 337 and some aspects of replay protection; 339 * privacy: confidentiality; 341 * authorization and access control; and 343 * suitable remote configuration and administration capabilities 344 for these features. 346 The SNMPv3 Management Framework, as described in this document and the 347 companion documents, addresses these significant deficiencies. 349 5. The SNMPv3 Working Group 351 This document, and its companion documents, were produced by the SNMPv3 352 Working Group of the Internet Engineering Task Force (IETF). The SNMPv3 353 Working Group was chartered to prepare recommendations for the next 354 generation of SNMP. The goal of the Working Group was to produce the 355 necessary set of documents that provide a single standard for the next 356 generation of core SNMP functions. The single, most critical need in 357 the next generation is a definition of security and administration that 358 makes SNMP-based management transactions secure in a way which is useful 359 for users who wish to use SNMPv3 to manage networks, the systems that 360 make up those networks, and the applications which reside on those 361 systems, including manager-to-agent, agent-to-manager, and manager-to- 362 manager transactions. 364 In the several years prior to the chartering of the Working Group, there 365 were a number of activities aimed at incorporating security and other 366 improvements to SNMP. These efforts included: 368 * "SNMP Security" circa 1991-1992 [RFC 1351 - RFC 1353], 370 * "SMP" circa 1992-1993, 371 * "The Party-based SNMPv2" circa 1993-1995 [RFC 1441 - RFC 1452]. 373 Each of these efforts incorporated commercial grade, industrial strength 374 security including authentication, privacy, authorization, view-based 375 access control, and administration, including remote configuration. 377 These efforts fed the development of the SNMPv2 Management Framework as 378 described in RFCs 1902 - 1908. However, the Framework described in 379 those RFCs had no standards-based security and administrative framework 380 of its own; rather, it was associated with multiple security and 381 administrative frameworks, including: 383 * "The Community-based SNMPv2" (SNMPv2c) [RFC 1901], 385 * "SNMPv2u" [RFCs 1909 - 1910] and 387 * "SNMPv2*." 389 SNMPv2c had the endorsement of the IETF but no security and 390 administration whereas both SNMPv2u and SNMPv2* had security but lacked 391 the endorsement of the IETF. 393 The SNMPv3 Working Group was chartered to produce a single set of 394 specifications for the next generation of SNMP, based upon a convergence 395 of the concepts and technical elements of SNMPv2u and SNMPv2*, as was 396 suggested by an advisory team which was formed to provide a single 397 recommended approach for SNMP evolution. 399 In so doing, the Working Group charter defined the following objectives: 401 * accommodate the wide range of operational environments with 402 differing management demands; 404 * facilitate the need to transition from previous, multiple 405 protocols to SNMPv3; 407 * facilitate the ease of setup and maintenance activities. 409 In the initial work of the SNMPv3 Working Group, the group focused on 410 security and administration, including 412 * authentication and privacy, 414 * authorization and view-based access control, and 415 * standards-based remote configuration of the above. 417 The SNMPv3 Working Group did not "reinvent the wheel," but reused the 418 SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for those 419 portions of the design that were outside the focused scope. 421 Rather, the primary contributors to the SNMPv3 Working Group, and the 422 Working Group in general, devoted their considerable efforts to 423 addressing the missing link -- security and administration -- and in the 424 process made invaluable contributions to the state-of-the-art of 425 management. 427 They produced a design based on a modular architecture with evolutionary 428 capabilities with emphasis on layering. As a result, SNMPv3 can be 429 thought of as SNMPv2 with additional security and administration 430 capabilities. 432 In doing so, the Working Group achieved the goal of producing a single 433 specification which has both the endorsement of the IETF and security 434 and administration. 436 6. SNMPv3 Framework Module Specifications 438 The specification of the SNMPv3 Management Framework is partitioned in a 439 modular fashion among several documents. It is the intention of the 440 SNMPv3 Working Group that, with proper care, any or all of the 441 individual documents can be revised, upgraded, or replaced as 442 requirements change, new understandings are obtained, and new 443 technologies become available. 445 Whenever feasible, the initial document set which defines the SNMPv3 446 Management Framework leverages prior investments defining and 447 implementing the SNMPv2 Management Framework by incorporating by 448 reference each of the specifications of the SNMPv2 Management Framework. 450 The SNMPv3 Framework augments those specifications with specifications 451 for security and administration for SNMPv3. 453 The documents which specify the SNMPv3 Management Framework follow the 454 same architecture as those of the prior versions and can be organized 455 for expository purposes into four main categories as follows: 457 * the data definition language, 459 * Management Information Base (MIB) modules, 461 * protocol operations, and 463 * security and administration. 465 The first three sets of documents are incorporated from SNMPv2. The 466 fourth set of documents are new to SNMPv3, but, as described previously, 467 build on significant prior related works. 469 6.1. Data Definition Language 471 The specifications of the data definition language includes RFC 1902, 472 "The Structure of Management Information for Version 2 of the Simple 473 Network Management Protocol (SNMPv2)" [4], and related specifications. 474 The Structure of Management Information (SMI) defines fundamental data 475 types, an object model, and the rules for writing and revising MIB 476 modules. Related specifications include RFC 1903 and RFC 1904. The 477 updated data definition language is sometimes refered to as SMIv2. 479 RFC 1903, "Textual Conventions for Version 2 of the Simple Network 480 Management Protocol (SNMPv2)" [5], defines an initial set of shorthand 481 abbreviations which are available for use within all MIB modules for the 482 convenience of human readers and writers. 484 RFC 1904, "Conformance Statements for Version 2 of the Simple Network 485 Management Protocol (SNMPv2)" [6], defines the format for compliance 486 statements which are used for describing requirements for agent 487 implementations and capability statements which can be used to document 488 the characteristics of particular implementations. 490 6.2. MIB Modules 492 MIB modules usually contain object definitions, may contain definitions 493 of event notifications, and sometimes include compliance statements 494 specified in terms of appropriate object and event notification groups. 495 As such, MIB modules define the management information maintained by the 496 instrumentation in managed nodes, made remotely accessible by management 497 agents, conveyed by the management protocol, and manipulated by 498 management applications. 500 MIB modules are defined according the rules defined in the documents 501 which specify the data definition language, principally the SMI as 502 supplemented by the related specifications. 504 There is a large and growing number of standards-based MIB modules, as 505 defined in the periodically updated list of standard protocols [STD 506 0001, RFC 2000]. As of this writing, there are nearly 100 standards- 507 based MIB modules with a total number of defined objects approaching 508 10,000. In addition, there is an even larger and growing number of 509 enterprise-specific MIB modules defined unilaterally by various vendors, 510 research groups, consortia, and the like resulting in an unknown and 511 virtually uncountable number of defined objects. 513 In general, management information defined in any MIB module, regardless 514 of the version of the data definition language used, can be used with 515 any version of the protocol. For example, MIB modules defined in terms 516 of the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management 517 Framework and can be conveyed by the protocols specified therein. 518 Furthermore, MIB modules defined in terms of the SNMPv2 SMI (SMIv2) are 519 compatible with SNMPv1 protocol operations and can be conveyed by it. 520 However, there is one noteworthy exception: the Counter64 datatype 521 which can be defined in a MIB module defined in SMIv2 format but which 522 cannot be conveyed by an SNMPv1 protocol engine. 524 6.3. Protocol Operations and Transport Mappings 526 The specifications for the protocol operations and transport mappings of 527 the SNMPv3 Framework are incorporated by reference to the two SNMPv2 528 Framework documents. 530 The specification for protocol operations is found in RFC 1905, 531 "Protocol Operations for Version 2 of the Simple Network Management 532 Protocol (SNMPv2)" [7]. 534 The specification of transport mappings is found in RFC 1906, "Transport 535 Mappings for Version 2 of the Simple Network Management Protocol 536 (SNMPv2)" [8]. 538 6.4. SNMPv3 Security and Administration 540 The SNMPv3 document series defined by the SNMPv3 Working Group consists 541 of six [seven] documents at this time: 543 RFC xxxx, "Introduction to the Third Version of the Internet 544 Standard Management Framework (SNMPv3)," which is this document. 546 RFC 2271, "An Architecture for Describing SNMP Management 547 Frameworks" [15], describes the overall architecture with special 548 emphasis on the architecture for security and administration. 550 RFC 2272, "Message Processing and Dispatching for the Simple 551 Network Management Protocol (SNMP)" [16], describes the possibly 552 multiple message processing models and the dispatcher portion that 553 can be a part of an SNMP protocol engine. 555 RFC 2273, "SNMPv3 Applications" [17], describes the five types of 556 applications that can be associated with an SNMPv3 engine and 557 their elements of procedure. 559 RFC 2274, "The User-Based Security Model for Version 3 of the 560 Simple Network Management Protocol (SNMPv3)" [18], describes the 561 threats, mechanisms, protocols, and supporting data used to 562 provide SNMP message-level security. 564 RFC 2275, "View-based Access Control Model for the Simple Network 565 Management Protocol (SNMP)" [19], describes how view-based access 566 control can be applied within command responder and notification 567 originator applications. 569 RFC yyyy, "SNMPv3 Coexistence and Transition" [20], does not exist 570 yet and is still in development. 572 7. Document Summaries 574 The following sections provide brief summaries of each document with 575 slightly more detail than is provided in the overviews, above. 577 7.1. Structure of Management Information 579 Management information is viewed as a collection of managed objects, 580 residing in a virtual information store, termed the Management 581 Information Base (MIB). Collections of related objects are defined in 582 MIB modules. These modules are written in the SNMP MIB module language, 583 which contains elements of OSI's Abstract Syntax Notation One (ASN.1) 584 [11] language. RFC 1902, RFC 1903, and RFC 1904 together define the MIB 585 module language, specify the base data types for objects, specify a core 586 set of short-hand specifications for data types called textual 587 conventions, and specify a few administrative assignments of object 588 identifier (OID) values. 590 The SMI is divided into three parts: module definitions, object 591 definitions, and, trap definitions. 593 (1) Module definitions are used when describing information modules. 594 An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the 595 semantics of an information module. 597 (2) Object definitions are used when describing managed objects. An 598 ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax 599 and semantics of a managed object. 601 (3) Notification definitions are used when describing unsolicited 602 transmissions of management information. An ASN.1 macro, 603 NOTIFICATION-TYPE, is used to convey concisely the syntax and 604 semantics of a notification. 606 7.1.1. Base SMI Specification 608 RFC 1902 specifies the base data types for the MIB module language, 609 which include: Integer32, enumerated integers, Unsigned32, Gauge32, 610 Counter32, Counter64, TimeTicks, OCTET STRING, OBJECT IDENTIFIER, 611 IpAddress, Opaque, and BITS. It also assigns values to several object 612 identifiers. RFC 1902 further defines the following constructs of the 613 MIB module language: 615 * IMPORTS to allow the specification of items that are used 616 in a MIB module, but defined in another MIB module. 618 * MODULE-IDENTITY to specify for a MIB module a description 619 and administrative information such as contact and revision 620 history. 622 * OBJECT-IDENTITY and OID value assignments to specify a 623 an OID value. 625 * OBJECT-TYPE to specify the data type, status, and the semantics 626 of managed objects. 628 * SEQUENCE type assignement to list the columnar objects in 629 a table. 631 * NOTIFICATION-TYPE construct to describe an event notification. 633 7.1.2. Textual Conventions 635 When designing a MIB module, it is often useful to specify in a short- 636 hand way the semantics for a set of objects with similar behavior. This 637 is done by defining a new data type using a base data type specified in 638 the SMI. Each new type has a different name, and specifies a base type 639 with more restrictive semantics. These newly defined types are termed 640 textual conventions, and are used for the convenience of humans reading 641 a MIB module and potentially by "intelligent" management applications. 642 It is the purpose of RFC 1903, Textual Conventions for SNMPv2 [5], to 643 define the construct, TEXTUAL-CONVENTION, of the MIB module language 644 used to define such new types and to specify an initial set of textual 645 conventions available to all MIB modules. 647 7.1.3. Conformance Statements 649 It may be useful to define the acceptable lower-bounds of 650 implementation, along with the actual level of implementation achieved. 651 It is the purpose of RFC 1904, Conformance Statements for SNMPv2 [6], to 652 define the constructs of the MIB module language used for these 653 purposes. There are two kinds of constructs: 655 (1) Compliance statements are used when describing requirements for 656 agents with respect to object and event notification definitions. 657 The MODULE-COMPLIANCE construct is used to convey concisely 658 such requirements. 660 (2) Capability statements are used when describing capabilities of 661 agents with respect to object and event notification definitions. 662 The AGENT-CAPABILITIES construct is used to convey concisely such 663 capabilities. 665 Finally, collections of related objects and collections of related event 666 notifications are grouped together to form a unit of conformance. The 667 OBJECT-GROUP construct is used to convey concisely the objects in and 668 the semantics of an object group. The NOTIFICATION-GROUP construct is 669 used to convey concisely the event notifications in and the semantics of 670 an event notification group. 672 7.2. Protocol Operations 674 The management protocol provides for the exchange of messages which 675 convey management information between the agents and the management 676 stations. The form of these messages is a message "wrapper" which 677 encapsulates a Protocol Data Unit (PDU). 679 It is the purpose of RFC 1905, Protocol Operations for SNMPv2 [7], to 680 define the operations of the protocol with respect to the sending and 681 receiving of the PDUs. 683 7.3. Transport Mappings 685 SNMP Messages may be used over a variety of protocol suites. It is the 686 purpose of RFC 1906, Transport Mappings for SNMPv2 [8], to define how 687 SNMP messages maps onto an initial set of transport domains. Other 688 mappings may be defined in the future. 690 Although several mappings are defined, the mapping onto UDP is the 691 preferred mapping. As such, to provide for the greatest level of 692 interoperability, systems which choose to deploy other mappings should 693 also provide for proxy service to the UDP mapping. 695 7.4. Protocol Instrumentation 697 It is the purpose of RFC 1907, the Management Information Base for 698 SNMPv2 document [9] to define managed objects which describe the 699 behavior of an SNMPv2 entity. 701 7.5. Architecture / Security and Administration 703 It is the purpose of RFC 2271, "Architecture Document" [15], to define 704 an architecture for specifying SNMP Management Frameworks. While 705 addressing general architectural issues, it focuses on aspects related 706 to security and administration. It defines a number of terms used 707 throughout the SNMPv3 Management Framework and, in so doing, clarifies 708 and extends the naming of 710 * engines and applications, 712 * entities (service providers such as the engines in agents 713 and managers), 715 * identities (service users), and 717 * management information, including support for multiple 718 logical contexts. 720 The document contains a small MIB module which is implemented by all 721 authoritative SNMPv3 protocol engines. 723 7.6. Message Processing and Dispatch (MPD) 725 RFC 2272, "Message Processing and Dispatching for the Simple Network 726 Management Protocol (SNMP)" [16], describes the Message Processing and 727 Dispatching for SNMP messages within the SNMP architecture. It defines 728 the procedures for dispatching potentially multiple versions of SNMP 729 messages to the proper SNMP Message Processing Models, and for 730 dispatching PDUs to SNMP applications. This document also describes one 731 Message Processing Model - the SNMPv3 Message Processing Model. 733 It is expected that an SNMPv3 protocol engine MUST support at least one 734 Message Processing Model. An SNMPv3 protocol engine MAY support more 735 than one, for example in a multilingual system which provides 736 simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c. 738 7.7. SNMPv3 Applications 740 It is the purpose of RFC 2273, "SNMPv3 Applications" to describe the 741 five types of applications which can be associated with an SNMP engine. 742 They are: Command Generators, Command Responders, Notification 743 Originators, Notification Receivers, and Proxy Forwarders. 745 The document also defines MIB modules for specifying targets of 746 management operations (including notifications), for notification 747 filtering, and for proxy forwarding. 749 7.8. User-based Security Model (USM) 751 RFC 2274, the "User-based Security Model (USM) for version 3 of the 752 Simple Network Management Protocol (SNMPv3)" describes the User-based 753 Security Model for SNMPv3. It defines the Elements of Procedure for 754 providing SNMP message-level security. 756 The document describes the two primary and two secondary threats which 757 are defended against by the User-based Security Model. They are: 758 modification of information, masquerade, message stream modification, 759 and [optionally] disclosure. 761 The USM utilizes MD5 [21] and the Secure Hash Algorithm [22] as keyed 762 hashing algorithms [22] for digest computation to provide data integrity 764 * to directly protect against data modification attacks, 766 * to indirectly provide data origin authentication, and 768 * to defend against masquerade attacks. 770 The USM uses loosely synchronized monotonically increasing time 771 indicators to defend against certain message stream modification 772 attacks. Automatic clock synchronization mechanisms based on the 773 protocol are specified without dependence on third-party time sources 774 and concomitant security considerations. 776 The USM uses the Data Encryption Standard (DES) [24] in the cipher block 777 chaining mode (CBC) if disclosure protection is desired. 779 The document also includes a MIB suitable for remotely monitoring and 780 managing the configuration parameters for the USM, including key 781 distribution and key management. 783 An entity may provide simultaneous support for multiple security models 784 as well as multiple authentication and privacy protocols. All of the 785 protocols used by the USM are based on pre-placed keys, i.e., private 786 key mechanisms. The SNMPv3 architecture permits the use of asymetric 787 mechanisms and protocols (commonly called but as of this writing, no 788 such SNMPv3 security models utilizing public key cryptography have been 789 published. 791 7.9. View-based Access Control (VACM) 793 The purpose of RFC 2275, the "View-based Access Control Model (VACM) for 794 the Simple Network Management Protocol (SNMP)" is to describe the View- 795 based Access Control Model for use in the SNMP architecture. The VACM 796 can simultaneously be associated in a single engine implementation with 797 multiple Message Processing Models and multiple Security Models. 799 It is architecturally possible to have multiple, different, Access 800 Control Models active and present simultaneously in a single engine 801 implementation, but this is expected to be *_very_* rare in practice and 802 *_far_* less common than simultaneous support for multiple Message 803 Processing Models and/or multiple Security Models. 805 7.10. SNMPv3 Coexistence and Transition 807 This document does not exist yet. It needs to contain: 808 background of 2 approaches to coexistence and transition 809 multilingual approach 810 proxy approach 812 mapping functions derived from rfc 2089 but incorporated by value 813 rather than by reference in order to get these functions onto the 814 standards track and to fix up any lingering problems 816 a community-based security model consistent with the architecture 817 and containing a suitable MIB module for remote configuration thereof 818 for use by multilingual engines supporting snmpv1 and snmpv2c in 819 addition to snmpv3 821 This could be multiple documents, but it really isn't necessary to have more 822 than one and fewer are better than many. 824 8. Security Considerations 826 As this document is primarily a roadmap document, it introduces no new 827 security considerations. The reader is referred to the relevant 828 sections of each of the referenced documents for information about 829 security considerations. 831 9. Editors' Addresses 833 Jeffrey Case 834 SNMP Research, Inc. 835 3001 Kimberlin Heights Road 836 Knoxville, TN 37920-9716 837 USA 838 Phone: +1 423 573 1434 839 EMail: case@snmp.com 841 Russ Mundy 842 TIS Labs at Network Associates 843 3060 Washington Rd 844 Glenwood, MD 21738 845 USA 846 Phone: +1 301 854 6889 847 Email: mundy@tis.com 849 David Partain 850 SNMP Research Europe 851 Teknikringen 1 852 S-583 30 Linkoping 853 Sweden 854 Phone: +46 13 21 18 81 855 Email: partain@europe.snmp.com 857 Bob Stewart 858 Cisco Systems, Inc. 859 170 West Tasman Drive 860 San Jose, CA 95134-1706 861 U.S.A. 862 Phone: +1 603 654 6923 863 EMail: bstewart@cisco.com 865 10. Full Copyright Statement 867 Copyright (C) The Internet Society (1998). All Rights Reserved. 869 This document and translations of it may be copied and furnished to 870 others, and derivative works that comment on or otherwise explain it 871 or assist in its implementation may be prepared, copied, published 872 and distributed, in whole or in part, without restriction of any 873 kind, provided that the above copyright notice and this paragraph 874 are included on all such copies and derivative works. However, this 875 document itself may not be modified in any way, such as by removing 876 the copyright notice or references to the Internet Society or other 877 Internet organizations, except as needed for the purpose of 878 developing Internet standards in which case the procedures for 879 copyrights defined in the Internet Standards process must be 880 followed, or as required to translate it into languages other than 881 English. 883 The limited permissions granted above are perpetual and will not be 884 revoked by the Internet Society or its successors or assigns. 886 This document and the information contained herein is provided on an 887 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 888 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 889 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 890 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 891 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 893 11. References 895 [1] Rose, M., and K. McCloghrie, "Structure and Identification of 896 Management Information for TCP/IP-based internets", STD 16, RFC 897 1155, May 1990. 899 [2] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, 900 RFC 1212, March 1991. 902 [3] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 903 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 904 Systems International, MIT Laboratory for Computer Science, May 905 1990. 907 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 908 S. Waldbusser, "Structure of Management Information for Version 2 909 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 910 January 1996. 912 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 913 S. Waldbusser, "Textual Conventions for Version 2 of the Simple 914 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 916 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 917 S. Waldbusser, "Conformance Statements for Version 2 of the Simple 918 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 920 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 921 S. Waldbusser, "Protocol Operations for Version 2 of the Simple 922 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 924 [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 925 S. Waldbusser, "Transport Mappings for Version 2 of the Simple 926 Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 928 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 929 S. Waldbusser, "Management Information Base for Version 2 of the 930 Simple Network Management Protocol (SNMPv2)", RFC 1907, 931 January 1996. 933 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 934 S. Waldbusser, "Coexistence between Version 1 and Version 2 of the 935 Internet-standard Network Management Framework", RFC 1908, 936 January 1996. 938 [11] Information processing systems - Open Systems Interconnection - 939 Specification of Abstract Syntax Notation One (ASN.1), 940 International Organization for Standardization. International 941 Standard 8824, (December, 1987). 943 [12] McCloghrie, K., and M. Rose, "Management Information Base for 944 Network Management of TCP/IP-based Internets", RFC 1066, 945 August 1988. 947 [13] McCloghrie, K., and M. Rose, "Management Information Base for 948 Network Management of TCP/IP-based internets: MIB-II, RFC 1213, 949 March 1991. 951 [14] Cerf, V., "IAB Recommendations for the Development of Internet 952 Network Management Standards", RFC 1052, April 1988. 954 [15] Harrington, D, R. Presuhn, and B. Wijnen, "An Architecture for 955 Describing SNMP Management Frameworks, RFC 2271, January, 1998. 957 [16] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message 958 Processing and Dispatching for the Simple Network Management 959 Protocol (SNMP)", RFC 2272, January 1998. 961 [17] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 962 RFC 2273, January 1998. 964 [18] Blumenthal, U., and B. Wijnen, "The User-Based Security Model for 965 Version 3 of the Simple Network Management Protocol (SNMPv3)", 966 RFC 2274, January 1998. 968 [19] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 969 Control Model for the Simple Network Management Protocol (SNMP)", 970 RFC 2275, January 1998. 972 [20] TBD, "SNMPv3 Coexistence and Transition", RFC yyyy, Work in 973 progress, date TBD. 975 [21] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992. 977 [22] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) 978 http://csrc.nist.gov/fips/fip180-1.txt (ASCII) 979 http://csrc.nist.gov/fips/fip180-1.ps (Postscript) 981 [23] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: 982 Keyed-Hashing for Message Authentication", RFC 2104, February 983 1997. 985 [24] Data Encryption Standard, National Institute of Standards 986 and Technology. Federal Information Processing Standard (FIPS) 987 Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; 988 reaffirmed January, 1988). 990 [25] M.T. Rose, "A Convention for Defining Traps for use with the 991 SNMP", RFC 1215, March 1991. 993 Table of Contents 995 0 Revision History: ............................................... 2 996 1 Introduction .................................................... 3 997 2 The Internet Standard Management Framework ...................... 4 998 2.1 Basic Structure and Components ................................ 4 999 2.2 Architecture of the Internet Standard Management Framework .... 4 1000 3 The SNMPv1 Management Framework ................................. 6 1001 3.1 The SNMPv1 Data Definition Language ........................... 6 1002 3.2 Management Information ........................................ 7 1003 3.3 Protocol Operations ........................................... 7 1004 3.4 SNMPv1 Security and Administration ............................ 7 1005 4 The SNMPv2 Management Framework ................................. 8 1006 5 The SNMPv3 Working Group ........................................ 9 1007 6 SNMPv3 Framework Module Specifications .......................... 12 1008 6.1 Data Definition Language ...................................... 12 1009 6.2 MIB Modules ................................................... 13 1010 6.3 Protocol Operations and Transport Mappings .................... 14 1011 6.4 SNMPv3 Security and Administration ............................ 14 1012 7 Document Summaries .............................................. 16 1013 7.1 Structure of Management Information ........................... 16 1014 7.1.1 Base SMI Specification ...................................... 16 1015 7.1.2 Textual Conventions ......................................... 17 1016 7.1.3 Conformance Statements ...................................... 17 1017 7.2 Protocol Operations ........................................... 18 1018 7.3 Transport Mappings ............................................ 18 1019 7.4 Protocol Instrumentation ...................................... 18 1020 7.5 Architecture / Security and Administration .................... 19 1021 7.6 Message Processing and Dispatch (MPD) ......................... 19 1022 7.7 SNMPv3 Applications ........................................... 19 1023 7.8 User-based Security Model (USM) ............................... 20 1024 7.9 View-based Access Control (VACM) .............................. 21 1025 7.10 SNMPv3 Coexistence and Transition ............................ 21 1026 8 Security Considerations ......................................... 22 1027 9 Editors' Addresses .............................................. 22 1028 10 Full Copyright Statement ....................................... 23 1029 11 References ..................................................... 23