idnits 2.17.1 draft-ietf-diffserv-tunnels-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-2474,RFC-2475], [RFC-2475]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 569 has weird spacing: '...cations who h...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2000) is 8676 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1933 (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Differentiated Services WG D. Black 2 INTERNET-DRAFT EMC Corporation 3 Document: draft-ietf-diffserv-tunnels-02.txt July 2000 5 Differentiated Services and Tunnels 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance 10 with all provisions of Section 10 of RFC2026. Internet-Drafts are 11 working documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Discussion and suggestions for improvement are requested. This 27 draft will expire before January, 2001. Distribution of this draft 28 is unlimited. 30 1. Abstract 32 This draft considers the interaction of Differentiated Services 33 (diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms. 34 The discussion of tunnels in the diffserv architecture [RFC-2475] 35 provides insufficient guidance to tunnel designers and implementers. 36 This document describes two conceptual models for the interaction of 37 diffserv with IP tunnels and employs them to explore the resulting 38 configurations and combinations of functionality. An important 39 consideration is how and where it is appropriate to perform diffserv 40 traffic conditioning in the presence of tunnel encapsulation and 41 decapsulation. A few simple mechanisms are also proposed that limit 42 the complexity that tunnels would otherwise add to the diffserv 43 traffic conditioning model. Security considerations for IPSec 44 tunnels limit the possible functionality in some circumstances. 46 2. Conventions used in this document 48 An IP tunnel encapsulates IP traffic in another IP header as it 49 passes through the tunnel; the presence of these two IP headers is a 50 defining characteristic of IP tunnels, although there may be 51 additional headers inserted between the two IP headers. The inner 52 IP header is that of the original traffic; an outer IP header is 53 attached and detached at tunnel endpoints. In general, intermediate 54 network nodes between tunnel endpoints operate solely on the outer 55 IP header, and hence diffserv-capable intermediate nodes access and 56 modify only the DSCP field in the outer IP header. The terms 57 "tunnel" and "IP tunnel" are used interchangeably in this document. 58 For simplicity, this document does not consider tunnels other than 59 IP tunnels (i.e., for which there is no encapsulating IP header), 60 such as MPLS paths and "tunnels" formed by encapsulation in layer 2 61 (link) headers, although the conceptual models and approach 62 described here may be useful in understanding the interaction of 63 diffserv with such tunnels. 65 This analysis considers tunnels to be unidirectional; bi-directional 66 tunnels are considered to be composed of two unidirectional tunnels 67 carrying traffic in opposite directions between the same tunnel 68 endpoints. A tunnel consists of an ingress where traffic enters the 69 tunnel and is encapsulated by the addition of the outer IP header, 70 an egress where traffic exits the tunnel and is decapsulated by the 71 removal of the outer IP header, and intermediate nodes through which 72 tunneled traffic passes between the ingress and egress. This 73 document does not make any assumptions about routing and forwarding 74 of tunnel traffic, and in particular assumes neither the presence 75 nor the absence of route pinning in any form. 77 3. Diffserv and Tunnels Overview 79 Tunnels range in complexity from simple IP-in-IP tunnels [RFC-2003] 80 to more complex multi-protocol tunnels, such as IP in PPP in L2TP in 81 IPSec transport mode [RFC-1661, RFC-2401, RFC-2661]. The most 82 general tunnel configuration is one in which the tunnel is not end- 83 to-end, i.e., the ingress and egress nodes are not the source and 84 destination nodes for traffic carried by the tunnel; such a tunnel 85 may carry traffic with multiple sources and destinations. If the 86 ingress node is the end-to-end source of all traffic in the tunnel, 87 the result is a simplified configuration to which much of the 88 analysis and guidance in this document are applicable, and likewise 89 if the egress node is the end-to-end destination. 91 A primary concern for differentiated services is the use of the 92 Differentiated Services Code Point (DSCP) in the IP header [RFC- 93 2474, RFC-2475]. The diffserv architecture permits intermediate 94 nodes to examine and change the value of the DSCP, which may result 95 in the DSCP value in the outer IP header being modified between 96 tunnel ingress and egress. When a tunnel is not end-to-end, there 97 are circumstances in which it may be desirable to propagate the DSCP 98 and/or some of the information that it contains to the outer IP 99 header on ingress and/or back to inner IP header on egress. The 100 current situation facing tunnel implementers is that [RFC-2475] 101 offers incomplete guidance. Guideline G.7 in Section 3 is an 102 example, as some PHB specifications have followed it by explicitly 103 specifying the PHBs that may be used in the outer IP header for 104 tunneled traffic. This is overly restrictive; for example, if a 105 specification requires that the same PHB be used in both the inner 106 and outer IP headers, traffic conforming to that specification 107 cannot be tunneled across domains or networks that do not support 108 that PHB. A more flexible approach that should be used instead is 109 to describe the behavioral properties of a PHB that are important to 110 preserve when traffic is tunneled and allow the outer IP header to 111 be marked in any fashion that is sufficient to preserve those 112 properties. 114 This document proposes an approach in which traffic conditioning is 115 performed in series with tunnel ingress or egress processing, rather 116 than in parallel. This approach does not create any additional 117 paths that transmit information across a tunnel endpoint, as all 118 diffserv information is contained in the DSCPs in the IP headers. 119 The IPSec architecture [RFC-2401] requires that this be the case to 120 preserve security properties at the egress of IPSec tunnels, but 121 this approach also avoids complicating diffserv traffic conditioning 122 blocks by introducing out-of-band inputs. A consequence of this 123 approach is that the last sentence of Guideline G.7 in Section 3 of 124 [RFC-2475] becomes moot because there are no tunnel egress diffserv 125 components that have access to both the inner and outer DSCPs. 127 An additional advantage of this traffic conditioning approach is 128 that it places no additional restrictions on the positioning of 129 diffserv domain boundaries with respect to traffic conditioning and 130 tunnel encapsulation/decapsulation components. An interesting class 131 of configurations involves a diffserv domain boundary that passes 132 through (i.e., divides) a network node; such a boundary can be split 133 to create a DMZ-like region between the domains that contains the 134 tunnel encapsulation or decapsulation processing. Diffserv traffic 135 conditioning is not appropriate for such a DMZ-like region, as 136 traffic conditioning is part of the operation and management of 137 diffserv domains. 139 4. Conceptual Models for Diffserv Tunnels 141 This analysis introduces two conceptual traffic conditioning models 142 for IP tunnels based on an initial discussion that assumes a fully 143 diffserv-capable network. Configurations in which this is not the 144 case are taken up in Section 4.2. 146 4.1 Conceptual Models for Fully DS-capable Configurations 148 The first conceptual model is a uniform model that views IP tunnels 149 as artifacts of the end to end path from a traffic conditioning 150 standpoint; tunnels may be necessary mechanisms to get traffic to 151 its destination(s), but have no significant impact on traffic 152 conditioning. In this model, any packet has exactly one DS Field 153 that is used for traffic conditioning at any point, namely the DS 154 Field in the outermost IP header; any others are ignored. 155 Implementations of this model copy the DSCP value to the outer IP 156 header at encapsulation and copy the outer header's DSCP value to 157 the inner IP header at decapsulation. Use of this model allows IP 158 tunnels to be configured without regard to diffserv domain 159 boundaries because diffserv traffic conditioning functionality is 160 not impacted by the presence of IP tunnels. 162 The second conceptual model is a pipe model that views an IP tunnel 163 as hiding the nodes between its ingress and egress so that they do 164 not participate fully in traffic conditioning. In this model, a 165 tunnel egress node uses traffic conditioning information conveyed 166 from the tunnel ingress by the DSCP value in the inner header, and 167 ignores (i.e., discards) the DSCP value in the outer header. The 168 pipe model cannot completely hide traffic conditioning within the 169 tunnel, as the effects of dropping and shaping at intermediate 170 tunnel nodes may be visible at the tunnel egress and beyond. 172 The pipe model has traffic conditioning consequences when the 173 ingress and egress nodes are in different diffserv domains. In such 174 a situation, the egress node must perform traffic conditioning to 175 ensure that the traffic exiting the tunnel has DSCP values 176 acceptable to the egress diffserv domain (see Section 6 of the 177 diffserv architecture [RFC-2475]). An inter-domain TCA (Traffic 178 Conditioning Agreement) between the diffserv domains containing the 179 tunnel ingress and egress nodes may be used to reduce or eliminate 180 egress traffic conditioning. Complete elimination of egress traffic 181 conditioning requires that the diffserv domains at ingress and 182 egress have compatible service provisioning policies for the 183 tunneled traffic and support all of the PHB groups and DSCP values 184 used for that traffic in a consistent fashion. Examples of this 185 situation are provided by some virtual private network tunnels; it 186 may be useful to view such tunnels as linking the diffserv domains 187 at their endpoints into a diffserv region by making the tunnel 188 endpoints virtually contiguous even though they may be physically 189 separated by intermediate network nodes. 191 The pipe model is also appropriate for situations in which the DSCP 192 itself carries information through the tunnel. For example, if 193 transit between two domains is obtained via a path that uses the EF 194 PHB [RFC-2598], the drop precedence information in the AF PHB DSCP 195 values [RFC-2597] will be lost unless something is done to preserve 196 it; an IP tunnel is one possible preservation mechanism. A path 197 that crosses one or more non-diffserv domains between its DS-capable 198 endpoints may experience a similar information loss phenomenon if a 199 tunnel is not used due to the limited set of DSCP codepoints that 200 are compatible with such domains. 202 4.2 Considerations for Partially DS-capable Configurations 204 If only the tunnel egress node is DS-capable, [RFC-2475] requires 205 the egress node to perform any edge traffic conditioning needed by 206 the diffserv domain for tunneled traffic entering from outside the 207 domain. If the egress node would not otherwise be a DS edge node, 208 one way to meet this requirement is to perform edge traffic 209 conditioning at an appropriate upstream DS edge node or nodes within 210 the tunnel, and copy the DSCP value from the outer IP header to the 211 inner IP header as part of tunnel decapsulation processing; this 212 applies the uniform model to the portion of the tunnel within the 213 egress node's diffserv domain. A second alternative is to discard 214 the outer DSCP value as part of decapsulation processing, reducing 215 the resulting traffic conditioning problem and requirements to those 216 of an ordinary DS ingress node. This applies the pipe model to the 217 portion of the tunnel within the egress node's diffserv domain and 218 hence the adjacent upstream node for DSCP marking purposes is the 219 tunnel ingress node, rather than the immediately upstream 220 intermediate tunnel node. 222 If only the tunnel ingress node is DS-capable, [RFC-2475] requires 223 that traffic emerging from the tunnel be compatible with the network 224 at the tunnel egress. If tunnel decapsulation processing discards 225 the outer header's DSCP value without changing the inner header's 226 DSCP value, the DS-capable tunnel ingress node is obligated to set 227 the inner header's DSCP to a value compatible with the network at 228 the tunnel egress. The value 0 (DSCP of 000000) is used for this 229 purpose by a number of existing tunnel implementations. If the 230 egress network implements IP precedence as specified in [RFC-791], 231 then some or all of the eight class selector DSCP codepoints defined 232 in [RFC-2474] may be usable. DSCP codepoints other than the class 233 selectors are not generally suitable for this purpose, as correct 234 operation would usually require diffserv functionality at the DS- 235 incapable tunnel egress node. 237 5. Ingress Functionality 239 As described in Section 3 above, this analysis is based on an 240 approach in which diffserv functionality and/or out-of-band 241 communication paths are not placed in parallel with tunnel 242 encapsulation processing. This allows three possible locations for 243 traffic conditioning with respect to tunnel encapsulation 244 processing, as shown in the following diagram that depicts the flow 245 of IP headers through tunnel encapsulation: 247 +--------- [2 - Outer] -->> 248 / 249 / 250 >>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->> 252 Traffic conditioning at [1 - Before] is logically separate from the 253 tunnel, as it is not impacted by the presence of tunnel 254 encapsulation, and hence should be allowed by tunnel designs and 255 specifications. Traffic conditioning at [2 - Outer] may interact 256 with tunnel protocols that are sensitive to packet reordering; such 257 tunnels may need to limit the functionality at [2 - Outer] as 258 discussed further in Section 5.1. In the absence of reordering 259 sensitivity, no additional restrictions should be necessary, 260 although traffic conditioning at [2 - Outer] may be responsible for 261 remarking traffic to be compatible with the next diffserv domain 262 that the tunneled traffic enters. 264 In contrast, the [3 - Inner] location is difficult to utilize for 265 traffic conditioning because it requires functionality that reaches 266 inside the packet to operate on the inner IP header. This is 267 impossible for IPSec tunnels and any other tunnels that are 268 encrypted or employ cryptographic integrity checks. Hence traffic 269 conditioning at [3 - Inner] can often only be performed as part of 270 tunnel encapsulation processing, complicating both the encapsulation 271 and traffic conditioning implementations. In many cases, the 272 desired functionality can be achieved via a combination of traffic 273 conditioners in the other two locations, both of which can be 274 specified and implemented independently of tunnel encapsulation. 276 An exception for which traffic conditioning functionality is 277 necessary at [3 - Inner] occurs when the DS-incapable tunnel egress 278 discards the outer IP header as part of decapsulation processing, 279 and hence the DSCP in the inner IP header must be compatible with 280 the egress network. Setting the inner DSCP to 0 as part of 281 encapsulation addresses most of these cases, and the class selector 282 DCSP codepoint values are also useful for this purpose, as they are 283 valid for networks that support IP precedence [RFC-791]. 285 The following table summarizes the achievable relationships among 286 the before (B), outer (O), and inner (I) DSCP values and the 287 corresponding locations of traffic conditioning logic. 289 Relationship Traffic Conditioning Location(s) 290 ------------ -------------------------------- 291 B = I = O No traffic conditioning required 292 B != I = O [1 - Before] 293 B = I != O [2 - Outer] 294 B = O != I Limited support as part of encapsulation: 295 I can be set to 000000 or possibly one of 296 the class selector code points. 297 B != I != O Some combination of the above three scenarios. 299 A combination of [1 - Before] and [2 - Outer] is applicable to many 300 cases covered by the last two lines of the table, and may be 301 preferable to deploying functionality at [3 - Inner]. Traffic 302 conditioning may still be required for purposes such as rate and 303 burst control even if DSCP values are not changed. 305 5.1 Ingress DSCP Selection and Reordering 307 It may be necessary or desirable to limit the DS behavior aggregates 308 that utilize an IP tunnel that is sensitive to packet reordering 309 within the tunnel. The diffserv architecture allows packets to be 310 reordered when they belong to behavior aggregates among which 311 reordering is permitted; for example, reordering is allowed among 312 behavior aggregates marked with different Class Selector DSCPs [RFC- 313 2474]. IPSec [RFC-2401] and L2TP [RFC-2661] provide examples of 314 tunnels that are sensitive to packet reordering. If IPSec's anti- 315 replay support is configured, audit events are generated in response 316 to packet reordering that exceeds certain levels, with the audit 317 events indicating potential security issues. L2TP can be configured 318 to restore the ingress ordering of packets at tunnel egress, not 319 only undoing any differentiation based on reordering within the 320 tunnel, but also negatively impacting the traffic (e.g., by 321 increasing latency). The uniform model cannot be completely applied 322 to such tunnels, as arbitrary mixing of traffic from different 323 behavior aggregates can cause these undesirable interactions. 325 The simplest method of avoiding undesirable interactions of 326 reordering with reordering-sensitive tunnel protocols and features 327 is not to employ the reordering-sensitive protocols or features, but 328 this is often not desirable or even possible. When such protocols 329 or features are used, interactions can be avoided by ensuring that 330 the aggregated flows through the tunnel are marked at [2 - Outer] to 331 constitute a single ordered aggregate (i.e., the PHBs used share an 332 ordering constraint that prevents packets from being reordered). 333 Tunnel protocol specifications should indicate both whether and 334 under what circumstances a tunnel should be restricted to a single 335 ordered aggregate as well as the consequences of deviating from that 336 restriction. For the IPSec and L2TP examples discussed above, the 337 specifications should restrict each tunnel to a single ordered 338 aggregate when protocol features sensitive to reordering are 339 configured, and may adopt the approach of restricting all tunnels in 340 order to avoid unexpected consequences of changes in protocol 341 features or composition of tunneled traffic. Diffserv 342 implementations should not attempt to look within such tunnels to 343 provide reordering-based differentiation to the encapsulated 344 microflows. If reordering-based differentiation is desired within 345 such tunnels, multiple parallel tunnels between the same endpoints 346 should be used. This enables reordering among packets in different 347 tunnels to coexist with an absence of packet reordering within each 348 individual tunnel. For IPSec and related security protocols, there 349 is no cryptographic advantage to using a single tunnel for multiple 350 ordered aggregates rather than multiple tunnels because any traffic 351 analysis made possible by the use of multiple tunnels can also be 352 performed based on the DSCPs in the outer headers of traffic in a 353 single tunnel. In general, the additional resources required to 354 support multiple tunnels (e.g., cryptographic contexts), and the 355 impact of multiple tunnels on network management should be 356 considered in determining whether and where to deploy them. 358 5.2 Tunnel Selection 360 The behavioral characteristics of a tunnel are an important 361 consideration in determining what traffic should utilize the tunnel. 362 This involves the service provisioning policies of all the 363 participating domains, not just the PHBs and DSCPs marked on the 364 traffic at [2 - Outer]. For example, while it is in general a bad 365 idea to tunnel EF PHB traffic via a Default PHB tunnel, this can be 366 acceptable if the EF traffic is the only traffic that utilizes the 367 tunnel, and the tunnel is provisioned in a fashion adequate to 368 preserve the behavioral characteristics required by the EF PHB. 370 Service provisioning policies are responsible for preventing 371 mismatches such as forwarding EF traffic via an inadequately 372 provisioned Default tunnel. When multiple parallel tunnels with 373 different behavioral characteristics are available, service 374 provisioning policies are responsible for determining which flows 375 should use which tunnels. Among the possibilities is a coarse 376 version of the uniform tunnel model in which the inner DSCP value is 377 used to select a tunnel that will forward the traffic using a 378 behavioral aggregate that is compatible with the traffic's PHB. 380 6. Egress Functionality 382 As described in Section 3 above, this analysis is based on an 383 approach in which diffserv functionality and/or out-of-band 384 communication paths are not placed in parallel with tunnel 385 encapsulation processing. This allows three possible locations for 386 traffic conditioners with respect to tunnel decapsulation 387 processing, as shown in the following diagram that depicts the flow 388 of IP headers through tunnel decapsulation: 390 >>----[5 - Outer]-------------+ 391 \ 392 \ 393 >>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->> 395 Traffic conditioning at [5 - Outer] and [6 - After] is logically 396 separate from the tunnel, as it is not impacted by the presence of 397 tunnel decapsulation. Tunnel designs and specifications should 398 allow diffserv traffic conditioning at these locations. Such 399 conditioning can be viewed as independent of the tunnel, i.e., 400 [5 - Outer] is traffic conditioning that takes place prior to tunnel 401 egress, and [6 - After] is traffic conditioning that takes place 402 after egress decapsulation. An important exception is that the 403 configuration of a tunnel (e.g., the absence of traffic conditioning 404 at tunnel ingress) and/or the diffserv domains involved may require 405 that all traffic exiting a tunnel pass through diffserv traffic 406 conditioning to fulfill the diffserv edge node traffic conditioning 407 responsibilities of the tunnel egress node. Tunnel designers are 408 strongly encouraged to include the ability to require that all 409 traffic exiting a tunnel pass through diffserv traffic conditioning 410 in order to ensure that traffic exiting the node is compatible with 411 the egress node's diffserv domain. 413 In contrast, the [4 - Inner] location is difficult to employ for 414 traffic conditioning because it requires reaching inside the packet 415 to operate on the inner IP header. Unlike the [3 - Inner] case for 416 encapsulation, there is no need for functionality to be performed at 417 [4- Inner], as diffserv traffic conditioning can be appended to the 418 tunnel decapsulation (i.e., performed at [6 - After]). 420 6.1 Egress DSCP Selection 421 The elimination of parallel functionality and data paths from 422 decapsulation causes a potential loss of information. As shown in 423 the above diagram, decapsulation combines and reduces two DSCP 424 values to one DSCP value, losing information in the most general 425 case, even if arbitrary functionality is allowed. Beyond this, 426 allowing arbitrary functionality poses a structural problem, namely 427 that the DSCP value from the outer IP header would have to be 428 presented as an out-of-band input to the traffic conditioning block 429 at [6 - After], complicating the traffic conditioning model. 431 To avoid such complications, the simpler approach of statically 432 selecting either the inner or outer DSCP value at decapsulation is 433 recommended, leaving the full generality of traffic conditioning 434 functionality to be implemented at [5 - Outer] and/or [6 - After]. 435 Tunnels should support static selection of one or the other DSCP 436 value at tunnel egress. The rationale for this approach is usually 437 only one of the two DSCP values contains useful information. The 438 conceptual model for the tunnel provides a strong indication of 439 which one contains useful information; the outer DSCP value usually 440 contains the useful information for tunnels based on the uniform 441 model, and the inner DSCP value usually contains the useful 442 information for tunnels based on the pipe model. IPSec tunnels are 443 usually based on the pipe model, and for security reasons are 444 required to select the inner DSCP value; they should not be 445 configured to select the outer DSCP value in the absence of an 446 adequate security analysis of the resulting risks and implications. 448 6.2 Egress DSCP Selection Case Study 450 As a sanity check on the egress DSCP selection approach proposed 451 above, this subsection considers a situation in which a more complex 452 approach might be required. Statically choosing a single DSCP value 453 may not work well when both DSCPs are carrying information that is 454 relevant to traffic conditioning. 456 As an example, consider a situation in which different AF groups 457 [RFC-2597] are used by the two domains at the tunnel endpoints, and 458 there is an intermediate domain along the tunnel using RFC 791 IP 459 precedences that is transited by setting the DSCP to zero. This 460 situation is shown in the following IP header flow diagram where I 461 is the tunnel ingress node, E is the tunnel egress node and the 462 vertical lines are domain boundaries. The node at the left-hand 463 vertical line sets the DSCP in the outer header to 0 in order to 464 obtain compatibility with the middle domain: 466 | | 467 +-----|-------------------|------+ 468 / | | \ 469 >>-----------I-------|-------------------|--------E---------->> 470 | | 471 Ingress DS Domain RFC 791 Egress DS domain 472 IP Precedence 473 Domain 475 In this situation, the DS edge node for the egress domain (i.e., the 476 node at the right-hand vertical line) can select the appropriate AF 477 group (e.g., via an MF classifier), but cannot reconstruct the drop 478 precedence information that was removed from the outer header when 479 it transited the RFC 791 domain (although it can construct new 480 information via metering and marking). The original drop precedence 481 information is preserved in the inner IP header's DSCP, and could be 482 combined at the tunnel egress with the AF class selection 483 communicated via the outer IP header's DSCP. The marginal benefit 484 of being able to reuse the original drop precedence information as 485 opposed to constructing new drop precedence markings does not 486 justify the additional complexity introduced into tunnel egress 487 traffic conditioners by making both DSCP values available to traffic 488 conditioning at [6 - After]. 490 7. Diffserv and Protocol Translators 492 A related issue involves protocol translators, including those 493 employing the Stateless IP/ICMP Translation Algorithm [RFC-2765]. 494 These translators are not tunnels because they do not add or remove 495 a second IP header to/from packets (e.g., in contrast to IPv6 over 496 IPv4 tunnels [RFC-1933]) and hence do not raise concerns of 497 information propagation between inner and outer IP headers. The 498 primary interaction between translators and diffserv is that the 499 translation boundary is likely to also be a diffserv domain boundary 500 (e.g., the IPv4 and IPv6 domains may have different policies for 501 traffic conditioning and DSCP usage), and hence such translators 502 should allow the insertion of diffserv edge node processing 503 (including traffic conditioning) both before and after the 504 translation processing. 506 8. Security Considerations 508 The security considerations for the diffserv architecture discussed 509 in [RFC-2474, RFC-2475] apply when tunnels are present. One of the 510 requirements is that a tunnel egress node in the interior of a 511 diffserv domain is the DS ingress node for traffic exiting the 512 tunnel, and is responsible for performing appropriate traffic 513 conditioning. The primary security implication is that the traffic 514 conditioning is responsible for dealing with theft- and denial-of- 515 service threats posed to the diffserv domain by traffic exiting from 516 the tunnel. The IPSec architecture [RFC-2401] places a further 517 restriction on tunnel egress processing; the outer header is to be 518 discarded unless the properties of the traffic conditioning to be 519 applied are known and have been adequately analyzed for security 520 vulnerabilities. This includes both the [5 - Outer] and [6 - After] 521 traffic conditioning blocks on the tunnel egress node, if present, 522 and may involve traffic conditioning performed by an upstream DS- 523 edge node that is the DS domain ingress node for the encapsulated 524 tunneled traffic. 526 9. References 528 [RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, September 529 1981. 531 [RFC-1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD 51, 532 RFC 1661, July 1994. 534 [RFC-1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for 535 IPv6 Hosts and Routers", RFC 1933, April 1996. 537 [RFC-2003] C. Perkins, "IP Encapsulation within IP,", RFC 2003, 538 October 1996. 540 [RFC-2401] S. Kent and R. Atkinson, "Security Architecture for the 541 Internet Protocol", RFC 2401, November 1998. 543 [RFC-2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition 544 of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 545 Headers", RFC 2474, December 1998. 547 [RFC-2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and 548 W. Weiss, "An Architecture for Differentiated Services", RFC 2475, 549 December 1998. 551 [RFC-2597] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, 552 "Assured Forwarding PHB Group", RFC 2597. June 1999. 554 [RFC-2598] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited 555 Forwarding PHB", RFC 2598, June 1999. 557 [RFC-2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, 558 and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC 2661, 559 August 1999. 561 [RFC-2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm 562 (SIIT)", RFC 2765. February, 2000. 564 10. Acknowledgments 566 Some of this material is based on discussions with Brian Carpenter, 567 and in particular his presentation on this topic to the diffserv WG 568 during the summer 1999 IETF meeting in Oslo. Credit is also due to 569 a number of people working on tunnel specifications who have 570 discovered limitations of the diffserv architecture [RFC-2475] in 571 the area of tunnels. Their patience with the time it has taken to 572 address this set of issues is greatly appreciated. Finally, this 573 material has benefited from discussions within the diffserv WG, both 574 in meetings and on the mailing list -- the contributions of 575 participants in those discussions are gratefully acknowledged. 577 11. Author's Address 579 David L. Black 580 EMC Corporation 581 42 South St. 582 Hopkinton, MA 01748 583 Phone: +1 (508) 435-1000 x75140 584 Email: black_david@emc.com