draft-ietf-diffserv-tunnels-01.txt   draft-ietf-diffserv-tunnels-02.txt 
skipping to change at page 1, line 27 skipping to change at page 1, line 27
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
draft will expire before December, 2000. Distribution of this draft draft will expire before January, 2001. Distribution of this draft
is unlimited. is unlimited.
1. Abstract 1. Abstract
This draft considers the interaction of Differentiated Services This draft considers the interaction of Differentiated Services
(diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms. (diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms.
The discussion of tunnels in the diffserv architecture [RFC-2475] The discussion of tunnels in the diffserv architecture [RFC-2475]
provides insufficient guidance to tunnel designers and implementers. provides insufficient guidance to tunnel designers and implementers.
This document describes two conceptual models for the interaction of This document describes two conceptual models for the interaction of
diffserv with IP tunnels and employs them to explore the resulting diffserv with IP tunnels and employs them to explore the resulting
configurations and combinations of functionality. An important configurations and combinations of functionality. An important
consideration is how and where it is appropriate to perform diffserv consideration is how and where it is appropriate to perform diffserv
traffic conditioning in the presence of tunnel encapsulation and traffic conditioning in the presence of tunnel encapsulation and
decapsulation. A few simple mechanisms are also proposed that limit decapsulation. A few simple mechanisms are also proposed that limit
the complexity that tunnels would otherwise add to the diffserv the complexity that tunnels would otherwise add to the diffserv
traffic conditioning model. Security considerations for IPsec traffic conditioning model. Security considerations for IPSec
tunnels limit the possible functionality in some circumstances. tunnels limit the possible functionality in some circumstances.
2. Conventions used in this document 2. Conventions used in this document
An IP tunnel encapsulates IP traffic in another IP header as it 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 passes through the tunnel; the presence of these two IP headers is a
defining characteristic of IP tunnels, although there may be defining characteristic of IP tunnels, although there may be
additional headers inserted between the two IP headers. The inner additional headers inserted between the two IP headers. The inner
IP header is that of the original traffic; an outer IP header is IP header is that of the original traffic; an outer IP header is
attached and detached at tunnel endpoints. In general, intermediate attached and detached at tunnel endpoints. In general, intermediate
skipping to change at page 2, line 32 skipping to change at page 2, line 32
removal of the outer IP header, and intermediate nodes through which removal of the outer IP header, and intermediate nodes through which
tunneled traffic passes between the ingress and egress. This tunneled traffic passes between the ingress and egress. This
document does not make any assumptions about routing and forwarding document does not make any assumptions about routing and forwarding
of tunnel traffic, and in particular assumes neither the presence of tunnel traffic, and in particular assumes neither the presence
nor the absence of route pinning in any form. nor the absence of route pinning in any form.
3. Diffserv and Tunnels Overview 3. Diffserv and Tunnels Overview
Tunnels range in complexity from simple IP-in-IP tunnels [RFC-2003] Tunnels range in complexity from simple IP-in-IP tunnels [RFC-2003]
to more complex multi-protocol tunnels, such as IP in PPP in L2TP in to more complex multi-protocol tunnels, such as IP in PPP in L2TP in
IPsec transport mode [RFC-1661, RFC-2401, RFC-2661]. The most IPSec transport mode [RFC-1661, RFC-2401, RFC-2661]. The most
general tunnel configuration is one in which the tunnel is not end- 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 to-end, i.e., the ingress and egress nodes are not the source and
destination nodes for traffic carried by the tunnel; such a tunnel destination nodes for traffic carried by the tunnel; such a tunnel
may carry traffic with multiple sources and destinations. If the may carry traffic with multiple sources and destinations. If the
ingress node is the end-to-end source of all traffic in the tunnel, ingress node is the end-to-end source of all traffic in the tunnel,
the result is a simplified configuration to which much of the the result is a simplified configuration to which much of the
analysis and guidance in this document are applicable, and likewise analysis and guidance in this document are applicable, and likewise
if the egress node is the end-to-end destination. if the egress node is the end-to-end destination.
A primary concern for differentiated services is the use of the A primary concern for differentiated services is the use of the
skipping to change at page 3, line 17 skipping to change at page 3, line 17
to describe the behavioral properties of a PHB that are important to to describe the behavioral properties of a PHB that are important to
preserve when traffic is tunneled and allow the outer IP header to preserve when traffic is tunneled and allow the outer IP header to
be marked in any fashion that is sufficient to preserve those be marked in any fashion that is sufficient to preserve those
properties. properties.
This document proposes an approach in which traffic conditioning is This document proposes an approach in which traffic conditioning is
performed in series with tunnel ingress or egress processing, rather performed in series with tunnel ingress or egress processing, rather
than in parallel. This approach does not create any additional than in parallel. This approach does not create any additional
paths that transmit information across a tunnel endpoint, as all paths that transmit information across a tunnel endpoint, as all
diffserv information is contained in the DSCPs in the IP headers. diffserv information is contained in the DSCPs in the IP headers.
The IPsec architecture [RFC-2401] requires that this be the case to The IPSec architecture [RFC-2401] requires that this be the case to
preserve security properties at the egress of IPsec tunnels, but preserve security properties at the egress of IPSec tunnels, but
this approach also avoids complicating diffserv traffic conditioning this approach also avoids complicating diffserv traffic conditioning
blocks by introducing out-of-band inputs. A consequence of this blocks by introducing out-of-band inputs. A consequence of this
approach is that the last sentence of Guideline G.7 in Section 3 of approach is that the last sentence of Guideline G.7 in Section 3 of
[RFC-2475] becomes moot because there are no tunnel egress diffserv [RFC-2475] becomes moot because there are no tunnel egress diffserv
components that have access to both the inner and outer DSCPs. components that have access to both the inner and outer DSCPs.
An additional advantage of this traffic conditioning approach is An additional advantage of this traffic conditioning approach is
that it places no additional restrictions on the positioning of that it places no additional restrictions on the positioning of
diffserv domain boundaries with respect to traffic conditioning and diffserv domain boundaries with respect to traffic conditioning and
tunnel encapsulation/decapsulation components. An interesting class tunnel encapsulation/decapsulation components. An interesting class
skipping to change at page 6, line 8 skipping to change at page 6, line 8
tunnels may need to limit the functionality at [2 - Outer] as tunnels may need to limit the functionality at [2 - Outer] as
discussed further in Section 5.1. In the absence of reordering discussed further in Section 5.1. In the absence of reordering
sensitivity, no additional restrictions should be necessary, sensitivity, no additional restrictions should be necessary,
although traffic conditioning at [2 - Outer] may be responsible for although traffic conditioning at [2 - Outer] may be responsible for
remarking traffic to be compatible with the next diffserv domain remarking traffic to be compatible with the next diffserv domain
that the tunneled traffic enters. that the tunneled traffic enters.
In contrast, the [3 - Inner] location is difficult to utilize for In contrast, the [3 - Inner] location is difficult to utilize for
traffic conditioning because it requires functionality that reaches traffic conditioning because it requires functionality that reaches
inside the packet to operate on the inner IP header. This is inside the packet to operate on the inner IP header. This is
impossible for IPsec tunnels and any other tunnels that are impossible for IPSec tunnels and any other tunnels that are
encrypted or employ cryptographic integrity checks. Hence traffic encrypted or employ cryptographic integrity checks. Hence traffic
conditioning at [3 - Inner] can often only be performed as part of conditioning at [3 - Inner] can often only be performed as part of
tunnel encapsulation processing, complicating both the encapsulation tunnel encapsulation processing, complicating both the encapsulation
and traffic conditioning implementations. In many cases, the and traffic conditioning implementations. In many cases, the
desired functionality can be achieved via a combination of traffic desired functionality can be achieved via a combination of traffic
conditioners in the other two locations, both of which can be conditioners in the other two locations, both of which can be
specified and implemented independently of tunnel encapsulation. specified and implemented independently of tunnel encapsulation.
An exception for which traffic conditioning functionality is An exception for which traffic conditioning functionality is
necessary at [3 - Inner] occurs when the DS-incapable tunnel egress necessary at [3 - Inner] occurs when the DS-incapable tunnel egress
skipping to change at page 6, line 54 skipping to change at page 6, line 54
burst control even if DSCP values are not changed. burst control even if DSCP values are not changed.
5.1 Ingress DSCP Selection and Reordering 5.1 Ingress DSCP Selection and Reordering
It may be necessary or desirable to limit the DS behavior aggregates It may be necessary or desirable to limit the DS behavior aggregates
that utilize an IP tunnel that is sensitive to packet reordering that utilize an IP tunnel that is sensitive to packet reordering
within the tunnel. The diffserv architecture allows packets to be within the tunnel. The diffserv architecture allows packets to be
reordered when they belong to behavior aggregates among which reordered when they belong to behavior aggregates among which
reordering is permitted; for example, reordering is allowed among reordering is permitted; for example, reordering is allowed among
behavior aggregates marked with different Class Selector DSCPs [RFC- behavior aggregates marked with different Class Selector DSCPs [RFC-
2474]. IPsec [RFC-2401] and L2TP [RFC-2661] provide examples of 2474]. IPSec [RFC-2401] and L2TP [RFC-2661] provide examples of
tunnels that are sensitive to packet reordering. If IPsec's anti- tunnels that are sensitive to packet reordering. If IPSec's anti-
replay support is configured, audit events are generated in response replay support is configured, audit events are generated in response
to packet reordering that exceeds certain levels, with the audit to packet reordering that exceeds certain levels, with the audit
events indicating potential security issues. L2TP can be configured events indicating potential security issues. L2TP can be configured
to restore the ingress ordering of packets at tunnel egress, not to restore the ingress ordering of packets at tunnel egress, not
only undoing any differentiation based on reordering within the only undoing any differentiation based on reordering within the
tunnel, but also negatively impacting the traffic (e.g., by tunnel, but also negatively impacting the traffic (e.g., by
increasing latency). The uniform model cannot be completely applied increasing latency). The uniform model cannot be completely applied
to such tunnels, as arbitrary mixing of traffic from different to such tunnels, as arbitrary mixing of traffic from different
behavior aggregates can cause these undesirable interactions. behavior aggregates can cause these undesirable interactions.
skipping to change at page 7, line 23 skipping to change at page 7, line 23
reordering with reordering-sensitive tunnel protocols and features reordering with reordering-sensitive tunnel protocols and features
is not to employ the reordering-sensitive protocols or features, but is not to employ the reordering-sensitive protocols or features, but
this is often not desirable or even possible. When such protocols this is often not desirable or even possible. When such protocols
or features are used, interactions can be avoided by ensuring that or features are used, interactions can be avoided by ensuring that
the aggregated flows through the tunnel are marked at [2 - Outer] to the aggregated flows through the tunnel are marked at [2 - Outer] to
constitute a single ordered aggregate (i.e., the PHBs used share an constitute a single ordered aggregate (i.e., the PHBs used share an
ordering constraint that prevents packets from being reordered). ordering constraint that prevents packets from being reordered).
Tunnel protocol specifications should indicate both whether and Tunnel protocol specifications should indicate both whether and
under what circumstances a tunnel should be restricted to a single under what circumstances a tunnel should be restricted to a single
ordered aggregate as well as the consequences of deviating from that ordered aggregate as well as the consequences of deviating from that
restriction. For the IPsec and L2TP examples discussed above, the restriction. For the IPSec and L2TP examples discussed above, the
specifications should restrict each tunnel to a single ordered specifications should restrict each tunnel to a single ordered
aggregate when protocol features sensitive to reordering are aggregate when protocol features sensitive to reordering are
configured, and may adopt the approach of restricting all tunnels in configured, and may adopt the approach of restricting all tunnels in
order to avoid unexpected consequences of changes in protocol order to avoid unexpected consequences of changes in protocol
features or composition of tunneled traffic. Diffserv features or composition of tunneled traffic. Diffserv
implementations should not attempt to look within such tunnels to implementations should not attempt to look within such tunnels to
provide reordering-based differentiation to the encapsulated provide reordering-based differentiation to the encapsulated
microflows. If reordering-based differentiation is desired within microflows. If reordering-based differentiation is desired within
such tunnels, multiple parallel tunnels between the same endpoints such tunnels, multiple parallel tunnels between the same endpoints
should be used. This enables reordering among packets in different should be used. This enables reordering among packets in different
tunnels to coexist with an absence of packet reordering within each tunnels to coexist with an absence of packet reordering within each
individual tunnel. The additional management complexity introduced individual tunnel. For IPSec and related security protocols, there
by multiple tunnels should be considered in determining whether and is no cryptographic advantage to using a single tunnel for multiple
where to deploy them. ordered aggregates rather than multiple tunnels because any traffic
analysis made possible by the use of multiple tunnels can also be
performed based on the DSCPs in the outer headers of traffic in a
single tunnel. In general, the additional resources required to
support multiple tunnels (e.g., cryptographic contexts), and the
impact of multiple tunnels on network management should be
considered in determining whether and where to deploy them.
5.2 Tunnel Selection 5.2 Tunnel Selection
The behavioral characteristics of a tunnel are an important The behavioral characteristics of a tunnel are an important
consideration in determining what traffic should utilize the tunnel. consideration in determining what traffic should utilize the tunnel.
This involves the service provisioning policies of all the This involves the service provisioning policies of all the
participating domains, not just the PHBs and DSCPs marked on the participating domains, not just the PHBs and DSCPs marked on the
traffic at [2 - Outer]. For example, while it is in general a bad traffic at [2 - Outer]. For example, while it is in general a bad
idea to tunnel EF PHB traffic via a Default PHB tunnel, this can be idea to tunnel EF PHB traffic via a Default PHB tunnel, this can be
acceptable if the EF traffic is the only traffic that utilizes the acceptable if the EF traffic is the only traffic that utilizes the
skipping to change at page 9, line 18 skipping to change at page 9, line 25
selecting either the inner or outer DSCP value at decapsulation is selecting either the inner or outer DSCP value at decapsulation is
recommended, leaving the full generality of traffic conditioning recommended, leaving the full generality of traffic conditioning
functionality to be implemented at [5 - Outer] and/or [6 - After]. functionality to be implemented at [5 - Outer] and/or [6 - After].
Tunnels should support static selection of one or the other DSCP Tunnels should support static selection of one or the other DSCP
value at tunnel egress. The rationale for this approach is usually value at tunnel egress. The rationale for this approach is usually
only one of the two DSCP values contains useful information. The only one of the two DSCP values contains useful information. The
conceptual model for the tunnel provides a strong indication of conceptual model for the tunnel provides a strong indication of
which one contains useful information; the outer DSCP value usually which one contains useful information; the outer DSCP value usually
contains the useful information for tunnels based on the uniform contains the useful information for tunnels based on the uniform
model, and the inner DSCP value usually contains the useful model, and the inner DSCP value usually contains the useful
information for tunnels based on the pipe model. IPsec tunnels are information for tunnels based on the pipe model. IPSec tunnels are
usually based on the pipe model, and for security reasons are usually based on the pipe model, and for security reasons are
required to select the inner DSCP value; they should not be required to select the inner DSCP value; they should not be
configured to select the outer DSCP value in the absence of an configured to select the outer DSCP value in the absence of an
adequate security analysis of the resulting risks and implications. adequate security analysis of the resulting risks and implications.
6.2 Egress DSCP Selection Case Study 6.2 Egress DSCP Selection Case Study
As a sanity check on the egress DSCP selection approach proposed As a sanity check on the egress DSCP selection approach proposed
above, this subsection considers a situation in which a more complex above, this subsection considers a situation in which a more complex
approach might be required. Statically choosing a single DSCP value approach might be required. Statically choosing a single DSCP value
skipping to change at page 10, line 39 skipping to change at page 10, line 45
8. Security Considerations 8. Security Considerations
The security considerations for the diffserv architecture discussed The security considerations for the diffserv architecture discussed
in [RFC-2474, RFC-2475] apply when tunnels are present. One of the in [RFC-2474, RFC-2475] apply when tunnels are present. One of the
requirements is that a tunnel egress node in the interior of a requirements is that a tunnel egress node in the interior of a
diffserv domain is the DS ingress node for traffic exiting the diffserv domain is the DS ingress node for traffic exiting the
tunnel, and is responsible for performing appropriate traffic tunnel, and is responsible for performing appropriate traffic
conditioning. The primary security implication is that the traffic conditioning. The primary security implication is that the traffic
conditioning is responsible for dealing with theft- and denial-of- conditioning is responsible for dealing with theft- and denial-of-
service threats posed to the diffserv domain by traffic exiting from service threats posed to the diffserv domain by traffic exiting from
the tunnel. The IPsec architecture [RFC-2401] places a further the tunnel. The IPSec architecture [RFC-2401] places a further
restriction on tunnel egress processing; the outer header is to be restriction on tunnel egress processing; the outer header is to be
discarded unless the properties of the traffic conditioning to be discarded unless the properties of the traffic conditioning to be
applied are known and have been adequately analyzed for security applied are known and have been adequately analyzed for security
vulnerabilities. This includes both the [5 - Outer] and [6 - After] vulnerabilities. This includes both the [5 - Outer] and [6 - After]
traffic conditioning blocks on the tunnel egress node, if present, traffic conditioning blocks on the tunnel egress node, if present,
and may involve traffic conditioning performed by an upstream DS- and may involve traffic conditioning performed by an upstream DS-
edge node that is the DS domain ingress node for the encapsulated edge node that is the DS domain ingress node for the encapsulated
tunneled traffic. tunneled traffic.
9. References 9. References
 End of changes. 10 change blocks. 
14 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/