idnits 2.17.1 draft-ietf-disman-framework-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 23, 1998) is 9371 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2271 (ref. '1') (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Obsolete normative reference: RFC 1902 (ref. '5') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '6') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '7') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (ref. '11') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '12') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '14') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '15') (Obsoleted by RFC 2575) Summary: 22 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Distributed Management Framework Aug, 1998 4 Distributed Management Framework 5 7 August 23, 1998 9 Authors: 11 Andy Bierman 12 Cisco Systems 13 abierman@cisco.com 15 Maria Greene 16 Ascom Nexion 17 greene@nexen.com 19 Bob Stewart 20 Cisco Systems 21 bstewart@cisco.com 23 Steve Waldbusser 24 International Network Services (INS) 25 waldbusser@ins.com 27 1. Status of this Memo 29 This document is an Internet-Draft. Internet-Drafts are 30 working documents of the Internet Engineering Task Force 31 (IETF), its areas, and its working groups. Note that other 32 groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other 37 documents at any time. It is inappropriate to use Internet- 38 Drafts as reference material or to cite them other than as 39 "work in progress." 41 To view the entire list of current Internet-Drafts, please 42 check the "1id-abstracts.txt" listing contained in the 43 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 44 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 45 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 46 Coast), or ftp.isi.edu (US West Coast). 48 2. Abstract 50 This memo defines a distributed management architecture for 51 use with the SNMP network management architecture. 53 This memo does not specify a standard for the Internet 54 community. 56 3. Overview 58 Distributed Management is the delegation of control from one 59 management station to another. While the SNMP Network 60 Management Framework does not specifically address distributed 61 management, this function is desired and has been implemented 62 and deployed in the internet using proprietary architectures. 63 It is desired that there be a standard upon which to promote 64 interoperability, as well as a common framework upon which 65 various systems can be built. 67 The goals of distributed management are: 69 o Scalability through Distribution 70 In order to build network management systems that have the 71 power to manage very large networks, it is important to 72 reduce bottlenecks in the management system. Therefore, a 73 distributed systems approach is often helpful when 74 building large management systems. A distributed approach 75 is often very effective at reducing load on the central 76 management station, and may be effective at reducing the 77 load that the central management station places on 78 backbone networks. However, a distributed approach usually 79 has no benefit in reducing load on remote networks and has 80 no benefit in reducing load on management agents. Further, 81 in a distributed data collection architecture, if all data 82 collected is eventually forwarded to the central 83 management station (without aggregation or compression), 84 then no benefit in backbone load or central management 85 station load should be expected (except perhaps to time- 86 shift this load to a time of excess capacity, at the 87 expense of a lack of timeliness of data. 89 o Disconnected or Low-Bandwidth Operation 90 There are sometimes conditions when a management station 91 will not be in constant contact with all portions of the 92 managed network. This is sometimes by design in an attempt 93 to lower communications costs (especially when 94 communicating over a WAN or dialup link), or by accident 95 as network failures affect the communications between the 96 management station and portions of the managed network. 98 For this reason, a distributed management station will be 99 configured to perform network management functions, even 100 when communication with the management station may not be 101 possible or efficient. The distributed management station 102 may then attempt to notify the management station when an 103 exceptional condition occurs. Thus, even in circumstances 104 where communication with the distributed management 105 station is not continuous, network management operations 106 may run continuously, communicating with the management 107 station conveniently and efficiently, on an as-needed 108 basis. 110 o Mirroring organization boundaries and processes 111 Business organizations are typically set up in a 112 hierarchical fashion. Multiple people in the hierarchy 113 have different roles, responsibilites, and authority. The 114 network management system often has to be configured to 115 match this organization. Distributed network managers can 116 be set up in a hierarchy that matches the roles of various 117 people in the organization. 119 o Promotes a modular system architecture 120 A modular system architecture allows flexibility and re- 121 usability of network management components. This also 122 enables a multi-vendor approach to building management 123 systems. A distributed network management system with 124 well-defined interfaces creates this modular scheme. 126 This document defines an architectural framework for 127 standards-based distributed management 129 4. Relationship to the SNMP Management Framework 131 A distributed network management station is a management 132 station that receives requests from another manager and 133 executes those requests by performing management operations on 134 agents or other managers. Note that these requests may take a 135 long time to execute, and may be registered indefinitely. This 136 framework uses the services of the SNMP Management Framework. 138 4.1. The SNMP Management Framework 140 The SNMP Management Framework presently consists of five major 141 components: 143 o An overall architecture, described in RFC 2271 [1]. 145 o Mechanisms for describing and naming objects and 146 events for the purpose of management. The first 147 version of this Structure of Management Information 148 (SMI) is called SMIv1 and described in RFC 1155 [2], 149 RFC 1212 [3] and RFC 1215 [4]. The second version, 150 called SMIv2, is described in RFC 1902 [5], RFC 1903 151 [6] and RFC 1904 [7]. 153 o Message protocols for transferring management 154 information. The first version of the SNMP message 155 protocol is called SNMPv1 and described in RFC 1157 156 [8]. A second version of the SNMP message protocol, 157 which is not an Internet standards track protocol, is 158 called SNMPv2c and described in RFC 1901 [9] and RFC 159 1906 [10]. The third version of the message protocol 160 is called SNMPv3 and described in RFC 1906 [10], RFC 161 2272 [11] and RFC 2274 [12]. 163 o Protocol operations for accessing management 164 information. The first set of protocol operations and 165 associated PDU formats is described in RFC 1157 [8]. A 166 second set of protocol operations and associated PDU 167 formats is described in RFC 1905 [13]. 169 o A set of fundamental applications described in RFC 170 2273 [14] and the view-based access control mechanism 171 described in RFC 2275 [15]. Managed objects are 172 accessed via a virtual information store, termed the 173 Management Information Base or MIB. Objects in the 174 MIB are defined using the mechanisms defined in the 175 SMI. This memo specifies a MIB module that is 176 compliant to the SMIv2. A MIB conforming to the SMIv1 177 can be produced through the appropriate translations. 178 The resulting translated MIB must be semantically 179 equivalent, except where objects or events are omitted 180 because no translation is possible (use of Counter64). 181 Some machine readable information in SMIv2 will be 182 converted into textual descriptions in SMIv1 during 183 the translation process. However, this loss of machine 184 readable information is not considered to change the 185 semantics of the MIB. 187 5. Distributed Management Framework 189 The distributed management framework consists of applications 190 and services. 192 A distributed management application performs some management 193 function, often by monitoring and controlling managed 194 elements. These applications perform functions such as 195 threshold polling, historical data polling, or discovery. The 196 specifications and communications protocols of some of these 197 applications will be defined by standards, while others will 198 be enterprise specific. 200 Distributed management services are a collection of services 201 that make up the run-time environment for the distributed 202 management application. These services are crucial to ensuring 203 the usability, scalability, and efficiency of the distributed 204 management applications that depend on them. Some of these 205 services are mandatory, while others are optional. Further, 206 even the mandatory services allow varying depths of support, 207 as described further, below. 209 Each of these services is made available through a MIB 210 interface. 212 The purpose of these services is to provide true enterprise 213 management that allows distributed management functions to be 214 used on an enterprise-wide basis without undue amounts of 215 administrative difficulty. These services also make a set of 216 applications more efficient because the service can perform 217 functions or store information once for all applications on 218 the local system. Further, less work is required to be put 219 into writing the application because some of the core 220 functions are performed elsewhere. 222 5.1. Known Systems 224 The Known Systems service provides a list of all systems which 225 the distributed management system knows about and is prepared 226 to perform management operations upon. This list may be 227 populated by a continuously-running auto-discovery process, it 228 may be populated with SNMP SET requests, or it may be a static 229 list dictated by the system. 231 This service also stores type and attribute information for 232 each of the known systems. 234 The purpose of this service is to allow a management 235 application to be executed on a list of systems so that true 236 enterprise management is possible rather than more ad-hoc 237 management functions. Further, the targets of management 238 applications can be configured separately from the 239 applications to reduce administrative burden as the list of 240 known systems changes. 242 An example of a known systems list is a list of all systems at 243 a site discovered by the autodiscovery module, along with 244 various addressing, type, and attribute information for each. 246 5.2. Management Domains 248 The Management Domains service provides a list of known 249 systems which is a subset of the entire list of known systems. 250 The subset is defined by a rule, or filter, which selects only 251 the known systems that match or those that don't match certain 252 criteria. 254 These domains are multiple, potentially overlapping, sets of 255 devices based on (human) organizational boundaries that define 256 the extents over which management operations should be 257 performed. 259 The purpose of this service is to allow a management 260 application to be executed on a list of known systems within a 261 particular domain. Further, as the domains change over time, 262 the application will automatically be kept up to date and will 263 only monitor the correct systems. 265 An example of a management domain is the subset of all known 266 systems that is on the engineering LAN. 268 5.3. Management Operations Targets 270 The Management Operations Targets service provides a list of 271 known systems in a set of domains that match certain criteria 272 that indicate that it makes sense to perform a particular 273 management function on them. 275 The purpose of this service is to direct management operations 276 to be performance only on those systems where that operation 277 would make sense. Because this is described as a filter, there 278 are no static configuration requirements that would be 279 unacceptable in a dynamically changing network environment. 281 An example of a management operation target list is the subset 282 of all known routers on the engineering LAN. 284 5.4. Credential Delegation 286 The Credential Delegation Service allows credentials of a 287 network management user to be delegated to a distributed 288 management application so that it can perform secure 289 operations on behalf of that user. 291 Fundamental to this distributed management architecture is the 292 notion that distributed management operations must not run 293 with the credentials of the distributed manager. To do so 294 would require that the authorization of these credentials (or 295 subsets of this authorization) would need to be apportioned to 296 users of that distributed manager in a pre-defined and secure 297 way. This would require the creation of a access control 298 architecture mirroring the SNMP View-Based Access Control 299 architecture that would control what subsets of authority are 300 available to what users. The existing View-Based Access 301 Control mechanism was not designed for this task and is not 302 appropriate. Further, it would require that the distributed 303 manager be configured in a way that was consistent with the 304 access control policy embodied in the managed systems. This 305 would be extremely problematic because: 307 1. This would require a massive amount of configuration to 308 be replicated on the distributed manager 310 2. If any part of this configuration on the distributed 311 manager is inconsistent with that on the managed systems, a 312 security hole could be exposed. 314 Because it is assumed that the distributed manager adds no 315 credentials to management operations, when a manager wishes to 316 configure a distributed manager to perform secure transactions 317 on its behalf, it must download to the distributed manager the 318 appropriate credentials to be placed in secure SNMP messages, 319 identifying them as the manager. A credential contains at 320 least the securityModel, securityName, securityLevel, 321 authentication and privacy keys, and an indication of which 322 management targets the credential should be used for. 324 5.4.1. Definitions 326 ----------- --------------- -------------- 327 | | | | | | 328 | Manager |---------->| Distributed |------------->| Management | 329 | | Disman | Manager | Target | Target | 330 | | User | | User | | 331 | | | | Identity | | 332 | | | | | | 333 ----------- --------------- -------------- 335 1. Disman User - The user whose credentials are used to 336 configure the distributed manager for an operation and to 337 download credentials for that operation. There is no 338 relationship implied between the disman user and the 339 user(s) who's credentials are installed (in other words, 340 "joe" can install credentials for "ops-center-east" as 341 well as "joe"). 343 2. Target User Identity - The user identity used in SNMP 344 messages between the distributed manager and management 345 targets. 347 3. Credential - The set of secrets that are transferred 348 to the distributed manager giving it the authority to act 349 as an identity. 351 4. Owner - The disman user who sets up a distributed 352 management function, including the credentials for the 353 function. 355 5. Invoker - The user who invokes a previously setup 356 distributed management function. The owner may choose to 357 allow others to invoke a function, potentially allowing 358 that function to operate with the owner's credentials (of 359 course the owner would want to tightly constrain what the 360 function was configured to perform). 362 6. Invokation Identity - The identity of the credentials 363 a function is operating with. These may be of the owner, 364 of the invoker, or possibly the union of both 365 credentials. 367 Because multiple Disman Users will have access to a 368 Distributed Manager, the Credential Delegation Service will be 369 responsible for ensuring that credentials are only used by 370 authorized users. The Credential Delegation Service will 371 include: 373 1. Credential Store - a MIB in which to transfer and 374 store credentials 376 2. MIB prototype - a prototype MIB fragment that will be 377 added to disman functions that wish to use the Credential 378 Store 380 3. Access Control Policy - a policy for configuration of 381 the VACM MIB for use with the Credential Delegation 382 Service. This will limit access to the credential store. 384 5.5. Delegation Control 386 The Delegation Control Service provides functions that limit 387 the resource usage of a distributed management application 388 that has had control delegated to it. 390 Network management applications are often responsible for 391 adding stress on the network and causing problems. Examples 392 are excessive polling load on slow-speed networks or on router 393 CPUs. This problem will become even more dangerous when 394 network management functions are delegated to distributed 395 management stations. 397 Policies need to be configured that limit average and burst 398 polling, notification, and broadcast rates. These rates may 399 be defined for the sending system as a whole, per end node, or 400 per management application on the sending system. 402 It is also important to have a "Deadman's switch" so that 403 delegated applications will not continue indefinitely if their 404 "sponsor" has forgotten about them. 406 5.6. Scheduling 408 The Scheduling Service allows the execution of distributed 409 management applications to be controlled so that they run at a 410 particular time, periodically, or based on the occurance of 411 another event. 413 5.7. Reliable Notification 415 The Reliable Notification Service provides services that 416 ensure that notifications are received correctly. 418 For example, all the information that describes an event may 419 not fit within a single PDU, so an eventID varbind is defined 420 that associates multiple PDU's as describing the same event. 421 It is also necessary to know if the entire notification has 422 been received or if more PDU's are still outstanding. 424 Further, a receiving management station must be given more 425 information so that it can distinguish duplicated inform PDU's 426 because events are not idempotent. No rule makes it mandatory 427 for the requestID to be unique for all PDUs sent from a 428 system. 430 In addition, a logging mechanism provides for retrieval of 431 notifications after a communications failure. 433 5.8. Notification Destinations 435 The Notification Destination Service provides services for 436 configuring destinations for notifications. 438 When management functions are delegated and MLMs are given the 439 autonomy to generate notifications, they need to be configured 440 as to where the notifications should be sent. Additionally, 441 retry counts and numbers need to be configured. Average and 442 burst notification rates need to be defined. 444 6. Acknowledgments 446 This document was produced by the IETF Distributed Network 447 Management Working Group. 449 7. References 451 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An 452 Architecture for Describing SNMP Management Frameworks", 453 RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., 454 IBM T. J. Watson Research, January 1998 456 [2] Rose, M., and K. McCloghrie, "Structure and 457 Identification of Management Information for TCP/IP-based 458 Internets", RFC 1155, Performance Systems International, 459 Hughes LAN Systems, May 1990 461 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 462 RFC 1212, Performance Systems International, Hughes LAN 463 Systems, March 1991 465 [4] M. Rose, "A Convention for Defining Traps for use with 466 the SNMP", RFC 1215, Performance Systems International, 467 March 1991 469 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 470 "Structure of Management Information for Version 2 of the 471 Simple Network Management Protocol (SNMPv2)", RFC 1902, 472 SNMP Research,Inc., Cisco Systems, Inc., Dover Beach 473 Consulting, Inc., International Network Services, January 474 1996. 476 [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 477 "Textual Conventions for Version 2 of the Simple Network 478 Management Protocol (SNMPv2)", RFC 1903, SNMP Research, 479 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 480 International Network Services, January 1996. 482 [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 483 "Conformance Statements for Version 2 of the Simple 484 Network Management Protocol (SNMPv2)", RFC 1904, SNMP 485 Research, Inc., Cisco Systems, Inc., Dover Beach 486 Consulting, Inc., International Network Services, January 487 1996. 489 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 490 "Simple Network Management Protocol", RFC 1157, SNMP 491 Research, Performance Systems International, Performance 492 Systems International, MIT Laboratory for Computer 493 Science, May 1990. 495 [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 496 "Introduction to Community-based SNMPv2", RFC 1901, SNMP 497 Research, Inc., Cisco Systems, Inc., Dover Beach 498 Consulting, Inc., International Network Services, January 499 1996. 501 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 502 "Transport Mappings for Version 2 of the Simple Network 503 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, 504 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 505 International Network Services, January 1996. 507 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, 508 "Message Processing and Dispatching for the Simple 509 Network Management Protocol (SNMP)", RFC 2272, SNMP 510 Research, Inc., Cabletron Systems, Inc., BMC Software, 511 Inc., IBM T. J. Watson Research, January 1998. 513 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model 514 (USM) for version 3 of the Simple Network Management 515 Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, 516 January 1998. 518 [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 519 "Protocol Operations for Version 2 of the Simple Network 520 Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 521 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 522 International Network Services, January 1996. 524 [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 525 Applications", RFC 2273, SNMP Research, Inc., Secure 526 Computing Corporation, Cisco Systems, January 1998 528 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 529 Access Control Model (VACM) for the Simple Network 530 Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson 531 Research, BMC Software, Inc., Cisco Systems, Inc., 532 January 1998 534 Table of Contents 536 1 Status of this Memo ................................... 1 537 2 Abstract .............................................. 2 538 3 Overview .............................................. 3 539 4 Relationship to the SNMP Management Framework ......... 4 540 4.1 The SNMP Management Framework ....................... 4 541 5 Distributed Management Framework ...................... 6 542 5.1 Known Systems ....................................... 6 543 5.2 Management Domains .................................. 7 544 5.3 Management Operations Targets ....................... 7 545 5.4 Credential Delegation ............................... 8 546 5.4.1 Definitions ....................................... 9 547 5.5 Delegation Control .................................. 10 548 5.6 Scheduling .......................................... 11 549 5.7 Reliable Notification ............................... 11 550 5.8 Notification Destinations ........................... 11 551 6 Acknowledgments ....................................... 11 552 7 References ............................................ 12