idnits 2.17.1 draft-presuhn-nmwebdav-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 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 339: '...tion, the practice is NOT RECOMMENDED....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (30 December 2002) is 7786 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SnmpConf' is mentioned on line 89, but not defined == Missing Reference: 'XmlCim' is mentioned on line 258, but not defined == Missing Reference: 'RFC3165' is mentioned on line 353, but not defined == Unused Reference: 'RFC1157' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 415, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-webdav-ordering-protocol-03 ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) == Outdated reference: A later version (-13) exists of draft-ietf-webdav-acl-09 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Presuhn 3 Internet Draft BMC Software, Inc. 4 Expires: May 30 December 2002 6 Applying WebDAV (Web Distributed Authoring and Versioning) 7 to Network Configuration Management Problems 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Copyright Notice 31 Copyright (C) The Internet Society (2002). All Rights Reserved. 33 Abstract 35 This memo examines the potential of using WWW Distributed Authoring 36 and Versioning (WebDAV) technologies to address the problems of 37 network configuration management. It reviews requirements and issues 38 that have been identified in IETF network configuration management 39 and operator requirements discussions, matching these requirements 40 and issues with various WebDAV facilities. It concludes by 41 identifying areas for further exploration. 43 Comments are welcomed, both from the Operations and Management Area 44 in general, and from participants in the webdav and deltav working 45 groups in particular. Please send comments to the author at 46 randy_presuhn@bmc.com. 48 Table of Contents 50 1. Introduction ................................................ 3 51 2. Problem Decomposition ....................................... 3 52 3. Proposed Solution ........................................... 4 53 3.1. More Sophisticated Uses ................................... 6 54 3.2. IANA Considerations ....................................... 6 55 4. Requirements Satisfied ...................................... 6 56 5. Requirements Not Addressed .................................. 6 57 6. Open Issues ................................................. 7 58 7. Notice on Intellectual Property ............................. 7 59 8. Security Considerations ..................................... 8 60 8.1. Security of Stored Configurations ......................... 8 61 8.2. Security Configuration as Configuration Data .............. 8 62 8.3. Security Consequences of Applying Configurations .......... 8 63 8.3.1. Keys to the Kingdom ..................................... 8 64 8.3.2. Unwanted Reincarnation .................................. 8 65 8.3.3. The Dark Side of Implicit Delegation .................... 9 66 8.4. Policy Coherency .......................................... 9 67 8.4.1. Referential Integrity, or the Lack Thereof .............. 9 68 8.4.2. What About VACM? ....................................... 9 69 9. References .................................................. 10 70 9.1. Informative References .................................... 10 71 9.2. Normative References ...................................... 11 72 10. Author's Address ........................................... 11 73 11. Full Copyright Statement ................................... 11 75 1. Introduction 77 Since the appearance of [OpsReq], there has been considerable debate 78 in the Operations and Management Area about how to address these 79 operator requirements, particularly for the configuration of network 80 equipment. 82 Although [SnmpConf] work does a good job of describing current 83 practices, there is clearly a significant disconnect between this 84 work, the requirements in [OpsReq], and the current state of the art 85 of configuration management in other domains, such as software 86 engineering or technical publications. 88 This document does not attempt to solve all the interesting problems 89 described in [OpsReq] and [SnmpConf]. It focuses on the "distributed 90 database" aspects of the problem, and shows how existing IETF 91 specifications can be used to address this problem. 93 2. Problem Decomposition 95 Previous discussions of network configuration management have been 96 bedeviled by issues of common data models, representation of 97 configuration information, storage, distribution, policy logic, 98 command line interfaces, and so on. Although such things are nice to 99 wish for, we cannot insist that they will all become available at the 100 same time on all equipment across the entire Internet. Indeed, by 101 de-coupling some of these concerns we can arrive at an approach which 102 provides for a simpler, more flexible architecture and allows 103 smoother transition and coexistance. 105 Some (heretical) observations: 107 - managing a network's configuration does not require a 108 common data model; 110 - managing a network's configuration does not require a 111 common representation format for object configuration 112 parameters; 114 - managing a network's configuration does not require 115 agreement on a single protocol for movement of 116 configuration data. 118 These things might be nice to have, and are probably good goals to 119 have, but a network configuration management solution shouldn't 120 depend on them. 122 To make these heresies a bit more plausible, let's look at what 123 network configuration management does require: 125 - the ability to store configuration information, in whatever 126 format the device or its element management system needs; 128 - The ability to identify (version) specific sets of 129 configuration data at various levels of granularity, from 130 an entire network to a single interface; 132 - The ability to preserve past configurations, and to store 133 configurations which have not yet been applied 134 (provisioning); 136 - The ability to retrieve a stored configuration, so that the 137 device or its element management system can apply that 138 configuration to a device or its drop-in replacement. 140 Although it would be really nice to have common information models 141 and representation of configuration parameters, the minimal 142 requirement is only for a device (or its drop-in replacement) to be 143 able to accept playback (possibly under control of an element 144 management system) of something that was probably retrieved from that 145 device in the first place. 147 Throughout all this, it's important to maintain the distinction 148 between "desired configuration" and "actual configuration". As we'll 149 see below, there are many factors that can prevent the actual 150 configuration from exactly matching the desired one, and factors that 151 can prevent determining just what the actual configuration is so that 152 it might be saved. 154 In discussions of these problems, there's been talk of the need for 155 some kind of "distributed database" to handle this job. Today, 156 common practice is to use tools like CVS to handle storage of 157 critical configuration information. Although these are a great help, 158 they require a fair amount of ad hoc "glue" between them and the 159 systems being managed. Some propose LDAP, layering versioning 160 information through the schema. 162 3. Proposed Solution 164 This proposal is to employ WebDAV [RFC2518] [RFC3253] [ColProt] 165 [WebAcl]. One of the most interesting properties about this approach 166 is the number of things it permits, but does not require, 167 consequently supporting smooth evolution and coexistance. 168 Specifically: 170 - A coherent naming architecture. If a standard approach to 171 naming configuration information is ever developed, it can 172 be supported. If not, and naming is done on an ad hoc 173 basis, it still works. 175 - A common data model. Because bits and pieces of 176 configuration data are simply documents or collections, the 177 data model can be very rich and structured or completely 178 flat or total chaos. If a common data model is adopted, it 179 can be deployed without adversely impacting installed base 180 or stored configurations. 182 - A common representation for configuration parameters. 183 Because document contents are opaque to the configuration 184 management system, the lack of a common data representation 185 doesn't stop us. As one becomes available, it can be 186 deployed without any adverse impact on legacy systems or 187 the need to translate old configurations. If we go the 188 path of using XML, the use of a web-based technology is 189 particularly attractive. 191 - A common data transport mechanism. Though the WebDAV 192 protocol itself is an HTTP extension, the documents (which 193 are the interesting bits of configuration parameters) can 194 be accessed by any number of other protocols. 196 - Use of mid-level or element management systems. The use of 197 WebDav can support saving and retrieval of versioned 198 configuration by managed systems, element management 199 systems, applications, or users, giving great flexibility 200 in the degree of automation that one can choose to apply to 201 any given task. 203 There are also a lot of other intriguing possibilities opened up by 204 this approach. For example, the use of collections permits 205 structuring of configurations, as well as talking about abstractions 206 like connections. One could use a collection to support coordinated 207 manipulation of the two interfaces attached to the ends of a single 208 link. It even allows us to think about inter-domain coordination of 209 configuration parameters. 211 3.1. More Sophisticated Uses 213 A more sophisticated approach is possible. One could generate XML 214 documents to describe configuration information, and XSLTs to 215 generate the vendor- or device-specific configuration directives. If 216 agreement on the generic information requirements could be reached, 217 vendors would be able to provide their own XSLTs to generate 218 configuration sequences for thier products. WebDav would be 219 appropriate for handling the the high-level configuration data base, 220 the generated XML documents, the XSLTs, and the directives generated 221 for the specific devices. 223 3.2. IANA Considerations 225 If we pursue this path, we might want to define some standard 226 representations for configuration parameters retrieved from SNMP 227 MIBs, and register a document type for it. 229 4. Requirements Satisfied 231 Key advantages of this proposal are: 233 - provides versioning; 235 - provides rollback; 237 - supports access control; 239 - supports provisioning; 241 - maintains strict distinction between "what it is now" and 242 "what it's supposed to be now"; 244 - able to represent configurations spanning multiple managed 245 systems; 247 - supports composition of configurations from arbitrary 248 hierarchies of component configurations; 250 And, perhaps most importantly, all without requiring new protocols, 251 or information models. 253 5. Requirements Not Addressed 255 This proposal deliberately sidesteps the question of how the lowest- 256 level bits and pieces of configuration data are represented. This 257 does not preclude the eventual development or adoption of a specific 258 representation, whether it be [XmlCim] or standardized CLI. It does, 259 however, recognize the reality that no matter how quickly such a 260 standardized representation might be adopted, there will be a fairly 261 length period during which multiple representation formats need to 262 coexist. One of the advantages of this proposal is that it can 263 operate effectively without requiring any knowledge of the internal 264 syntax of a chunk of configuration data. 266 This proposal also deliberately sidesteps the question of the 267 protocol used to deliver a configuration to the managed resource. 268 This does not preclude eventual agreement on which protocol[s] should 269 be used for this purpose. It does, however, recognize the reality 270 that multiple protocols are already in use for the transfer of such 271 information, and will continue to be in use for some time. One of 272 the advantages of this proposal derives from the ability of URLs to 273 identify the protocol to be used. 275 6. Open Issues 277 There are lots of interesting security issues (see below), but these 278 same issues will arise in any attempt to solve these problems. 280 7. Notice on Intellectual Property 282 The IETF takes no position regarding the validity or scope of any 283 intellectual property or other rights that might be claimed to 284 pertain to the implementation or use of the technology described in 285 this document or the extent to which any license under such rights 286 might or might not be available; neither does it represent that it 287 has made any effort to identify any such rights. Information on the 288 IETF's procedures with respect to rights in standards-track and 289 standards-related documentation can be found in BCP-11. Copies of 290 claims of rights made available for publication and any assurances of 291 licenses to be made available, or the result of an attempt made to 292 obtain a general license or permission for the use of such 293 proprietary rights by implementors or users of this specification can 294 be obtained from the IETF Secretariat. 296 The IETF invites any interested party to bring to its attention any 297 copyrights, patents or patent applications, or other proprietary 298 rights which may cover technology that may be required to practice 299 this standard. Please address the information to the IETF Executive 300 Director. 302 8. Security Considerations 304 Needless to say, there are lots of security considerations here. 305 First, it's obviously necessary to be able to secure stored 306 configurations. Secondly, we must not lose sight of the fact that at 307 least portions of the security configuration itself need to be 308 stored. The third area of concern has to do with the security 309 consequences of applying a given configuration. Finally, the fact 310 that we're dealing with distributed data conveyed by multiple 311 protocols begs the operationally vexing question of keeping multiple 312 security policies reasonably coherent. 314 8.1. Security of Stored Configurations 316 The security of stored configurations would be the responsibility of 317 [WebAcl] in this proposal, just as the security of the device's 318 actual configuration is subject to the use of the View-Based Access 319 Control Model (VACM) [RFC3415] in the SNMP world. 321 8.2. Security Configuration as Configuration Data 323 It is desirable in some respects to be able to treat the security 324 configuration of a managed device (e.g., the User-Based Security 325 Model (USM) [RFC3414] and VACM configurations) just like any other 326 configuration. For example, one would like to be able to provision 327 new users in advance of actually deploying the configuration. 329 8.3. Security Consequences of Applying Configurations 331 Unfortunately, applying a particular configuration to a system or set 332 of systems can have serious (un)intended security implications. 334 8.3.1. Keys to the Kingdom 336 The question of whether keying material should be considered part of 337 a system's configuration needs further thought. Though this proposal 338 can support the storage of keying material as part of a 339 configuration, the practice is NOT RECOMMENDED. 341 8.3.2. Unwanted Reincarnation 343 If security configuration is treated as part of the overall system or 344 network configuration, rollback can have the undesirable side-effect 345 of resurrecting deactivated users or revoked permissions. 347 8.3.3. The Dark Side of Implicit Delegation 349 Unlike the previous two categories, which will be rather obvious to 350 anyone familiar with USM and VACM, there is a subtler family of 351 problems arising in MIBs that assume knowledge of who "pushed the 352 button" to create or activate a particular row in a control table. 353 Examples include [RFC3014], [RFC3165], and [RFC3231]. This means 354 that faithfully saving or restoring such a configuration requires 355 more information than is explicitly represented in the MIB. Other 356 approaches, such as explicitly representing all credentials needed to 357 perform delegation, might circumvent this problem, but would bring 358 their own complications. 360 8.4. Policy Coherency 362 There are three major sources of policy coherency concerns that need 363 to be worked through. The first source iof concern comes from the 364 referential integrity problems resulting from the mutability of SNMP 365 indexes with respect to an underlying logical configuration. The 366 second arises from the fact that the different protocols used for 367 moving the information between systems differ in how their security 368 is managed. Finally, the access control models for the various 369 storage mechanisms differ from each other and from VACM. 371 8.4.1. Referential Integrity, or the Lack Thereof 373 A family of problems that has surfaced in several MIBs arises from 374 the need to ensure that the references (e.g., RowPointers and 375 indexes) to persistent data remain consistent across reboots. An 376 example of where things become problematic is the use of ifIndex, 377 which is not guaranteed to keep its value across reboots. I 378 addition to keeping direct references consistent, there are also 379 cases where keeping references stable across reboots is a 380 requirement. For example, a VACM access control policy could be 381 subverted if the indexes don't remain the same. 383 When we look to the problem of versioning configurations, this same 384 problem still exists, and is compounded by the fact that sometimes 385 changes to indexes or RowPointers are the essence of the differences 386 between two versions. 388 8.4.2. What About VACM? 390 Ensuring that the VACM policy's references to management information 391 remain consistent is not enough. The relationship of the access 392 control policy, as represented in VACM, to the access control policy 393 for the configuration, as represented in [WebAcl], needs to be 394 thought through. 396 9. References 398 9.1. Informative References 400 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple 401 Network Management Protocol", STD 15, RFC 1157, May 1990. 403 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 404 16, RFC 1212, March 1991. 406 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 407 Rose, M., and S. Waldbusser, "Structure of Management 408 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 409 1999. 411 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 412 Rose, M., and S. Waldbusser, "Textual Conventions for 413 SMIv2", STD 58, RFC 2579, April 1999. 415 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 416 Rose, M., and S. Waldbusser, "Conformance Statements for 417 SMIv2", STD 58, RFC 2580, April 1999. 419 [ColProt] Slein, J. Whitehead, J., Davis, J., Clemm, G., Fay, C., 420 Crawford, J. and J. Reschke, "WebDAV Ordered Collections 421 Protocol", draft-ietf-webdav-ordering-protocol-03.txt, 422 September 2002. 424 [OpsReq] Woodcock, B., "Operator Requirements of Infrastructure 425 Management Methods", draft-ops-operator-req-mgmt-02.txt, 426 February 2002. 428 [SnmpConf]MacFaden, M., Saperia, J. and W. Tackabury, "Configuring 429 Networks and Devices With SNMP", draft-ietf-snmpconf- 430 bcp-10.txt, October 2002. 432 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 433 (USM) for version 3 of the Simple Network Management 434 Protocol (SNMPv3)", STD 64, RFC 3414, December 2002. 436 [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 437 Access Control Model (VACM) for the Simple Network 438 Management Protocol (SNMP)", STD 62, RFC 3415, December 439 2002. 441 [RFC3231] Levi, D. and J. Schoenwaelder, "Definitions of Managed 442 Objects for Scheduling Management Operations", RFC 3231, 443 January 2002. 445 [RFC3231] Levi, D. and J. Schoenwaelder, "Definitions of Managed 446 Objects for Scheduling Management Operations", RFC 3231, 447 January 2002. 449 [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 450 2000. 452 9.2. Normative References 454 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 455 Jensen, "HTTP Extensions for Distributed Authoring -- 456 WEBDAV", RFC 2518, February 1999. 458 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. 459 Whitehead, "Versioning Extensions to WebDAV (Web 460 Distributed Authoring and Versioning)", RFC 3253, March 461 2002. 463 [WebAcl] Clemm, G., Hopkins, A., Sedlar, E. and J Whitehead, "WebDAV 464 Access Control Protocol", draft-ietf-webdav-acl-09.txt, 465 July 2002. 467 10. Author's Address 469 Randy Presuhn 470 BMC Software, Inc. 471 2141 North First Street 472 San Jose, CA 95131 473 USA 475 Phone: +1 408 546 1006 476 EMail: randy_presuhn@bmc.com 478 11. Full Copyright Statement 480 Copyright (C) The Internet Society (2002). All Rights Reserved. 482 This document and translations of it may be copied and furnished to 483 others, and derivative works that comment on or otherwise explain it 484 or assist in its implementation may be prepared, copied, published 485 and distributed, in whole or in part, without restriction of any 486 kind, provided that the above copyright notice and this paragraph are 487 included on all such copies and derivative works. However, this 488 document itself may not be modified in any way, such as by removing 489 the copyright notice or references to the Internet Society or other 490 Internet organizations, except as needed for the purpose of 491 developing Internet standards in which case the procedures for 492 copyrights defined in the Internet Standards process must be 493 followed, or as required to translate it into languages other than 494 English. 496 The limited permissions granted above are perpetual and will not be 497 revoked by the Internet Society or its successors or assigns. 499 This document and the information contained herein is provided on an 500 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 501 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 502 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 503 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 504 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.