Network Working Group C. Jacquenet Internet Draft France Telecom R&D Document: draft-jacquenet-tunman-reqts-00.txt November 2001 Category: Informational Expires May 2002 Requirements for dynamic tunnel configuration Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. 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 In today's Internet, tunnels are established and activated to provide a facility for conveying a specific traffic from one point to another, or from one point to several others. This draft aims at describing the requirements for the specification and the standardization of the configuration information that will be used to define, establish, activate and maintain such facilities. From this standpoint, this document complements the statements introduced by RFC 3139 ([2]). Table of Contents 1. Introduction................................................2 2. Conventions used in this document...........................3 3. Terminology.................................................3 4. A tentative taxonomy for classifying tunnel configuration information.................................4 5. Tunnel configuration information requirements...............6 5.1. Architectural considerations................................6 Jacquenet Informational - Exp. May 2002 [Page 1] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 5.1.1. Tunnel identification information...........................6 5.1.2. Tunneling protocol configuration information................6 5.1.3. Routing and forwarding configuration information............6 5.1.4. Traffic engineering configuration information...............7 5.2. Quality of service considerations...........................7 5.2.1. Tunnel configuration information for QoS policy enforcement...............................................7 5.2.2. QoS parameters as (part of) tunnel configuration information...............................................8 5.3. Security considerations.....................................8 5.4. Management considerations...................................9 6. Functional requirements for a protocol to convey tunnel configuration information.................................9 7. Consistency with some IETF standardization efforts.........10 8. Security Considerations....................................10 9. Acknowledgements...........................................10 10. References.................................................10 11. Author's Addresses.........................................11 1. Introduction In today's Internet, tunnels are established and activated to provide a facility for conveying a specific traffic from one point to another. The design of such facilities refer to the deployment of a range of IP service offerings, ranging from IP VPN (Virtual Private Networks, [3]) to IP multicast-based services ([4]), like videoconferencing, for example. The increasing growth of such advanced services systematically implies the manipulation of a large set of configuration information for the actual engineering, establishment, activation and maintenance of such tunnels. This configuration information includes the definition of forwarding and routing schemes (i.e. what kind of traffic should be conveyed by the tunnel, to which destination, etc.), security considerations (identification and authentication of the users who are granted to access the tunnel facility), as well as Quality of Service (QoS) considerations, like the DSCP (DiffServ Code Point, [5]) marking associated to the IP datagrams that are entitled to be forwarded through the tunnel. Due to the increased complexity of deploying the corresponding value- added IP service offerings, it is important, then, that an interface exists such that tunnel management configuration information can be dynamically provided in a vendor-independent manner, and for a number of services, whatever the underlying technology, and whatever the nature of such services. This document is organized into the following sections: Jacquenet Informational - Exp. May 2002 [Page 2] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 - Section 3 is the terminology section of the document, where several basic notions have been defined, - Section 4 aims at defining a taxonomy for the various kinds of configuration information that is needed to design, establish, activate and maintain a tunnel, - Section 5 proposes a list of requirements according to the above- mentioned taxonomy, - Finally, section 6 aims at describing the functional requirements for a communication protocol that would be the privileged vector for conveying tunnel configuration information. 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 [6]. 3. Terminology This section aims at providing a set of basic definitions for the terms that will be used by this document. - 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 tunnel. Such devices include routers, whatever the tunneling technique to be used for tunnel construction. - Subscriber: A subscriber (or a customer) is a legal representative who has the (legal) ability to subscribe to a service offering. - 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 capabilities, - Access IPv6 networks over IPv4 clouds, - Deploy IP Virtual Private Networks, - Deploy Mobile IP ([7]) architectures. - 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. Jacquenet Informational - Exp. May 2002 [Page 3] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 - 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. - User: A user is an entity (a human being or a process, from a general perspective) who has been named by a subscriber and appropriately identified by a service provider, and whose traffic will be conveyed through a tunnel facility, according to his associated rights and duties. - VPN: Virtual Private Network. A collection of switching resources (namely routers) and transmission resources which will be used over an IP backbone thanks to the establishment and the activation of tunnels, so that they will convey the IP traffic which will reflect the data oriented-communication service of an enterprise (VPNs that are designed to support intranet-based applications) or a set of enterprises (VPNs that are designed to support extranet-based applications). Hence, IP VPN networks are an applicability example of tunnel configuration and management activities. 4. A tentative taxonomy for classifying tunnel configuration information For the last decade, the deployment of value-added IP service offerings has yielded the tremendous development of complex configuration information, which ranges from IP address assignment to dynamic key management, not to mention routing strategies and QoS policy enforcement. There is a wide variety of advanced IP service offerings - IP VPNs, IP multicast-based services, multimedia services like IP videoconferencing - that rely upon the use of tunnels, because of various motivations: 1. The need for isolating the traffic that corresponds to the deployment of these services from other traffics, 2. The need for preserving the confidentiality of the traffic that will be conveyed over a public IP infrastructure, 3. The need for enforcing specific forwarding and routing schemes, because of the (non)-support of specific capabilities, like IP multicast, 4. The need for servicing customers according to specific QoS parameters, 5. Etc. Because of the crucial importance of such tunnels, it seems reasonable to clearly identify what will compose the configuration Jacquenet Informational - Exp. May 2002 [Page 4] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 information for the design, the establishment, the activation and the maintenance of these transport facilities. To do so, this document proposes the following taxonomy, while the next sub-sections will elaborate on each of these domains. - Architectural considerations: the corresponding tunnel configuration information refers to the very basic information that is needed for the establishment and the activation of the tunnel - namely the identification of the endpoints, the forwarding and routing schemes (including possible traffic engineering capabilities) to be enforced by the devices that will participate in the processing of the traffic conveyed by the tunnel, possibly the identification of the tunnel facility itself. - QoS considerations: the associated configuration information is expected to deal with any QoS parameter that the tunnel will have to take into account. This may include the classification of the traffic that will be forwarded through the tunnel, the marking parameters associated to such traffic, the Per-Hop Behavior (PHB, [8]) that will be enforced by the participating routers, etc. - Security considerations: any tunnel that may be established and activated by a service provider to convey a specific traffic yields the need for identification and authentication capabilities that will help the service provider in provisioning some guarantees as far as the user identification and authentication are concerned, but also as far as the tunnel resource identification and authentication are concerned. Indeed, the establishment and the activation of a tunnel between two or more endpoints imply that the corresponding devices are granted for supporting tunnel capabilities, but also for any related capability, including route announcement. - Management considerations: if (tunnel) configuration is part of the basic management tasks, there is a need for collecting all the relevant statistical information about the tunnels that are under establishment, those that are under activation, those that are up and running, etc. According to the following taxonomy, this draft proposes to classify the tunnel configuration information into the following domains: 1. Architecture, 2. Quality of service, 3. Security, 4. Management. The following sections provide elaboration on the corresponding requirements, as far as this tunnel configuration information is concerned. Jacquenet Informational - Exp. May 2002 [Page 5] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 5. Tunnel configuration information requirements 5.1. Architectural considerations 5.1.1. Tunnel identification information The identification of a tunnel should be globally unique, especially if the tunnel is to be established and activated between 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, the IP VPN it refers to. There may be cases where this additional information is irrelevant, e.g. in the case where the tunnel is expected to convey public Internet traffic, where a user wishes to access IP multicast-based services through non-multicast capable clouds. 5.1.2. 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, [9]), IP Secure in tunnel mode (IPSec, [10]), Layer 2 Tunneling Protocol (L2TP, [11]), etc. 5.1.3. Routing and forwarding configuration information Routing and forwarding configuration information deals with the decision criteria that should be taken by a participating router to forward an incoming IP datagram into the tunnel, according to a given tunnel routing policy. From this perspective, the participating routers 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 through the tunnel, the participating router should be provided with the relevant metric information so that, the router (dynamically) assigns the metric values accordingly, - In the case where the tunnel is expected to convey traffic across domains, the participating devices should be provided by the relevant BGP-4 (Border Gateway Protocol, version 4, [12])-based reachability information, including the BGP-4 attribute-related Jacquenet Informational - Exp. May 2002 [Page 6] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 information that be taken into account by the route selection process of the router to decide whether the corresponding traffic should be conveyed by the tunnel or not, - Also, the participating routers should be provided by the configuration information related to any static route that may identify a tunnel endpoint as the next hop to reach a given destination prefix. 5.1.4. Traffic engineering configuration information Traffic engineering is an implicit task of tunnel configuration management: within this context, the participating devices should be provided with the configuration information that will help them to choose the appropriate tunnel that leads to a given destination, according to specific constraints. These constraints may be expressed in terms of time duration (e.g. the use of a tunnel on a weekly basis), traffic characterization (e.g. all the IP multicast traffic should be conveyed by a specific tunnel), security concerns (e.g. use IPSec tunnels whenever possible), and/or QoS considerations (e.g. EF (Expedited Forwarding, [13])-marked traffic should always use a subset of activated tunnels). The enforcement of an IP traffic engineering policy would therefore yield the use of specific tunnels that will be constructed according to the above-mentioned type of configuration information. 5.2. Quality of service considerations Tunnels may be established to enforce a QoS policy, and/or tunnels may be established according to QoS parameters. 5.2.1. Tunnel configuration information for QoS policy enforcement Service providers may decide to rely upon the use of tunneling techniques to enforce a given QoS policy within a domain. For example, the implementation of an EF PHB by the routers of a DiffServ domain may be tightly related to the establishment and the activation of (a set of) tunnels that will be dedicated to the transportation of EF-marked traffic over the whole domain. Therefore, the participating devices should be provided with the PHB- related configuration information, DSCP marking, policing and scheduling configuration information that will be associated to the establishment of such tunnels. Jacquenet Informational - Exp. May 2002 [Page 7] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 5.2.2. QoS parameters as (part of) tunnel configuration information On the other hand, a tunnel may be established and activated once the associated QoS-related information has been provisioned to the participating devices. Without any QoS policy consideration, such devices should indeed be provided with the configuration information that may consist of: - The DSCP marking associated to the datagrams that may be conveyed by the tunnel, - The scheduling algorithm parameters that will be used by the participating devices to enforce a tunnel-based buffering policy accordingly, - The policing algorithm parameters that will be used by the participating devices to enforce a tunnel-based traffic shaping policy accordingly, - Etc. While these parameters may very well be the same as those that have been identified in sub-section 5.2.1.of this draft, the actual usage of these parameters as tunnel configuration information may dramatically differ, depending on domain-wide policy enforcement considerations, or locally-processed configuration information. 5.3. Security considerations This section aims at identifying the requirements for the provisioning of the configuration information related to the security associated to the establishment and the activation of tunnels. By "security", this draft basically means: - The identification and the authentication of users who may access the tunnel facility, - The identification and the authentication of the switching resources that will not only participate in the establishment and the activation of the tunnel, but also in the route information propagation that may be used by the participating devices to actually forward the corresponding traffic to the tunnel, - Finally, the preservation of the confidentiality of the information that may be conveyed by the tunnel. Therefore, the participating devices should be provided with all the appropriate configuration information related to the above-mentioned topics. This does not necessarily mean that the routers will have to maintain a dynamically updated user database, but rather, they should be provided with the following configuration information: - The knowledge of the IP networks that may exchange data through the tunnel and/or the configuration information needed for the activation of an identification/authentication mechanism such as RADIUS (Remote Dial-In User Interface, [14]), Jacquenet Informational - Exp. May 2002 [Page 8] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 - The knowledge of the participating devices that support the other endpoint(s) of the tunnel and possibly the configuration information related to the activation of a mechanism for identifying and authenticating such peers (based upon the use of an MD5 (Message Digest type 5, [15]) digital signature, for example), - The knowledge of the configuration information needed in the case of using encryption techniques. 5.4. Management considerations Service providers who rely upon the use of tunneling techniques for the deployment of a range of IP service offerings will naturally have requirements as far as the usage of these tunnels is concerned. From this perspective, the participating devices should be able to give access to any statistical information related to: - The volume of traffic that has been conveyed by the tunnel on a given period of time, including a distinction between incoming and outgoing traffic, - The volume of tunneled traffic that has been dropped by the participating devices on a given period of time, - The IPPM (IP Performance Metrics, [16])-related information that is relevant to the tunnel usage: such information includes the one-way packet delay, the inter-packet delay variation, etc. 6. Functional requirements for a protocol to convey tunnel configuration information Although this draft basically focuses on the requirements for providing configuration information related to tunnel establishment, activation and maintenance, it is assumed that this 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 - namely a database repository. This communication protocol should have the following characteristics: 1. The protocol should use of a reliable transport mode, given the importance of configuration information, 2. The protocol architecture should provide a means for dynamically provision the configuration information to the participating devices, so that it may introduce/contribute to a high level of automation in the actual negotiation and invocation of the corresponding IP service offerings (e.g. the configuration of thousands of IPSec tunnels for the deployment of an IP VPN for a large banking company should NOT be manual anymore), Jacquenet Informational - Exp. May 2002 [Page 9] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 3. The protocol should support a reporting mechanism that may be use for statistical information retrieval, 4. The protocol should support the appropriate security mechanisms to provide some guarantees as far as the preservation of the confidentiality of the configuration information is concerned. 7. Consistency with some IETF standardization efforts It is required that the specification work to be launched around the tunnel configuration topic should be as consistent as possible with any work item of any relevant IETF working group that has identified tunneling techniques as a means for deploying a specific architecture and/or conveying IP traffic. Such working groups include ppvpn and ngtrans. 8. Security Considerations This draft has tried to list a set of configuration information that would be required for the establishment, the activation and the management of tunnels to be deployed over public IP infrastructures. As such, it raises the issue of the security associated to the provisioning of such information, by means of a protocol whose some basic characteristics have been identified in the previous section. There are also security concerns associated with the propagation of the tunnel provisioning data to the network elements, that must participate in the tunnel establishment and activation procedures, and to the customers (including service providers within an inter- domain context) who may access such data. A basic recommendation would therefore consist in using the resources of the IPSec protocol suite whenever possible. 9. Acknowledgements The author would like to thank the "tunman" ([17]) community for the useful discussion that yielded the release of this draft. 10. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Sanchez, L., McCloghrie, K., Saperia, J., "Requirements for Configuration Management of IP-based Networks", RFC 3139, June 2001. [3] Gleeson, B. et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. [4] Quinn, B., Almeroth, K., "IP Multicast Applications: Challenges and Solutions", RFC 3170, September 2001. Jacquenet Informational - Exp. May 2002 [Page 10] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 [5] Nichols K., Blake S., Baker F., Black D., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [6] Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Perkins, C., et al., "IP Mobility Support", RFC 2002, October 1996. [8] Blake, S., et al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [9] Farinacci, D., et al., "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [10] Atkinson R., "Security Architecture for the Internet Protocol", RFC 2401, August 1998. [11] Townsley, W., et al., "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [12] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [13] Jacobson, V., et al., "An Expedited Forwarding PHB", RFC 2598, June 1999. [14] Rigney, C., et al., "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [15] Rivest, R., " The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [16] Paxson, V. et al., "Framework for IP Performance Metrics", RFC 2330, May 1998. [17] tunman@external.cisco.com. 11. Author's Addresses Christian Jacquenet France Telecom R & D DMI/SIR 42, rue des Coutures BP 6243 14066 Caen Cedex 4 France Phone: +33 2 31 75 94 28 Email: christian.jacquenet@francetelecom.com Full Copyright Statement Copyright(C) The Internet Society (2001). 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 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 included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing Jacquenet Informational - Exp. May 2002 [Page 11] Internet Draft Rqts. for dynamic tunnel configuration Nov. 2001 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. Jacquenet Informational - Exp. May 2002 [Page 12]