Network Working Group C. Jacquenet Internet Draft France Telecom R&D Document: draft-jacquenet-tunman-reqts-02.txt October 2002 Category: Informational Expires April 2003 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. Table of Contents 1. Introduction................................................2 2. Conventions used in this document...........................3 3. Changes since the previous version of the draft.............3 4. Terminology.................................................3 5. A proposed taxonomy for classifying tunnel configuration information.................................4 6. Tunnel configuration information requirements...............6 6.1. Architectural considerations................................6 6.1.1. Tunnel identification information...........................6 Jacquenet Informational - Exp. April 2003 [Page 1] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 6.1.2. Tunneling protocol configuration information................6 6.1.3. Routing and forwarding configuration information............6 6.1.4. Traffic engineering configuration information...............7 6.2. Quality of service considerations...........................7 6.2.1. Tunnel configuration information for QoS policy enforcement...............................................7 6.2.2. QoS parameters as (part of) tunnel configuration information...............................................8 6.3. Security considerations.....................................8 6.4. Management considerations...................................9 7. Functional requirements for a protocol to convey tunnel configuration information.................................9 8. Consistency with some IETF standardization efforts.........10 9. Security Considerations....................................10 10. Acknowledgements...........................................11 11. References.................................................11 12. Author's Address...........................................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 use of such facilities is motivated by the deployment of a range of IP service offerings, like IP VPN (Virtual Private Networks, [2]) or IP multicast-based services ([3]), such as videoconferencing. The implicit complexity of these value-added services is due to 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, [4]) marking associated to the IP datagrams that are entitled to be forwarded through the tunnel. Because of the wide variety of devices that may support the aforementioned capabilities, it is important 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. From this standpoint, this document complements the statements introduced by RFC 3139 ([5]). Jacquenet Informational - Exp. April 2003 [Page 2] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 This document is organized into the following sections: - Section 4 is the terminology section of the document, where several basic notions have been defined, - Section 5 aims at defining a taxonomy for the various kinds of configuration information that is needed to design, establish, activate and maintain a tunnel, - Section 6 proposes a list of requirements according to the above- mentioned taxonomy, - Finally, section 7 aims at describing the functional requirements for a communication protocol that would be a 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. Changes since the previous version of the draft This new version of the draft introduces the following changes: - Slight re-wording of the abstract section, - Correction of remaining typos. 4. 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 may include routers and hosts, 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.: Jacquenet Informational - Exp. April 2003 [Page 3] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 - 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 ([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. - 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 identified (and possibly authenticated) 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 (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 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. 5. A proposed 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, from dynamic IP address assignment to security 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, Jacquenet Informational - Exp. April 2003 [Page 4] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 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 such as 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 are the elementary components of the configuration 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 processed by the devices that will participate in the forwarding of the traffic conveyed by the tunnel. Such information may also include the identification of the tunnel facility itself. - QoS considerations: the corresponding configuration information deals with any QoS parameter that may characterize the tunnel. 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 Behaviors (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. Such capabilities relate to the tunnel users' identification and authentication, but also to the possible identification and authentication of the resources that participate in the establishment, the activation and the maintenance of a tunnel. 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: it is assumed that the exploitation of tunnels is part of the basic management tasks, and there is therefore 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. Jacquenet Informational - Exp. April 2003 [Page 5] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 Thus, the tunnel configuration information can be classified into the following domains: 1. Architecture, 2. Quality of service, 3. Security, 4. Management. The following sections provide elaboration on the corresponding requirements. 6. Tunnel configuration information requirements 6.1. Architectural considerations 6.1.1. 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. 6.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. 6.1.3. 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 into the tunnel, according to a given tunnel routing policy. From this perspective, the participating devices should be provided with the following information: Jacquenet Informational - Exp. April 2003 [Page 6] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 - 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 with the relevant BGP-4 (Border Gateway Protocol, version 4, [12])-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 whether the corresponding traffic should be forwarded through the tunnel or not, - Also, the participating routers should be provided with the configuration information related to any static route that may identify a tunnel endpoint as the next hop to reach a given destination prefix. 6.1.4. Traffic engineering configuration information Traffic engineering is an important 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 and/or requirements. These constraints and/or requirements 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 and well-identified tunnels). The enforcement of an IP traffic engineering policy would therefore yield the use of specific tunnels that will be constructed according to the aforementioned type of configuration information. 6.2. Quality of service considerations Tunnels may be established to enforce a QoS policy, and/or tunnels may be established according to QoS parameters. 6.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 Jacquenet Informational - Exp. April 2003 [Page 7] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 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. 6.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 specific 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 traffic conditioning 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 6.2.1.of this document, 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. 6.3. Security considerations This section aims at listing the basic 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 the 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 appropriately forward traffic into the tunnels, Jacquenet Informational - Exp. April 2003 [Page 8] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 - 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 configuration information related to the aforementioned topics. This does not 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 Authentication Dial-In User Service, [14]), - 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. 6.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. 7. Functional requirements for a protocol to convey tunnel configuration information Although this document focuses on the motivation 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 Jacquenet Informational - Exp. April 2003 [Page 9] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 participating devices and a presumably centralized entity that would aim at storing, maintaining and updating this configuration information, as well as making appropriate decisions at the right time and under various conditions. This communication protocol should have the following characteristics: 1. The protocol should use 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), 3. The protocol should support a reporting mechanism that may be used 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. 8. Consistency with some IETF standardization efforts It is required that the specification work that may be launched because of an interest of the IETF community for this 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 mobileip. 9. Security Considerations This draft has identified 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 discussed in section 7. There are also security concerns associated with the propagation of the tunnel provisioning data to the network elements that will participate in the tunnel establishment and activation procedures, and also to the customers (including service providers within an inter-domain context) who may access such data. A basic recommendation therefore consists in using the resources of the IPSec protocol suite whenever possible. Jacquenet Informational - Exp. April 2003 [Page 10] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 10. Acknowledgements The author would like to thank the "tunman" ([17]) community for the useful discussion that yielded the publication of this draft. 11. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Gleeson, B. et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. [3] Quinn, B., Almeroth, K., "IP Multicast Applications: Challenges and Solutions", RFC 3170, September 2001. [4] 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. [5] Sanchez, L., McCloghrie, K., Saperia, J., "Requirements for Configuration Management of IP-based Networks", RFC 3139, June 2001. [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. 12. Author's Address Christian Jacquenet France Telecom Long Distance IAP/CTO 3, rue François Chateau 35000 Rennes Jacquenet Informational - Exp. April 2003 [Page 11] Internet Draft Rqts. for dynamic tunnel configuration Oct. 2002 France Phone: +33 2 99 87 63 31 E-Mail: christian.jacquenet@francetelecom.com 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 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 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. April 2003 [Page 12]