[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
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
                   <draft-jacquenet-tunman-rqts-02.txt>


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]