idnits 2.17.1 draft-black-diffserv-tunnels-00.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. == 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: ---------------------------------------------------------------------------- == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The rationale for the choice of these functions is that of the two DSCP values, one of them usually contains useful information, and the other is of little value. In terms of the conceptual models discussed in Section 3, Discard corresponds to the pipe model, Overwrite corresponds to the uniform model, and the two Conditional operations are motivated by the use of 0 as an "escape value" indicating that the useful information is in the other header's DSCP (see Section 4.2). IPsec tunnels and other tunnels with similar security properties MUST default to Discard, and SHOULD not choose a different function in the absence of an adequate security analysis. -- 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 (October 1999) is 8953 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) == Missing Reference: 'RFC-2575' is mentioned on line 123, but not defined ** Obsolete undefined reference: RFC 2575 (Obsoleted by RFC 3415) ** 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) == Outdated reference: A later version (-08) exists of draft-ietf-ngtrans-siit-06 Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Differentiated Services WG D. Black, EMC Corporation 2 INTERNET-DRAFT 3 Document: draft-black-diffserv-tunnels-00.txt October 1999 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. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 A revised version of this draft document will be submitted to the 29 RFC editor as a Proposed Standard for the Internet Community. 30 Discussion and suggestions for improvement are requested. This 31 document will expire before May, 2000. 33 Distribution of this draft is unlimited. 35 1. Abstract 37 This draft discusses the interaction of Differentiated Services 38 (diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms. 39 The discussion of tunnels in the diffserv architecture [RFC-2475] 40 has been found to provide insufficient guidance to tunnel designers 41 and implementers. With the aim of providing such guidance, this 42 document describes two conceptual models for the interaction of 43 diffserv with IP tunnels and employs them to explore the resulting 44 configurations and combinations of functionality. An important 45 consideration is how and where diffserv traffic conditioning should 46 be performed in the presence of tunnel encapsulation/decapsulation. 47 A few simple mechanisms are also proposed that limit the complexity 48 that tunnels would otherwise add to the diffserv traffic 49 conditioning model; these mechanisms are also generally useful in 50 situations where more general traffic conditioning is inappropriate 51 or unavailable. Security considerations for IPsec tunnels place 52 some limits on possible functionality in some circumstances. 54 WARNING: The current status of this draft is highly preliminary; its 55 major purpose is to foster discussion within the working group. 56 Above and beyond the usual cautionary notice about not relying on 57 Internet-Drafts, implementers are specifically warned that 58 significant changes are expected to the contents of this draft. 60 2. Conventions used in this document 62 An IP tunnel encapsulates IP traffic in another IP header as it 63 passes through the tunnel; the presence of these two IP headers is a 64 defining characteristic of IP tunnels. The inner IP header is that 65 of the original traffic; an outer IP header is attached and detached 66 at tunnel endpoints. In general, network nodes within a tunnel 67 operate solely on the outer IP header, and hence diffserv-capable 68 nodes within a tunnel can only access and modify the DSCP field in 69 the outer IP header (e.g., for an encrypted tunnel, interior nodes 70 cannot access the inner IP header). The terms "tunnel" and "IP 71 tunnel" are used interchangeably in this document. 73 This document considers tunnels to be unidirectional; bi-directional 74 tunnels are composed of two unidirectional tunnels carrying traffic 75 in opposite directions between the same pair of tunnel endpoints. A 76 tunnel consists of an ingress where traffic enters the tunnel and is 77 encapsulated by addition of the outer IP header, an egress where 78 traffic exits the tunnel and is decapsulated by removal of the outer 79 IP header, and interior nodes through which tunneled traffic passes 80 between ingress and egress. This document does not make any 81 assumptions about routing and forwarding of tunnel traffic, and in 82 particular neither requires nor forbids route pinning of any form. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 86 this document are to be interpreted as described in [RFC-2119]. 88 Text in single square brackets labeled "Author's note:" (e.g., 89 [Author's note: this is a note from the author.]) is editorial in 90 nature and will be addressed in a future version of this document. 92 3. Diffserv and Tunnels Overview 94 Tunnels range in complexity from simple IP-in-IP tunnels [RFC-2003] 95 to complex multi-protocol tunnels, such as IP in PPP in L2TP in 96 IPsec transport mode [RFC-1661, RFC-2401, RFC-2661]. The most 97 general tunnel configuration is one in which the tunnel is not end- 98 to-end, i.e., the ingress and egress nodes are not the source and 99 destination nodes for traffic carried by the tunnel. If the ingress 100 or egress nodes do coincide with the end-to-end source or 101 destination (respectively), the result is a simplification of this 102 general configuration to which much of the analysis in this document 103 remains applicable. 105 A primary concern for differentiated services is the use of the 106 Differentiated Services Code Point (DSCP) in the IP header; see 107 [RFC-2474, RFC-2475] for more extensive descriptions of the DSCP 108 field and the diffserv architecture. Diffserv permits intermediate 109 nodes to examine and change the value of the DSCP, which may result 110 in the DSCP value in the outer IP header being modified between 111 tunnel ingress and egress. When a tunnel is not end-to-end, there 112 are circumstances in which it may be desirable to propagate the DSCP 113 and/or some of the information that it contains to the outer IP 114 header on ingress and/or back to inner IP header on egress. The 115 current situation facing tunnel implementers is that [RFC-2475] 116 offers some guidance, but is insufficient in detail. In contrast 117 the EF PHB specification [RFC-2598] may be too specific (in 20/20 118 hindsight) because its requirement to use EF in the outer header of 119 tunneled EF packets is unworkable in domains that do not support EF, 120 and excludes other techniques for obtaining sufficient conditioning 121 for tunneled EF traffic. In fairness to the authors of that RFC, 122 this particular requirement responds to a guideline in the diffserv 123 architecture RFC, specifically G.7 in Section 3 of [RFC-2575]; that 124 guideline is also in need of revision as it is based on over- 125 simplified assumptions about how tunnels are deployed with respect 126 to DS domain boundaries. 128 The first issue raised by IP tunnels is the relationship of diffserv 129 domain boundaries and traffic conditioning functionality to tunnel 130 ingress and egress processing. This document proposes an approach 131 in which traffic conditioning is performed in series with tunnel 132 ingress or egress processing, not in parallel. This approach does 133 not create any additional paths that transmit information across a 134 tunnel endpoint; all diffserv information is contained in the DSCPs 135 in the IP headers. IPsec requires that this be the case to preserve 136 security properties at the egress of IPsec tunnels, but this model 137 also avoids introducing out-of-band inputs to diffserv traffic 138 conditioner blocks, which would complicate them. [Author's note: 139 This needs to be updated to coordinate with the conceptual model 140 draft; the conclusion won't change, but more detailed rationale will 141 appear, along with a citation of that document.] Diffserv domain 142 boundaries can then be positioned as appropriate for the set of 143 traffic conditioning blocks and tunnel processing modules. One 144 configuration of interest involves a diffserv domain boundary that 145 passes through (i.e., divides) a network node; it is acceptable to 146 split the boundary to create a DMZ-like region between the domains 147 that contains the tunnel ingress or egress processing. Diffserv 148 traffic conditioning is not appropriate for such a DMZ-like region, 149 as that traffic conditioning is part of the operation and management 150 of one or more diffserv domains. 152 4. Conceptual Models for Diffserv Tunnels 154 There are two important conceptual traffic conditioning models for 155 IP tunnels. For clarity, the initial discussion of these models 156 assumes a fully diffserv-capable network. Configurations in which 157 this is not the case are taken up in Section 4.2. 159 4.1 Conceptual Models for Fully DS-capable Configurations 161 The first conceptual model is a uniform model that views IP tunnels 162 as artifacts of the end to end path from a traffic conditioning 163 standpoint; tunnels may be necessary mechanisms to get traffic to 164 its destination(s), but have no significant impact on traffic 165 conditioning. In this model, any packet has exactly one DS Field 166 that is used for traffic conditioning at any point, namely the DS 167 field in the outermost IP header; all others are ignored. 168 Implementations of this model copy the DSCP value to the outer IP 169 header at encapsulation and copy the outer header's DSCP value to 170 the inner IP header at decapsulation. Support for this model allows 171 IP tunnels to be configured without regard to diffserv domain 172 boundaries because diffserv traffic conditioning functionality is 173 not impacted by the presence of IP tunnels. 175 The second conceptual model is a pipe model that views an IP tunnel 176 as hiding the nodes between its ingress and egress so that they do 177 not participate fully in traffic conditioning. In this model, a 178 tunnel egress node uses traffic conditioning information conveyed 179 from the tunnel ingress by the DSCP value in the inner header, and 180 ignores (i.e., discards) the DSCP value in the outer header. This 181 model cannot completely hide traffic conditioning within the tunnel, 182 as the effects of dropping and shaping at tunnel interior nodes may 183 be visible to nodes beyond the tunnel egress. One class of 184 configurations for which this model is appropriate are situations in 185 which the ingress and egress nodes belong to the same diffserv 186 domain, but the IP tunnel may pass through other domains. In this 187 case, the DSCP values from the ingress node are valid at the egress 188 node. Effective use of this pipe model in configurations other than 189 this single domain case generally require that an inter-domain TCA 190 (Traffic Conditioning Agreement) exist between the diffserv domains 191 containing the tunnel ingress and egress nodes in order to specify 192 the interpretation of the DSCP values in the inner IP headers and 193 the resulting traffic conditioning requirements. 195 The pipe conceptual model is also appropriate for situations in 196 which the DSCP carries information that is destroyed by a node or 197 nodes within the tunnel. For example, if transit between two 198 domains is purchased via a tunnel that uses the EF PHB [RFC-2598], 199 the drop precedence information in the AF PHB DSCP values [RFC-2597] 200 will be destroyed unless something is done to preserve it; an IP 201 tunnel is one possible preservation mechanism. A tunnel that 202 crosses one or more non-diffserv domains between its DS-capable 203 endpoints may experience a similar information destruction 204 phenomenon due to the limited set of DSCP codepoints that are 205 compatible with such domains. 207 4.2 Considerations for Partially DS-capable Configurations 209 If only the tunnel egress node is DS-capable, [RFC-2475] requires 210 that node to take responsibility for any edge traffic conditioning 211 required by the diffserv domain for tunneled traffic from outside 212 the domain. If the egress node would not otherwise be a DS edge 213 node, one way to meet this requirement is to perform edge traffic 214 conditioning at an appropriate upstream DS edge node or nodes within 215 the tunnel, and copy the DSCP value from the outer IP header to the 216 inner IP header as part of tunnel decapsulation processing. This 217 preserves correct operation of the DS domain independent of how the 218 tunnel ingress node handles the DSCP values in the inner IP headers. 219 A second alternative discards the outer DSCP value as part of 220 decapsulation processing, reducing the resulting traffic 221 conditioning problem and requirements to those of an ordinary DS 222 ingress node. One exception that the existence of the tunnel may 223 complicate placing some traffic conditioning responsibility on the 224 upstream node because that node would then be the tunnel ingress 225 node, not the immediately upstream tunnel interior node. 227 If only the tunnel ingress node is DS-capable, [RFC-2475] requires 228 that traffic emerging from the tunnel be compatible with the network 229 at the tunnel egress. If tunnel decapsulation processing discards 230 the outer header's DSCP value without changing the inner header's 231 DSCP value, then the DS-capable tunnel ingress node MUST set the 232 inner header's DSCP to a value compatible with the network at tunnel 233 egress. The value 0 (DSCP of 000000) is often used for this purpose 234 in existing tunnel implementations. If the egress network is known 235 to implement IP precedence as specified in [RFC-791], then some or 236 all of the eight class selector DSCP codepoints defined in [RFC- 237 2474] are usable. Use of any DSCP codepoints other than the class 238 selectors for this purpose is NOT RECOMMENDED, as compatible 239 operation would then require diffserv traffic conditioning at the 240 tunnel egress node that is not DS-capable. Based on the existing 241 use of the value 0, setting the DSCP to 0 is RECOMMENDED when a 242 signaling convention is needed to inform the tunnel egress that a 243 DSCP value in a packet carries no useful information. This is 244 appropriate for the outer IP header's DSCP when a tunnel fits the 245 pipe conceptual model, and may be useful for the inner IP header's 246 DSCP for tunnels that do not have a TCA in place between the ingress 247 and egress DS domains. 249 5. Ingress Functionality 251 As described in Section 3 above, this draft is based on an approach 252 in which diffserv functionality and/or out-of-band communication 253 paths are not placed in parallel with tunnel encapsulation 254 processing. This model allows three possible locations for traffic 255 conditioners with respect to tunnel encapsulation processing, as 256 shown in the following diagram that depicts the flow of IP headers 257 through tunnel encapsulation: 259 +--------- [[2 - Outer]] -->> 260 / 261 / 262 >>---- [[1 - Before]] -------- Encapsulate ---- [[3 - Inner]] -->> 264 Of these three possible locations, [[3 - Inner]] SHOULD NOT be 265 utilized for general traffic conditioning because it requires 266 traffic conditioning functionality to reach inside the packet in 267 order to operate on the inner IP header. This is difficult in 268 general, and is impossible for IPsec tunnels and any other tunnels 269 that employ encryption or cryptographic integrity checks. Hence 270 traffic conditioning at [[3 - Inner]] can only be done as part of 271 tunnel encapsulation processing, complicating both the encapsulation 272 and traffic conditioning implementations for little apparent 273 benefit. In many cases, the desired functionality can be achieved 274 via a combination of traffic conditioners in the other two 275 locations, both of which can be specified and implemented 276 independently of tunnel encapsulation processing. Tunnel designs 277 and specifications SHOULD allow diffserv traffic conditioning to be 278 deployed at [[1 - Before]] and [[2 - Outer]]. 280 An exception in which functionality may need to be deployed at 281 [[3 - Inner]] occurs when the tunnel egress is not DS-capable, as 282 discussed in Section 4.2 above. Setting the inner DSCP to 0 as part 283 of encapsulation addresses a large portion of these cases, and the 284 maximum functionality that should be provided is setting the inner 285 DSCP to one of the class selector codepoint values. This level of 286 functionality (set DSCP to one of the class selector codepoint 287 values) is also appropriate for [[2 - Outer]] in configurations that 288 do not have more general traffic conditioning in that location. 290 The following table summarizes the achievable relationships among 291 the Before (B), outer (O), and inner (I) DSCP values and the 292 corresponding locations of traffic conditioning logic. 294 Relationship Traffic Conditioning Location(s) 295 ------------ -------------------------------- 296 B = I = O = B No traffic conditioning required 297 B != I = O != B [[1 - Before]] 298 B = I != O != B [[2 - Outer]] 299 B != I != O = B Limited support as part of encapsulation 300 processing, instead of [[3 - Inner]]; I can 301 be to one of class selectors. May be 302 accomplished in some cases via a combination 303 of [[1 - Before]] and [[2 - Outer]]. 304 B != I != O != B Some combination of the above three cases. 306 Minimizing the number of traffic conditioning blocks is recommended 307 as a general design principle. Implementers are cautioned that 308 traffic conditioning may still be required even if DSCP values are 309 not changed for purposes such as rate and burst limitation. 311 [Author's note: Is the above table useful?] 313 6. Egress Functionality 315 As described in Section 3 above, this draft is based on an approach 316 in which diffserv functionality and/or out-of-band communication 317 paths are not placed in parallel with tunnel encapsulation 318 processing. This model allows three possible locations for traffic 319 conditioners with respect to tunnel decapsulation processing, as 320 shown in the following diagram that depicts the flow of IP headers 321 through tunnel encapsulation: 323 >>----[[5 - Outer]]-------------+ 324 \ 325 \ 326 >>----[[4 - Inner]] --------- Decapsulate ---- [[6 - After]] -->> 328 As was the case for [[3 - Inner]] at tunnel ingress nodes, [[4 - 329 Inner]] SHOULD NOT be employed for general traffic conditioning 330 because it requires reaching inside the packet to operate on the 331 inner IP header. See the discussion of [[3 - Inner]] in Section 5 332 for further explanation. 334 In contrast to the encapsulation case, the elimination of parallel 335 functionality and data paths from decapsulation causes a potential 336 loss of information. As shown in the above diagram, decapsulation 337 reduces two DSCP values to one DSCP value, and hence necessarily 338 loses information in the most general case, even if arbitrary 339 functionality is allowed. Beyond this, allowing arbitrary 340 functionality poses a structural problem, namely that the DSCP value 341 from the outer IP header should to be presented as an out-of-band 342 input to the traffic conditioning block at [[6 - After]], 343 significantly complicating the traffic conditioning model and 344 implementations at that location. To avoid such complications, this 345 document proposes a simpler approach of defining a few primitive 346 DSCP combination operations that can be performed as part of 347 decapsulation, leaving the full generality of traffic conditioning 348 functionality to be implemented at [[5 - Outer]] and [[6 - After]]. 349 These operations should be straightforward to add to tunnel 350 implementations and are expected to yield most of the benefits of a 351 more fully general approach without imposing the complexity of such 352 an approach on tunnel implementations. 354 The following four primitive DSCP operations are proposed for 355 incorporation into tunnel decapsulation. Each takes an Inner and an 356 Outer DSCP value as arguments and produces a Result DSCP value for 357 the IP header of the decapsulated packet. The operations are 358 described in "Name: Pseudo-code specification" format. 360 (1) Discard: Result = Inner; 361 (2) Overwrite: Result = Outer; 362 (3) Conditional Overwrite: If (Outer != 0), Result = Outer; 363 Else Result = Inner; 364 (4) Conditional Discard: If (Inner != 0), Result = Inner; 365 Else Result = Outer; 367 The rationale for the choice of these functions is that of the two 368 DSCP values, one of them usually contains useful information, and 369 the other is of little value. In terms of the conceptual models 370 discussed in Section 3, Discard corresponds to the pipe model, 371 Overwrite corresponds to the uniform model, and the two Conditional 372 operations are motivated by the use of 0 as an "escape value" 373 indicating that the useful information is in the other header's DSCP 374 (see Section 4.2). IPsec tunnels and other tunnels with similar 375 security properties MUST default to Discard, and SHOULD not choose a 376 different function in the absence of an adequate security analysis. 378 [Author's note: The above section is particularly tentative, and 379 needs WG discussion, starting from whether the "simpler approach" is 380 simple enough or too simple. Recommendations about what the list 381 should be and what MUST/SHOULD/MAY be implemented in tunnels will 382 emerge from that discussion. The author's current inclination is 383 that at least one of the first two functions is a MUST (but choosing 384 which one to implement, or implementing both is a MAY), the third 385 function is a SHOULD, and the fourth function is a MAY. The IPsec 386 discussion probably needs to be expanded.] 388 6.1 Limited Decapsulation Functionality Rationale 390 As a sanity check on the simpler approach proposed in the above 391 section (6), this subsection considers a situation in which a more 392 complex approach might be required. The four DSCP combination 393 functions proposed above are actually selection functions; one of 394 the two DSCPs is selected to pass onward as the DSCP for the 395 decapsulated packet. This is a poor match to situations in which 396 both DSCPs are carrying information that is needed to perform 397 outgoing traffic conditioning (i.e., at [[6 - After]]) correctly. 399 As an example, consider a situation in which two different AF groups 400 [RFC-2597] are being used by the two domains at the tunnel 401 endpoints, there is an intermediate domain along the tunnel that 402 uses RFC 791 IP precedences, this domain is transited by setting the 403 DSCP to zero, and the tunnel egress is at a node that would not 404 otherwise be an edge node for that diffserv domain. This situation 405 is shown in the following IP header flow diagram where I is the 406 tunnel ingress node, E is the tunnel egress node and the vertical 407 lines are domain boundaries. The node at the left-hand vertical 408 line sets the DSCP in the outer header to 0 in order to obtain 409 compatibility with the middle domain: 411 | | 412 +-----|-------------------|------+ 413 / | | \ 414 >>-----------I-------|-------------------|--------E---------->> 415 | | 416 Ingress DS Domain RFC 791 Egress DS domain 417 IP Precedence 418 Domain 420 In this situation, the DS edge node for the egress domain (i.e., the 421 node at the right-hand vertical line) can select the appropriate AF 422 group (e.g., via an MF classifier), but cannot reconstruct the drop 423 precedence information that was removed from the outer header when 424 it transited the RFC-791 compliant domain (although it can construct 425 new information via metering and marking). The original drop 426 precedence information is preserved in the inner IP header's DSCP, 427 and could be combined with the AF class selection communicated via 428 the outer IP header's DSCP. On the other hand, the same result can 429 be obtained in most cases by placing traffic conditioning 430 functionality at location [[6 - After]] in the tunnel egress node, 431 and discarding the outer header. This works as long as the 432 appropriate AF class for the egress domain is implicit in the fact 433 that traffic is emerging from the tunnel, or can be determined via 434 BA or MF classification of the emerging traffic. 436 [Author's note: This is a flimsy start at "proof by example". The 437 intention is to start a requirements discussion in the WG and 438 capture the results in the next version of this draft.] 440 7. Summary of Advice to Tunnel Implementers 442 [Author's note: To be written after WG discussion; WG consensus is a 443 prerequisite to this sort of text that will be full of MUST/SHOULD/ 444 MAY items. Will probably also add some discussion and 445 recommendations about existing tunnel specifications in light of 446 this advice.] 448 8. Diffserv and Protocol Translators 450 A related issue involves protocol translators, of which a specific 451 example is the Stateless IP/ICMP translator [SIIT]. These 452 translators are not tunnels because they do not add or remove a 453 second IP header to/from packets (e.g., in contrast to IPv6 over 454 IPv4 tunnels [RFC-1933]) and hence do not raise concerns of 455 information propagation between inner and outer IP headers. The 456 primary interaction between translators and diffserv is that the 457 translation boundary is likely to be a diffserv domain boundary 458 (e.g., the IPv4 and IPv6 domains may have different policies for 459 traffic conditioning and DSCP usage), and hence such translators 460 SHOULD permit the insertion of diffserv edge node processing, 461 including traffic conditioning and/or the simplified ingress 462 functional addition discussed in Section 5. 464 9. Security Considerations 466 The security considerations for the diffserv architecture discussed 467 in [RFC-2474, RFC-2475] apply when tunnels are present; readers are 468 referred to those documents for further background. One of the 469 requirements noted there is that a tunnel egress node in the 470 interior of a diffserv domain is the DS ingress node for traffic 471 exiting the tunnel, and is responsible for performing appropriate 472 traffic conditioning. The primary security implication is that the 473 traffic conditioning is responsible for dealing with theft- and 474 denial-of-service threats posed to the diffserv domain by traffic 475 exiting from the tunnel. The IPsec architecture [RFC-2401] places a 476 further restriction on tunnel egress processing; the outer header 477 MUST be discarded unless the properties of the traffic conditioning 478 that results are known and have been adequately analyzed for 479 security vulnerabilities. This includes both the [[5 - Outer]] and 480 [[6 - After]] traffic conditioning blocks on the tunnel egress node, 481 if present, and may involve traffic conditioning performed by an 482 upstream DS-edge node that is the DS domain ingress node for the 483 encapsulated tunneled traffic. 485 10. References 487 [RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, September 488 1981. 490 [RFC-1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD 51, 491 RFC 1661, July 1994. 493 [RFC-1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for 494 IPv6 Hosts and Routers", RFC 1933, April 1996. 496 [RFC-2003] C. Perkins, "IP Encapsulation within IP,", RFC 2003, 497 October 1996. 499 [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate 500 Requirement Levels", RFC 2119, March 1997. 502 [RFC-2401] S. Kent and R. Atkinson, "Security Architecture for the 503 Internet Protocol", RFC 2401, November 1998. 505 [RFC-2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition 506 of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 507 Headers", RFC 2474, December 1998. 509 [RFC-2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and 510 W. Weiss, "An Architecture for Differentiated Services", RFC 2475, 511 December 1998. 513 [RFC-2597] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, 514 "Assured Forwarding PHB Group", RFC 2597. June 1999. 516 [RFC-2598] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited 517 Forwarding PHB", RFC 2598, June 1999. 519 [RFC-2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, 520 and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC 2661, 521 August 1999. 523 [SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)", 524 draft-ietf-ngtrans-siit-06.txt, Work in Progress, IETF ngtrans WG, 525 July 1999. 527 [Author's note: This needs to be extended by additional tunnel RFC 528 references as part of writing Section 7, the references section of 529 the Tunnel MIB RFC (RFC 2667) provides a good starting point.] 531 11. Acknowledgments 533 Some of this material is based on discussions with Brian Carpenter, 534 and is derived in part from his presentation on this topic to the 535 diffserv WG at its summer 1999 meeting in Oslo. Credit is also due 536 to a significant number of people working on tunnel specifications 537 [names will appear here in a future version] who have discovered 538 limitations of the diffserv architecture RFC (2475) in the area of 539 tunnels. Their kind patience with the time it has taken to address 540 this set of issues has been greatly appreciated. 542 12. Author's Address 544 David L. Black 545 EMC Corporation 546 42 South St. 547 Hopkinton, MA 01748 548 Phone: +1 (508) 435-1000 x75140 549 Email: black_david@emc.com