idnits 2.17.1 draft-ietf-tsvwg-ecn-tunnel-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4774, but the abstract doesn't seem to directly say this. It does mention RFC4774 though, so this could be OK. -- The draft header indicates that this document updates RFC4301, but the abstract doesn't seem to directly say this. It does mention RFC4301 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 the creation date from RFC3168, updated by this document, for RFC5378 checks: 2000-11-17) -- 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 30, 2010) is 5019 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) == Outdated reference: A later version (-11) exists of draft-ietf-pcn-3-in-1-encoding-03 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2481 (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5696 (Obsoleted by RFC 6660) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group B. Briscoe 3 Internet-Draft BT 4 Updates: 3168, 4301, 4774 July 30, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: January 31, 2011 9 Tunnelling of Explicit Congestion Notification 10 draft-ietf-tsvwg-ecn-tunnel-09 12 Abstract 14 This document redefines how the explicit congestion notification 15 (ECN) field of the IP header should be constructed on entry to and 16 exit from any IP in IP tunnel. On encapsulation it updates RFC3168 17 to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec 18 ECN processing. On decapsulation it updates both RFC3168 and RFC4301 19 to add new behaviours for previously unused combinations of inner and 20 outer header. The new rules ensure the ECN field is correctly 21 propagated across a tunnel whether it is used to signal one or two 22 severity levels of congestion, whereas before only one severity level 23 was supported. Tunnel endpoints can be updated in any order without 24 affecting pre-existing uses of the ECN field, thus ensuring backward 25 compatibility. Nonetheless, operators wanting to support two 26 severity levels (e.g. for pre-congestion notification--PCN) can 27 require compliance with this new specification. A thorough analysis 28 of the reasoning for these changes and the implications is included. 29 In the unlikely event that the new rules do not meet a specific need, 30 RFC4774 gives guidance on designing alternate ECN semantics and this 31 document extends that to include tunnelling issues. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 31, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 14 71 3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 14 72 3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 15 73 4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 16 74 4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 16 75 4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 17 76 4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 19 77 4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 20 78 5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 21 79 5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 21 80 5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 22 81 5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 23 82 5.3.1. Motivation for Changing Encapsulation . . . . . . . . 23 83 5.3.2. Motivation for Changing Decapsulation . . . . . . . . 24 84 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 27 85 6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 27 86 6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 27 87 6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 28 88 7. Design Principles for Alternate ECN Tunnelling Semantics . . . 28 89 8. IANA Considerations (to be removed on publication): . . . . . 30 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 91 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 96 Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 35 97 Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 35 98 B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 36 99 B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 38 100 B.3. Management Constraints . . . . . . . . . . . . . . . . . . 39 101 Appendix C. Contribution to Congestion across a Tunnel . . . . . 39 102 Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0) 103 Outer . . . . . . . . . . . . . . . . . . . . . . . . 40 104 Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . . 41 106 Request to the RFC Editor (to be removed on publication): 108 In the RFC index, RFC3168 should be identified as an update to 109 RFC2003. RFC4301 should be identified as an update to RFC3168. 111 Changes from previous drafts (to be removed by the RFC Editor) 113 Full text differences between IETF draft versions are available at 114 , and 115 between earlier individual draft versions at 116 118 From ietf-08 to ietf-09 (current): Added change log entry for -07 to 119 -08 that was previously omitted. 121 * Changes to standards action text: 123 + Added RFC4774 to 'Updates:' header (the draft always has 124 extended the advice in RFC4774 (BCP124) which said very 125 little about tunnels. The GENART reviewer merely pointed 126 out that the header did not highlight this fact.) 128 * Editorial changes: 130 + Abstract: s/providing backward compatibility./thus ensuring 131 backward compatibility./ 133 + Moved PCN-related text motivating changes to decapsulation 134 from "Default Tunnel Egress Behaviour" (Section 4.2) to 135 "Motivation for Changing Decapsulation" (Section 5.3.2) 136 where it was merged with existing similar text. 138 + In the non-normative Design Principles avoided using words 139 in lower case where they were in contexts that might make 140 them confusable with upper case RFC2119 normative language. 142 + Added Stephen Hanna and Ben Campbell to acks and corrected 143 spelling of Agarwal. 145 + Deleted endnote discussing corner case with IKEv2 manual 146 keying (identified as "to be removed before publication 147 following SecDir review"). 149 + Deleted Appendices D & E on why existing ingress & egress 150 tunnelling behavour impede PCN and the endnotes that 151 referred to them (identified as "to be removed before 152 publication"). 154 + Various minor corrections pointed out by reviewers. 156 From ietf-07 to ietf-08: 158 * Changes to standards actions: 160 + Section 4: Changed non-RFC2119 phrase 'NOT RECOMMENDED' to 161 'SHOULD be avoided', wrt alternate ECN tunnelling schemes. 163 + Section 4.2: Used upper-case in 'Alarms SHOULD be rate- 164 limited'. 166 + Section 7: Made bullet #1 in the decapsulation guidelines 167 for alternate schemes more precise. Also changed any upper- 168 case keywords in this informative section to lower case. 170 * Editorial changes: 172 + Changed copyright notice to allow for pre-5378 material. 174 + Shifted supporting text intended for deletion on publication 175 into editorial comments. 177 + Explained how to read the decapsulation matrices in their 178 captions. 180 + Minor clarifications throughout. 182 From ietf-06 to ietf-07: 184 * Emphasised that this is the opposite of a fork in the RFC 185 series. 187 * Altered Section 5 to focus on updates to implementations of 188 earlier RFCs, rather than on updates to the text of the RFCs. 190 * Removed potential loop-holes in normative text that 191 implementers might have used to claim compliance without 192 implementing normal mode. Highlighted the deliberate 193 distinction between "MUST implement" and "SHOULD use" normal 194 mode. 196 * Added question for Security Directorate reviewers on whether to 197 mention a corner-case concerning manual keying of IPsec 198 tunnels. 200 * Minor clarifications, updated references and updated acks. 202 * Marked two appendices about PCN motivations for removal before 203 publication. 205 From ietf-05 to ietf-06: 207 * Minor textual clarifications and corrections. 209 From ietf-04 to ietf-05: 211 * Functional changes: 213 + Section 4.2: ECT(1) outer with Not-ECT inner: reverted to 214 forwarding as Not-ECT (as in RFC3168 & RFC4301), rather than 215 dropping. 217 + Altered rationale in bullet 3 of Section 5.3.2 to justify 218 this. 220 + Distinguished alarms for dangerous and invalid combinations 221 and allowed combinations that are valid in some tunnel 222 configurations but dangerous in others to be alarmed at the 223 discretion of the implementer and/or operator. 225 + Altered advice on designing alternate ECN tunnelling 226 semantics to reflect the above changes. 228 * Textual changes: 230 + Changed "Future non-default schemes" to "Alternate ECN 231 Tunnelling Semantics" throughout. 233 + Cut down Appendix D and Appendix E for brevity. 235 + A number of clarifying edits & updated refs. 237 From ietf-03 to ietf-04: 239 * Functional changes: none 241 * Structural changes: 243 + Added "Open Issues" appendix 245 * Textual changes: 247 + Section title: "Changes from Earlier RFCs" -> "Updates to 248 Earlier RFCs" 250 + Emphasised that change on decap to previously unused 251 combinations will propagate PCN encoding. 253 + Acknowledged additional reviewers and updated references 255 From ietf-02 to ietf-03: 257 * Functional changes: 259 + Corrected errors in recap of previous RFCs, which wrongly 260 stated the different decapsulation behaviours of RFC3168 & 261 RFC4301 with a Not-ECT inner header. This also required 262 corrections to the "Changes from Earlier RFCs" and the 263 Motivations for these changes. 265 + Mandated that any future standards action SHOULD NOT use the 266 ECT(0) codepoint as an indication of congestion, without 267 giving strong reasons. 269 + Added optional alarm when decapsulating ECT(1) outer, 270 ECT(0), but noted it would need to be disabled for 271 2-severity level congestion (e.g. PCN). 273 * Structural changes: 275 + Removed Document Roadmap which merely repeated the Contents 276 (previously Section 1.2). 278 + Moved "Changes from Earlier RFCs" (Section 5) before 279 Section 6 on Backward Compatibility and internally organised 280 both by RFC, rather than by ingress then egress. 282 + Moved motivation for changing existing RFCs (Section 5.3) to 283 after the changes are specified. 285 + Moved informative "Design Principles for Future Non-Default 286 Schemes" after all the normative sections. 288 + Added Appendix A on early history of ECN tunnelling RFCs. 290 + Removed specialist appendix on "Relative Placement of 291 Tunnelling and In-Path Load Regulation" (Appendix D in the 292 -02 draft) 294 + Moved and updated specialist text on "Compromise on Decap 295 with ECT(1) Inner and ECT(0) Outer" from Security 296 Considerations to Appendix D 298 * Textual changes: 300 + Simplified vocabulary for non-native-english speakers 302 + Simplified Introduction and defined regularly used terms in 303 an expanded Terminology section. 305 + More clearly distinguished statically configured tunnels 306 from dynamic tunnel endpoint discovery, before explaining 307 operating modes. 309 + Simplified, cut-down and clarified throughout 311 + Updated references. 313 From ietf-01 to ietf-02: 315 * Scope reduced from any encapsulation of an IP packet to solely 316 IP in IP tunnelled encapsulation. Consequently changed title 317 and removed whole section 'Design Guidelines for New 318 Encapsulations of Congestion Notification' (to be included in a 319 future companion informational document). 321 * Included a new normative decapsulation rule for ECT(0) inner 322 and ECT(1) outer that had previously only been outlined in the 323 non-normative appendix 'Comprehensive Decapsulation Rules'. 324 Consequently: 326 + The Introduction has been completely re-written to motivate 327 this change to decapsulation along with the existing change 328 to encapsulation. 330 + The tentative text in the appendix that first proposed this 331 change has been split between normative standards text in 332 Section 4 and Appendix D, which explains specifically why 333 this change would streamline PCN. New text on the logic of 334 the resulting decap rules added. 336 * If inner/outer is Not-ECT/ECT(0), changed decapsulation to 337 propagate Not-ECT rather than drop the packet; and added 338 reasoning. 340 * Considerably restructured: 342 + "Design Constraints" analysis moved to an appendix 343 (Appendix B); 345 + Added Section 3 to summarise relevant existing RFCs; 347 + Structured Section 4 and Section 6 into subsections. 349 + Added tables to sections on old and new rules, for precision 350 and comparison. 352 + Moved Section 7 on Design Principles to the end of the 353 section specifying the new default normative tunnelling 354 behaviour. Rewritten and shifted text on identifiers and 355 in-path load regulators to Appendix B.1 [deleted in revision 356 -03]. 358 From ietf-00 to ietf-01: 360 * Identified two additional alarm states in the decapsulation 361 rules (Figure 4) if ECT(X) in outer and inner contradict each 362 other. 364 * Altered Comprehensive Decapsulation Rules (Appendix D) so that 365 ECT(0) in the outer no longer overrides ECT(1) in the inner. 366 Used the term 'Comprehensive' instead of 'Ideal'. And 367 considerably updated the text in this appendix. 369 * Added Appendix D.1 (removed again in a later revision) to weigh 370 up the various ways the Comprehensive Decapsulation Rules might 371 be introduced. This replaces the previous contradictory 372 statements saying complex backwards compatibility interactions 373 would be introduced while also saying there would be no 374 backwards compatibility issues. 376 * Updated references. 378 From briscoe-01 to ietf-00: 380 * Re-wrote Appendix C giving much simpler technique to measure 381 contribution to congestion across a tunnel. 383 * Added discussion of backward compatibility of the ideal 384 decapsulation scheme in Appendix D 386 * Updated references. Minor corrections & clarifications 387 throughout. 389 From briscoe-00 to briscoe-01: 391 * Related everything conceptually to the uniform and pipe models 392 of RFC2983 on Diffserv Tunnels, and completely removed the 393 dependence of tunnelling behaviour on the presence of any in- 394 path load regulation by using the [1 - Before] [2 - Outer] 395 function placement concepts from RFC2983; 397 * Added specific cases where the existing standards limit new 398 proposals, particularly Appendix E; 400 * Added sub-structure to Introduction (Need for Rationalisation, 401 Roadmap), added new Introductory subsection on "Scope" and 402 improved clarity; 404 * Added Design Guidelines for New Encapsulations of Congestion 405 Notification; 407 * Considerably clarified the Backward Compatibility section 408 (Section 6); 410 * Considerably extended the Security Considerations section 411 (Section 9); 413 * Summarised the primary rationale much better in the 414 conclusions; 416 * Added numerous extra acknowledgements; 418 * Added Appendix E. "Why resetting CE on encapsulation harms 419 PCN", Appendix C. "Contribution to Congestion across a Tunnel" 420 and Appendix D. "Ideal Decapsulation Rules"; 422 * Re-wrote Appendix B [deleted in a later revision], explaining 423 how tunnel encapsulation no longer depends on in-path load- 424 regulation (changed title from "In-path Load Regulation" to 425 "Non-Dependence of Tunnelling on In-path Load Regulation"), but 426 explained how an in-path load regulation function must be 427 carefully placed with respect to tunnel encapsulation (in a new 428 sub-section entitled "Dependence of In-Path Load Regulation on 429 Tunnelling"). 431 1. Introduction 433 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 434 element (e.g. a router) to notify the onset of congestion without 435 having to drop packets. Instead it can explicitly mark a proportion 436 of packets in the 2-bit ECN field in the IP header (Table 1 recaps 437 the ECN codepoints). 439 The outer header of an IP packet can encapsulate one or more IP 440 headers for tunnelling. A forwarding element using ECN to signify 441 congestion will only mark the immediately visible outer IP header. 442 When a tunnel decapsulator later removes this outer header, it 443 follows rules to propagate congestion markings by combining the ECN 444 fields of the inner and outer IP header into one outgoing IP header. 446 This document updates those rules for IPsec [RFC4301] and non-IPsec 447 [RFC3168] tunnels to add new behaviours for previously unused 448 combinations of inner and outer header. It also updates the tunnel 449 ingress behaviour of RFC3168 to match that of RFC4301. The updated 450 rules are backward compatible with RFC4301 and RFC3168 when 451 interworking with any other tunnel endpoint complying with any 452 earlier specification. 454 When ECN and its tunnelling was defined in RFC3168, only the minimum 455 necessary changes to the ECN field were propagated through tunnel 456 endpoints--just enough for the basic ECN mechanism to work. This was 457 due to concerns that the ECN field might be toggled to communicate 458 between a secure site and someone on the public Internet--a covert 459 channel. This was because a mutable field like ECN cannot be 460 protected by IPsec's integrity mechanisms--it has to be able to 461 change as it traverses the Internet. 463 Nonetheless, the latest IPsec architecture [RFC4301] considered a 464 bandwidth limit of 2 bits per packet on a covert channel made it a 465 manageable risk. Therefore, for simplicity, an RFC4301 ingress 466 copied the whole ECN field to encapsulate a packet. It dispensed 467 with the two modes of RFC3168, one which partially copied the ECN 468 field, and the other which blocked all propagation of ECN changes. 470 Unfortunately, this entirely reasonable sequence of standards actions 471 resulted in a perverse outcome; non-IPsec tunnels (RFC3168) blocked 472 the 2-bit covert channel, while IPsec tunnels (RFC4301) did not--at 473 least not at the ingress. At the egress, both IPsec and non-IPsec 474 tunnels still partially restricted propagation of the full ECN field. 476 The trigger for the changes in this document was the introduction of 477 pre-congestion notification (PCN [RFC5670]) to the IETF standards 478 track. PCN needs the ECN field to be copied at a tunnel ingress and 479 it needs four states of congestion signalling to be propagated at the 480 egress, but pre-existing tunnels only propagate three in the ECN 481 field. 483 This document draws on currently unused (CU) combinations of inner 484 and outer headers to add tunnelling of four-state congestion 485 signalling to RFC3168 and RFC4301. Operators of tunnels who 486 specifically want to support four states can require that all their 487 tunnels comply with this specification. However, this is not a fork 488 in the RFC series. It is an update that can be deployed first by 489 those that need it, and subsequently by all tunnel endpoint 490 implementations (RFC4301, RFC3168, RFC2481, RFC2401, RFC2003), which 491 can safely be updated to this new specification as part of general 492 code maintenance. This will gradually add support for four 493 congestion states to the Internet. Existing three state schemes will 494 continue to work as before. 496 In fact, this document is the opposite of a fork. At the same time 497 as supporting a fourth state, the opportunity has been taken to draw 498 together divergent ECN tunnelling specifications into a single 499 consistent behaviour, harmonising differences such as perverse covert 500 channel treatment. Then any tunnel can be deployed unilaterally, and 501 it will support the full range of congestion control and management 502 schemes without any modes or configuration. Further, any host or 503 router can expect the ECN field to behave in the same way, whatever 504 type of tunnel might intervene in the path. 506 1.1. Scope 508 This document only concerns wire protocol processing of the ECN field 509 at tunnel endpoints and makes no changes or recommendations 510 concerning algorithms for congestion marking or congestion response. 512 This document specifies common ECN field processing at encapsulation 513 and decapsulation for any IP in IP tunnelling, whether IPsec or non- 514 IPsec tunnels. It applies irrespective of whether IPv4 or IPv6 is 515 used for either of the inner and outer headers. It applies for 516 packets with any destination address type, whether unicast or 517 multicast. It applies as the default for all Diffserv per-hop 518 behaviours (PHBs), unless stated otherwise in the specification of a 519 PHB (but Section 4 strongly deprecates such exceptions). It is 520 intended to be a good trade off between somewhat conflicting 521 security, control and management requirements. 523 [RFC2983] is a comprehensive primer on differentiated services and 524 tunnels. Given ECN raises similar issues to differentiated services 525 when interacting with tunnels, useful concepts introduced in RFC2983 526 are used throughout, with brief recaps of the explanations where 527 necessary. 529 2. Terminology 531 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 532 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 533 document are to be interpreted as described in RFC 2119 [RFC2119]. 535 Table 1 recaps the names of the ECN codepoints [RFC3168]. 537 +------------------+----------------+---------------------------+ 538 | Binary codepoint | Codepoint name | Meaning | 539 +------------------+----------------+---------------------------+ 540 | 00 | Not-ECT | Not ECN-capable transport | 541 | 01 | ECT(1) | ECN-capable transport | 542 | 10 | ECT(0) | ECN-capable transport | 543 | 11 | CE | Congestion experienced | 544 +------------------+----------------+---------------------------+ 546 Table 1: Recap of Codepoints of the ECN Field [RFC3168] in the IP 547 Header 549 Further terminology used within this document: 551 Encapsulator: The tunnel endpoint function that adds an outer IP 552 header to tunnel a packet (also termed the 'ingress tunnel 553 endpoint' or just the 'ingress' where the context is clear). 555 Decapsulator: The tunnel endpoint function that removes an outer IP 556 header from a tunnelled packet (also termed the 'egress tunnel 557 endpoint' or just the 'egress' where the context is clear). 559 Incoming header: The header of an arriving packet before 560 encapsulation. 562 Outer header: The header added to encapsulate a tunnelled packet. 564 Inner header: The header encapsulated by the outer header. 566 Outgoing header: The header constructed by the decapsulator using 567 logic that combines the fields in the outer and inner headers. 569 Copying ECN: On encapsulation, setting the ECN field of the new 570 outer header to be a copy of the ECN field in the incoming header. 572 Zeroing ECN: On encapsulation, clearing the ECN field of the new 573 outer header to Not-ECT ("00"). 575 Resetting ECN: On encapsulation, setting the ECN field of the new 576 outer header to be a copy of the ECN field in the incoming header 577 except the outer ECN field is set to the ECT(0) codepoint if the 578 incoming ECN field is CE. 580 3. Summary of Pre-Existing RFCs 582 This section is informative not normative, as it recaps pre-existing 583 RFCs. Earlier relevant RFCs that were either experimental or 584 incomplete with respect to ECN tunnelling (RFC2481, RFC2401 and 585 RFC2003) are briefly outlined in Appendix A. The question of whether 586 tunnel implementations used in the Internet comply with any of these 587 RFCs is not discussed. 589 3.1. Encapsulation at Tunnel Ingress 591 At the encapsulator, the controversy has been over whether to 592 propagate information about congestion experienced on the path so far 593 into the outer header of the tunnel. 595 Specifically, RFC3168 says that, if a tunnel fully supports ECN 596 (termed a 'full-functionality' ECN tunnel in [RFC3168]), the 597 encapsulator must not copy a CE marking from the inner header into 598 the outer header that it creates. Instead the encapsulator must set 599 the outer header to ECT(0) if the ECN field is marked CE in the 600 arriving IP header. We term this 'resetting' a CE codepoint. 602 However, the new IPsec architecture in [RFC4301] reverses this rule, 603 stating that the encapsulator must simply copy the ECN field from the 604 incoming header to the outer header. 606 RFC3168 also provided a Limited Functionality mode that turns off ECN 607 processing over the scope of the tunnel by setting the outer header 608 to Not-ECT ("00"). Then such packets will be dropped to indicate 609 congestion rather than marked with ECN. This is necessary for the 610 ingress to interwork with legacy decapsulators ([RFC2481], [RFC2401] 611 and [RFC2003]) that do not propagate ECN markings added to the outer 612 header. Otherwise such legacy decapsulators would throw away 613 congestion notifications before they reached the transport layer. 615 Neither Limited Functionality mode nor Full Functionality mode are 616 used by an RFC4301 IPsec encapsulator, which simply copies the 617 incoming ECN field into the outer header. An earlier key-exchange 618 phase ensures an RFC4301 ingress will not have to interwork with a 619 legacy egress that does not support ECN. 621 These pre-existing behaviours are summarised in Figure 1. 623 +-----------------+-----------------------------------------------+ 624 | Incoming Header | Outgoing Outer Header | 625 | (also equal to +---------------+---------------+---------------+ 626 | Outgoing Inner | RFC3168 ECN | RFC3168 ECN | RFC4301 IPsec | 627 | Header) | Limited | Full | | 628 | | Functionality | Functionality | | 629 +-----------------+---------------+---------------+---------------+ 630 | Not-ECT | Not-ECT | Not-ECT | Not-ECT | 631 | ECT(0) | Not-ECT | ECT(0) | ECT(0) | 632 | ECT(1) | Not-ECT | ECT(1) | ECT(1) | 633 | CE | Not-ECT | ECT(0) | CE | 634 +-----------------+---------------+---------------+---------------+ 636 Figure 1: IP in IP Encapsulation: Recap of Pre-existing Behaviours 638 3.2. Decapsulation at Tunnel Egress 640 RFC3168 and RFC4301 specify the decapsulation behaviour summarised in 641 Figure 2. The ECN field in the outgoing header is set to the 642 codepoint at the intersection of the appropriate incoming inner 643 header (row) and incoming outer header (column). 644 +---------+------------------------------------------------+ 645 |Incoming | Incoming Outer Header | 646 | Inner +---------+------------+------------+------------+ 647 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 648 +---------+---------+------------+------------+------------+ 649 RFC3168->| Not-ECT | Not-ECT |Not-ECT |Not-ECT | drop | 650 RFC4301->| Not-ECT | Not-ECT |Not-ECT |Not-ECT |Not-ECT | 651 | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE | 652 | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE | 653 | CE | CE | CE | CE | CE | 654 +---------+---------+------------+------------+------------+ 656 In pre-existing RFCs, the ECN field in the outgoing header was set to 657 the codepoint at the intersection of the appropriate incoming inner 658 header (row) and incoming outer header (column). 660 Figure 2: IP in IP Decapsulation; Recap of Pre-existing Behaviour 662 The behaviour in the table derives from the logic given in RFC3168 663 and RFC4301, briefly recapped as follows: 665 o On decapsulation, if the inner ECN field is Not-ECT the outer is 666 ignored. RFC3168 (but not RFC4301) also specified that the 667 decapsulator must drop a packet with a Not-ECT inner and CE in the 668 outer. 670 o In all other cases, if the outer is CE, the outgoing ECN field is 671 set to CE, but otherwise the outer is ignored and the inner is 672 used for the outgoing ECN field. 674 Section 9.2.2 of RFC3168 also made it an auditable event for an IPsec 675 tunnel "if the ECN Field is changed inappropriately within an IPsec 676 tunnel...". Inappropriate changes were not specifically enumerated. 677 RFC4301 did not mention inappropriate ECN changes. 679 4. New ECN Tunnelling Rules 681 The standards actions below in Section 4.1 (ingress encapsulation) 682 and Section 4.2 (egress decapsulation) define new default ECN tunnel 683 processing rules for any IP packet (v4 or v6) with any Diffserv 684 codepoint. 686 If these defaults do not meet a particular requirement, an alternate 687 ECN tunnelling scheme can be introduced as part of the definition of 688 an alternate congestion marking scheme used by a specific Diffserv 689 PHB (see S.5 of [RFC3168] and [RFC4774]). When designing such 690 alternate ECN tunnelling schemes, the principles in Section 7 should 691 be followed. However, alternate ECN tunnelling schemes SHOULD be 692 avoided whenever possible as the deployment burden of handling 693 exceptional PHBs in implementations of all affected tunnels should 694 not be underestimated. There is no requirement for a PHB definition 695 to state anything about ECN tunnelling behaviour if the default 696 behaviour in the present specification is sufficient. 698 4.1. Default Tunnel Ingress Behaviour 700 Two modes of encapsulation are defined here; a REQUIRED `normal mode' 701 and a `compatibility mode', which is for backward compatibility with 702 tunnel decapsulators that do not understand ECN. Note that these are 703 modes of the ingress tunnel endpoint only, not the whole tunnel. 704 Section 4.3 explains why two modes are necessary and specifies the 705 circumstances in which it is sufficient to solely implement normal 706 mode. 708 Whatever the mode, an encapsulator forwards the inner header without 709 changing the ECN field. 711 In normal mode an encapsulator compliant with this specification MUST 712 construct the outer encapsulating IP header by copying the 2-bit ECN 713 field of the incoming IP header. In compatibility mode it clears the 714 ECN field in the outer header to the Not-ECT codepoint (the IPv4 715 header checksum also changes whenever the ECN field is changed). 716 These rules are tabulated for convenience in Figure 3. 718 +-----------------+-------------------------------+ 719 | Incoming Header | Outgoing Outer Header | 720 | (also equal to +---------------+---------------+ 721 | Outgoing Inner | Compatibility | Normal | 722 | Header) | Mode | Mode | 723 +-----------------+---------------+---------------+ 724 | Not-ECT | Not-ECT | Not-ECT | 725 | ECT(0) | Not-ECT | ECT(0) | 726 | ECT(1) | Not-ECT | ECT(1) | 727 | CE | Not-ECT | CE | 728 +-----------------+---------------+---------------+ 730 Figure 3: New IP in IP Encapsulation Behaviours 732 4.2. Default Tunnel Egress Behaviour 734 To decapsulate the inner header at the tunnel egress, a compliant 735 tunnel egress MUST set the outgoing ECN field to the codepoint at the 736 intersection of the appropriate incoming inner header (row) and outer 737 header (column) in Figure 4 (the IPv4 header checksum also changes 738 whenever the ECN field is changed). There is no need for more than 739 one mode of decapsulation, as these rules cater for all known 740 requirements. 741 +---------+------------------------------------------------+ 742 |Incoming | Incoming Outer Header | 743 | Inner +---------+------------+------------+------------+ 744 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 745 +---------+---------+------------+------------+------------+ 746 | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| drop(!!!)| 747 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | 748 | ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE | 749 | CE | CE | CE | CE(!!!)| CE | 750 +---------+---------+------------+------------+------------+ 752 The ECN field in the outgoing header is set to the codepoint at the 753 intersection of the appropriate incoming inner header (row) and 754 incoming outer header (column). Currently unused combinations are 755 indicated by '(!!!)' or '(!)' 757 Figure 4: New IP in IP Decapsulation Behaviour 759 This table for decapsulation behaviour is derived from the following 760 logic: 762 o If the inner ECN field is Not-ECT the decapsulator MUST NOT 763 propagate any other ECN codepoint onwards. This is because the 764 inner Not-ECT marking is set by transports that use drop as an 765 indication of congestion and would not understand or respond to 766 any other ECN codepoint [RFC4774]. Specifically: 768 * If the inner ECN field is Not-ECT and the outer ECN field is CE 769 the decapsulator MUST drop the packet. 771 * If the inner ECN field is Not-ECT and the outer ECN field is 772 Not-ECT, ECT(0) or ECT(1) the decapsulator MUST forward the 773 outgoing packet with the ECN field cleared to Not-ECT. 775 o In all other cases where the inner supports ECN, the decapsulator 776 MUST set the outgoing ECN field to the more severe marking of the 777 outer and inner ECN fields, where the ranking of severity from 778 highest to lowest is CE, ECT(1), ECT(0), Not-ECT. This in no way 779 precludes cases where ECT(1) and ECT(0) have the same severity; 781 o Certain combinations of inner and outer ECN fields cannot result 782 from any transition in any current or previous ECN tunneling 783 specification. These currently unused (CU) combinations are 784 indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the 785 combination is CU and always potentially dangerous, while '(!)' 786 means it is CU and possibly dangerous. In these cases, 787 particularly the more dangerous ones, the decapsulator SHOULD log 788 the event and MAY also raise an alarm. 790 Just because the highlighted combinations are currently unused, 791 does not mean that all the other combinations are always valid. 792 Some are only valid if they have arrived from a particular type of 793 legacy ingress, and dangerous otherwise. Therefore an 794 implementation MAY allow an operator to configure logging and 795 alarms for such additional header combinations known to be 796 dangerous or CU for the particular configuration of tunnel 797 endpoints deployed at run-time. 799 Alarms SHOULD be rate-limited so that the anomalous combinations 800 will not amplify into a flood of alarm messages. It MUST be 801 possible to suppress alarms or logging, e.g. if it becomes 802 apparent that a combination that previously was not used has 803 started to be used for legitimate purposes such as a new standards 804 action. 806 The above logic allows for ECT(0) and ECT(1) to both represent the 807 same severity of congestion marking (e.g. "not congestion marked"). 808 But it also allows future schemes to be defined where ECT(1) is a 809 more severe marking than ECT(0), in particular enabling the simplest 810 possible encoding for PCN [I-D.ietf-pcn-3-in-1-encoding] (see 811 Section 5.3.2). Treating ECT(1) as either the same as ECT(0) or as a 812 higher severity level is explained in the discussion of the ECN nonce 814 [RFC3540] in Section 9, which in turn refers to Appendix D. 816 4.3. Encapsulation Modes 818 Section 4.1 introduces two encapsulation modes, normal mode and 819 compatibility mode, defining their encapsulation behaviour (i.e. 820 header copying or zeroing respectively). Note that these are modes 821 of the ingress tunnel endpoint only, not the tunnel as a whole. 823 To comply with this specification, a tunnel ingress MUST at least 824 implement `normal mode'. Unless it will never be used with legacy 825 tunnel egress nodes (RFC2003, RFC2401 or RFC2481 or the limited 826 functionality mode of RFC3168), an ingress MUST also implement 827 `compatibility mode' for backward compatibility with tunnel egresses 828 that do not propagate explicit congestion notifications [RFC4774]. 830 We can categorise the way that an ingress tunnel endpoint is paired 831 with an egress as either static or dynamically discovered: 833 Static: Tunnel endpoints paired together by prior configuration. 835 Some implementations of encapsulator might always be statically 836 deployed, and constrained to never be paired with a legacy 837 decapsulator (RFC2003, RFC2401 or RFC2481 or the limited 838 functionality mode of RFC3168). In such a case, only normal mode 839 needs to be implemented. 841 For instance, RFC4301-compatible IPsec tunnel endpoints invariably 842 use IKEv2 [RFC4306] for key exchange, which was introduced 843 alongside RFC4301. Therefore both endpoints of an RFC4301 tunnel 844 can be sure that the other end is RFC4301-compatible, because the 845 tunnel is only formed after IKEv2 key management has completed, at 846 which point both ends will be RFC4301-compliant by definition. 847 Therefore an IPsec tunnel ingress does not need compatibility 848 mode, as it will never interact with legacy ECN tunnels. To 849 comply with the present specification, it only needs to implement 850 the required normal mode, which is identical to the pre-existing 851 RFC4301 behaviour. 853 Dynamic Discovery: Tunnel endpoints paired together by some form of 854 tunnel endpoint discovery, typically finding an egress on the path 855 taken by the first packet. 857 This specification does not require or recommend dynamic discovery 858 and it does not define how dynamic negotiation might be done, but 859 it recognises that proprietary tunnel endpoint discovery protocols 860 exist. It therefore sets down some constraints on discovery 861 protocols to ensure safe interworking. 863 If dynamic tunnel endpoint discovery might pair an ingress with a 864 legacy egress (RFC2003, RFC2401 or RFC2481 or the limited 865 functionality mode of RFC3168), the ingress MUST implement both 866 normal and compatibility mode. If the tunnel discovery process is 867 arranged to only ever find a tunnel egress that propagates ECN 868 (RFC3168 full functionality mode, RFC4301 or this present 869 specification), then a tunnel ingress can be compliant with the 870 present specification without implementing compatibility mode. 872 While a compliant tunnel ingress is discovering an egress, it MUST 873 send packets in compatibility mode in case the egress it discovers 874 is a legacy egress. If, through the discovery protocol, the 875 egress indicates that it is compliant with the present 876 specification, with RFC4301 or with RFC3168 full functionality 877 mode, the ingress can switch itself into normal mode. If the 878 egress denies compliance with any of these or returns an error 879 that implies it does not understand a request to work to any of 880 these ECN specifications, the tunnel ingress MUST remain in 881 compatibility mode. 883 If an ingress claims compliance with this specification it MUST NOT 884 permanently disable ECN processing across the tunnel (i.e. only using 885 compatibility mode). It is true that such a tunnel ingress is at 886 least safe with the ECN behaviour of any egress it may encounter, but 887 it does not meet the central aim of this specification: introducing 888 ECN support to tunnels. 890 Instead, if the ingress knows that the egress does support 891 propagation of ECN (full functionality mode of RFC3168 or RFC4301 or 892 the present specification), it SHOULD use normal mode, in order to 893 support ECN where possible. Note that this section started by saying 894 an ingress "MUST implement "normal mode, while it has just said an 895 ingress "SHOULD use" normal mode. This distinction is deliberate, to 896 allow the mode to be turned off in exceptional circumstances but to 897 ensure all implementations make normal mode available. 899 Implementation note: If a compliant node is the ingress for multiple 900 tunnels, a mode setting will need to be stored for each tunnel 901 ingress. However, if a node is the egress for multiple tunnels, 902 none of the tunnels will need to store a mode setting, because a 903 compliant egress only needs one mode. 905 4.4. Single Mode of Decapsulation 907 A compliant decapsulator only needs one mode of operation. However, 908 if a compliant egress is implemented to be dynamically discoverable, 909 it may need to respond to discovery requests from various types of 910 legacy tunnel ingress. This specification does not define how 911 dynamic negotiation might be done by (proprietary) discovery 912 protocols, but it sets down some constraints to ensure safe 913 interworking. 915 Through the discovery protocol, a tunnel ingress compliant with the 916 present specification might ask if the egress is compliant with the 917 present specification, with RFC4301 or with RFC3168 full 918 functionality mode. Or an RFC3168 tunnel ingress might try to 919 negotiate to use limited functionality or full functionality mode 920 [RFC3168]. In all these cases, a decapsulating tunnel egress 921 compliant with this specification MUST agree to any of these 922 requests, since it will behave identically in all these cases. 924 If no ECN-related mode is requested, a compliant tunnel egress MUST 925 continue without raising any error or warning, because its egress 926 behaviour is compatible with all the legacy ingress behaviours that 927 do not negotiate capabilities. 929 A compliant tunnel egress SHOULD raise a warning alarm about any 930 requests to enter modes it does not recognise but, for 'forward 931 compatibility' with standards actions possibly defined after it was 932 implemented, it SHOULD continue operating. 934 5. Updates to Earlier RFCs 936 5.1. Changes to RFC4301 ECN processing 938 Ingress: An RFC4301 IPsec encapsulator is not changed at all by the 939 present specification. It uses the normal mode of the present 940 specification, which defines packet encapsulation identically to 941 RFC4301. 943 Egress: An RFC4301 egress will need to be updated to the new 944 decapsulation behaviour in Figure 4, in order to comply with the 945 present specification. However, the changes are backward 946 compatible; combinations of inner and outer that result from any 947 protocol defined in the RFC series so far are unaffected. Only 948 combinations that have never been used have been changed, 949 effectively adding new behaviours to RFC4301 decapsulation without 950 altering existing behaviours. The following specific updates have 951 been made: 953 * The outer, not the inner, is propagated when the outer is 954 ECT(1) and the inner is ECT(0); 956 * A packet with Not-ECT in the inner and an outer of CE is 957 dropped rather than forwarded as Not-ECT; 959 * Certain combinations of inner and outer ECN field have been 960 identified as currently unused. These can trigger logging 961 and/or raise alarms. 963 Modes: RFC4301 tunnel endpoints do not need modes and are not 964 updated by the modes in the present specification. Effectively an 965 RFC4301 IPsec ingress solely uses the REQUIRED normal mode of 966 encapsulation, which is unchanged from RFC4301 encapsulation. It 967 will never need the OPTIONAL compatibility mode as explained in 968 Section 4.3. 970 5.2. Changes to RFC3168 ECN processing 972 Ingress: On encapsulation, the new rule in Figure 3 that a normal 973 mode tunnel ingress copies any ECN field into the outer header 974 updates the full functionality behaviour of an RFC3168 ingress. 975 Nonetheless, the new compatibility mode encapsulates packets 976 identically to the limited functionality mode of an RFC3168 977 ingress. 979 Egress: An RFC3168 egress will need to be updated to the new 980 decapsulation behaviour in Figure 4, in order to comply with the 981 present specification. However, the changes are backward 982 compatible; combinations of inner and outer that result from any 983 protocol defined in the RFC series so far are unaffected. Only 984 combinations that have never been used have been changed, 985 effectively adding new behaviours to RFC3168 decapsulation without 986 altering existing behaviours. The following specific updates have 987 been made: 989 * The outer, not the inner, is propagated when the outer is 990 ECT(1) and the inner is ECT(0); 992 * Certain combinations of inner and outer ECN field have been 993 identified as currently unused. These can trigger logging 994 and/or raise alarms. 996 Modes: An RFC3168 ingress will need to be updated if it is to comply 997 with the present specification, whether or not it implemented the 998 optional full functionality mode of RFC3168. 1000 RFC3168 defined a (required) limited functionality mode and an 1001 (optional) full functionality mode for a tunnel. In RFC3168, 1002 modes applied to both ends of the tunnel, while in the present 1003 specification, modes are only used at the ingress--a single egress 1004 behaviour covers all cases. 1006 The normal mode of encapsulation is an update to the encapsulation 1007 behaviour of the full functionality mode of an RFC3168 ingress. 1008 The compatibility mode of encapsulation is identical to the 1009 encapsulation behaviour of the limited functionality mode of an 1010 RFC3168 ingress, except it is optional. 1012 The constraints on how tunnel discovery protocols set modes in 1013 Section 4.3 and Section 4.4 are an update to RFC3168, but they are 1014 unlikely to require code changes as they document existing safe 1015 practice. 1017 5.3. Motivation for Changes 1019 An overriding goal is to ensure the same ECN signals can mean the 1020 same thing whatever tunnels happen to encapsulate an IP packet flow. 1021 This removes gratuitous inconsistency, which otherwise constrains the 1022 available design space and makes it harder to design networks and new 1023 protocols that work predictably. 1025 5.3.1. Motivation for Changing Encapsulation 1027 The normal mode in Section 4 updates RFC3168 to make all IP in IP 1028 encapsulation of the ECN field consistent--consistent with the way 1029 both RFC4301 IPsec [RFC4301] and IP in MPLS or MPLS in MPLS 1030 encapsulation [RFC5129] construct the ECN field. 1032 Compatibility mode has also been defined so that a non-RFC4301 1033 ingress can still switch to using drop across a tunnel for backwards 1034 compatibility with legacy decapsulators that do not propagate ECN 1035 correctly. 1037 The trigger that motivated this update to RFC3168 encapsulation was a 1038 standards track proposal for pre-congestion notification (PCN 1039 [RFC5670]). PCN excess rate marking only works correctly if the ECN 1040 field is copied on encapsulation (as in RFC4301 and RFC5129); it does 1041 not work if ECN is reset (as in RFC3168). This is because PCN excess 1042 rate marking depends on the outer header revealing any congestion 1043 experienced so far on the whole path, not just since the last tunnel 1044 ingress. 1046 PCN allows a network operator to add flow admission and termination 1047 for inelastic traffic at the edges of a Diffserv domain, but without 1048 any per-flow mechanisms in the interior and without the generous 1049 provisioning typical of Diffserv, aiming to significantly reduce 1050 costs. The PCN architecture [RFC5559] states that RFC3168 IP in IP 1051 tunnelling of the ECN field cannot be used for any tunnel ingress in 1052 a PCN domain. Prior to the present specification, this left a stark 1053 choice between not being able to use PCN for inelastic traffic 1054 control or not being able to use the many tunnels already deployed 1055 for Mobile IP, VPNs and so forth. 1057 The present specification provides a clean solution to this problem, 1058 so that network operators who want to use both PCN and tunnels can 1059 specify that every tunnel ingress in a PCN region must comply with 1060 this latest specification. 1062 Rather than allow tunnel specifications to fragment further into one 1063 for PCN, one for IPsec and one for other tunnels, the opportunity has 1064 been taken to consolidate the diverging specifications back into a 1065 single tunnelling behaviour. Resetting ECN was originally motivated 1066 by a covert channel concern that has been deliberately set aside in 1067 RFC4301 IPsec. Therefore the reset behaviour of RFC3168 is an 1068 anomaly that we do not need to keep. Copying ECN on encapsulation is 1069 anyway simpler than resetting. So, as more tunnel endpoints comply 1070 with this single consistent specification, encapsulation will be 1071 simpler as well as more predictable. 1073 Appendix B assesses whether copying rather than resetting CE on 1074 ingress will cause any unintended side-effects, from the three 1075 perspectives of security, control and management. In summary this 1076 analysis finds that: 1078 o From the control perspective either copying or resetting works for 1079 existing arrangements, but copying has more potential for 1080 simplifying control and resetting breaks at least one proposal 1081 already on the standards track. 1083 o From the management and monitoring perspective copying is 1084 preferable. 1086 o From the traffic security perspective (enforcing congestion 1087 control, mitigating denial of service etc) copying is preferable. 1089 o From the information security perspective resetting is preferable, 1090 but the IETF Security Area now considers copying acceptable given 1091 the bandwidth of a 2-bit covert channel can be managed. 1093 Therefore there are two points against resetting CE on ingress while 1094 copying CE causes no significant harm. 1096 5.3.2. Motivation for Changing Decapsulation 1098 The specification for decapsulation in Section 4 fixes three problems 1099 with the pre-existing behaviours of both RFC3168 and RFC4301: 1101 1. The pre-existing rules prevented the introduction of alternate 1102 ECN semantics to signal more than one severity level of 1103 congestion [RFC4774], [RFC5559]. The four states of the 2-bit 1104 ECN field provide room for signalling two severity levels in 1105 addition to not-congested and not-ECN-capable states. But, the 1106 pre-existing rules assumed that two of the states (ECT(0) and 1107 ECT(1)) are always equivalent. This unnecessarily restricts the 1108 use of one of four codepoints (half a bit) in the IP (v4 & v6) 1109 header. The new rules are designed to work in either case; 1110 whether ECT(1) is more severe than or equivalent to ECT(0). 1112 As explained in Appendix B.1, the original reason for not 1113 forwarding the outer ECT codepoints was to limit the covert 1114 channel across a decapsulator to 1 bit per packet. However, now 1115 that the IETF Security Area has deemed that a 2-bit covert 1116 channel through an encapsulator is a manageable risk, the same 1117 should be true for a decapsulator. 1119 As well as being useful for general future-proofing, this problem 1120 is immediately pressing for standardisation of pre-congestion 1121 notification (PCN), which uses two severity levels of congestion. 1122 If a congested queue used ECT(1) in the outer header to signal 1123 more severe congestion than ECT(0), the pre-existing 1124 decapsulation rules would have thrown away this congestion 1125 signal, preventing tunnelled traffic from ever knowing that it 1126 should reduce its load. 1128 Before the present specification was written, the PCN working 1129 group had to consider a number of wasteful or convoluted work- 1130 rounds to this problem. Without wishing to disparage the 1131 ingenuity of these work-rounds, none were chosen for the 1132 standards track because they were either somewhat wasteful, 1133 imprecise or complicated. Instead a baseline PCN encoding was 1134 specified [RFC5696] that supported only one severity level of 1135 congestion but allowed space for these work-rounds as 1136 experimental extensions. 1138 But by far the simplest approach is that taken by the current 1139 specification: just to remove the covert channel blockages from 1140 tunnelling behaviour--now deemed unnecessary anyway. Then 1141 network operators that want to support two congestion severity- 1142 levels for PCN can specify that every tunnel egress in a PCN 1143 region must comply with this latest specification. Having taken 1144 this step, the simplest possible encoding for PCN with two 1145 severity levels of congestion [I-D.ietf-pcn-3-in-1-encoding] can 1146 be used. 1148 Not only does this make two congestion severity-levels available 1149 for PCN, but also for other potential uses of the extra ECN 1150 codepoint (e.g. [VCP]). 1152 2. Cases are documented where a middlebox (e.g. a firewall) drops 1153 packets with header values that were currently unused (CU) when 1154 the box was deployed, often on the grounds that anything 1155 unexpected might be an attack. This tends to bar future use of 1156 CU values. The new decapsulation rules specify optional logging 1157 and/or alarms for specific combinations of inner and outer header 1158 that are currently unused. The aim is to give implementers a 1159 recourse other than drop if they are concerned about the security 1160 of CU values. It recognises legitimate security concerns about 1161 CU values but still eases their future use. If the alarms are 1162 interpreted as an attack (e.g. by a management system) the 1163 offending packets can be dropped. But alarms can be turned off 1164 if these combinations come into regular use (e.g. through a 1165 future standards action). 1167 3. While reviewing currently unused combinations of inner and outer, 1168 the opportunity was taken to define a single consistent behaviour 1169 for the three cases with a Not-ECT inner header but a different 1170 outer. RFC3168 and RFC4301 had diverged in this respect and even 1171 their common behaviours had never been justified. 1173 None of these combinations should result from Internet protocols 1174 in the RFC series, but future standards actions might put any or 1175 all of them to good use. Therefore it was decided that a 1176 decapsulator must forward a Not-ECT inner unchanged when the 1177 arriving outer is ECT(0) or ECT(1). But for safety it must drop 1178 a combination of Not-ECT inner and CE outer. Then, if some 1179 unfortunate misconfiguration resulted in a congested router 1180 marking CE on a packet that was originally Not-ECT, drop would be 1181 the only appropriate signal for the egress to propagate--the only 1182 signal a non-ECN-capable transport (Not-ECT) would understand. 1184 It may seem contradictory that the same argument has not been 1185 applied to the ECT(1) codepoint, given it is being proposed as an 1186 intermediate level of congestion in a scheme progressing through 1187 the IETF [I-D.ietf-pcn-3-in-1-encoding]. Instead, a decapsulator 1188 must forward a Not-ECT inner unchanged when its outer is ECT(1). 1189 The rationale for not dropping this CU combination is to ensure 1190 it will be usable if needed in the future. If any 1191 misconfiguration led to ECT(1) congestion signals with a Not-ECT 1192 inner, it would not be disastrous for the tunnel egress to 1193 suppress them, because the congestion should then escalate to CE 1194 marking, which the egress would drop, thus at least preventing 1195 congestion collapse. 1197 Problems 2 & 3 alone would not warrant a change to decapsulation, but 1198 it was decided they are worth fixing and making consistent at the 1199 same time as decapsulation code is changed to fix problem 1 (two 1200 congestion severity-levels). 1202 6. Backward Compatibility 1204 A tunnel endpoint compliant with the present specification is 1205 backward compatible when paired with any tunnel endpoint compliant 1206 with any previous tunnelling RFC, whether RFC4301, RFC3168 (see 1207 Section 3) or the earlier RFCs summarised in Appendix A (RFC2481, 1208 RFC2401 and RFC2003). Each case is enumerated below. 1210 6.1. Non-Issues Updating Decapsulation 1212 At the egress, this specification only augments the per-packet 1213 calculation of the ECN field (RFC3168 and RFC4301) for combinations 1214 of inner and outer headers that have so far not been used in any IETF 1215 protocols. 1217 Therefore, all other things being equal, if an RFC4301 IPsec egress 1218 is updated to comply with the new rules, it will still interwork with 1219 any RFC4301 compliant ingress and the packet outputs will be 1220 identical to those it would have output before (fully backward 1221 compatible). 1223 And, all other things being equal, if an RFC3168 egress is updated to 1224 comply with the same new rules, it will still interwork with any 1225 ingress complying with any previous specification (both modes of 1226 RFC3168, both modes of RFC2481, RFC2401 and RFC2003) and the packet 1227 outputs will be identical to those it would have output before (fully 1228 backward compatible). 1230 A compliant tunnel egress merely needs to implement the one behaviour 1231 in Section 4 with no additional mode or option configuration at the 1232 ingress or egress nor any additional negotiation with the ingress. 1233 The new decapsulation rules have been defined in such a way that 1234 congestion control will still work safely if any of the earlier 1235 versions of ECN processing are used unilaterally at the encapsulating 1236 ingress of the tunnel (any of RFC2003, RFC2401, either mode of 1237 RFC2481, either mode of RFC3168, RFC4301 and this present 1238 specification). 1240 6.2. Non-Update of RFC4301 IPsec Encapsulation 1242 An RFC4301 IPsec ingress can comply with this new specification 1243 without any update and it has no need for any new modes, options or 1244 configuration. So, all other things being equal, it will continue to 1245 interwork identically with any egress it worked with before (fully 1246 backward compatible). 1248 6.3. Update to RFC3168 Encapsulation 1250 The encapsulation behaviour of the new normal mode copies the ECN 1251 field whereas RFC3168 full functionality mode reset it. However, all 1252 other things being equal, if RFC3168 ingress is updated to the 1253 present specification, the outgoing packets from any tunnel egress 1254 will still be unchanged. This is because all variants of tunnelling 1255 at either end (RFC4301, both modes of RFC3168, both modes of RFC2481, 1256 RFC2401, RFC2003 and the present specification) have always 1257 propagated an incoming CE marking through the inner header and onward 1258 into the outgoing header, whether the outer header is reset or 1259 copied. Therefore, If the tunnel is considered as a black box, the 1260 packets output from any egress will be identical with or without an 1261 update to the ingress. Nonetheless, if packets are observed within 1262 the black box (between the tunnel endpoints), CE markings copied by 1263 the updated ingress will be visible within the black box, whereas 1264 they would not have been before. Therefore, the update to 1265 encapsulation can be termed 'black-box backwards compatible' (i.e. 1266 identical unless you look inside the tunnel). 1268 This specification introduces no new backward compatibility issues 1269 when a compliant ingress talks with a legacy egress, but it has to 1270 provide similar safeguards to those already defined in RFC3168. 1271 RFC3168 laid down rules to ensure that an RFC3168 ingress turns off 1272 ECN (limited functionality mode) if it is paired with a legacy egress 1273 (RFC 2481, RFC2401 or RFC2003), which would not propagate ECN 1274 correctly. The present specification carries forward those rules 1275 (Section 4.3). It uses compatibility mode whenever RFC3168 would 1276 have used limited functionality mode, and their per-packet behaviours 1277 are identical. Therefore, all other things being equal, an ingress 1278 using the new rules will interwork with any legacy tunnel egress in 1279 exactly the same way as an RFC3168 ingress (still black-box backward 1280 compatible). 1282 7. Design Principles for Alternate ECN Tunnelling Semantics 1284 This section is informative not normative. 1286 S.5 of RFC3168 permits the Diffserv codepoint (DSCP)[RFC2474] to 1287 'switch in' alternative behaviours for marking the ECN field, just as 1288 it switches in different per-hop behaviours (PHBs) for scheduling. 1289 [RFC4774] gives best current practice for designing such alternative 1290 ECN semantics and very briefly mentions in section 5.4 that 1291 tunnelling needs to be considered. The guidance below complements 1292 and extends RFC4774, giving additional guidance on designing any 1293 alternate ECN semantics that would also require alternate tunnelling 1294 semantics. 1296 The overriding guidance is: "Avoid designing alternate ECN tunnelling 1297 semantics, if at all possible." If a scheme requires tunnels to 1298 implement special processing of the ECN field for certain DSCPs, it 1299 will be hard to guarantee that every implementer of every tunnel will 1300 have added the required exception or that operators will have 1301 ubiquitously deployed the required updates. It is unlikely a single 1302 authority is even aware of all the tunnels in a network, which may 1303 include tunnels set up by applications between endpoints, or 1304 dynamically created in the network. Therefore it is highly likely 1305 that some tunnels within a network or on hosts connected to it will 1306 not implement the required special case. 1308 That said, if a non-default scheme for tunnelling the ECN field is 1309 really required, the following guidelines might prove useful in its 1310 design: 1312 On encapsulation in any alternate scheme: 1314 1. The ECN field of the outer header ought to be cleared to Not- 1315 ECT ("00") unless it is guaranteed that the corresponding 1316 tunnel egress will correctly propagate congestion markings 1317 introduced across the tunnel in the outer header. 1319 2. If it has established that ECN will be correctly propagated, 1320 an encapsulator ought to also copy incoming congestion 1321 notification into the outer header. The general principle 1322 here is that the outer header should reflect congestion 1323 accumulated along the whole upstream path, not just since the 1324 tunnel ingress (Appendix B.3 on management and monitoring 1325 explains). 1327 In some circumstances (e.g. pseudowires, PCN), the whole path 1328 is divided into segments, each with its own congestion 1329 notification and feedback loop. In these cases, the function 1330 that regulates load at the start of each segment will need to 1331 reset congestion notification for its segment. Often the 1332 point where congestion notification is reset will also be 1333 located at the start of a tunnel. However, the resetting 1334 function can be thought of as being applied to packets after 1335 the encapsulation function--two logically separate functions 1336 even though they might run on the same physical box. Then the 1337 code module doing encapsulation can keep to the copying rule 1338 and the load regulator module can reset congestion, without 1339 any code in either module being conditional on whether the 1340 other is there. 1342 On decapsulation in any new scheme: 1344 1. If the arriving inner header is Not-ECT it implies the 1345 transport will not understand other ECN codepoints. If the 1346 outer header carries an explicit congestion marking, the 1347 alternate scheme would be expected to drop the packet--the 1348 only indication of congestion the transport will understand. 1349 If the alternate scheme recommends forwarding rather than 1350 dropping such a packet, it will need to clearly justify this 1351 decision. If the inner is Not-ECT and the outer carries any 1352 other ECN codepoint that does not indicate congestion, the 1353 alternate scheme can forward the packet, but probably only as 1354 Not-ECT. 1356 2. If the arriving inner header is other than Not-ECT, the ECN 1357 field that the alternate decapsulation scheme forwards ought 1358 to reflect the more severe congestion marking of the arriving 1359 inner and outer headers. 1361 3. Any alternate scheme will need to define a behaviour for all 1362 combinations of inner and outer headers, even those that would 1363 not be expected to result from standards known at the time and 1364 even those that would not be expected from the tunnel ingress 1365 paired with the egress at run-time. Consideration should be 1366 given to logging such unexpected combinations and raising an 1367 alarm, particularly if there is a danger that the invalid 1368 combination implies congestion signals are not being 1369 propagated correctly. The presence of currently unused 1370 combinations may represent an attack, but the new scheme 1371 should try to define a way to forward such packets, at least 1372 if a safe outgoing codepoint can be defined. 1374 Raising an alarm allows a management system to decide whether 1375 the anomaly is indeed an attack, in which case it can decide 1376 to drop such packets. This is a preferable approach to hard- 1377 coded discard of packets that seem anomalous today, but may be 1378 needed tomorrow in future standards actions. 1380 8. IANA Considerations (to be removed on publication): 1382 This memo includes no request to IANA. 1384 9. Security Considerations 1386 Appendix B.1 discusses the security constraints imposed on ECN tunnel 1387 processing. The new rules for ECN tunnel processing (Section 4) 1388 trade-off between information security (covert channels) and traffic 1389 security (congestion monitoring & control). Ensuring congestion 1390 markings are not lost is itself an aspect of security, because if we 1391 allowed congestion notification to be lost, any attempt to enforce a 1392 response to congestion would be much harder. 1394 Security issues in unlikely but possible scenarios: 1396 Tunnels intersecting Diffserv regions with alternate ECN semantics: 1397 If alternate congestion notification semantics are defined for a 1398 certain Diffserv PHB, the scope of the alternate semantics might 1399 typically be bounded by the limits of a Diffserv region or 1400 regions, as envisaged in [RFC4774] (e.g. the pre-congestion 1401 notification architecture [RFC5559]). The inner headers in 1402 tunnels crossing the boundary of such a Diffserv region but ending 1403 within the region can potentially leak the external congestion 1404 notification semantics into the region, or leak the internal 1405 semantics out of the region. [RFC2983] discusses the need for 1406 Diffserv traffic conditioning to be applied at these tunnel 1407 endpoints as if they are at the edge of the Diffserv region. 1408 Similar concerns apply to any processing or propagation of the ECN 1409 field at the endpoints of tunnels with one end inside and the 1410 other outside the domain. [RFC5559] gives specific advice on this 1411 for the PCN case, but other definitions of alternate semantics 1412 will need to discuss the specific security implications in each 1413 case. 1415 ECN nonce tunnel coverage: The new decapsulation rules improve the 1416 coverage of the ECN nonce [RFC3540] relative to the previous rules 1417 in RFC3168 and RFC4301. However, nonce coverage is still not 1418 perfect, as this would have led to a safety problem in another 1419 case. Both are corner-cases, so discussion of the compromise 1420 between them is deferred to Appendix D. 1422 Covert channel not turned off: A legacy (RFC3168) tunnel ingress 1423 could ask an RFC3168 egress to turn off ECN processing as well as 1424 itself turning off ECN. An egress compliant with the present 1425 specification will agree to such a request from a legacy ingress, 1426 but it relies on the ingress always sending Not-ECT in the outer. 1427 If the egress receives other ECN codepoints in the outer it will 1428 process them as normal, so it will actually still copy congestion 1429 markings from the outer to the outgoing header. Referring for 1430 example to Figure 5 (Appendix B.1), although the tunnel ingress 1431 'I' will set all ECN fields in outer headers to Not-ECT, 'M' could 1432 still toggle CE or ECT(1) on and off to communicate covertly with 1433 'B', because we have specified that 'E' only has one mode 1434 regardless of what mode it says it has negotiated. We could have 1435 specified that 'E' should have a limited functionality mode and 1436 check for such behaviour. But we decided not to add the extra 1437 complexity of two modes on a compliant tunnel egress merely to 1438 cater for an historic security concern that is now considered 1439 manageable. 1441 10. Conclusions 1443 This document allows tunnels to propagate an extra level of 1444 congestion severity. It uses previously unused combinations of inner 1445 and outer header to augment the rules for calculating the ECN field 1446 when decapsulating IP packets at the egress of IPsec (RFC4301) and 1447 non-IPsec (RFC3168) tunnels. 1449 This document also updates the ingress tunnelling encapsulation of 1450 RFC3168 ECN to bring all IP in IP tunnels into line with the new 1451 behaviour in the IPsec architecture of RFC4301, which copies rather 1452 than resets the ECN field when creating outer headers. 1454 The need for both these updated behaviours was triggered by the 1455 introduction of pre-congestion notification (PCN) onto the IETF 1456 standards track. Operators wanting to support PCN or other alternate 1457 ECN schemes that use an extra severity level can require that their 1458 tunnels comply with the present specification. This is not a fork in 1459 the RFC series, it is an update that can be deployed first by those 1460 that need it, and subsequently by all tunnel endpoint implementations 1461 during general code maintenance. It is backward compatible with all 1462 previous tunnelling behaviours, so existing single severity level 1463 schemes will continue to work as before, but support for two severity 1464 levels will gradually be added to the Internet. 1466 The new rules propagate changes to the ECN field across tunnel end- 1467 points that previously blocked them to restrict the bandwidth of a 1468 potential covert channel. Limiting the channel's bandwidth to 2 bits 1469 per packet is now considered sufficient. 1471 At the same time as removing these legacy constraints, the 1472 opportunity has been taken to draw together diverging tunnel 1473 specifications into a single consistent behaviour. Then any tunnel 1474 can be deployed unilaterally, and it will support the full range of 1475 congestion control and management schemes without any modes or 1476 configuration. Further, any host or router can expect the ECN field 1477 to behave in the same way, whatever type of tunnel might intervene in 1478 the path. This new certainty could enable new uses of the ECN field 1479 that would otherwise be confounded by ambiguity. 1481 11. Acknowledgements 1483 Thanks to David Black for his insightful reviews and patient 1484 explanations of better ways to think about function placement and 1485 alarms. Thanks to David and to Anil Agarwal for pointing out cases 1486 where it is safe to forward CU combinations of headers. Also thanks 1487 to Arnaud Jacquet for the idea for Appendix C. Thanks to Gorry 1488 Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster, 1489 Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson and 1490 Philip Eardley for their thoughts and careful review comments, and to 1491 Stephen Hanna and Ben Campbell respectively for conducting the 1492 Security Directorate and General Area reviews. 1494 Bob Briscoe is partly funded by Trilogy, a research project (ICT- 1495 216372) supported by the European Community under its Seventh 1496 Framework Programme. The views expressed here are those of the 1497 author only. 1499 Comments Solicited (to be removed by the RFC Editor): 1501 Comments and questions are encouraged and very welcome. They can be 1502 addressed to the IETF Transport Area working group mailing list 1503 , and/or to the authors. 1505 12. References 1507 12.1. Normative References 1509 [RFC2003] Perkins, C., "IP Encapsulation within 1510 IP", RFC 2003, October 1996. 1512 [RFC2119] Bradner, S., "Key words for use in 1513 RFCs to Indicate Requirement Levels", 1514 BCP 14, RFC 2119, March 1997. 1516 [RFC3168] Ramakrishnan, K., Floyd, S., and D. 1517 Black, "The Addition of Explicit 1518 Congestion Notification (ECN) to IP", 1519 RFC 3168, September 2001. 1521 [RFC4301] Kent, S. and K. Seo, "Security 1522 Architecture for the Internet 1523 Protocol", RFC 4301, December 2005. 1525 12.2. Informative References 1527 [I-D.ietf-pcn-3-in-1-encoding] Briscoe, B., Moncaster, T., and M. 1528 Menth, "Encoding 3 PCN-States in the 1529 IP header using a single DSCP", 1530 draft-ietf-pcn-3-in-1-encoding-03 1531 (work in progress), July 2010. 1533 [RFC2401] Kent, S. and R. Atkinson, "Security 1534 Architecture for the Internet 1535 Protocol", RFC 2401, November 1998. 1537 [RFC2474] Nichols, K., Blake, S., Baker, F., 1538 and D. Black, "Definition of the 1539 Differentiated Services Field (DS 1540 Field) in the IPv4 and IPv6 Headers", 1541 RFC 2474, December 1998. 1543 [RFC2481] Ramakrishnan, K. and S. Floyd, "A 1544 Proposal to add Explicit Congestion 1545 Notification (ECN) to IP", RFC 2481, 1546 January 1999. 1548 [RFC2983] Black, D., "Differentiated Services 1549 and Tunnels", RFC 2983, October 2000. 1551 [RFC3540] Spring, N., Wetherall, D., and D. 1552 Ely, "Robust Explicit Congestion 1553 Notification (ECN) Signaling with 1554 Nonces", RFC 3540, June 2003. 1556 [RFC4306] Kaufman, C., "Internet Key Exchange 1557 (IKEv2) Protocol", RFC 4306, 1558 December 2005. 1560 [RFC4774] Floyd, S., "Specifying Alternate 1561 Semantics for the Explicit Congestion 1562 Notification (ECN) Field", BCP 124, 1563 RFC 4774, November 2006. 1565 [RFC5129] Davie, B., Briscoe, B., and J. Tay, 1566 "Explicit Congestion Marking in 1567 MPLS", RFC 5129, January 2008. 1569 [RFC5559] Eardley, P., "Pre-Congestion 1570 Notification (PCN) Architecture", 1571 RFC 5559, June 2009. 1573 [RFC5670] Eardley, P., "Metering and Marking 1574 Behaviour of PCN-Nodes", RFC 5670, 1575 November 2009. 1577 [RFC5696] Moncaster, T., Briscoe, B., and M. 1578 Menth, "Baseline Encoding and 1579 Transport of Pre-Congestion 1580 Information", RFC 5696, 1581 November 2009. 1583 [VCP] Xia, Y., Subramanian, L., Stoica, I., 1584 and S. Kalyanaraman, "One more bit is 1585 enough", Proc. SIGCOMM'05, ACM 1586 CCR 35(4)37--48, 2005, . 1589 Appendix A. Early ECN Tunnelling RFCs 1591 IP in IP tunnelling was originally defined in [RFC2003]. On 1592 encapsulation, the incoming header was copied to the outer and on 1593 decapsulation the outer was simply discarded. Initially, IPsec 1594 tunnelling [RFC2401] followed the same behaviour. 1596 When ECN was introduced experimentally in [RFC2481], legacy (RFC2003 1597 or RFC2401) tunnels would have discarded any congestion markings 1598 added to the outer header, so RFC2481 introduced rules for 1599 calculating the outgoing header from a combination of the inner and 1600 outer on decapsulation. RC2481 also introduced a second mode for 1601 IPsec tunnels, which turned off ECN processing (Not-ECT) in the outer 1602 header on encapsulation because an RFC2401 decapsulator would discard 1603 the outer on decapsulation. For RFC2401 IPsec this had the side- 1604 effect of completely blocking the covert channel. 1606 In RFC2481 the ECN field was defined as two separate bits. But when 1607 ECN moved from the experimental to the standards track [RFC3168], the 1608 ECN field was redefined as four codepoints. This required a 1609 different calculation of the ECN field from that used in RFC2481 on 1610 decapsulation. RFC3168 also had two modes; a 'full functionality 1611 mode' that restricted the covert channel as much as possible but 1612 still allowed ECN to be used with IPsec, and another that completely 1613 turned off ECN processing across the tunnel. This 'limited 1614 functionality mode' both offered a way for operators to completely 1615 block the covert channel and allowed an RFC3168 ingress to interwork 1616 with a legacy tunnel egress (RFC2481, RFC2401 or RFC2003). 1618 The present specification includes a similar compatibility mode to 1619 interwork safely with tunnels compliant with any of these three 1620 earlier RFCs. However, unlike RFC3168, it is only a mode of the 1621 ingress, as decapsulation behaviour is the same in either case. 1623 Appendix B. Design Constraints 1625 Tunnel processing of a congestion notification field has to meet 1626 congestion control and management needs without creating new 1627 information security vulnerabilities (if information security is 1628 required). This appendix documents the analysis of the tradeoffs 1629 between these factors that led to the new encapsulation rules in 1630 Section 4.1. 1632 B.1. Security Constraints 1634 Information security can be assured by using various end to end 1635 security solutions (including IPsec in transport mode [RFC4301]), but 1636 a commonly used scenario involves the need to communicate between two 1637 physically protected domains across the public Internet. In this 1638 case there are certain management advantages to using IPsec in tunnel 1639 mode solely across the publicly accessible part of the path. The 1640 path followed by a packet then crosses security 'domains'; the ones 1641 protected by physical or other means before and after the tunnel and 1642 the one protected by an IPsec tunnel across the otherwise unprotected 1643 domain. The scenario in Figure 5 will be used where endpoints 'A' 1644 and 'B' communicate through a tunnel. The tunnel ingress 'I' and 1645 egress 'E' are within physically protected edge domains, while the 1646 tunnel spans an unprotected internetwork where there may be 'men in 1647 the middle', M. 1649 physically unprotected physically 1650 <-protected domain-><--domain--><-protected domain-> 1651 +------------------+ +------------------+ 1652 | | M | | 1653 | A-------->I=========>==========>E-------->B | 1654 | | | | 1655 +------------------+ +------------------+ 1656 <----IPsec secured----> 1657 tunnel 1659 Figure 5: IPsec Tunnel Scenario 1661 IPsec encryption is typically used to prevent 'M' seeing messages 1662 from 'A' to 'B'. IPsec authentication is used to prevent 'M' 1663 masquerading as the sender of messages from 'A' to 'B' or altering 1664 their contents. 'I' can use IPsec tunnel mode to allow 'A' to 1665 communicate with 'B', but impose encryption to prevent 'A' leaking 1666 information to 'M'. Or 'E' can insist that 'I' uses tunnel mode 1667 authentication to prevent 'M' communicating information to 'B'. 1669 Mutable IP header fields such as the ECN field (as well as the TTL/ 1670 Hop Limit and DS fields) cannot be included in the cryptographic 1671 calculations of IPsec. Therefore, if 'I' copies these mutable fields 1672 into the outer header that is exposed across the tunnel it will have 1673 allowed a covert channel from 'A' to M that bypasses its encryption 1674 of the inner header. And if 'E' copies these fields from the outer 1675 header to the inner, even if it validates authentication from 'I', it 1676 will have allowed a covert channel from 'M' to 'B'. 1678 ECN at the IP layer is designed to carry information about congestion 1679 from a congested resource towards downstream nodes. Typically a 1680 downstream transport might feed the information back somehow to the 1681 point upstream of the congestion that can regulate the load on the 1682 congested resource, but other actions are possible (see [RFC3168] 1683 S.6). In terms of the above unicast scenario, ECN effectively 1684 intends to create an information channel (for congestion signalling) 1685 from 'M' to 'B' (for 'B' to feed back to 'A'). Therefore the goals 1686 of IPsec and ECN are mutually incompatible, requiring some 1687 compromise. 1689 With respect to using the DS or ECN fields as covert channels, 1690 S.5.1.2 of RFC4301 says, "controls are provided to manage the 1691 bandwidth of this channel". Using the ECN processing rules of 1692 RFC4301, the channel bandwidth is two bits per datagram from 'A' to 1693 'M' and one bit per datagram from 'M' to 'A' (because 'E' limits the 1694 combinations of the 2-bit ECN field that it will copy). In both 1695 cases the covert channel bandwidth is further reduced by noise from 1696 any real congestion marking. RFC4301 implies that these covert 1697 channels are sufficiently limited to be considered a manageable 1698 threat. However, with respect to the larger (6b) DS field, the same 1699 section of RFC4301 says not copying is the default, but a 1700 configuration option can allow copying "to allow a local 1701 administrator to decide whether the covert channel provided by 1702 copying these bits outweighs the benefits of copying". Of course, an 1703 administrator considering copying of the DS field has to take into 1704 account that it could be concatenated with the ECN field giving an 8b 1705 per datagram covert channel. 1707 For tunnelling the 6b Diffserv field two conceptual models have had 1708 to be defined so that administrators can trade off security against 1709 the needs of traffic conditioning [RFC2983]: 1711 The uniform model: where the Diffserv field is preserved end-to-end 1712 by copying into the outer header on encapsulation and copying from 1713 the outer header on decapsulation. 1715 The pipe model: where the outer header is independent of that in the 1716 inner header so it hides the Diffserv field of the inner header 1717 from any interaction with nodes along the tunnel. 1719 However, for ECN, the new IPsec security architecture in RFC4301 only 1720 standardised one tunnelling model equivalent to the uniform model. 1721 It deemed that simplicity was more important than allowing 1722 administrators the option of a tiny increment in security, especially 1723 given not copying congestion indications could seriously harm 1724 everyone's network service. 1726 B.2. Control Constraints 1728 Congestion control requires that any congestion notification marked 1729 into packets by a resource will be able to traverse a feedback loop 1730 back to a function capable of controlling the load on that resource. 1731 To be precise, rather than calling this function the data source, it 1732 will be called the Load Regulator. This allows for exceptional cases 1733 where load is not regulated by the data source, but usually the two 1734 terms will be synonymous. Note the term "a function _capable of_ 1735 controlling the load" deliberately includes a source application that 1736 doesn't actually control the load but ought to (e.g. an application 1737 without congestion control that uses UDP). 1739 A--->R--->I=========>M=========>E-------->B 1741 Figure 6: Simple Tunnel Scenario 1743 A similar tunnelling scenario to the IPsec one just described will 1744 now be considered, but without the different security domains, 1745 because the focus now shifts to whether the control loop and 1746 management monitoring work (Figure 6). If resources in the tunnel 1747 are to be able to explicitly notify congestion and the feedback path 1748 is from 'B' to 'A', it will certainly be necessary for 'E' to copy 1749 any CE marking from the outer header to the inner header for onward 1750 transmission to 'B', otherwise congestion notification from resources 1751 like 'M' cannot be fed back to the Load Regulator ('A'). But it does 1752 not seem necessary for 'I' to copy CE markings from the inner to the 1753 outer header. For instance, if resource 'R' is congested, it can 1754 send congestion information to 'B' using the congestion field in the 1755 inner header without 'I' copying the congestion field into the outer 1756 header and 'E' copying it back to the inner header. 'E' can still 1757 write any additional congestion marking introduced across the tunnel 1758 into the congestion field of the inner header. 1760 All this shows that 'E' can preserve the control loop irrespective of 1761 whether 'I' copies congestion notification into the outer header or 1762 resets it. 1764 That is the situation for existing control arrangements but, because 1765 copying reveals more information, it would open up possibilities for 1766 better control system designs. For instance, resetting CE marking on 1767 encapsulation breaks the standards track PCN congestion marking 1768 scheme [RFC5670]. It ends up removing excessive amounts of traffic 1769 unnecessarily. Whereas copying CE markings at ingress leads to the 1770 correct control behaviour. 1772 B.3. Management Constraints 1774 As well as control, there are also management constraints. 1775 Specifically, a management system may monitor congestion markings in 1776 passing packets, perhaps at the border between networks as part of a 1777 service level agreement. For instance, monitors at the borders of 1778 autonomous systems may need to measure how much congestion has 1779 accumulated so far along the path, perhaps to determine between them 1780 how much of the congestion is contributed by each domain. 1782 In this document the baseline of congestion marking (or the 1783 Congestion Baseline) is defined as the source of the layer that 1784 created (or most recently reset) the congestion notification field. 1785 When monitoring congestion it would be desirable if the Congestion 1786 Baseline did not depend on whether packets were tunnelled or not. 1787 Given some tunnels cross domain borders (e.g. consider M in Figure 6 1788 is monitoring a border), it would therefore be desirable for 'I' to 1789 copy congestion accumulated so far into the outer headers, so that it 1790 is exposed across the tunnel. 1792 For management purposes it might be useful for the tunnel egress to 1793 be able to monitor whether congestion occurred across a tunnel or 1794 upstream of it. Superficially it appears that copying congestion 1795 markings at the ingress would make this difficult, whereas it was 1796 straightforward when an RFC3168 ingress reset them. However, 1797 Appendix C gives a simple and precise method for a tunnel egress to 1798 infer the congestion level introduced across a tunnel. It works 1799 irrespective of whether the ingress copies or resets congestion 1800 markings. 1802 Appendix C. Contribution to Congestion across a Tunnel 1804 This specification mandates that a tunnel ingress determines the ECN 1805 field of each new outer tunnel header by copying the arriving header. 1806 Concern has been expressed that this will make it difficult for the 1807 tunnel egress to monitor congestion introduced only along a tunnel, 1808 which is easy if the outer ECN field is reset at a tunnel ingress 1809 (RFC3168 full functionality mode). However, in fact copying CE marks 1810 at ingress will still make it easy for the egress to measure 1811 congestion introduced across a tunnel, as illustrated below. 1813 Consider 100 packets measured at the egress. Say it measures that 30 1814 are CE marked in the inner and outer headers and 12 have additional 1815 CE marks in the outer but not the inner. This means packets arriving 1816 at the ingress had already experienced 30% congestion. However, it 1817 does not mean there was 12% congestion across the tunnel. The 1818 correct calculation of congestion across the tunnel is p_t = 12/ 1819 (100-30) = 12/70 = 17%. This is easy for the egress to measure. It 1820 is simply the proportion of packets not marked in the inner header 1821 (70) that have a CE marking in the outer header (12). This technique 1822 works whether the ingress copies or resets CE markings, so it can be 1823 used by an egress that is not sure which RFC the ingress complies 1824 with. 1826 Figure 7 illustrates this in a combinatorial probability diagram. 1827 The square represents 100 packets. The 30% division along the bottom 1828 represents marking before the ingress, and the p_t division up the 1829 side represents marking introduced across the tunnel. 1831 ^ outer header marking 1832 | 1833 100% +-----+---------+ The large square 1834 | | | represents 100 packets 1835 | 30 | | 1836 | | | p_t = 12/(100-30) 1837 p_t + +---------+ = 12/70 1838 | | 12 | = 17% 1839 0 +-----+---------+---> 1840 0 30% 100% inner header marking 1842 Figure 7: Tunnel Marking of Packets Already Marked at Ingress 1844 Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0) Outer 1846 A packet with an ECT(1) inner and an ECT(0) outer should never arise 1847 from any known IETF protocol. Without giving a reason, RFC3168 and 1848 RFC4301 both say the outer should be ignored when decapsulating such 1849 a packet. This appendix explains why it was decided not to change 1850 this advice. 1852 In summary, ECT(0) always means 'not congested' and ECT(1) may imply 1853 the same [RFC3168] or it may imply a higher severity congestion 1854 signal [RFC4774], [I-D.ietf-pcn-3-in-1-encoding], depending on the 1855 transport in use. Whether they mean the same or not, at the ingress 1856 the outer should have started the same as the inner and only a broken 1857 or compromised router could have changed the outer to ECT(0). 1859 The decapsulator can detect this anomaly. But the question is, 1860 should it correct the anomaly by ignoring the outer, or should it 1861 reveal the anomaly to the end-to-end transport by forwarding the 1862 outer? 1864 On balance, it was decided that the decapsulator should correct the 1865 anomaly, but log the event and optionally raise an alarm. This is 1866 the safe action if ECT(1) is being used as a more severe marking than 1867 ECT(0), because it passes the more severe signal to the transport. 1869 However, it is not a good idea to hide anomalies, which is why an 1870 optional alarm is suggested. It should be noted that this anomaly 1871 may be the result of two changes to the outer: a broken or 1872 compromised router within the tunnel might be erasing congestion 1873 markings introduced earlier in the same tunnel by a congested router. 1874 In this case, the anomaly would be losing congestion signals, which 1875 needs immediate attention. 1877 The original reason for defining ECT(0) and ECT(1) as equivalent was 1878 so that the data source could use the ECN nonce [RFC3540] to detect 1879 if congestion signals were being erased. However, in this case, the 1880 decapsulator does not need a nonce to detect any anomalies introduced 1881 within the tunnel, because it has the inner as a record of the header 1882 at the ingress. Therefore, it was decided that the best compromise 1883 would be to give precedence to solving the safety issue over 1884 revealing the anomaly, because the anomaly could at least be detected 1885 and dealt with internally. 1887 Superficially, the opposite case where the inner and outer carry 1888 different ECT values, but with an ECT(1) outer and ECT(0) inner, 1889 seems to require a similar compromise. However, because that case is 1890 reversed, no compromise is necessary; it is best to forward the outer 1891 whether the transport expects the ECT(1) to mean a higher severity 1892 than ECT(0) or the same severity. Forwarding the outer either 1893 preserves a higher value (if it is higher) or it reveals an anomaly 1894 to the transport (if the two ECT codepoints mean the same severity). 1896 Appendix E. Open Issues 1898 The new decapsulation behaviour defined in Section 4.2 adds support 1899 for propagation of 2 severity levels of congestion. However 1900 transports have no way to discover whether there are any legacy 1901 tunnels on their path that will not propagate 2 severity levels. It 1902 would have been nice to add a feature for transports to check path 1903 support, but this remains an open issue that will have to be 1904 addressed in any future standards action to define an end-to-end 1905 scheme that requires 2-severity levels of congestion. PCN avoids 1906 this problem because it is only for a controlled region, so all 1907 legacy tunnels can be upgraded by the same operator that deploys PCN. 1909 Author's Address 1911 Bob Briscoe 1912 BT 1913 B54/77, Adastral Park 1914 Martlesham Heath 1915 Ipswich IP5 3RE 1916 UK 1918 Phone: +44 1473 645196 1919 EMail: bob.briscoe@bt.com 1920 URI: http://bobbriscoe.net/