idnits 2.17.1 draft-ietf-snmpv3-intro-04.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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. ** 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 710: '... protocol engine MUST support at least...' RFC 2119 keyword, line 711: '...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 39 has weird spacing: '...vide an overv...' == Line 40 has weird spacing: '... third versi...' == Line 43 has weird spacing: '...and the secon...' == Line 46 has weird spacing: '...o allow the ...' == Line 974 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 278 -- Looks like a reference, but probably isn't: 'RFC 1901' on line 347 ** 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') -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- 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: 19 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jeffrey D. Case 2 SNMP Research, Inc. 3 Russ Mundy 4 TIS Labs at Network Associates, Inc. 5 David Partain 6 SNMP Research Europe 7 Bob Stewart 8 Cisco Systems 10 Introduction to Version 3 of the 11 Internet standard Network Management Framework 13 1999/02/10 14:47:33 14 draft-ietf-snmpv3-intro-04.txt 15 1.13 -- 1999/02/10 14:47:33 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other groups 24 may also distribute 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 material 29 or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The purpose of this document is to provide an overview of the 40 third version of the Internet-standard Management Framework, 41 termed the SNMP version 3 Framework (SNMPv3). This Framework is 42 derived from and builds upon both the original Internet-standard 43 Management Framework (SNMPv1) and the second Internet-standard 44 Management Framework (SNMPv2). 46 The architecture is designed to be modular to allow the evolu- 47 tion of the Framework over time. 49 1. Introduction 51 This document is an introduction to the third version of the Internet- 52 standard Management Framework, termed the SNMP version 3 Management 53 Framework (SNMPv3) and has multiple purposes. 55 First, it describes the relationship between the SNMP version 3 (SNMPv3) 56 specifications and the specifications of the SNMP version 1 (SNMPv1) 57 Management Framework, the SNMP version 2 (SNMPv2) Management Framework, 58 and the Community-based Administrative Framework for SNMPv2. 60 Second, it provides a roadmap to the multiple documents which contain 61 the relevant specifications. 63 Third, this document provides a brief easy-to-read summary of the 64 contents of each of the relevant specification documents. 66 This document is intentionally tutorial in nature and, as such, may 67 occasionally be "guilty" of oversimplification. In the event of a 68 conflict or contradiction between this document and the more detailed 69 documents for which this document is a roadmap, the specifications in 70 the more detailed documents shall prevail. 72 Further, the detailed documents attempt to maintain separation between 73 the various component modules in order to specify well-defined 74 interfaces between them. This roadmap document, however, takes a 75 different approach and attempts to provide an integrated view of the 76 various component modules in the interest of readability. 78 2. The Internet Standard Management Framework 80 The third version of the Internet Standard Management Framework (the 81 SNMPv3 Framework) is derived from and builds upon both the original 82 Internet-standard Management Framework (SNMPv1) and the second 83 Internet-standard Management Framework (SNMPv2). 85 All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard 86 Management Framework share the same basic structure and components. 87 Furthermore, all versions of the specifications of the Internet Standard 88 Management Framework follow the same architecture. 90 2.1. Basic Structure and Components 92 An enterprise deploying the Internet Standard Management Framework 93 contains four basic components: 95 * several (typically many) managed nodes, each with an SNMP entity 96 which provides remote access to management instrumentation 97 (traditionally called an agent); 99 * at least one SNMP entity with management applications (typically 100 called a manager), 102 * a management protocol used to convey management information 103 between the SNMP entities, and 105 * management information. 107 The management protocol is used to convey management information between 108 SNMP entities such as managers and agents. 110 This basic structure is common to all versions of the Internet Standard 111 Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3. 113 2.2. Architecture of the Internet Standard Management Framework 115 The specifications of the Internet Standard Management Framework are 116 based on a modular architecture. This framework is more than just a 117 protocol for moving data. It consists of: 119 * a data definition language, 120 * definitions of management information (the Management 121 Information Base, or MIB), 123 * a protocol definition, and 125 * security and administration. 127 Over time, as the Framework has evolved from SNMPv1, through SNMPv2, to 128 SNMPv3, the definitions of each of these architectural components have 129 become richer and more clearly defined, but the fundamental architecture 130 has remained consistent. 132 One prime motivator for this modularity was to enable the ongoing 133 evolution of the Framework as is documented in RFC 1052 [14]. When 134 originally envisioned, this capability was to be used to ease the 135 transition from SNMP-based management of internets to management based 136 on OSI protocols. To this end, the framework was architected with a 137 protocol-independent data definition language and Management Information 138 Base along with a MIB-independent protocol. This separation was 139 designed to allow the SNMP-based protocol to be replaced without 140 requiring the management information to be redefined or reinstrumented. 141 History has shown that the selection of this architecture was the right 142 decision for the wrong reason -- it turned out that this architecture 143 has eased the transition from SNMPv1 to SNMPv2 and from SNMPv2 to SNMPv3 144 rather than easing the transition away from management based on the 145 Simple Network Management Protocol. 147 The SNMPv3 Framework builds and extends these architectural principles 148 by: 150 * building on these four basic architectural components, in some 151 cases incorporating them from the SNMPv2 Framework by reference, 152 and 154 * by using these same layering principles in the definition of new 155 capabilities in the security and administration portion of the 156 architecture. 158 Those who are familiar with the architecture of the SNMPv1 Management 159 Framework and the SNMPv2 Management Framework will find many familiar 160 concepts in the architecture of the SNMPv3 Management Framework. 161 However, in some cases, the terminology may be somewhat different. 163 3. The SNMPv1 Management Framework 165 The original Internet-standard Network Management Framework (SNMPv1) is 166 defined in the following documents: 168 * STD 16, RFC 1155 [1] which defines the Structure of Management 169 Information (SMI), the mechanisms used for describing and naming 170 objects for the purpose of management. 172 * STD 16, RFC 1212 [2] which defines a more concise description 173 mechanism for describing and naming management information objects, 174 but which is wholly consistent with the SMI. 176 * STD 15, RFC 1157 [3] which defines the Simple Network Management 177 Protocol (SNMP), the protocol used for network access to managed 178 objects and event notification. Note this document also defines an 179 initial set of event notifications. 181 Additionally, two documents are generally considered to be companions to 182 these three: 184 * STD 17, RFC 1213 [13] which contains definitions for the base 185 set of management information 187 * RFC 1215 [25] defines a concise description mechanism for 188 defining event notifications, which are called traps in the SNMPv1 189 protocol. It also specifies the generic traps from RFC 1157 in the 190 concise notation. 192 These documents describe the four parts of the first version of the SNMP 193 Framework. 195 3.1. The SNMPv1 Data Definition Language 197 The first two and the last document describe the SNMPv1 data definition 198 language. Note that due to the initial requirement that the SMI be 199 protocol-independent, the first two SMI documents do not provide a means 200 for defining event notifications (traps). Instead, the SNMP protocol 201 document defines a few standardized event notifications (generic traps) 202 and provides a means for additional event notifications to be defined. 203 The last document specifies a straight-forward approach towards defining 204 event notifications used with the SNMPv1 protocol. At the time that it 205 was written, use of traps in the Internet-standard network management 206 framework was controversial. As such, RFC 1215 was put forward with the 207 status of "Informational", which was never updated because it was 208 believed that the second version of the SNMP Framework would replace the 209 first version. Note that the SNMPv1 data definition language is 210 sometimes referred to as SMIv1. 212 3.2. Management Information 214 The data definition language described in the first two documents was 215 first used to define the now-historic MIB-I as specified in RFC 1066 216 [12], and was subsequently used to define MIB-II as specified in RFC 217 1213 [13]. 219 Later, after the publication of MIB-II, a different approach to 220 management information definition was taken from the earlier approach of 221 having a single committee staffed by generalists work on a single 222 document to define the Internet-standard MIB. Rather, many mini-MIB 223 documents were produced in a parallel and distributed fashion by groups 224 chartered to produce a specification for a focused portion of the 225 Internet-standard MIB and staffed by personnel with expertise in those 226 particular areas ranging from various aspects of network management, to 227 system management, and application management. 229 3.3. Protocol Operations 231 The third document, STD 15, describes the SNMPv1 protocol operations 232 performed by protocol data units (PDUs) on lists of variable bindings 233 and describes the format of SNMPv1 messages. The operators defined by 234 SNMPv1 are: get, get-next, get-response, set-request, and trap. 235 Typical layering of SNMP on a connectionless transport service is also 236 defined. 238 3.4. SNMPv1 Security and Administration 240 STD 15 also describes an approach to security and administration. Many 241 of these concepts are carried forward and some, particularly security, 242 are extended by the SNMPv3 Framework. 244 The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in SNMP 245 messages between SNMP entities and distinguishes between application 246 entities and protocol entities. In SNMPv3, these are renamed 247 applications and engines, respectively. 249 The SNMPv1 Framework also introduces the concept of an authentication 250 service supporting one or more authentication schemes. In addition to 251 authentication, SNMPv3 defines the additional security capability 252 referred to as privacy. (Note: some literature from the security 253 community would describe SNMPv3 security capabilities as providing data 254 integrity, source authenticity, and confidentiality.) The modular 255 nature of the SNMPv3 Framework permits both changes and additions to the 256 security capabilities. 258 Finally, the SNMPv1 Framework introduces access control based on a 259 concept called an SNMP MIB view. The SNMPv3 Framework specifies a 260 fundamentally similar concept called view-based access control. With 261 this capability, SNMPv3 provides the means for controlling access to 262 information on managed devices. 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 strings. 267 This was a known fundamental weakness in the SNMPv1 Framework but it was 268 thought at that time that the definition of commercial grade security 269 might be contentious in its design and difficult to get approved because 270 "security" means many different things to different people. To that 271 end, and because some users do not require strong authentication, the 272 SNMPv1 architected an authentication service as a separate block to be 273 defined "later" and the SNMPv3 Framework provides an architecture for 274 use within that block as well as a definition for its subsystems. 276 4. The SNMPv2 Management Framework 278 The SNMPv2 Management Framework is fully described in [4-9] and 279 coexistence and transition issues relating to SNMPv1 and SNMPv2 are 280 discussed in [10]. 282 SNMPv2 provides several advantages over SNMPv1, including: 284 * expanded data types (e.g., 64 bit counter) 286 * improved efficiency and performance (get-bulk operator) 288 * confirmed event notification (inform operator) 290 * richer error handling (errors and exceptions) 291 * improved sets, especially row creation and deletion 293 * fine tuning of the data definition language 295 However, the SNMPv2 Framework, as described in these documents, is 296 incomplete in that it does not meet the original design goals of the 297 SNMPv2 project. The unmet goals included provision of security and 298 administration delivering so-called "commercial grade" security with 300 * authentication: origin identification, message integrity, 301 and some aspects of replay protection; 303 * privacy: confidentiality; 305 * authorization and access control; and 307 * suitable remote configuration and administration capabilities 308 for these features. 310 The SNMPv3 Management Framework, as described in this document and the 311 companion documents, addresses these significant deficiencies. 313 5. The SNMPv3 Working Group 315 This document, and its companion documents, were produced by the SNMPv3 316 Working Group of the Internet Engineering Task Force (IETF). The SNMPv3 317 Working Group was chartered to prepare recommendations for the next 318 generation of SNMP. The goal of the Working Group was to produce the 319 necessary set of documents that provide a single standard for the next 320 generation of core SNMP functions. The single, most critical need in 321 the next generation is a definition of security and administration that 322 makes SNMP-based management transactions secure in a way which is useful 323 for users who wish to use SNMPv3 to manage networks, the systems that 324 make up those networks, and the applications which reside on those 325 systems, including manager-to-agent, agent-to-manager, and manager-to- 326 manager transactions. 328 In the several years prior to the chartering of the Working Group, there 329 were a number of activities aimed at incorporating security and other 330 improvements to SNMP. These efforts included: 332 * "SNMP Security" circa 1991-1992 [RFC 1351 - RFC 1353], 334 * "SMP" circa 1992-1993, 335 * "The Party-based SNMPv2" circa 1993-1995 [RFC 1441 - RFC 1452]. 337 Each of these efforts incorporated commercial grade, industrial strength 338 security including authentication, privacy, authorization, view-based 339 access control, and administration, including remote configuration. 341 These efforts fed the development of the SNMPv2 Management Framework as 342 described in RFCs 1902 - 1908. However, the Framework described in 343 those RFCs had no standards-based security and administrative framework 344 of its own; rather, it was associated with multiple security and 345 administrative frameworks, including: 347 * "The Community-based SNMPv2" (SNMPv2c) [RFC 1901], 349 * "SNMPv2u" [RFCs 1909 - 1910] and 351 * "SNMPv2*". 353 SNMPv2c had the endorsement of the IETF but no security and 354 administration whereas both SNMPv2u and SNMPv2* had security but lacked 355 the endorsement of the IETF. 357 The SNMPv3 Working Group was chartered to produce a single set of 358 specifications for the next generation of SNMP, based upon a convergence 359 of the concepts and technical elements of SNMPv2u and SNMPv2*, as was 360 suggested by an advisory team which was formed to provide a single 361 recommended approach for SNMP evolution. 363 In so doing, the Working Group charter defined the following objectives: 365 * accommodate the wide range of operational environments with 366 differing management demands; 368 * facilitate the need to transition from previous, multiple 369 protocols to SNMPv3; 371 * facilitate the ease of setup and maintenance activities. 373 In the initial work of the SNMPv3 Working Group, the group focused on 374 security and administration, including 376 * authentication and privacy, 378 * authorization and view-based access control, and 379 * standards-based remote configuration of the above. 381 The SNMPv3 Working Group did not "reinvent the wheel," but reused the 382 SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for those 383 portions of the design that were outside the focused scope. 385 Rather, the primary contributors to the SNMPv3 Working Group, and the 386 Working Group in general, devoted their considerable efforts to 387 addressing the missing link -- security and administration -- and in the 388 process made invaluable contributions to the state-of-the-art of 389 management. 391 They produced a design based on a modular architecture with evolutionary 392 capabilities with emphasis on layering. As a result, SNMPv3 can be 393 thought of as SNMPv2 with additional security and administration 394 capabilities. 396 In doing so, the Working Group achieved the goal of producing a single 397 specification which has not only the endorsement of the IETF but also 398 has security and administration. 400 6. SNMPv3 Framework Module Specifications 402 The specification of the SNMPv3 Management Framework is partitioned in a 403 modular fashion among several documents. It is the intention of the 404 SNMPv3 Working Group that, with proper care, any or all of the 405 individual documents can be revised, upgraded, or replaced as 406 requirements change, new understandings are obtained, and new 407 technologies become available. 409 Whenever feasible, the initial document set which defines the SNMPv3 410 Management Framework leverages prior investments defining and 411 implementing the SNMPv2 Management Framework by incorporating by 412 reference each of the specifications of the SNMPv2 Management Framework. 414 The SNMPv3 Framework augments those specifications with specifications 415 for security and administration for SNMPv3. 417 The documents which specify the SNMPv3 Management Framework follow the 418 same architecture as those of the prior versions and can be organized 419 for expository purposes into four main categories as follows: 421 * the data definition language, 423 * Management Information Base (MIB) modules, 425 * protocol operations, and 427 * security and administration. 429 The first three sets of documents are incorporated from SNMPv2. The 430 fourth set of documents are new to SNMPv3, but, as described previously, 431 build on significant prior related works. 433 6.1. Data Definition Language 435 The specifications of the data definition language includes RFC 1902, 436 "The Structure of Management Information for Version 2 of the Simple 437 Network Management Protocol (SNMPv2)" [4], and related specifications. 438 The Structure of Management Information (SMI) defines fundamental data 439 types, an object model, and the rules for writing and revising MIB 440 modules. Related specifications include RFC 1903 and RFC 1904. The 441 updated data definition language is sometimes referred to as SMIv2. 443 RFC 1903, "Textual Conventions for Version 2 of the Simple Network 444 Management Protocol (SNMPv2)" [5], defines an initial set of shorthand 445 abbreviations which are available for use within all MIB modules for the 446 convenience of human readers and writers. 448 RFC 1904, "Conformance Statements for Version 2 of the Simple Network 449 Management Protocol (SNMPv2)" [6], defines the format for compliance 450 statements which are used for describing requirements for agent 451 implementations and capability statements which can be used to document 452 the characteristics of particular implementations. 454 6.2. MIB Modules 456 MIB modules usually contain object definitions, may contain definitions 457 of event notifications, and sometimes include compliance statements 458 specified in terms of appropriate object and event notification groups. 459 As such, MIB modules define the management information maintained by the 460 instrumentation in managed nodes, made remotely accessible by management 461 agents, conveyed by the management protocol, and manipulated by 462 management applications. 464 MIB modules are defined according the rules defined in the documents 465 which specify the data definition language, principally the SMI as 466 supplemented by the related specifications. 468 There is a large and growing number of standards-based MIB modules, as 469 defined in the periodically updated list of standard protocols [STD 470 0001, RFC 2400]. As of this writing, there are nearly 100 standards- 471 based MIB modules with a total number of defined objects approaching 472 10,000. In addition, there is an even larger and growing number of 473 enterprise-specific MIB modules defined unilaterally by various vendors, 474 research groups, consortia, and the like resulting in an unknown and 475 virtually uncountable number of defined objects. 477 In general, management information defined in any MIB module, regardless 478 of the version of the data definition language used, can be used with 479 any version of the protocol. For example, MIB modules defined in terms 480 of the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management 481 Framework and can be conveyed by the protocols specified therein. 482 Furthermore, MIB modules defined in terms of the SNMPv2 SMI (SMIv2) are 483 compatible with SNMPv1 protocol operations and can be conveyed by it. 484 However, there is one noteworthy exception: the Counter64 datatype 485 which can be defined in a MIB module defined in SMIv2 format but which 486 cannot be conveyed by an SNMPv1 protocol engine. 488 6.3. Protocol Operations and Transport Mappings 490 The specifications for the protocol operations and transport mappings of 491 the SNMPv3 Framework are incorporated by reference to the two SNMPv2 492 Framework documents. 494 The specification for protocol operations is found in RFC 1905, 495 "Protocol Operations for Version 2 of the Simple Network Management 496 Protocol (SNMPv2)" [7]. The SNMPv3 Framework is designed to allow 497 various portions of the architecture to evolve independently. For 498 example, it might be possible for a new specification of protocol 499 operations to be defined within the Framework to allow for additional 500 protocol operations. 502 The specification of transport mappings is found in RFC 1906, "Transport 503 Mappings for Version 2 of the Simple Network Management Protocol 504 (SNMPv2)" [8]. 506 6.4. SNMPv3 Security and Administration 508 The SNMPv3 document series defined by the SNMPv3 Working Group consists 509 of seven documents at this time: 511 RFC xxxx (draft-ietf-snmpv3-intro-04.txt), "Introduction to 512 Version 3 of the Internet-standard Network Management Framework", 513 which is this document. 515 RFC xxx1 (draft-ietf-snmpv3-arch-05.txt), "An Architecture for 516 Describing SNMP Management Frameworks" [15], describes the overall 517 architecture with special emphasis on the architecture for 518 security and administration. 520 RFC xxx2 (draft-ietf-snmpv3-mpc-05.txt), "Message Processing and 521 Dispatching for the Simple Network Management Protocol (SNMP)" 522 [16], describes the possibly multiple message processing models 523 and the dispatcher portion that can be a part of an SNMP protocol 524 engine. 526 RFC xxx3 (draft-ietf-snmpv3-appl-v2-03.txt), "SNMP Applications" 527 [17], describes the five types of applications that can be 528 associated with an SNMPv3 engine and their elements of procedure. 530 RFC xxx4 (draft-ietf-snmpv3-usm-v2-05.txt), "The User-Based 531 Security Model for Version 3 of the Simple Network Management 532 Protocol (SNMPv3)" [18], describes the threats, mechanisms, 533 protocols, and supporting data used to provide SNMP message-level 534 security. 536 RFC xxx5 (draft-ietf-snmpv3-vacm-04.txt), "View-based Access 537 Control Model for the Simple Network Management Protocol (SNMP)" 538 [19], describes how view-based access control can be applied 539 within command responder and notification originator applications. 541 RFC yyyy (draft-ietf-snmpv3-coex-03.txt), "Coexistence between 542 Version 1, Version 2, and Version 3 of the Internet-standard 543 Network Management Framework" [20], describes coexistence between 544 the SNMPv3 Management Framework, the SNMPv2 Management Framework, 545 and the original SNMPv1 Management Framework. 547 7. Document Summaries 549 The following sections provide brief summaries of each document with 550 slightly more detail than is provided in the overviews above. 552 7.1. Structure of Management Information 554 Management information is viewed as a collection of managed objects, 555 residing in a virtual information store, termed the Management 556 Information Base (MIB). Collections of related objects are defined in 557 MIB modules. These modules are written in the SNMP MIB module language, 558 which contains elements of OSI's Abstract Syntax Notation One (ASN.1) 559 [11] language. RFC 1902, RFC 1903, and RFC 1904 together define the MIB 560 module language, specify the base data types for objects, specify a core 561 set of short-hand specifications for data types called textual 562 conventions, and specify a few administrative assignments of object 563 identifier (OID) values. 565 The SMI is divided into three parts: module definitions, object 566 definitions, and notification definitions. 568 (1) Module definitions are used when describing information modules. 569 An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the 570 semantics of an information module. 572 (2) Object definitions are used when describing managed objects. An 573 ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax 574 and semantics of a managed object. 576 (3) Notification definitions are used when describing unsolicited 577 transmissions of management information. An ASN.1 macro, 578 NOTIFICATION-TYPE, is used to convey concisely the syntax and 579 semantics of a notification. 581 7.1.1. Base SMI Specification 583 RFC 1902 specifies the base data types for the MIB module language, 584 which include: Integer32, enumerated integers, Unsigned32, Gauge32, 585 Counter32, Counter64, TimeTicks, INTEGER, OCTET STRING, OBJECT 586 IDENTIFIER, IpAddress, Opaque, and BITS. It also assigns values to 587 several object identifiers. RFC 1902 further defines the following 588 constructs of the MIB module language: 590 * IMPORTS to allow the specification of items that are used 591 in a MIB module, but defined in another MIB module. 593 * MODULE-IDENTITY to specify for a MIB module a description 594 and administrative information such as contact and revision 595 history. 597 * OBJECT-IDENTITY and OID value assignments to specify a 598 an OID value. 600 * OBJECT-TYPE to specify the data type, status, and the semantics 601 of managed objects. 603 * SEQUENCE type assignment to list the columnar objects in 604 a table. 606 * NOTIFICATION-TYPE construct to specify an event notification. 608 7.1.2. Textual Conventions 610 When designing a MIB module, it is often useful to specify in a short- 611 hand way the semantics for a set of objects with similar behavior. This 612 is done by defining a new data type using a base data type specified in 613 the SMI. Each new type has a different name, and specifies a base type 614 with more restrictive semantics. These newly defined types are termed 615 textual conventions, and are used for the convenience of humans reading 616 a MIB module and potentially by "intelligent" management applications. 617 It is the purpose of RFC 1903, Textual Conventions for SNMPv2 [5], to 618 define the construct, TEXTUAL-CONVENTION, of the MIB module language 619 used to define such new types and to specify an initial set of textual 620 conventions available to all MIB modules. 622 7.1.3. Conformance Statements 624 It may be useful to define the acceptable lower-bounds of 625 implementation, along with the actual level of implementation achieved. 626 It is the purpose of RFC 1904, Conformance Statements for SNMPv2 [6], to 627 define the constructs of the MIB module language used for these 628 purposes. There are two kinds of constructs: 630 (1) Compliance statements are used when describing requirements for 631 agents with respect to object and event notification definitions. 632 The MODULE-COMPLIANCE construct is used to convey concisely 633 such requirements. 635 (2) Capability statements are used when describing capabilities of 636 agents with respect to object and event notification definitions. 637 The AGENT-CAPABILITIES construct is used to convey concisely such 638 capabilities. 640 Finally, collections of related objects and collections of related event 641 notifications are grouped together to form a unit of conformance. The 642 OBJECT-GROUP construct is used to convey concisely the objects in and 643 the semantics of an object group. The NOTIFICATION-GROUP construct is 644 used to convey concisely the event notifications in and the semantics of 645 an event notification group. 647 7.2. Protocol Operations 649 The management protocol provides for the exchange of messages which 650 convey management information between the agents and the management 651 stations. The form of these messages is a message "wrapper" which 652 encapsulates a Protocol Data Unit (PDU). 654 It is the purpose of RFC 1905, Protocol Operations for SNMPv2 [7], to 655 define the operations of the protocol with respect to the sending and 656 receiving of the PDUs. 658 7.3. Transport Mappings 660 SNMP Messages may be used over a variety of protocol suites. It is the 661 purpose of RFC 1906, Transport Mappings for SNMPv2 [8], to define how 662 SNMP messages maps onto an initial set of transport domains. Other 663 mappings may be defined in the future. 665 Although several mappings are defined, the mapping onto UDP is the 666 preferred mapping. As such, to provide for the greatest level of 667 interoperability, systems which choose to deploy other mappings should 668 also provide for proxy service to the UDP mapping. 670 7.4. Protocol Instrumentation 672 It is the purpose of RFC 1907, the Management Information Base for 673 SNMPv2 document [9] to define managed objects which describe the 674 behavior of an SNMPv2 entity. 676 7.5. Architecture / Security and Administration 678 It is the purpose of RFC xxx1 (draft-ietf-snmpv3-arch-05.txt), "An 679 Architecture for Describing SNMP Management Frameworks" [15], to define 680 an architecture for specifying SNMP Management Frameworks. While 681 addressing general architectural issues, it focuses on aspects related 682 to security and administration. It defines a number of terms used 683 throughout the SNMPv3 Management Framework and, in so doing, clarifies 684 and extends the naming of 686 * engines and applications, 688 * entities (service providers such as the engines in agents 689 and managers), 691 * identities (service users), and 693 * management information, including support for multiple 694 logical contexts. 696 The document contains a small MIB module which is implemented by all 697 authoritative SNMPv3 protocol engines. 699 7.6. Message Processing and Dispatch (MPD) 701 RFC xxx2 (draft-ietf-snmpv3-mpc-05.txt), "Message Processing and 702 Dispatching for the Simple Network Management Protocol (SNMP)" [16], 703 describes the Message Processing and Dispatching for SNMP messages 704 within the SNMP architecture. It defines the procedures for dispatching 705 potentially multiple versions of SNMP messages to the proper SNMP 706 Message Processing Models, and for dispatching PDUs to SNMP 707 applications. This document also describes one Message Processing Model 708 - the SNMPv3 Message Processing Model. 710 It is expected that an SNMPv3 protocol engine MUST support at least one 711 Message Processing Model. An SNMPv3 protocol engine MAY support more 712 than one, for example in a multi-lingual system which provides 713 simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c. 715 7.7. SNMP Applications 717 It is the purpose of RFC xxx3 (draft-ietf-snmpv3-appl-v2-03.txt), "SNMP 718 Applications" to describe the five types of applications which can be 719 associated with an SNMP engine. They are: Command Generators, Command 720 Responders, Notification Originators, Notification Receivers, and Proxy 721 Forwarders. 723 The document also defines MIB modules for specifying targets of 724 management operations (including notifications), for notification 725 filtering, and for proxy forwarding. 727 7.8. User-based Security Model (USM) 729 RFC xxx4 (draft-ietf-snmpv3-usm-v2-05.txt), the "User-based Security 730 Model (USM) for version 3 of the Simple Network Management Protocol 731 (SNMPv3)" describes the User-based Security Model for SNMPv3. It 732 defines the Elements of Procedure for providing SNMP message-level 733 security. 735 The document describes the two primary and two secondary threats which 736 are defended against by the User-based Security Model. They are: 737 modification of information, masquerade, message stream modification, 738 and disclosure. 740 The USM utilizes MD5 [21] and the Secure Hash Algorithm [22] as keyed 741 hashing algorithms [23] for digest computation to provide data integrity 743 * to directly protect against data modification attacks, 745 * to indirectly provide data origin authentication, and 747 * to defend against masquerade attacks. 749 The USM uses loosely synchronized monotonically increasing time 750 indicators to defend against certain message stream modification 751 attacks. Automatic clock synchronization mechanisms based on the 752 protocol are specified without dependence on third-party time sources 753 and concomitant security considerations. 755 The USM uses the Data Encryption Standard (DES) [24] in the cipher block 756 chaining mode (CBC) if disclosure protection is desired. Support for 757 DES in the USM is optional, primarily because export and usage 758 restrictions in many countries make it difficult to export and use 759 products which include cryptographic technology. 761 The document also includes a MIB suitable for remotely monitoring and 762 managing the configuration parameters for the USM, including key 763 distribution and key management. 765 An entity may provide simultaneous support for multiple security models 766 as well as multiple authentication and privacy protocols. All of the 767 protocols used by the USM are based on pre-placed keys, i.e., private 768 key mechanisms. The SNMPv3 architecture permits the use of asymmetric 769 mechanisms and protocols (commonly called "public key cryptography") but 770 as of this writing, no such SNMPv3 security models utilizing public key 771 cryptography have been published. 773 7.9. View-based Access Control (VACM) 775 The purpose of RFC xxx5 (draft-ietf-snmpv3-vacm-04.txt), the "View-based 776 Access Control Model (VACM) for the Simple Network Management Protocol 777 (SNMP)" is to describe the View-based Access Control Model for use in 778 the SNMP architecture. The VACM can simultaneously be associated in a 779 single engine implementation with multiple Message Processing Models and 780 multiple Security Models. 782 It is architecturally possible to have multiple, different, Access 783 Control Models active and present simultaneously in a single engine 784 implementation, but this is expected to be *_very_* rare in practice and 785 *_far_* less common than simultaneous support for multiple Message 786 Processing Models and/or multiple Security Models. 788 7.10. SNMPv3 Coexistence and Transition 790 The purpose of RFC yyyy (draft-ietf-snmpv3-coex-03.txt), "Coexistence 791 between Version 1, Version 2, and Version 3 of the Internet-standard 792 Network Management Framework" is to describe coexistence between the 793 SNMPv3 Management Framework, the SNMPv2 Management Framework, and the 794 original SNMPv1 Management Framework. In particular, this document 795 describes four aspects of coexistence: 797 * Conversion of MIB documents from SMIv1 to SMIv2 format 799 * Mapping of notification parameters 801 * Approaches to coexistence between entities which support 802 the various versions of SNMP in a multi-lingual network, in 803 particular the processing of protocol operations in 804 multi-lingual implementations, as well as behaviour of 805 proxy implementations 807 * The SNMPv1 Message Processing Model and Community-Based 808 Security Model, which provides mechanisms for adapting 809 SNMPv1 and SNMPv2c into the View-Based Access Control Model 810 (VACM) [19] 812 8. Security Considerations 814 As this document is primarily a roadmap document, it introduces no new 815 security considerations. The reader is referred to the relevant 816 sections of each of the referenced documents for information about 817 security considerations. 819 9. Editors' Addresses 821 Jeffrey Case 822 SNMP Research, Inc. 823 3001 Kimberlin Heights Road 824 Knoxville, TN 37920-9716 825 USA 826 Phone: +1 423 573 1434 827 EMail: case@snmp.com 829 Russ Mundy 830 TIS Labs at Network Associates 831 3060 Washington Rd 832 Glenwood, MD 21738 833 USA 834 Phone: +1 301 854 6889 835 EMail: mundy@tis.com 837 David Partain 838 SNMP Research Europe 839 Teknikringen 1 840 S-583 30 Linkoping 841 Sweden 842 Phone: +46 13 21 18 81 843 EMail: partain@europe.snmp.com 845 Bob Stewart 846 Cisco Systems, Inc. 847 170 West Tasman Drive 848 San Jose, CA 95134-1706 849 U.S.A. 850 Phone: +1 603 654 6923 851 EMail: bstewart@cisco.com 853 10. Full Copyright Statement 855 Copyright (C) The Internet Society (1998). All Rights Reserved. 857 This document and translations of it may be copied and furnished to 858 others, and derivative works that comment on or otherwise explain it 859 or assist in its implementation may be prepared, copied, published 860 and distributed, in whole or in part, without restriction of any 861 kind, provided that the above copyright notice and this paragraph 862 are included on all such copies and derivative works. However, this 863 document itself may not be modified in any way, such as by removing 864 the copyright notice or references to the Internet Society or other 865 Internet organizations, except as needed for the purpose of 866 developing Internet standards in which case the procedures for 867 copyrights defined in the Internet Standards process must be 868 followed, or as required to translate it into languages other than 869 English. 871 The limited permissions granted above are perpetual and will not be 872 revoked by the Internet Society or its successors or assigns. 874 This document and the information contained herein is provided on an 875 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 876 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 877 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 878 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 879 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 881 11. References 883 [1] Rose, M., and K. McCloghrie, "Structure and Identification of 884 Management Information for TCP/IP-based internets", STD 16, RFC 885 1155, May 1990. 887 [2] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, 888 RFC 1212, March 1991. 890 [3] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 891 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 892 Systems International, MIT Laboratory for Computer Science, May 893 1990. 895 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 896 S. Waldbusser, "Structure of Management Information for Version 2 897 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 898 January 1996. 900 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 901 S. Waldbusser, "Textual Conventions for Version 2 of the Simple 902 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 904 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 905 S. Waldbusser, "Conformance Statements for Version 2 of the Simple 906 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 908 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 909 S. Waldbusser, "Protocol Operations for Version 2 of the Simple 910 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 912 [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 913 S. Waldbusser, "Transport Mappings for Version 2 of the Simple 914 Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 916 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 917 S. Waldbusser, "Management Information Base for Version 2 of the 918 Simple Network Management Protocol (SNMPv2)", RFC 1907, 919 January 1996. 921 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 922 S. Waldbusser, "Coexistence between Version 1 and Version 2 of the 923 Internet-standard Network Management Framework", RFC 1908, 924 January 1996. 926 [11] Information processing systems - Open Systems Interconnection - 927 Specification of Abstract Syntax Notation One (ASN.1), 928 International Organization for Standardization. International 929 Standard 8824, (December, 1987). 931 [12] McCloghrie, K., and M. Rose, "Management Information Base for 932 Network Management of TCP/IP-based Internets", RFC 1066, 933 August 1988. 935 [13] McCloghrie, K., and M. Rose, "Management Information Base for 936 Network Management of TCP/IP-based internets: MIB-II, RFC 1213, 937 March 1991. 939 [14] Cerf, V., "IAB Recommendations for the Development of Internet 940 Network Management Standards", RFC 1052, April 1988. 942 [15] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 943 for Describing SNMP Management Frameworks", 944 , January 1999. 946 [16] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message 947 Processing and Dispatching for the Simple Network Management 948 Protocol (SNMP)", , 949 January, 1999. 951 [17] Levi, D., Meyer, P., and B. Stewart, "SNMP Applications", 952 , January 1999. 954 [18] Blumenthal, U. and B. Wijnen, "The User-Based Security 955 Model for Version 3 of the Simple Network Management Protocol 956 (SNMPv3)", , January 1999. 958 [19] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 959 Access Control Model for the Simple Network Management Protocol 960 (SNMP)", , January 1999. 962 [20] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence 963 between Version 1, Version 2, and Version 3 of the 964 Internet-standard Network Management Framework", 965 , January 1999. 967 [21] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992. 969 [22] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) 970 http://csrc.nist.gov/fips/fip180-1.txt (ASCII) 971 http://csrc.nist.gov/fips/fip180-1.ps (Postscript) 973 [23] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: 974 Keyed-Hashing for Message Authentication", RFC 2104, February 975 1997. 977 [24] Data Encryption Standard, National Institute of Standards 978 and Technology. Federal Information Processing Standard (FIPS) 979 Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; 980 reaffirmed January, 1988). 982 [25] M.T. Rose, "A Convention for Defining Traps for use with the 983 SNMP", RFC 1215, March 1991. 985 Table of Contents 987 1 Introduction .................................................... 3 988 2 The Internet Standard Management Framework ...................... 4 989 2.1 Basic Structure and Components ................................ 4 990 2.2 Architecture of the Internet Standard Management Framework .... 4 991 3 The SNMPv1 Management Framework ................................. 6 992 3.1 The SNMPv1 Data Definition Language ........................... 6 993 3.2 Management Information ........................................ 7 994 3.3 Protocol Operations ........................................... 7 995 3.4 SNMPv1 Security and Administration ............................ 7 996 4 The SNMPv2 Management Framework ................................. 8 997 5 The SNMPv3 Working Group ........................................ 9 998 6 SNMPv3 Framework Module Specifications .......................... 12 999 6.1 Data Definition Language ...................................... 12 1000 6.2 MIB Modules ................................................... 13 1001 6.3 Protocol Operations and Transport Mappings .................... 14 1002 6.4 SNMPv3 Security and Administration ............................ 14 1003 7 Document Summaries .............................................. 16 1004 7.1 Structure of Management Information ........................... 16 1005 7.1.1 Base SMI Specification ...................................... 16 1006 7.1.2 Textual Conventions ......................................... 17 1007 7.1.3 Conformance Statements ...................................... 17 1008 7.2 Protocol Operations ........................................... 18 1009 7.3 Transport Mappings ............................................ 18 1010 7.4 Protocol Instrumentation ...................................... 18 1011 7.5 Architecture / Security and Administration .................... 19 1012 7.6 Message Processing and Dispatch (MPD) ......................... 19 1013 7.7 SNMP Applications ............................................. 19 1014 7.8 User-based Security Model (USM) ............................... 20 1015 7.9 View-based Access Control (VACM) .............................. 21 1016 7.10 SNMPv3 Coexistence and Transition ............................ 21 1017 8 Security Considerations ......................................... 23 1018 9 Editors' Addresses .............................................. 23 1019 10 Full Copyright Statement ....................................... 24 1020 11 References ..................................................... 24