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]
