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
<draft-jacquenet-tunman-reqts-00.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. 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]