netconf Working Group M. Boucadair INTERNET-DRAFT C. Jacquenet Document: draft-boucadair-netconf-req-00.txt M. Achemlal Category: Informational Y. Adam Expires January 2005 France Telecom July 2004 Requirements for Efficient and Automated Configuration Management Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Abstract Given the ever-increasing importance of configuration tasks for the provisioning of a wide range of IP resources, networks, and services in today's Internet, this draft aims at listing the basic requirements that should drive the specification of a protocol to convey configuration information towards network devices. This memo doesn't aim at listing candidate protocols to convey such information, nor at choosing one of these. This draft basically describes a whole set of issues a service provider has to deal with, hence a list of requirements to better address such issues. Table of Contents 1. Introduction................................................3 2. Conventions used in this document...........................3 3. Terminology.................................................3 4. Motivations and Goals.......................................5 Boucadair Informational - Expires January 2005 [Page 1] Internet Draft Network Configuration requirements July 2004 5. Positioning this Draft within the NETCONF Working Group.....5 6. Current Issues with Configuration Procedures................6 6.1. Protocol Diversity..........................................6 6.2. Topology Discovery..........................................6 6.3. Device capabilities discovery...............................6 6.4. Impact on the performance...................................7 6.5. Scalability.................................................7 6.6. Automation..................................................7 6.7. Security issues.............................................8 7. Towards a Service-Oriented Configuration Policy.............8 8. Requirements................................................9 8.1. Protocol Requirements.......................................9 8.1.1. Functional Requirements.....................................9 8.1.2. Performance requirements...................................10 8.1.3. Backward Compatibility.....................................10 8.2. Information requirements...................................10 8.2.1. Network services...........................................11 8.2.1.1. Identification of Interfaces.............................11 8.2.1.2. Quality of Service (QoS).................................12 8.2.1.3. Security.................................................12 8.2.1.4. Applications.............................................12 8.2.2. Forwarding services........................................13 8.2.2.1. Routing and Forwarding Configuration Information.........13 8.2.2.2. Traffic Engineering Configuration Information............13 8.2.2.3. Configuration Information for Tunnel Design and Activation...............................................13 8.2.2.4. Tunnel Identification Information........................14 8.2.2.5. Tunneling Protocol Configuration Information.............14 8.2.3. Management services........................................14 8.2.3.1. Fault Management.........................................14 8.2.3.2. Configuration Management.................................14 8.2.3.3. Performance Management...................................15 8.2.3.4. Security Management......................................15 8.2.3.4.1. Device Authentication..................................15 8.2.3.4.2. Integrity of configuration information.................15 8.2.3.4.3. Confidentiality of exchanged data......................15 8.2.3.4.4. Key management.........................................16 8.2.3.4.5. Log of connections.....................................16 8.2.3.4.6. Profiles...............................................16 9. Security Considerations....................................16 10. References.................................................16 11. Acknowledgments............................................17 12. Authors' Addresses.........................................17 Boucadair et al. Informational - Expires January 2005 [Page 2] Internet Draft Network Configuration requirements July 2004 1. Introduction In today's Internet, configuration procedures are achieved by technical personnel who's required an ever-growing level of expertise because of the various technologies and features that need to be used, configured and activated to deploy a wide range of IP service offerings. This level of expertise has become mandatory as each equipment manufacturer has developed its own interfaces and configuration schemes. In addition, as IP services may rely upon the activation of a set of sophisticated yet complex features, the time to adequately provision such services is also increasing. As a consequence, the specification and the use of standardized protocol (for conveying configuration information) and interfaces SHOULD dramatically help in facilitating if not automating the configuration process and the operational production of a wide range of IP services. This draft aims at describing basic requirements for configuration task purposes, from a service provider perspective. This document is structured as follows: - Section 3 introduces some terminology that is used by this document - Section 4 presents the goals and motivations of this draft - Sections 5 position this draft within the current netconf working group initiative. - Section 6 summarizes important issues that are related to configuration tasks in today's IP networks. - Section 7 discusses the importance of introducing a service- oriented configuration scheme. - Section 8 lists configuration information and protocol requirements. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 3. Terminology This section aims at providing a set of basic definitions for the terms that will be used by this document. . Decision point: is an entity that is responsible for generating decisions related to configuration tasks that yield the production of configuration data which needs to be conveyed Boucadair et al. Informational - Expires January 2005 [Page 3] Internet Draft Network Configuration requirements July 2004 towards (and processed by) a participating device. . Endpoint: one of the extremities of a tunnel. . Participating device: any networking equipment that will participate in the establishment, the activation and the maintenance of a given network service. Such devices may include routers and hosts, whatever the configuration procedures and underlying technologies to be used for the deployment of such service. . Subscriber: A subscriber (or a customer) is a legal representative who has the (legal) ability to subscribe to a service offering. . Tunnel activation: the configuration tasks that position a tunnel facility into an activated state, so that it can be used to convey traffic. Obviously, a tunnel must not (and, hopefully, cannot) be activated before it has been established. . Tunnel establishment: all the configuration tasks that lead to the configuration of a tunnel facility. Once the tunnel is established, it needs to be activated in order to be able to convey traffic. . Tunnel maintenance: the period of time during which a tunnel facility remains activated. . Tunnel: a tunnel is a transport facility that is designed to convey' (IP) data traffic between one endpoint and another (point-to-point tunnels), or between one endpoint and several others (point-to-multipoint tunnels). Tunnels can be used for different purposes, e.g.: - Access IP multicast networks over IP clouds that do not support multicast forwarding capabilities, - Access IPv6 networks over IPv4 clouds, - Deploy IP Virtual Private Networks, - Deploy Mobile IP architectures. . User: A user is an entity (a human being or a process, from a general perspective) who has been identified (and possibly authenticated) by a service provider, and who will access this service offering according to his associated rights and duties. . VPN: Virtual Private Network. A collection of switching resources (e.g. routers) and transmission resources that will be used over an IP backbone thanks to the establishment and the activation of tunnels. These tunnels will convey the IP traffic that characterizes the data oriented-communication service of a customer (VPNs that are designed to support intranet-based Boucadair et al. Informational - Expires January 2005 [Page 4] Internet Draft Network Configuration requirements July 2004 applications) or a set of customers (VPNs that are designed to support extranet-based applications). Thus, IP VPN networks are an applicability example of tunnel configuration and management activities. 4. Motivations and Goals Operators and protocol developers have gained experience to implement, deploy and manipulate a large set of protocols and associated information. Some data models have also been defined for network management purposes. Thus, several protocols have been standardized, such as SNMP (Simple Network Management Protocol, RFC 3410([3])), COPS (Common Open Policy Service, RFC 2748([4])), (COPS- PR, RFC 3084([5])). Multiple data models have been defined and used by operators like: CIM (Core information model, [6]), DEN (Directory enabled Network), SMI (Structure of Management Information, [7]), SPPI (Structure of Policy Provisioning Information, [8]), MIB (Management Information Base), PIB (Policy Information Management)à Despite this standardization effort, some operators and standardization bodies address a negative report (RFC3535) about the capacity of existing tools to deal with operator's requirements about network management and configuration operations. The purpose of this document is to clarify what are such requirements from a configuration task perspective. This initiative also aims at gathering any feedback from other service providers or vendors in order to agree on a common yet consolidated set of requirements, which SHOULD dramatically help in facilitating if not automating the configuration process and the operational production of a wide range of IP services. 5. Positioning this Draft within the NETCONF Working Group In mid-2003, the IETF netconf (Network Configuration) working group has been set up. The main objective of netconf is to produce a protocol suitable for network configuration. A proposal to use XML (Extensible Markup Language) for configuration purposes has been adopted. The choice of this technology hasn't been motivated nor discussed by some formal document yet. For instance, neither an analysis of existing configuration-based protocols nor a requirement draft have been published. Therefore, there is no explicit consensus about this technical choice (possibly an implicit consensus between some netconf WG members). Because of the lack of guidance documents (framework and requirement documents) and also of a clear view on the actual requirements, the netconf working group may experience some difficulties to make the Internet community widely adopt its ongoing protocol specification effort. Boucadair et al. Informational - Expires January 2005 [Page 5] Internet Draft Network Configuration requirements July 2004 6. Current Issues with Configuration Procedures This section aims at listing issues that SHOULD be carefully studied when dealing with configuration tasks. The items below SHOULD be taken into account when designing a protocol for configuration purposes. 6.1. Protocol Diversity The production of a whole set of IP yet complex services relies upon the activation of a set of capabilities in the participating devices. Especially, a large set of protocols need to be configured, such as routing protocols, management protocols, security protocols, not to mention capabilities that relate to addressing scheme management, QoS policy enforcement, etc. Such a diversity of features and protocols MAY increase the risk of inconsistencies. Therefore, the configuration information which is forwarded to the whole set of participating devices for producing a given service or a set of services SHOULD be consistent, whatever the number of features/services to be activated/deployed in the network. 6.2. Topology Discovery Network operators SHOULD have means to dynamically discover the topology of their network. This topology information should be as elaborate as possible, including details like: the links that connect network devices, including information about their capacity, such as the total bandwidth, the available bandwidth, the bandwidth that can be reserved, etc. 6.3. Device capabilities discovery As stated above a large number of participating devices are involved in deploying and offering IP-based services. These devices could vary depending on the following: - The manufacturer in charge of designing these devices - The version of operating system of the devices - The supported protocols - Configuration tools - Others As a result, it isn't evident to have homogenous capabilities and means to activate similar functionalities in two participating devices. Therefore, operators SHOULD have means to (1) detect the capabilities, (2) have an exhaustive description and (3) list activated process and functions of a given of participating devices. This COULD be done automatically or in demand. Boucadair et al. Informational - Expires January 2005 [Page 6] Internet Draft Network Configuration requirements July 2004 6.4. Impact on the performance Configuring network devices and IP services is a human task, and occurrences of erroneous configurations are therefore plausible. Such occurrences MAY seriously affect the overall quality of a service, like the access to a service or its global availability. From this perspective, some performance indicators SHOULD be defined and measured to qualify: - The impact of any modification of an operational configuration, in terms of performances, - The time needed to deliver and achieve any elementary configuration task. Simulation tools can also be useful to qualify any possible impact of an elementary configuration task before such task is performed. 6.5. Scalability As far as scalability is concerned, adequate indicators SHOULD be specified in order to qualify the ability of a given technical means to support a large number of configuration processes. The maintenance of these processes SHOULD not impact the performance of a given system (a system is a set of elements that compose the key fundamentals of an architecture that aims at delivering configuration data). Therefore, configuration operations SHOULD be qualified with performance indicators in order to check whether the architecture designed for configuration management is scalable in terms of: - Volume of configuration data to be processed per unit of time and according to the number of capabilities and devices that need to be configured, - Volume of information generated by any reporting mechanism that may be associated to a configuration process, - Number of processes that are created in order to achieve specific configuration operations, 6.6. Automation The efficiency of a configuration process SHOULD be enhanced by the introduction of the highest level of automation when performing configuration tasks. Automation is defined as follows: Boucadair et al. Informational - Expires January 2005 [Page 7] Internet Draft Network Configuration requirements July 2004 - Automatic provisioning of configuration information to the participating devices, - Dynamic enforcement of configuration policies, - Dynamic reporting mechanisms to notify about the actual processing of configuration information by a participating device. 6.7. Security issues Configuring a network or a service raises several security issues that need to be addressed, such as: - The integrity of the configuration information, possibly yielding the preservation of the confidentiality of such information when being conveyed over a public IP infrastructure, - The need for authorizing and authenticating devices/entities that have the ability of manipulating configuration information (define, instantiate, forward and process). - Mutual authentication between a decision point and a device that will receive configuration data In addition, additional configuration data SHOULD NOT yield additional security lacks. 7. Towards a Service-Oriented Configuration Policy Current configuration practice basically focuses on elementary functions, i.e. configuration management for a given service offering is decomposed in a set of elementary tasks. Thus, the consistency of configuration operations for producing IP services MUST be checked by any means appropriate, while current. Configuration methods can, at best, only check if provisioning decisions are correctly enforced by a single device. A network device SHOULD be seen as a means to deploy a service and not just as a component of such service. Thus, service configuration and production techniques SHOULD NOT focus on a set of devices taken one-by-one, but on the service itself, which will rely upon a set of features that need to be configured and activated in various regions of the network that supports such service. Service providers could dedicate centralized entities that will be responsible for the provisioning and the management of participating devices. The main function of these centralized entities is to make appropriate decisions and generate convenient configuration data that will be delivered to the participating devices. In addition, these Boucadair et al. Informational - Expires January 2005 [Page 8] Internet Draft Network Configuration requirements July 2004 centralized entities will make sure of the consistency of the decisions that have been taken to produce the service, as per a dynamic configuration policy enforcement scheme. Service-oriented configuration SHOULD rely upon the following requirements: - The data models MUST be service-oriented; - The configuration protocol(s) SHOULD at large extent possible reuse existing data and information models; - The configuration protocol(s) SHOULD be open for further enhancement and adding new functionalities that could reveal in the future as a must; - The configuration protocol(s) SHOULD provide means to validate the consistence and the validation of service configuration 8. Requirements 8.1. Protocol Requirements Configuration information SHOULD be provided to the participating devices by means of a communication protocol that would be used between the aforementioned participating devices and a presumably centralized entity that would aim at storing, maintaining and updating this configuration information as appropriate, as well as making adequate decisions at the right time and under various conditions. 8.1.1. Functional Requirements The vendor-independent communication protocol for conveying configuration information SHOULD have the following characteristics: 1. The protocol SHOULD use a reliable transport mode, and independent from the network layer (i.e. IPv4/IPv6), 2. The protocol architecture SHOULD provide a means for dynamically provision the configuration information to the participating devices, so that it may introduce a high level of automation in the actual negotiation and invocation of a a whole range of IP service offerings. 3. The protocol SHOULD provide the relevant means (encoding capabilities, operations and command primitives, extension capabilities that SHOULD allow additional operations, etc.) to be able to reliably convey any kind of configuration information, 4. The protocol SHOULD be a privileged vector for the dynamic provisioning of any kind of configuration data, as well as the dynamic enforcement of any kind of policy such as a routing Boucadair et al. Informational - Expires January 2005 [Page 9] Internet Draft Network Configuration requirements July 2004 policy, a QoS policy and/or a security policy. This requirement MAY yield the definition and the support of vendor-independent instantiation procedures that will aim at uniquely identifying the configuration data model and/or the policy enforcement scheme that refer to a given IP service offering. 5. The protocol SHOULD support a reporting mechanism that may be used for statistical information retrieval, 6. The protocol SHOULD support the appropriate security mechanisms to provide guarantees as far as the preservation of the confidentiality of the configuration information is concerned. 7. The protocol SHOULD support a notification mechanism that may be used to initiate configuration-related tasks (i.e. inform that a link drop down) 8.1.2. Performance requirements The protocol architecture for conveying configuration information within a network SHOULD be designed so that: 1. The activation of the protocol by the participating devices SHOULD not affect the overall switching performances of such devices, whatever the volume of configuration data these devices will have to process on a given period of time, 2. The activation of the protocol SHOULD NOT dramatically affect the global resources of the network infrastructure that will convey the protocol-specific traffic, whatever the volume of such traffic and whatever the scope (set of IP service offerings the configuration data refer to, set of policies to dynamically enforced, etc.) covered by such traffic. 8.1.3. Backward Compatibility The introduction and the activation of a protocol for conveying configuration data SHOULD allow for smooth migration procedures, so that vendor-specific and vendor-independent configuration procedures and management MAY gracefully co-exist on a (hopefully) limited period of time. Also, in case of any kind of protocol failure, it MUST be possible to rely upon any vendor-specific configuration procedure to keep on performing configuration tasks without any risk of disruption that may affect the availability of a (set of) service offerings, and/or the access to network resources. 8.2. Information requirements Boucadair et al. Informational - Expires January 2005 [Page 10] Internet Draft Network Configuration requirements July 2004 The increase of network service offerings, of the protocol amount to be implemented by equipment as well as the diversity of vendors made the configuration tasks being critical. These tasks are commonly achieved with vendor-specific solutions that deal with device-related information. Moreover the configuration information may be spread across different repositories through the network. It then becomes more and more difficult for the service provider to get a unified (and obviously confident) view of its network in term on æoffered servicesÆ rather than a ænetwork device jigsawÆ. Configuration information SHOULD therefore be provided to the participating devices as unified service parameters being independent from the aforementioned devices vendors. These parameters MUST relate to a standardized service model rather than device-specific as it used to be. Examples of the so-called service model may be tunneling service, internal routing service, VPN service. Their definition is outside the scope of this draft. Current service providers' concerns focus on the unification of accesses to heterogeneous devices (those that are part of a multi- vendor environment) and introduce a high level of automation when achieving configuration of this infrastructure. This unification depends on two major issues, the definition of a protocol (the container) and the definition of data models (the content). Standardizing these two points bring new opportunities: - Equipment are seen as functional blocks providing a set of standardized capabilities; - These functional blocks are described as vendor-independent capabilities; - These functional blocks are all managed homogeneously, whatever the underlying technology; As a result, it would be possible to add semantic rules to automate detection and correction of false configurations, either at the scale of a single device or at the scale of a whole network. Furthermore, an equipment from vendor X could de replaced by another device from vendor Y with no impact on the configuration management. To do so, the data models SHOULD satisfy the requirements described below. 8.2.1. Network services 8.2.1.1. Identification of Interfaces Configuration information that relates to identification deals with the namespace of the interfaces of a network equipment. This naming scheme describes the properties of an interface, and must take into Boucadair et al. Informational - Expires January 2005 [Page 11] Internet Draft Network Configuration requirements July 2004 account all the parameters that are required to correctly configure an interface. The following information MUST be provided: A name, with a generic syntax not related to a specific vendor. The name can define the media type of the interface; Depending on the media type, further information MAY be added (link mode, MTU, speed...); - Optionally, a logical descriptor. Depending on the media type it can be relevant to have a logical descriptor (for VLANs declared on Ethernet interfaces, for instance). In this case the encapsulation type must be provided; - Optionally, a description field giving general information about the interface (i.e. ôOC192 link from LA to SFö) 8.2.1.2. Quality of Service (QoS) IP services are provided with a level of quality that MAY be guaranteed (either qualitatively or quantitatively) by any means appropriate. QoS policies SHOULD be dynamically enforced according to a data model that will accurately reflect all the elementary QoS capabilities that MAY be configured and activated to enforce such policies. For instance, in the case of the activation of the DiffServ QoS model within a network infrastructure, the participating routers should be provided with the appropriate parameters. 8.2.1.3. Security The protocol architecture MUST provide security functions that provide source authentication, integrity and confidentiality of configuration information. The security functions MUST be activated, whatever the contents of the payload. In order to protect device accesses, the configuration architecture MUST provide a filtering / fire-walling access scheme that would allow to control remote and in-band accesses (i.e. console security rules, access listsà) 8.2.1.4. Applications Network devices usually run network functions that allow activation of specific services, like HTTP, BOOTP, DHCP, SYSLOG ... Such devices must therefore be provided with the relevant information related to these services: - the ability to enable or disable the service; - the mandatory parameters for each of the service. Boucadair et al. Informational - Expires January 2005 [Page 12] Internet Draft Network Configuration requirements July 2004 8.2.2. Forwarding services 8.2.2.1. Routing and Forwarding Configuration Information Routing and forwarding configuration information deals with the decision criteria that should be taken by a participating device to forward an incoming IP datagram, according to a given routing policy. From this perspective, the participating devices should be provided with the following information: - In the case of the activation of dynamic routing protocols for the computation and the selection of routes that will be considered for forwarding traffic, the participating routers SHOULD be provided with the relevant metric information so that the routers (dynamically) assign the metric values accordingly, - In the case where the traffic is to be conveyed across domains, the participating devices should be provided with the relevant BGP-4 (Border Gateway Protocol, version 4)-based reachability information, including the BGP-4 attribute-related information that will be taken into account by the route selection process of the router to decide where to forward the corresponding traffic, - Also, the participating routers should be provided with the configuration information related to any static route that may identify specific next hops to reach a given destination prefix. 8.2.2.2. Traffic Engineering Configuration Information Traffic engineering is an important task of configuration management: within this context, the participating devices should be provided with the configuration information that will help them to choose the appropriate routes that lead to a set of destinations, according to specific constraints. These constraints may be expressed in terms of time duration (e.g. the use of a traffic-engineered route on a weekly basis), traffic characterization (e.g. all the IP multicast traffic should be conveyed by a specific route), security concerns (e.g. use IPSec [9] tunnels whenever possible), and/or QoS considerations (e.g. EF (Expedited Forwarding, [10])-marked traffic should always use a subset of activated and well-identified routes). The enforcement of an IP traffic engineering policy would therefore yield the use of specific routes that will be dynamically computed and selected according to the aforementioned type of configuration information. 8.2.2.3. Configuration Information for Tunnel Design and Activation Boucadair et al. Informational - Expires January 2005 [Page 13] Internet Draft Network Configuration requirements July 2004 8.2.2.4. Tunnel Identification Information The identification of a tunnel should be globally unique, especially if the tunnel is to be established and activated across autonomous systems. The tunnel identification schemes (e.g. endpoint numbering) should be left to service providers, given that the corresponding formalism may be commonly understood, whatever the number of autonomous systems the tunnel may cross. The tunnel identification information should at least be composed of the tunnel endpoint identification information. The tunnel identification information may also be composed of an informal description of the tunnel, e.g. the purpose of its establishment, the customer(s) who may use this tunnel, etc. There may be cases where this additional information is irrelevant, e.g. in the case where the tunnel has been designed to convey public Internet traffic, where a user wishes to access IP multicast-based services through non-multicast capable clouds. 8.2.2.5. Tunneling Protocol Configuration Information Any participating device MUST be provided with the configuration information related to the tunneling technique to be used for the establishment and the activation of the tunnel. Such techniques include Generic Routing Encapsulation (GRE, [11]), IP Secure in tunnel mode (IPSec), Layer 2 Tunneling Protocol (L2TP, [12]), etc. 8.2.3. Management services 8.2.3.1. Fault Management Fault management is one of the critical points when managing a given service. Indeed, an operator MAY deploy means to detect fault occurring in its network and has pre-configured policies that SHOULD be enforced by participating devices to limit the impact on the quality of service. Mechanisms to monitor and report the incidents that occurred to the service management SHOULD be independent of the configuration protocol. 8.2.3.2. Configuration Management Configuration management is responsible for the provisioning of configuration information to produce a service. Errors during a configuration procedure could impact the availability of a given service offering, while consistency checks are mandatory so as to correctly enforce a configuration policy. The following requirements have been identified: Boucadair et al. Informational - Expires January 2005 [Page 14] Internet Draft Network Configuration requirements July 2004 - Data provisioning SHOULD be as automated as possible - An operator SHOULD have means to detect and diagnose configuration errors - An operator SHOULD deploy means to check the consistency of the configuration information forwarded to the participating devices, especially when a whole range of IP services can be delivered upon subscription requests. - An operator MAY simulate the impact of the enforcement of a given configuration policy on its services before delivering such information to the participating devices. 8.2.3.3. Performance Management Performance management is mainly deals with the monitoring of the network and the status of the services. The performance of a configuration policy/architecture will be studied in the next version of this draft. 8.2.3.4. Security Management 8.2.3.4.1. Device Authentication It MUST be possible to activate mutual authentication between a participating device and a centralized entity that is responsible for instantiating and forwarding configuration data to these participating devices. The authentication MUST be checked before exchanging any configuration data to prevent DoS (Denial of Service) attacks. 8.2.3.4.2. Integrity of configuration information Two types of integrity MUST be provided. The first one MAY be done at the network layer, e.g. by using the IPsec protocol suite. It will protect each IP datagram, exchanged between a participating device and the configuration management platform(s), from malicious modification. The second one SHOULD protect the configuration data at the application layer (e.g. the entire file configuration is integrity protected). 8.2.3.4.3. Confidentiality of exchanged data The participating device SHOULD provide security functions that provide confidentiality. The encryption algorithms MUST be selectable manually and/or automatically. The encryption algorithms MUST be the standard ones. Boucadair et al. Informational - Expires January 2005 [Page 15] Internet Draft Network Configuration requirements July 2004 8.2.3.4.4. Key management The configuration system MUST provide a scalable key management scheme. The number of keys to be managed must be at most linearly proportional to the number of the devices. 8.2.3.4.5. Log of connections The participating device MUST log all configuration connections. At least the following information must be provided: - Identity of the device which provided the configuration information, - Date of the connection, - Identity of the user that has launched the configuration process, - Version of the configuration data has been enforced. 8.2.3.4.6. Profiles The configuration system MUST allow the definition and the activation of several privilege levels. Each level could be associated to a set of administrative functions. And each configuration administrator could be assigned a specific privileged access level to perform a (possibly limited) set of configuration tasks. 9. Security Considerations This draft reflects a set of requirements as far as the design and the enforcement of configuration policies are concerned for (automated) service subscription, delivery and exploitation. As such, the document addresses some security concerns that have been depicted in section 9.2.3.5, and that SHOULD be taken into account when considering the specification of a protocol that will convey configuration information, as well as configuration information itself. 10. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Boucadair et al. Informational - Expires January 2005 [Page 16] Internet Draft Network Configuration requirements July 2004 [3] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [4] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [5] Chan, K., Durham, D., Gai, S., Herzog, S., McCloghrie,K., Reichmeyer, F., Seligson, J., Smith, A. and R. Yavatkar, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [6] Distributed Management Task Force, "Common Information Model (CIM) Specification Version 2.2", DSP 0004, June 1999. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [8] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001. [9] Atkinson R., "Security Architecture for the Internet Protocol", RFC 2401, August 1998. [10] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [11] Farinacci, D., et al., "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [12] Townsley, W., et al., "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. 11. Acknowledgments 12. Authors' Addresses Mohamed Boucadair France Telecom R & D 42, rue des Coutures 14000 Caen, France Phone: 33 2 31 75 92 31 Email: mohamed.boucadair@francetelecom.com Boucadair et al. Informational - Expires January 2005 [Page 17] Internet Draft Network Configuration requirements July 2004 Christian Jacquenet France Telecom Long Distance 3 Avenue Fran‡ois Ch‚teau 35901 Rennes Cedex, France Phone: 33 2 99 87 63 31 Email: christian.jacquenet@francetelecom.com Mohammed Achemlal France Telecom R & D 42, rue des Coutures 14000 Caen, France Phone: 33 2 31 75 92 28 Email: mohammed.achemlal@francetelecom.com Yan Adam France Telecom R&D LANNION 2 Avenue Pierre Marzin 22307 Lannion Cedex France Phone: 33 2 96 05 29 19 Email: yan.adam@francetelecom.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Boucadair et al. Informational - Expires January 2005 [Page 18]