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/