Network Working Group R. Presuhn Internet Draft BMC Software, Inc. Expires: May 30 December 2002 Applying WebDAV (Web Distributed Authoring and Versioning) to Network Configuration Management Problems Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo examines the potential of using WWW Distributed Authoring and Versioning (WebDAV) technologies to address the problems of network configuration management. It reviews requirements and issues that have been identified in IETF network configuration management and operator requirements discussions, matching these requirements and issues with various WebDAV facilities. It concludes by identifying areas for further exploration. Comments are welcomed, both from the Operations and Management Area in general, and from participants in the webdav and deltav working groups in particular. Please send comments to the author at randy_presuhn@bmc.com. Presuhn Expires May 2003 [Page 1] Internet Draft WebDAV to Manage Configurations 30 December 2002 Table of Contents 1. Introduction ................................................ 3 2. Problem Decomposition ....................................... 3 3. Proposed Solution ........................................... 4 3.1. More Sophisticated Uses ................................... 6 3.2. IANA Considerations ....................................... 6 4. Requirements Satisfied ...................................... 6 5. Requirements Not Addressed .................................. 6 6. Open Issues ................................................. 7 7. Notice on Intellectual Property ............................. 7 8. Security Considerations ..................................... 8 8.1. Security of Stored Configurations ......................... 8 8.2. Security Configuration as Configuration Data .............. 8 8.3. Security Consequences of Applying Configurations .......... 8 8.3.1. Keys to the Kingdom ..................................... 8 8.3.2. Unwanted Reincarnation .................................. 8 8.3.3. The Dark Side of Implicit Delegation .................... 9 8.4. Policy Coherency .......................................... 9 8.4.1. Referential Integrity, or the Lack Thereof .............. 9 8.4.2. What About VACM? ....................................... 9 9. References .................................................. 10 9.1. Informative References .................................... 10 9.2. Normative References ...................................... 11 10. Author's Address ........................................... 11 11. Full Copyright Statement ................................... 11 Presuhn Expires May 2003 [Page 2] Internet Draft WebDAV to Manage Configurations 30 December 2002 1. Introduction Since the appearance of [OpsReq], there has been considerable debate in the Operations and Management Area about how to address these operator requirements, particularly for the configuration of network equipment. Although [SnmpConf] work does a good job of describing current practices, there is clearly a significant disconnect between this work, the requirements in [OpsReq], and the current state of the art of configuration management in other domains, such as software engineering or technical publications. This document does not attempt to solve all the interesting problems described in [OpsReq] and [SnmpConf]. It focuses on the "distributed database" aspects of the problem, and shows how existing IETF specifications can be used to address this problem. 2. Problem Decomposition Previous discussions of network configuration management have been bedeviled by issues of common data models, representation of configuration information, storage, distribution, policy logic, command line interfaces, and so on. Although such things are nice to wish for, we cannot insist that they will all become available at the same time on all equipment across the entire Internet. Indeed, by de-coupling some of these concerns we can arrive at an approach which provides for a simpler, more flexible architecture and allows smoother transition and coexistance. Some (heretical) observations: - managing a network's configuration does not require a common data model; - managing a network's configuration does not require a common representation format for object configuration parameters; - managing a network's configuration does not require agreement on a single protocol for movement of configuration data. These things might be nice to have, and are probably good goals to have, but a network configuration management solution shouldn't depend on them. Presuhn Expires May 2003 [Page 3] Internet Draft WebDAV to Manage Configurations 30 December 2002 To make these heresies a bit more plausible, let's look at what network configuration management does require: - the ability to store configuration information, in whatever format the device or its element management system needs; - The ability to identify (version) specific sets of configuration data at various levels of granularity, from an entire network to a single interface; - The ability to preserve past configurations, and to store configurations which have not yet been applied (provisioning); - The ability to retrieve a stored configuration, so that the device or its element management system can apply that configuration to a device or its drop-in replacement. Although it would be really nice to have common information models and representation of configuration parameters, the minimal requirement is only for a device (or its drop-in replacement) to be able to accept playback (possibly under control of an element management system) of something that was probably retrieved from that device in the first place. Throughout all this, it's important to maintain the distinction between "desired configuration" and "actual configuration". As we'll see below, there are many factors that can prevent the actual configuration from exactly matching the desired one, and factors that can prevent determining just what the actual configuration is so that it might be saved. In discussions of these problems, there's been talk of the need for some kind of "distributed database" to handle this job. Today, common practice is to use tools like CVS to handle storage of critical configuration information. Although these are a great help, they require a fair amount of ad hoc "glue" between them and the systems being managed. Some propose LDAP, layering versioning information through the schema. 3. Proposed Solution This proposal is to employ WebDAV [RFC2518] [RFC3253] [ColProt] [WebAcl]. One of the most interesting properties about this approach Presuhn Expires May 2003 [Page 4] Internet Draft WebDAV to Manage Configurations 30 December 2002 is the number of things it permits, but does not require, consequently supporting smooth evolution and coexistance. Specifically: - A coherent naming architecture. If a standard approach to naming configuration information is ever developed, it can be supported. If not, and naming is done on an ad hoc basis, it still works. - A common data model. Because bits and pieces of configuration data are simply documents or collections, the data model can be very rich and structured or completely flat or total chaos. If a common data model is adopted, it can be deployed without adversely impacting installed base or stored configurations. - A common representation for configuration parameters. Because document contents are opaque to the configuration management system, the lack of a common data representation doesn't stop us. As one becomes available, it can be deployed without any adverse impact on legacy systems or the need to translate old configurations. If we go the path of using XML, the use of a web-based technology is particularly attractive. - A common data transport mechanism. Though the WebDAV protocol itself is an HTTP extension, the documents (which are the interesting bits of configuration parameters) can be accessed by any number of other protocols. - Use of mid-level or element management systems. The use of WebDav can support saving and retrieval of versioned configuration by managed systems, element management systems, applications, or users, giving great flexibility in the degree of automation that one can choose to apply to any given task. There are also a lot of other intriguing possibilities opened up by this approach. For example, the use of collections permits structuring of configurations, as well as talking about abstractions like connections. One could use a collection to support coordinated manipulation of the two interfaces attached to the ends of a single link. It even allows us to think about inter-domain coordination of configuration parameters. Presuhn Expires May 2003 [Page 5] Internet Draft WebDAV to Manage Configurations 30 December 2002 3.1. More Sophisticated Uses A more sophisticated approach is possible. One could generate XML documents to describe configuration information, and XSLTs to generate the vendor- or device-specific configuration directives. If agreement on the generic information requirements could be reached, vendors would be able to provide their own XSLTs to generate configuration sequences for thier products. WebDav would be appropriate for handling the the high-level configuration data base, the generated XML documents, the XSLTs, and the directives generated for the specific devices. 3.2. IANA Considerations If we pursue this path, we might want to define some standard representations for configuration parameters retrieved from SNMP MIBs, and register a document type for it. 4. Requirements Satisfied Key advantages of this proposal are: - provides versioning; - provides rollback; - supports access control; - supports provisioning; - maintains strict distinction between "what it is now" and "what it's supposed to be now"; - able to represent configurations spanning multiple managed systems; - supports composition of configurations from arbitrary hierarchies of component configurations; And, perhaps most importantly, all without requiring new protocols, or information models. 5. Requirements Not Addressed This proposal deliberately sidesteps the question of how the lowest- Presuhn Expires May 2003 [Page 6] Internet Draft WebDAV to Manage Configurations 30 December 2002 level bits and pieces of configuration data are represented. This does not preclude the eventual development or adoption of a specific representation, whether it be [XmlCim] or standardized CLI. It does, however, recognize the reality that no matter how quickly such a standardized representation might be adopted, there will be a fairly length period during which multiple representation formats need to coexist. One of the advantages of this proposal is that it can operate effectively without requiring any knowledge of the internal syntax of a chunk of configuration data. This proposal also deliberately sidesteps the question of the protocol used to deliver a configuration to the managed resource. This does not preclude eventual agreement on which protocol[s] should be used for this purpose. It does, however, recognize the reality that multiple protocols are already in use for the transfer of such information, and will continue to be in use for some time. One of the advantages of this proposal derives from the ability of URLs to identify the protocol to be used. 6. Open Issues There are lots of interesting security issues (see below), but these same issues will arise in any attempt to solve these problems. 7. Notice on Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Presuhn Expires May 2003 [Page 7] Internet Draft WebDAV to Manage Configurations 30 December 2002 8. Security Considerations Needless to say, there are lots of security considerations here. First, it's obviously necessary to be able to secure stored configurations. Secondly, we must not lose sight of the fact that at least portions of the security configuration itself need to be stored. The third area of concern has to do with the security consequences of applying a given configuration. Finally, the fact that we're dealing with distributed data conveyed by multiple protocols begs the operationally vexing question of keeping multiple security policies reasonably coherent. 8.1. Security of Stored Configurations The security of stored configurations would be the responsibility of [WebAcl] in this proposal, just as the security of the device's actual configuration is subject to the use of the View-Based Access Control Model (VACM) [RFC3415] in the SNMP world. 8.2. Security Configuration as Configuration Data It is desirable in some respects to be able to treat the security configuration of a managed device (e.g., the User-Based Security Model (USM) [RFC3414] and VACM configurations) just like any other configuration. For example, one would like to be able to provision new users in advance of actually deploying the configuration. 8.3. Security Consequences of Applying Configurations Unfortunately, applying a particular configuration to a system or set of systems can have serious (un)intended security implications. 8.3.1. Keys to the Kingdom The question of whether keying material should be considered part of a system's configuration needs further thought. Though this proposal can support the storage of keying material as part of a configuration, the practice is NOT RECOMMENDED. 8.3.2. Unwanted Reincarnation If security configuration is treated as part of the overall system or network configuration, rollback can have the undesirable side-effect Presuhn Expires May 2003 [Page 8] Internet Draft WebDAV to Manage Configurations 30 December 2002 of resurrecting deactivated users or revoked permissions. 8.3.3. The Dark Side of Implicit Delegation Unlike the previous two categories, which will be rather obvious to anyone familiar with USM and VACM, there is a subtler family of problems arising in MIBs that assume knowledge of who "pushed the button" to create or activate a particular row in a control table. Examples include [RFC3014], [RFC3165], and [RFC3231]. This means that faithfully saving or restoring such a configuration requires more information than is explicitly represented in the MIB. Other approaches, such as explicitly representing all credentials needed to perform delegation, might circumvent this problem, but would bring their own complications. 8.4. Policy Coherency There are three major sources of policy coherency concerns that need to be worked through. The first source iof concern comes from the referential integrity problems resulting from the mutability of SNMP indexes with respect to an underlying logical configuration. The second arises from the fact that the different protocols used for moving the information between systems differ in how their security is managed. Finally, the access control models for the various storage mechanisms differ from each other and from VACM. 8.4.1. Referential Integrity, or the Lack Thereof A family of problems that has surfaced in several MIBs arises from the need to ensure that the references (e.g., RowPointers and indexes) to persistent data remain consistent across reboots. An example of where things become problematic is the use of ifIndex, which is not guaranteed to keep its value across reboots. I addition to keeping direct references consistent, there are also cases where keeping references stable across reboots is a requirement. For example, a VACM access control policy could be subverted if the indexes don't remain the same. When we look to the problem of versioning configurations, this same problem still exists, and is compounded by the fact that sometimes changes to indexes or RowPointers are the essence of the differences between two versions. 8.4.2. What About VACM? Ensuring that the VACM policy's references to management information Presuhn Expires May 2003 [Page 9] Internet Draft WebDAV to Manage Configurations 30 December 2002 remain consistent is not enough. The relationship of the access control policy, as represented in VACM, to the access control policy for the configuration, as represented in [WebAcl], needs to be thought through. 9. References 9.1. Informative References [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [ColProt] Slein, J. Whitehead, J., Davis, J., Clemm, G., Fay, C., Crawford, J. and J. Reschke, "WebDAV Ordered Collections Protocol", draft-ietf-webdav-ordering-protocol-03.txt, September 2002. [OpsReq] Woodcock, B., "Operator Requirements of Infrastructure Management Methods", draft-ops-operator-req-mgmt-02.txt, February 2002. [SnmpConf]MacFaden, M., Saperia, J. and W. Tackabury, "Configuring Networks and Devices With SNMP", draft-ietf-snmpconf- bcp-10.txt, October 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 64, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December Presuhn Expires May 2003 [Page 10] Internet Draft WebDAV to Manage Configurations 30 December 2002 2002. [RFC3231] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 3231, January 2002. [RFC3231] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 3231, January 2002. [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 2000. 9.2. Normative References [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002. [WebAcl] Clemm, G., Hopkins, A., Sedlar, E. and J Whitehead, "WebDAV Access Control Protocol", draft-ietf-webdav-acl-09.txt, July 2002. 10. Author's Address Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, CA 95131 USA Phone: +1 408 546 1006 EMail: randy_presuhn@bmc.com 11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are Presuhn Expires May 2003 [Page 11] Internet Draft WebDAV to Manage Configurations 30 December 2002 included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Presuhn Expires May 2003 [Page 12]