One document matched: draft-ietf-diffserv-tunnels-00.txt
Differentiated Services WG D. Black
INTERNET-DRAFT EMC Corporation
Document: draft-ietf-diffserv-tunnels-00.txt February 2000
Differentiated Services and Tunnels
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This
document will expire before September, 2000.
Distribution of this draft is unlimited.
1. Abstract
This draft considers the interaction of Differentiated Services
(diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms.
The discussion of tunnels in the diffserv architecture [RFC-2475]
has been found to provide insufficient guidance to tunnel designers
and implementers. With the aim of providing such guidance, this
document describes two conceptual models for the interaction of
diffserv with IP tunnels and employs them to explore the resulting
configurations and combinations of functionality. An important
consideration is how and where it is appropriate to perform diffserv
traffic conditioning in the presence of tunnel encapsulation and
decapsulation. A few simple mechanisms are also proposed that limit
the complexity that tunnels would otherwise add to the diffserv
traffic conditioning model; these mechanisms are also generally
useful in situations where more general traffic conditioning is
inappropriate or unavailable. Security considerations for IPsec
Black [Page 1]
ietf-diffserv-tunnels Diffserv and Tunnels February 2000
tunnels may place limits on possible functionality in some
circumstances.
2. Conventions used in this document
An IP tunnel encapsulates IP traffic in another IP header as it
passes through the tunnel; the presence of these two IP headers is a
defining characteristic of IP tunnels. The inner IP header is that
of the original traffic; an outer IP header is attached and detached
at tunnel endpoints. In general, intermediate network nodes between
tunnel endpoints operate solely on the outer IP header, and hence
diffserv-capable intermediate nodes can only access and modify the
DSCP field in the outer IP header (e.g., for an encrypted tunnel,
interior nodes cannot access the inner IP header). The terms
"tunnel" and "IP tunnel" are used interchangeably in this document.
For simplicity, we do not consider issues raised by tunnels other
than IP tunnels (i.e., where there is no encapsulating IP header),
such as MPLS paths and "tunnels" formed by encapsulation in layer 2
(link) headers.
This document considers tunnels to be unidirectional; bi-directional
tunnels are composed of two unidirectional tunnels carrying traffic
in opposite directions between the same pair of tunnel endpoints. A
tunnel consists of an ingress where traffic enters the tunnel and is
encapsulated by the addition of the outer IP header, an egress where
traffic exits the tunnel and is decapsulated by the removal of the
outer IP header, and intermediate nodes through which tunneled
traffic passes between the ingress and egress. This document does
not make any assumptions about routing and forwarding of tunnel
traffic, and in particular neither requires nor forbids any form of
route pinning.
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].
Text in square brackets labeled "Author's note:" (e.g., [Author's
note: this is a note from the author.]) is editorial in nature and
will be addressed in a future version of this document.
3. Diffserv and Tunnels Overview
Tunnels range in complexity from simple IP-in-IP tunnels [RFC-2003]
to complex multi-protocol tunnels, such as IP in PPP in L2TP in
IPsec transport mode [RFC-1661, RFC-2401, RFC-2661]. The most
general tunnel configuration is one in which the tunnel is not end-
to-end, i.e., the ingress and egress nodes are not the source and
destination nodes for traffic carried by the tunnel. If the ingress
or egress nodes do coincide with the end-to-end source or
destination, the result is a simplified configuration to which much
of the analysis and recommendations in this document are applicable.
Black [Page 2]
ietf-diffserv-tunnels Diffserv and Tunnels February 2000
A primary concern for differentiated services is the use of the
Differentiated Services Code Point (DSCP) in the IP header; see
[RFC-2474, RFC-2475] for more extensive descriptions of the DSCP
field and the diffserv architecture. The diffserv architecture
permits intermediate nodes to examine and change the value of the
DSCP, which may result in the DSCP value in the outer IP header
being modified between tunnel ingress and egress. When a tunnel is
not end-to-end, there are circumstances in which it may be desirable
to propagate the DSCP and/or some of the information that it
contains to the outer IP header on ingress and/or back to inner IP
header on egress. The current situation facing tunnel implementers
is that [RFC-2475] offers some incomplete guidance, and guideline
G.7 for PHB specification in Section 3 of that RFC is based on over-
simplified assumptions about how tunnels are deployed with respect
to DS domain boundaries. The EF PHB specification [RFC-2598] may be
too specific (in 20/20 hindsight) because its requirement to use EF
in the outer header of tunneled EF packets (based on guideline G.7)
is unworkable in domains that do not support EF, and excludes other
techniques for conditioning tunneled EF traffic.
This document proposes an approach in which traffic conditioning is
performed in series with tunnel ingress or egress processing, not in
parallel. This approach does not create any additional paths that
transmit information across a tunnel endpoint, as all diffserv
information is contained in the DSCPs in the IP headers. The IPsec
architecture [RFC-2401] requires that this be the case to preserve
security properties at the egress of IPsec tunnels, but this
approach also avoids introducing out-of-band inputs to diffserv
traffic conditioner blocks, which would complicate them. Diffserv
domain boundaries can then be positioned as appropriate for the set
of traffic conditioning blocks and tunnel processing modules. One
configuration of interest involves a diffserv domain boundary that
passes through (i.e., divides) a network node; it is acceptable to
split such a boundary to create a DMZ-like region between the
domains that contains the tunnel ingress or egress processing.
Diffserv traffic conditioning is not appropriate for such a DMZ-like
region, as that traffic conditioning is part of the operation and
management of one or more diffserv domains.
4. Conceptual Models for Diffserv Tunnels
There are two important conceptual traffic conditioning models for
IP tunnels. For clarity, the initial discussion of these models
assumes a fully diffserv-capable network. Configurations in which
this is not the case are taken up in Section 4.2.
4.1 Conceptual Models for Fully DS-capable Configurations
The first conceptual model is a uniform model that views IP tunnels
as artifacts of the end to end path from a traffic conditioning
standpoint; tunnels may be necessary mechanisms to get traffic to
its destination(s), but have no significant impact on traffic
conditioning. In this model, any packet has exactly one DS Field
Black [Page 3]
ietf-diffserv-tunnels Diffserv and Tunnels February 2000
that is used for traffic conditioning at any point, namely the DS
Field in the outermost IP header; any others are ignored.
Implementations of this model copy the DSCP value to the outer IP
header at encapsulation and copy the outer header's DSCP value to
the inner IP header at decapsulation. Use of this model allows IP
tunnels to be configured without regard to diffserv domain
boundaries because diffserv traffic conditioning functionality is
not impacted by the presence of IP tunnels.
The second conceptual model is a pipe model that views an IP tunnel
as hiding the nodes between its ingress and egress so that they do
not participate fully in traffic conditioning. In this model, a
tunnel egress node uses traffic conditioning information conveyed
from the tunnel ingress by the DSCP value in the inner header, and
ignores (i.e., discards) the DSCP value in the outer header. This
model cannot completely hide traffic conditioning within the tunnel,
as the effects of dropping and shaping at intermediate tunnel nodes
may be visible at the tunnel egress and beyond. This model is
particularly appropriate to configurations in which the ingress and
egress nodes belong to the same diffserv domain but the IP tunnel
may pass through other domains; virtual private networks (VPNs) may
be configured in this fashion. In this class of configurations, the
DSCP values from the ingress node are valid at the egress node
because both nodes are in the same diffserv domain. Other uses of
the pipe model (i.e., for configurations in which the tunnel ingress
and egress nodes are not in the same diffserv domain) SHOULD employ
an inter-domain TCA (Traffic Conditioning Agreement) between the
diffserv domains containing the tunnel ingress and egress nodes in
order to specify the required egress traffic conditioning.
The pipe conceptual model is also appropriate for situations in
which the DSCP carries information that is within the tunnel. For
example, if transit between two domains is purchased via a tunnel
that uses the EF PHB [RFC-2598], the drop precedence information in
the AF PHB DSCP values [RFC-2597] will be destroyed unless something
is done to preserve it; an IP tunnel is one possible preservation
mechanism. A tunnel that crosses one or more non-diffserv domains
between its DS-capable endpoints may experience a similar
information destruction phenomenon due to the limited set of DSCP
codepoints that are compatible with such domains.
4.2 Considerations for Partially DS-capable Configurations
If only the tunnel egress node is DS-capable, [RFC-2475] requires
the egress node to perform any edge traffic conditioning needed by
the diffserv domain for tunneled traffic entering from outside the
domain. If the egress node would not otherwise be a DS edge node,
one way to meet this requirement is to perform edge traffic
conditioning at an appropriate upstream DS edge node or nodes within
the tunnel, and copy the DSCP value from the outer IP header to the
inner IP header as part of tunnel decapsulation processing. A
second alternative discards the outer DSCP value as part of
decapsulation processing, reducing the resulting traffic
Black [Page 4]
ietf-diffserv-tunnels Diffserv and Tunnels February 2000
conditioning problem and requirements to those of an ordinary DS
ingress node. This employs the pipe model of a tunnel and hence the
adjacent upstream node for DSCP marking purposes is the tunnel
ingress node, not the immediately upstream intermediate tunnel node.
If only the tunnel ingress node is DS-capable, [RFC-2475] requires
that traffic emerging from the tunnel be compatible with the network
at the tunnel egress. If tunnel decapsulation processing discards
the outer header's DSCP value without changing the inner header's
DSCP value, then the DS-capable tunnel ingress node MUST set the
inner header's DSCP to a value compatible with the network at tunnel
egress. The value 0 (DSCP of 000000) is used for this purpose by a
number of existing tunnel implementations. If the egress network
implements IP precedence as specified in [RFC-791], then some or all
of the eight class selector DSCP codepoints defined in [RFC-2474]
are usable. DSCP codepoints other than the class selectors SHOULD
NOT be used for this purpose, as correct operation under these
circumstances involves diffserv functionality at the DS-incapable
tunnel egress node.
5. Ingress Functionality
As described in Section 3 above, this draft is based on an approach
in which diffserv functionality and/or out-of-band communication
paths are not placed in parallel with tunnel encapsulation
processing. This model allows three possible locations for traffic
conditioners with respect to tunnel encapsulation processing, as
shown in the following diagram that depicts the flow of IP headers
through tunnel encapsulation:
+--------- [2 - Outer] -->>
/
/
>>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>
Traffic conditioning at [1 - Before] and [2 - Outer] is logically
separate from the tunnel, as it is not impacted by the presence of
tunnel encapsulation. Tunnel designs and specifications SHOULD
permit diffserv traffic conditioning at these locations. Such
conditioning can be performed by standard diffserv traffic
conditioning components, such as [Author's note: TBD based on
further diffserv WG efforts], and can be viewed as independent of
the tunnel (e.g., [1 - Before] can be viewed as separate traffic
conditioning that takes place prior to tunnel ingress).
In contrast, the [3 - Inner] location SHOULD NOT be utilized for
traffic conditioning because it requires functionality that reaches
inside the packet to operate on the inner IP header. This is
difficult in general, and is impossible for IPsec tunnels and any
other tunnels that are encrypted or employ cryptographic integrity
checks. Hence traffic conditioning at [3 - Inner] can only be
performed as part of tunnel encapsulation processing, complicating
both the encapsulation and traffic conditioning implementations. In
many cases, the desired functionality can be achieved via a
Black [Page 5]
ietf-diffserv-tunnels Diffserv and Tunnels February 2000
combination of traffic conditioners in the other two locations, both
of which can be specified and implemented independently of tunnel
encapsulation processing
An exception for which traffic conditioning functionality is
necessary at [3 - Inner] occurs when the tunnel egress is not DS-
capable and discards the outer IP header. Setting the inner DSCP to
0 as part of encapsulation addresses most of these cases, and
implementations MAY support setting the inner DSCP to one of the
class selector DCSP codepoint values, as these are valid for
networks that support IP precedence. This level of functionality
(set the DSCP to one of the class selector codepoint values) is also
generally appropriate for other traffic conditioning locations in
configurations that do not support more general traffic conditioning
at those locations.
The following table summarizes the achievable relationships among
the Before (B), outer (O), and inner (I) DSCP values and the
corresponding locations of traffic conditioning logic.
Relationship Traffic Conditioning Location(s)
------------ --------------------------------
B = I = O No traffic conditioning required
B != I = O [1 - Before]
B = I != O [2 - Outer]
B = O != I Limited support as part of encapsulation:
I can be set to 000000 or possibly one of
the class selector code points.
B != I != O Some combination of the above three cases.
A combination of [1 - Before] and [2 - Outer] is applicable in many
cases that fit one of the last two lines of the table, and this
combination is RECOMMENDED in preference to deploying functionality
at [3 - Inner]. Implementers are cautioned that traffic
conditioning may still be required for purposes such as rate and
burst control even if DSCP values are not changed.
[Author's note: Is the above table useful?]
6. Egress Functionality
As described in Section 3 above, this draft is based on an approach
in which diffserv functionality and/or out-of-band communication
paths are not placed in parallel with tunnel encapsulation
processing. This allows three possible locations for traffic
conditioners with respect to tunnel decapsulation processing, as
shown in the following diagram that depicts the flow of IP headers
through tunnel encapsulation:
>>----[5 - Outer]-------------+
\
\
>>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>
Black [Page 6]
ietf-diffserv-tunnels Diffserv and Tunnels February 2000
Traffic conditioning at [5 - Outer] and [6 - After] is logically
separate from the tunnel, as it is not impacted by the presence of
tunnel decapsulation. Tunnel designs and specifications SHOULD
permit diffserv traffic conditioning at these locations. Such
conditioning can be performed by standard diffserv traffic
conditioning components, such as [Author's note: TBD based on
further diffserv WG efforts], and can be viewed as independent of
the tunnel (e.g., [6 - After] can be viewed as separate traffic
conditioning that takes place after tunnel egress). An important
exception is that the configuration of a tunnel (e.g., the absence
of traffic conditioning at tunnel ingress) and/or the diffserv
domains involved may require that all traffic exiting a tunnel pass
through diffserv traffic conditioning to fulfill the diffserv edge
node traffic conditioning responsibilities of the tunnel egress
node. Tunnel specifications SHOULD include the ability to require
that all traffic exiting a tunnel pass through diffserv traffic
conditioning.
In contrast, the [4 - Inner] location SHOULD NOT be employed for
traffic conditioning because it requires reaching inside the packet
to operate on the inner IP header. Unlike the [3 - Inner] case for
encapsulation, there is no need for functionality to be performed
here, as diffserv traffic conditioning can be appended to the tunnel
decapsulation (i.e., performed at [6 - After]).
6.1 Egress DSCP Selection
The elimination of parallel functionality and data paths from
decapsulation causes a potential loss of information. As shown in
the diagram in Section 6, decapsulation combines and reduces two
DSCP values to one DSCP value, losing information in the most
general case, even if arbitrary functionality is allowed. Beyond
this, allowing arbitrary functionality poses a structural problem,
namely that the DSCP value from the outer IP header would have to be
presented as an out-of-band input to the traffic conditioning block
at [6 - After], complicating the traffic conditioning model.
To avoid such complications, we adopt the simpler approach of
statically selecting either the inner or outer DSCP value at
decapsulation, leaving the full generality of traffic conditioning
functionality to be implemented at [5 - Outer] and/or [6 - After].
Tunnels SHOULD support static selection of one or the other value at
tunnel egress. The rationale for this approach is that of the two
DSCP values, usually only one of them contains useful information,
with the other being of little value, and the conceptual model used
for the tunnel provides a strong indication as to which one contains
the useful information. In general, the outer DSCP value contains
the useful information for tunnels based on the uniform model, and
the inner DSCP value contains the useful information for tunnels
based on the pipe model. IPsec tunnels are usually based on the
pipe model, and for security reasons MUST default to selecting the
outer DSCP value and SHOULD not select the inner DSCP value in the
Black [Page 7]
ietf-diffserv-tunnels Diffserv and Tunnels February 2000
absence of an adequate security analysis of the resulting risks and
implications.
6.2 Egress DSCP Selection Case Study
As a sanity check on the simpler approach proposed above (i.e., in
Section 6), this subsection considers a situation in which a more
complex approach might be required. Statically choosing a single
DSCP value is a poor match to situations in which both DSCPs are
carrying information that is needed to perform traffic conditioning
(i.e., at [6 - After]) correctly.
As an example, we consider a situation in which two different AF
groups [RFC-2597] are being used by the two domains at the tunnel
endpoints, and there is an intermediate domain along the tunnel that
uses RFC 791 IP precedences that is transited by setting the DSCP to
zero. This situation is shown in the following IP header flow
diagram where I is the tunnel ingress node, E is the tunnel egress
node and the vertical lines are domain boundaries. The node at the
left-hand vertical line sets the DSCP in the outer header to 0 in
order to obtain compatibility with the middle domain:
| |
+-----|-------------------|------+
/ | | \
>>-----------I-------|-------------------|--------E---------->>
| |
Ingress DS Domain RFC 791 Egress DS domain
IP Precedence
Domain
In this situation, the DS edge node for the egress domain (i.e., the
node at the right-hand vertical line) can select the appropriate AF
group (e.g., via an MF classifier), but cannot reconstruct the drop
precedence information that was removed from the outer header when
it transited the RFC 791 domain (although it can construct new
information via metering and marking). The original drop precedence
information is preserved in the inner IP header's DSCP, and could be
combined with the AF class selection communicated via the outer IP
header's DSCP. The marginal benefit of being able to reuse the
original drop precedence information as opposed to constructing new
drop precedence markings does not appear to justify the additional
complexity that would be introduced into tunnel egress traffic
conditioners.
[Author's note: Last sentence is an open issue for WG discussion.]
7. Diffserv and Protocol Translators
A related issue involves protocol translators, of which a specific
example are those employing the Stateless IP/ICMP Translation
Algorithm [RFC-2765]. These translators are not tunnels because
they do not add or remove a second IP header to/from packets (e.g.,
Black [Page 8]
ietf-diffserv-tunnels Diffserv and Tunnels February 2000
in contrast to IPv6 over IPv4 tunnels [RFC-1933]) and hence do not
raise concerns of information propagation between inner and outer IP
headers. The primary interaction between translators and diffserv
is that the translation boundary is likely to also be a diffserv
domain boundary (e.g., the IPv4 and IPv6 domains may have different
policies for traffic conditioning and DSCP usage), and hence such
translators SHOULD permit the insertion of diffserv edge node
processing (i.e., including traffic conditioning) both before and
after the translation processing.
8. Security Considerations
The security considerations for the diffserv architecture discussed
in [RFC-2474, RFC-2475] apply when tunnels are present; readers are
referred to those documents for further information. One of the
requirements noted there is that a tunnel egress node in the
interior of a diffserv domain is the DS ingress node for traffic
exiting the tunnel, and is responsible for performing appropriate
traffic conditioning. The primary security implication is that the
traffic conditioning is responsible for dealing with theft- and
denial-of-service threats posed to the diffserv domain by traffic
exiting from the tunnel. The IPsec architecture [RFC-2401] places a
further restriction on tunnel egress processing; the outer header
MUST be discarded unless the properties of the traffic conditioning
that will be applied are known and have been adequately analyzed for
security vulnerabilities. This includes both the [5 - Outer] and
[6 - After] traffic conditioning blocks on the tunnel egress node,
if present, and may involve traffic conditioning performed by an
upstream DS-edge node that is the DS domain ingress node for the
encapsulated tunneled traffic.
9. References
[RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC-1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC-1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC-2003] C. Perkins, "IP Encapsulation within IP,", RFC 2003,
October 1996.
[RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC-2401] S. Kent and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
Black [Page 9]
ietf-diffserv-tunnels Diffserv and Tunnels February 2000
[RFC-2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition
of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998.
[RFC-2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and
W. Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[RFC-2597] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597. June 1999.
[RFC-2598] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[RFC-2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999.
[RFC-2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765. February, 2000.
[Author's note: This needs to be extended by additional tunnel RFC
references. The references section of the Tunnel MIB RFC (RFC 2667)
provides a good starting point.]
10. Acknowledgments
Some of this material is based on discussions with Brian Carpenter,
and in particular his presentation on this topic to the diffserv WG
during the summer 1999 IETF meeting in Oslo. Credit is also due to
a people working on tunnel specifications [Author's note: names may
appear here in a future version] who have discovered limitations of
the diffserv architecture RFC (2475) in the area of tunnels. Their
kind patience with the time it has taken to address this set of
issues has been greatly appreciated. Finally, this material has
benefited from discussions within the diffserv WG, and the
contributions of participants in those discussions are gratefully
acknowledged.
11. Author's Address
David L. Black
EMC Corporation
42 South St.
Hopkinton, MA 01748
Phone: +1 (508) 435-1000 x75140
Email: black_david@emc.com
Black [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 10:54:21 |