One document matched: draft-jacquenet-tunman-reqts-02.txt
Differences from draft-jacquenet-tunman-reqts-01.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 14:03:00 |