idnits 2.17.1
draft-ietf-tsvwg-ecn-tunnel-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See
https://trustee.ietf.org/license-info/)
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 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
(Using the creation date from RFC3168, updated by this document, for
RFC5378 checks: 2000-11-17)
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 03, 2010) is 5166 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-01
== Outdated reference: A later version (-02) exists of
draft-ietf-pcn-3-state-encoding-01
== Outdated reference: A later version (-02) exists of
draft-ietf-pcn-psdm-encoding-00
== Outdated reference: A later version (-12) exists of
draft-ietf-pcn-sm-edge-behaviour-01
-- 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: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 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 March 03, 2010
5 (if approved)
6 Intended status: Standards Track
7 Expires: September 4, 2010
9 Tunnelling of Explicit Congestion Notification
10 draft-ietf-tsvwg-ecn-tunnel-08
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, providing 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 to IETF 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), its areas, and its working groups. Note that
40 other groups may also distribute working documents as Internet-
41 Drafts.
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 The list of current Internet-Drafts can be accessed at
49 http://www.ietf.org/ietf/1id-abstracts.txt.
51 The list of Internet-Draft Shadow Directories can be accessed at
52 http://www.ietf.org/shadow.html.
54 This Internet-Draft will expire on September 4, 2010.
56 Copyright Notice
58 Copyright (c) 2010 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the BSD License.
71 This document may contain material from IETF Documents or IETF
72 Contributions published or made publicly available before November
73 10, 2008. The person(s) controlling the copyright in some of this
74 material may not have granted the IETF Trust the right to allow
75 modifications of such material outside the IETF Standards Process.
76 Without obtaining an adequate license from the person(s) controlling
77 the copyright in such materials, this document may not be modified
78 outside the IETF Standards Process, and derivative works of it may
79 not be created outside the IETF Standards Process, except to format
80 it for publication as an RFC or to translate it into languages other
81 than English.
83 Table of Contents
85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 9
86 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11
87 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
88 3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 12
89 3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 12
90 3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 13
91 4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 14
92 4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 15
93 4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 15
94 4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 17
95 4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 19
96 5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 20
97 5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 20
98 5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 20
99 5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 22
100 5.3.1. Motivation for Changing Encapsulation . . . . . . . . 22
101 5.3.2. Motivation for Changing Decapsulation . . . . . . . . 23
102 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 25
103 6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 25
104 6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 26
105 6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 26
106 7. Design Principles for Alternate ECN Tunnelling Semantics . . . 27
107 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
108 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30
109 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
111 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
112 11.2. Informative References . . . . . . . . . . . . . . . . . . 32
113 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
114 Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 34
115 Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 35
116 B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 35
117 B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 37
118 B.3. Management Constraints . . . . . . . . . . . . . . . . . . 38
119 Appendix C. Contribution to Congestion across a Tunnel . . . . . 39
120 Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN
121 (to be removed before publication) . . . . . . . . . 40
122 Appendix E. Why Resetting ECN on Encapsulation Impedes PCN
123 (to be removed before publication) . . . . . . . . . 41
124 Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0)
125 Outer . . . . . . . . . . . . . . . . . . . . . . . . 42
126 Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . . 43
128 Request to the RFC Editor (to be removed on publication):
130 In the RFC index, RFC3168 should be identified as an update to
131 RFC2003. RFC4301 should be identified as an update to RFC3168.
133 Changes from previous drafts (to be removed by the RFC Editor)
135 Full text differences between IETF draft versions are available at
136 , and
137 between earlier individual draft versions at
138
140 From ietf-06 to ietf-07 (current):
142 * Emphasised that this is the opposite of a fork in the RFC
143 series.
145 * Altered Section 5 to focus on updates to implementations of
146 earlier RFCs, rather than on updates to the text of the RFCs.
148 * Removed potential loop-holes in normative text that
149 implementers might have used to claim compliance without
150 implementing normal mode. Highlighted the deliberate
151 distinction between "MUST implement" and "SHOULD use" normal
152 mode.
154 * Added question for Security Directorate reviewers on whether to
155 mention a corner-case concerning manual keying of IPsec
156 tunnels.
158 * Minor clarifications, updated references and updated acks.
160 * Marked two appendices about PCN motivations for removal before
161 publication.
163 From ietf-05 to ietf-06:
165 * Minor textual clarifications and corrections.
167 From ietf-04 to ietf-05:
169 * Functional changes:
171 + Section 4.2: ECT(1) outer with Not-ECT inner: reverted to
172 forwarding as Not-ECT (as in RFC3168 & RFC4301), rather than
173 dropping.
175 + Altered rationale in bullet 3 of Section 5.3.2 to justify
176 this.
178 + Distinguished alarms for dangerous and invalid combinations
179 and allowed combinations that are valid in some tunnel
180 configurations but dangerous in others to be alarmed at the
181 discretion of the implementer and/or operator.
183 + Altered advice on designing alternate ECN tunnelling
184 semantics to reflect the above changes.
186 * Textual changes:
188 + Changed "Future non-default schemes" to "Alternate ECN
189 Tunnelling Semantics" throughout.
191 + Cut down Appendix D and Appendix E for brevity.
193 + A number of clarifying edits & updated refs.
195 From ietf-03 to ietf-04:
197 * Functional changes: none
199 * Structural changes:
201 + Added "Open Issues" appendix
203 * Textual changes:
205 + Section title: "Changes from Earlier RFCs" -> "Updates to
206 Earlier RFCs"
208 + Emphasised that change on decap to previously unused
209 combinations will propagate PCN encoding.
211 + Acknowledged additional reviewers and updated references
213 From ietf-02 to ietf-03:
215 * Functional changes:
217 + Corrected errors in recap of previous RFCs, which wrongly
218 stated the different decapsulation behaviours of RFC3168 &
219 RFC4301 with a Not-ECT inner header. This also required
220 corrections to the "Changes from Earlier RFCs" and the
221 Motivations for these changes.
223 + Mandated that any future standards action SHOULD NOT use the
224 ECT(0) codepoint as an indication of congestion, without
225 giving strong reasons.
227 + Added optional alarm when decapsulating ECT(1) outer,
228 ECT(0), but noted it would need to be disabled for
229 2-severity level congestion (e.g. PCN).
231 * Structural changes:
233 + Removed Document Roadmap which merely repeated the Contents
234 (previously Section 1.2).
236 + Moved "Changes from Earlier RFCs" (Section 5) before
237 Section 6 on Backward Compatibility and internally organised
238 both by RFC, rather than by ingress then egress.
240 + Moved motivation for changing existing RFCs (Section 5.3) to
241 after the changes are specified.
243 + Moved informative "Design Principles for Future Non-Default
244 Schemes" after all the normative sections.
246 + Added Appendix A on early history of ECN tunnelling RFCs.
248 + Removed specialist appendix on "Relative Placement of
249 Tunnelling and In-Path Load Regulation" (Appendix D in the
250 -02 draft)
252 + Moved and updated specialist text on "Compromise on Decap
253 with ECT(1) Inner and ECT(0) Outer" from Security
254 Considerations to Appendix F
256 * Textual changes:
258 + Simplified vocabulary for non-native-english speakers
260 + Simplified Introduction and defined regularly used terms in
261 an expanded Terminology section.
263 + More clearly distinguished statically configured tunnels
264 from dynamic tunnel endpoint discovery, before explaining
265 operating modes.
267 + Simplified, cut-down and clarified throughout
269 + Updated references.
271 From ietf-01 to ietf-02:
273 * Scope reduced from any encapsulation of an IP packet to solely
274 IP in IP tunnelled encapsulation. Consequently changed title
275 and removed whole section 'Design Guidelines for New
276 Encapsulations of Congestion Notification' (to be included in a
277 future companion informational document).
279 * Included a new normative decapsulation rule for ECT(0) inner
280 and ECT(1) outer that had previously only been outlined in the
281 non-normative appendix 'Comprehensive Decapsulation Rules'.
282 Consequently:
284 + The Introduction has been completely re-written to motivate
285 this change to decapsulation along with the existing change
286 to encapsulation.
288 + The tentative text in the appendix that first proposed this
289 change has been split between normative standards text in
290 Section 4 and Appendix D, which explains specifically why
291 this change would streamline PCN. New text on the logic of
292 the resulting decap rules added.
294 * If inner/outer is Not-ECT/ECT(0), changed decapsulation to
295 propagate Not-ECT rather than drop the packet; and added
296 reasoning.
298 * Considerably restructured:
300 + "Design Constraints" analysis moved to an appendix
301 (Appendix B);
303 + Added Section 3 to summarise relevant existing RFCs;
305 + Structured Section 4 and Section 6 into subsections.
307 + Added tables to sections on old and new rules, for precision
308 and comparison.
310 + Moved Section 7 on Design Principles to the end of the
311 section specifying the new default normative tunnelling
312 behaviour. Rewritten and shifted text on identifiers and
313 in-path load regulators to Appendix B.1 [deleted in revision
314 -03].
316 From ietf-00 to ietf-01:
318 * Identified two additional alarm states in the decapsulation
319 rules (Figure 4) if ECT(X) in outer and inner contradict each
320 other.
322 * Altered Comprehensive Decapsulation Rules (Appendix D) so that
323 ECT(0) in the outer no longer overrides ECT(1) in the inner.
324 Used the term 'Comprehensive' instead of 'Ideal'. And
325 considerably updated the text in this appendix.
327 * Added Appendix D.1 (removed again in a later revision) to weigh
328 up the various ways the Comprehensive Decapsulation Rules might
329 be introduced. This replaces the previous contradictory
330 statements saying complex backwards compatibility interactions
331 would be introduced while also saying there would be no
332 backwards compatibility issues.
334 * Updated references.
336 From briscoe-01 to ietf-00:
338 * Re-wrote Appendix C giving much simpler technique to measure
339 contribution to congestion across a tunnel.
341 * Added discussion of backward compatibility of the ideal
342 decapsulation scheme in Appendix D
344 * Updated references. Minor corrections & clarifications
345 throughout.
347 From briscoe-00 to briscoe-01:
349 * Related everything conceptually to the uniform and pipe models
350 of RFC2983 on Diffserv Tunnels, and completely removed the
351 dependence of tunnelling behaviour on the presence of any in-
352 path load regulation by using the [1 - Before] [2 - Outer]
353 function placement concepts from RFC2983;
355 * Added specific cases where the existing standards limit new
356 proposals, particularly Appendix E;
358 * Added sub-structure to Introduction (Need for Rationalisation,
359 Roadmap), added new Introductory subsection on "Scope" and
360 improved clarity;
362 * Added Design Guidelines for New Encapsulations of Congestion
363 Notification;
365 * Considerably clarified the Backward Compatibility section
366 (Section 6);
368 * Considerably extended the Security Considerations section
369 (Section 8);
371 * Summarised the primary rationale much better in the
372 conclusions;
374 * Added numerous extra acknowledgements;
376 * Added Appendix E. "Why resetting CE on encapsulation harms
377 PCN", Appendix C. "Contribution to Congestion across a Tunnel"
378 and Appendix D. "Ideal Decapsulation Rules";
380 * Re-wrote Appendix B [deleted in a later revision], explaining
381 how tunnel encapsulation no longer depends on in-path load-
382 regulation (changed title from "In-path Load Regulation" to
383 "Non-Dependence of Tunnelling on In-path Load Regulation"), but
384 explained how an in-path load regulation function must be
385 carefully placed with respect to tunnel encapsulation (in a new
386 sub-section entitled "Dependence of In-Path Load Regulation on
387 Tunnelling").
389 1. Introduction
391 Explicit congestion notification (ECN [RFC3168]) allows a forwarding
392 element (e.g. a router) to notify the onset of congestion without
393 having to drop packets. Instead it can explicitly mark a proportion
394 of packets in the 2-bit ECN field in the IP header (Table 1 recaps
395 the ECN codepoints).
397 The outer header of an IP packet can encapsulate one or more IP
398 headers for tunnelling. A forwarding element using ECN to signify
399 congestion will only mark the immediately visible outer IP header.
400 When a tunnel decapsulator later removes this outer header, it
401 follows rules to propagate congestion markings by combining the ECN
402 fields of the inner and outer IP header into one outgoing IP header.
404 This document updates those rules for IPsec [RFC4301] and non-IPsec
405 [RFC3168] tunnels to add new behaviours for previously unused
406 combinations of inner and outer header. It also updates the tunnel
407 ingress behaviour of RFC3168 to match that of RFC4301. The updated
408 rules are backward compatible with RFC4301 and RFC3168 when
409 interworking with any other tunnel endpoint complying with any
410 earlier specification.
412 When ECN and its tunnelling was defined in RFC3168, only the minimum
413 necessary changes to the ECN field were propagated through tunnel
414 endpoints--just enough for the basic ECN mechanism to work. This was
415 due to concerns that the ECN field might be toggled to communicate
416 between a secure site and someone on the public Internet--a covert
417 channel. This was because a mutable field like ECN cannot be
418 protected by IPsec's integrity mechanisms--it has to be able to
419 change as it traverses the Internet.
421 Nonetheless, the latest IPsec architecture [RFC4301] considered a
422 bandwidth limit of 2 bits per packet on a covert channel made it a
423 manageable risk. Therefore, for simplicity, an RFC4301 ingress
424 copied the whole ECN field to encapsulate a packet. It dispensed
425 with the two modes of RFC3168, one which partially copied the ECN
426 field, and the other which blocked all propagation of ECN changes.
428 Unfortunately, this entirely reasonable sequence of standards actions
429 resulted in a perverse outcome; non-IPsec tunnels (RFC3168) blocked
430 the 2-bit covert channel, while IPsec tunnels (RFC4301) did not--at
431 least not at the ingress. At the egress, both IPsec and non-IPsec
432 tunnels still partially restricted propagation of the full ECN field.
434 The trigger for the changes in this document was the introduction of
435 pre-congestion notification (PCN [RFC5670]) to the IETF standards
436 track. PCN needs the ECN field to be copied at a tunnel ingress and
437 it needs four states of congestion signalling to be propagated at the
438 egress, but pre-existing tunnels only propagate three in the ECN
439 field.
441 This document draws on currently unused (CU) combinations of inner
442 and outer headers to add tunnelling of four-state congestion
443 signalling to RFC3168 and RFC4301. Operators of tunnels who
444 specifically want to support four states can require that all their
445 tunnels comply with this specification. However, this is not a fork
446 in the RFC series. It is an update that can be deployed first by
447 those that need it, and subsequently by all tunnel endpoint
448 implementations (RFC4301, RFC3168, RFC2481, RFC2401, RFC2003), which
449 can safely be updated to this new specification as part of general
450 code maintenance. This will gradually add support for four
451 congestion states to the Internet. Existing three state schemes will
452 continue to work as before.
454 In fact, this document is the opposite of a fork. At the same time
455 as supporting a fourth state, the opportunity has been taken to draw
456 together divergent ECN tunnelling specifications into a single
457 consistent behaviour, harmonising differences such as perverse covert
458 channel treatment. Then any tunnel can be deployed unilaterally, and
459 it will support the full range of congestion control and management
460 schemes without any modes or configuration. Further, any host or
461 router can expect the ECN field to behave in the same way, whatever
462 type of tunnel might intervene in the path.
464 1.1. Scope
466 This document only concerns wire protocol processing of the ECN field
467 at tunnel endpoints and makes no changes or recommendations
468 concerning algorithms for congestion marking or congestion response.
470 This document specifies common ECN field processing at encapsulation
471 and decapsulation for any IP in IP tunnelling, whether IPsec or non-
472 IPsec tunnels. It applies irrespective of whether IPv4 or IPv6 is
473 used for either of the inner and outer headers. It applies for
474 packets with any destination address type, whether unicast or
475 multicast. It applies as the default for all Diffserv per-hop
476 behaviours (PHBs), unless stated otherwise in the specification of a
477 PHB (but Section 4 strongly deprecates such exceptions). It is
478 intended to be a good trade off between somewhat conflicting
479 security, control and management requirements.
481 [RFC2983] is a comprehensive primer on differentiated services and
482 tunnels. Given ECN raises similar issues to differentiated services
483 when interacting with tunnels, useful concepts introduced in RFC2983
484 are used throughout, with brief recaps of the explanations where
485 necessary.
487 2. Terminology
489 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
490 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
491 document are to be interpreted as described in RFC 2119 [RFC2119].
493 Table 1 recaps the names of the ECN codepoints [RFC3168].
495 +------------------+----------------+---------------------------+
496 | Binary codepoint | Codepoint name | Meaning |
497 +------------------+----------------+---------------------------+
498 | 00 | Not-ECT | Not ECN-capable transport |
499 | 01 | ECT(1) | ECN-capable transport |
500 | 10 | ECT(0) | ECN-capable transport |
501 | 11 | CE | Congestion experienced |
502 +------------------+----------------+---------------------------+
504 Table 1: Recap of Codepoints of the ECN Field [RFC3168] in the IP
505 Header
507 Further terminology used within this document:
509 Encapsulator: The tunnel endpoint function that adds an outer IP
510 header to tunnel a packet (also termed the 'ingress tunnel
511 endpoint' or just the 'ingress' where the context is clear).
513 Decapsulator: The tunnel endpoint function that removes an outer IP
514 header from a tunnelled packet (also termed the 'egress tunnel
515 endpoint' or just the 'egress' where the context is clear).
517 Incoming header: The header of an arriving packet before
518 encapsulation.
520 Outer header: The header added to encapsulate a tunnelled packet.
522 Inner header: The header encapsulated by the outer header.
524 Outgoing header: The header constructed by the decapsulator using
525 logic that combines the fields in the outer and inner headers.
527 Copying ECN: On encapsulation, setting the ECN field of the new
528 outer header to be a copy of the ECN field in the incoming header.
530 Zeroing ECN: On encapsulation, clearing the ECN field of the new
531 outer header to Not-ECT ("00").
533 Resetting ECN: On encapsulation, setting the ECN field of the new
534 outer header to be a copy of the ECN field in the incoming header
535 except the outer ECN field is set to the ECT(0) codepoint if the
536 incoming ECN field is CE.
538 3. Summary of Pre-Existing RFCs
540 This section is informative not normative, as it recaps pre-existing
541 RFCs. Earlier relevant RFCs that were either experimental or
542 incomplete with respect to ECN tunnelling (RFC2481, RFC2401 and
543 RFC2003) are briefly outlined in Appendix A. The question of whether
544 tunnel implementations used in the Internet comply with any of these
545 RFCs is not discussed.
547 3.1. Encapsulation at Tunnel Ingress
549 At the encapsulator, the controversy has been over whether to
550 propagate information about congestion experienced on the path so far
551 into the outer header of the tunnel.
553 Specifically, RFC3168 says that, if a tunnel fully supports ECN
554 (termed a 'full-functionality' ECN tunnel in [RFC3168]), the
555 encapsulator must not copy a CE marking from the inner header into
556 the outer header that it creates. Instead the encapsulator must set
557 the outer header to ECT(0) if the ECN field is marked CE in the
558 arriving IP header. We term this 'resetting' a CE codepoint.
560 However, the new IPsec architecture in [RFC4301] reverses this rule,
561 stating that the encapsulator must simply copy the ECN field from the
562 incoming header to the outer header.
564 RFC3168 also provided a Limited Functionality mode that turns off ECN
565 processing over the scope of the tunnel by setting the outer header
566 to Not-ECT ("00"). Then such packets will be dropped to indicate
567 congestion rather than marked with ECN. This is necessary for the
568 ingress to interwork with legacy decapsulators ([RFC2481], [RFC2401]
569 and [RFC2003]) that do not propagate ECN markings added to the outer
570 header. Otherwise such legacy decapsulators would throw away
571 congestion notifications before they reached the transport layer.
573 Neither Limited Functionality mode nor Full Functionality mode are
574 used by an RFC4301 IPsec encapsulator, which simply copies the
575 incoming ECN field into the outer header. An earlier key-exchange
576 phase ensures an RFC4301 ingress will not have to interwork with a
577 legacy egress that does not support ECN.
579 These pre-existing behaviours are summarised in Figure 1.
580 +-----------------+-----------------------------------------------+
581 | Incoming Header | Outgoing Outer Header |
582 | (also equal to +---------------+---------------+---------------+
583 | Outgoing Inner | RFC3168 ECN | RFC3168 ECN | RFC4301 IPsec |
584 | Header) | Limited | Full | |
585 | | Functionality | Functionality | |
586 +-----------------+---------------+---------------+---------------+
587 | Not-ECT | Not-ECT | Not-ECT | Not-ECT |
588 | ECT(0) | Not-ECT | ECT(0) | ECT(0) |
589 | ECT(1) | Not-ECT | ECT(1) | ECT(1) |
590 | CE | Not-ECT | ECT(0) | CE |
591 +-----------------+---------------+---------------+---------------+
593 Figure 1: IP in IP Encapsulation: Recap of Pre-existing Behaviours
595 3.2. Decapsulation at Tunnel Egress
597 RFC3168 and RFC4301 specify the decapsulation behaviour summarised in
598 Figure 2. The ECN field in the outgoing header is set to the
599 codepoint at the intersection of the appropriate incoming inner
600 header (row) and incoming outer header (column).
602 +---------+------------------------------------------------+
603 |Incoming | Incoming Outer Header |
604 | Inner +---------+------------+------------+------------+
605 | Header | Not-ECT | ECT(0) | ECT(1) | CE |
606 +---------+---------+------------+------------+------------+
607 RFC3168->| Not-ECT | Not-ECT |Not-ECT |Not-ECT | drop |
608 RFC4301->| Not-ECT | Not-ECT |Not-ECT |Not-ECT |Not-ECT |
609 | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE |
610 | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE |
611 | CE | CE | CE | CE | CE |
612 +---------+---------+------------+------------+------------+
614 In pre-existing RFCs, the ECN field in the outgoing header was set to
615 the codepoint at the intersection of the appropriate incoming inner
616 header (row) and incoming outer header (column).
618 Figure 2: IP in IP Decapsulation; Recap of Pre-existing Behaviour
620 The behaviour in the table derives from the logic given in RFC3168
621 and RFC4301, briefly recapped as follows:
623 o On decapsulation, if the inner ECN field is Not-ECT the outer is
624 ignored. RFC3168 (but not RFC4301) also specified that the
625 decapsulator must drop a packet with a Not-ECT inner and CE in the
626 outer.
628 o In all other cases, if the outer is CE, the outgoing ECN field is
629 set to CE, but otherwise the outer is ignored and the inner is
630 used for the outgoing ECN field.
632 Section 9.2.2 of RFC3168 also made it an auditable event for an IPsec
633 tunnel "if the ECN Field is changed inappropriately within an IPsec
634 tunnel...". Inappropriate changes were not specifically enumerated.
635 RFC4301 did not mention inappropriate ECN changes.
637 4. New ECN Tunnelling Rules
639 The standards actions below in Section 4.1 (ingress encapsulation)
640 and Section 4.2 (egress decapsulation) define new default ECN tunnel
641 processing rules for any IP packet (v4 or v6) with any Diffserv
642 codepoint.
644 If these defaults do not meet a particular requirement, an alternate
645 ECN tunnelling scheme can be introduced as part of the definition of
646 an alternate congestion marking scheme used by a specific Diffserv
647 PHB (see S.5 of [RFC3168] and [RFC4774]). When designing such
648 alternate ECN tunnelling schemes, the principles in Section 7 should
649 be followed. However, alternate ECN tunnelling schemes SHOULD be
650 avoided whenever possible as the deployment burden of handling
651 exceptional PHBs in implementations of all affected tunnels should
652 not be underestimated. There is no requirement for a PHB definition
653 to state anything about ECN tunnelling behaviour if the default
654 behaviour in the present specification is sufficient.
656 4.1. Default Tunnel Ingress Behaviour
658 Two modes of encapsulation are defined here; a REQUIRED `normal mode'
659 and a `compatibility mode', which is for backward compatibility with
660 tunnel decapsulators that do not understand ECN. Note that these are
661 modes of the ingress tunnel endpoint only, not the whole tunnel.
662 Section 4.3 explains why two modes are necessary and specifies the
663 circumstances in which it is sufficient to solely implement normal
664 mode.
666 Whatever the mode, an encapsulator forwards the inner header without
667 changing the ECN field.
669 In normal mode an encapsulator compliant with this specification MUST
670 construct the outer encapsulating IP header by copying the 2-bit ECN
671 field of the incoming IP header. In compatibility mode it clears the
672 ECN field in the outer header to the Not-ECT codepoint (the IPv4
673 header checksum also changes whenever the ECN field is changed).
674 These rules are tabulated for convenience in Figure 3.
675 +-----------------+-------------------------------+
676 | Incoming Header | Outgoing Outer Header |
677 | (also equal to +---------------+---------------+
678 | Outgoing Inner | Compatibility | Normal |
679 | Header) | Mode | Mode |
680 +-----------------+---------------+---------------+
681 | Not-ECT | Not-ECT | Not-ECT |
682 | ECT(0) | Not-ECT | ECT(0) |
683 | ECT(1) | Not-ECT | ECT(1) |
684 | CE | Not-ECT | CE |
685 +-----------------+---------------+---------------+
687 Figure 3: New IP in IP Encapsulation Behaviours
689 4.2. Default Tunnel Egress Behaviour
691 To decapsulate the inner header at the tunnel egress, a compliant
692 tunnel egress MUST set the outgoing ECN field to the codepoint at the
693 intersection of the appropriate incoming inner header (row) and outer
694 header (column) in Figure 4 (the IPv4 header checksum also changes
695 whenever the ECN field is changed). There is no need for more than
696 one mode of decapsulation, as these rules cater for all known
697 requirements.
698 +---------+------------------------------------------------+
699 |Incoming | Incoming Outer Header |
700 | Inner +---------+------------+------------+------------+
701 | Header | Not-ECT | ECT(0) | ECT(1) | CE |
702 +---------+---------+------------+------------+------------+
703 | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| drop(!!!)|
704 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
705 | ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE |
706 | CE | CE | CE | CE(!!!)| CE |
707 +---------+---------+------------+------------+------------+
709 The ECN field in the outgoing header is set to the codepoint at the
710 intersection of the appropriate incoming inner header (row) and
711 incoming outer header (column). Currently unused combinations are
712 indicated by '(!!!)' or '(!)'
714 Figure 4: New IP in IP Decapsulation Behaviour
716 This table for decapsulation behaviour is derived from the following
717 logic:
719 o If the inner ECN field is Not-ECT the decapsulator MUST NOT
720 propagate any other ECN codepoint onwards. This is because the
721 inner Not-ECT marking is set by transports that use drop as an
722 indication of congestion and would not understand or respond to
723 any other ECN codepoint [RFC4774]. Specifically:
725 * If the inner ECN field is Not-ECT and the outer ECN field is CE
726 the decapsulator MUST drop the packet.
728 * If the inner ECN field is Not-ECT and the outer ECN field is
729 Not-ECT, ECT(0) or ECT(1) the decapsulator MUST forward the
730 outgoing packet with the ECN field cleared to Not-ECT.
732 o In all other cases where the inner supports ECN, the decapsulator
733 MUST set the outgoing ECN field to the more severe marking of the
734 outer and inner ECN fields, where the ranking of severity from
735 highest to lowest is CE, ECT(1), ECT(0), Not-ECT. This in no way
736 precludes cases where ECT(1) and ECT(0) have the same severity;
738 o Certain combinations of inner and outer ECN fields cannot result
739 from any transition in any current or previous ECN tunneling
740 specification. These currently unused (CU) combinations are
741 indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the
742 combination is CU and always potentially dangerous, while '(!)'
743 means it is CU and possibly dangerous. In these cases,
744 particularly the more dangerous ones, the decapsulator SHOULD log
745 the event and MAY also raise an alarm.
747 Just because the highlighted combinations are currently unused,
748 does not mean that all the other combinations are always valid.
749 Some are only valid if they have arrived from a particular type of
750 legacy ingress, and dangerous otherwise. Therefore an
751 implementation MAY allow an operator to configure logging and
752 alarms for such additional header combinations known to be
753 dangerous or CU for the particular configuration of tunnel
754 endpoints deployed at run-time.
756 Alarms SHOULD be rate-limited so that the anomalous combinations
757 will not amplify into a flood of alarm messages. It MUST be
758 possible to suppress alarms or logging, e.g. if it becomes
759 apparent that a combination that previously was not used has
760 started to be used for legitimate purposes such as a new standards
761 action.
763 The above logic allows for ECT(0) and ECT(1) to both represent the
764 same severity of congestion marking (e.g. "not congestion marked").
765 But it also allows future schemes to be defined where ECT(1) is a
766 more severe marking than ECT(0), in particular enabling the simplest
767 possible encoding for PCN [I-D.ietf-pcn-3-in-1-encoding]. Before the
768 present specification was written, the PCN working-group had proposed
769 a number of work-rounds to the problem of a tunnel egress not
770 propagating two severity levels of congestion. Without wishing to
771 disparage the ingenuity of these work-rounds, none were chosen for
772 the standards track because they were either somewhat wasteful,
773 imprecise or complicated [Note_PCN_egress]. Treating ECT(1) as
774 either the same as ECT(0) or as a higher severity level is explained
775 in the discussion of the ECN nonce [RFC3540] in Section 8, which in
776 turn refers to Appendix F.
778 4.3. Encapsulation Modes
780 Section 4.1 introduces two encapsulation modes, normal mode and
781 compatibility mode, defining their encapsulation behaviour (i.e.
782 header copying or zeroing respectively). Note that these are modes
783 of the ingress tunnel endpoint only, not the tunnel as a whole.
785 To comply with this specification, a tunnel ingress MUST at least
786 implement `normal mode'. Unless it will never be used with legacy
787 tunnel egress nodes (RFC2003, RFC2401 or RFC2481 or the limited
788 functionality mode of RFC3168), an ingress MUST also implement
789 `compatibility mode' for backward compatibility with tunnel egresses
790 that do not propagate explicit congestion notifications [RFC4774].
792 We can categorise the way that an ingress tunnel endpoint is paired
793 with an egress as either static or dynamically discovered:
795 Static: Tunnel endpoints paired together by prior configuration.
797 Some implementations of encapsulator might always be statically
798 deployed, and constrained to never be paired with a legacy
799 decapsulator (RFC2003, RFC2401 or RFC2481 or the limited
800 functionality mode of RFC3168). In such a case, only normal mode
801 needs to be implemented.
803 For instance, RFC4301-compatible IPsec tunnel endpoints invariably
804 use IKEv2 [RFC4306] for key exchange, which was introduced
805 alongside RFC4301. Therefore both endpoints of an RFC4301 tunnel
806 can be sure that the other end is RFC4301-compatible, because the
807 tunnel is only formed after IKEv2 key management has completed, at
808 which point both ends will be RFC4301-compliant by definition.
809 Therefore an IPsec tunnel ingress does not need compatibility
810 mode, as it will never interact with legacy ECN tunnels. To
811 comply with the present specification, it only needs to implement
812 the required normal mode, which is identical to the pre-existing
813 RFC4301 behaviour.
815 Dynamic Discovery: Tunnel endpoints paired together by some form of
816 tunnel endpoint discovery, typically finding an egress on the path
817 taken by the first packet.
819 This specification does not require or recommend dynamic discovery
820 and it does not define how dynamic negotiation might be done, but
821 it recognises that proprietary tunnel endpoint discovery protocols
822 exist. It therefore sets down some constraints on discovery
823 protocols to ensure safe interworking.
825 If dynamic tunnel endpoint discovery might pair an ingress with a
826 legacy egress (RFC2003, RFC2401 or RFC2481 or the limited
827 functionality mode of RFC3168), the ingress MUST implement both
828 normal and compatibility mode. If the tunnel discovery process is
829 arranged to only ever find a tunnel egress that propagates ECN
830 (RFC3168 full functionality mode, RFC4301 or this present
831 specification), then a tunnel ingress can be complaint with the
832 present specification without implementing compatibility mode.
834 While a compliant tunnel ingress is discovering an egress, it MUST
835 send packets in compatibility mode in case the egress it discovers
836 is a legacy egress. If, through the discovery protocol, the
837 egress indicates that it is compliant with the present
838 specification, with RFC4301 or with RFC3168 full functionality
839 mode, the ingress can switch itself into normal mode. If the
840 egress denies compliance with any of these or returns an error
841 that implies it does not understand a request to work to any of
842 these ECN specifications, the tunnel ingress MUST remain in
843 compatibility mode.
845 If an ingress claims compliance with this specification it MUST NOT
846 permanently disable ECN processing across the tunnel (i.e. only using
847 compatibility mode). It is true that such a tunnel ingress is at
848 least safe with the ECN behaviour of any egress it may encounter, but
849 it does not meet the central aim of this specification: introducing
850 ECN support to tunnels.
852 Instead, if the ingress knows that the egress does support
853 propagation of ECN (full functionality mode of RFC3168 or RFC4301 or
854 the present specification), it SHOULD use normal mode, in order to
855 support ECN where possible. Note that this section started by saying
856 an ingress "MUST implement "normal mode, while it has just said an
857 ingress "SHOULD use" normal mode. This distinction is deliberate, to
858 allow the mode to be turned off in exceptional circumstances but to
859 ensure all implementations make normal mode available.
861 Implementation note: If a compliant node is the ingress for multiple
862 tunnels, a mode setting will need to be stored for each tunnel
863 ingress. However, if a node is the egress for multiple tunnels,
864 none of the tunnels will need to store a mode setting, because a
865 compliant egress only needs one mode.
867 4.4. Single Mode of Decapsulation
869 A compliant decapsulator only needs one mode of operation. However,
870 if a complaint egress is implemented to be dynamically discoverable,
871 it may need to respond to discovery requests from various types of
872 legacy tunnel ingress. This specification does not define how
873 dynamic negotiation might be done by (proprietary) discovery
874 protocols, but it sets down some constraints to ensure safe
875 interworking.
877 Through the discovery protocol, a tunnel ingress compliant with the
878 present specification might ask if the egress is compliant with the
879 present specification, with RFC4301 or with RFC3168 full
880 functionality mode. Or an RFC3168 tunnel ingress might try to
881 negotiate to use limited functionality or full functionality mode
882 [RFC3168]. In all these cases, a decapsulating tunnel egress
883 compliant with this specification MUST agree to any of these
884 requests, since it will behave identically in all these cases.
886 If no ECN-related mode is requested, a compliant tunnel egress MUST
887 continue without raising any error or warning, because its egress
888 behaviour is compatible with all the legacy ingress behaviours that
889 do not negotiate capabilities.
891 A compliant tunnel egress SHOULD raise a warning alarm about any
892 requests to enter modes it does not recognise but, for 'forward
893 compatibility' with standards actions possibly defined after it was
894 implemented, it SHOULD continue operating.
896 5. Updates to Earlier RFCs
898 5.1. Changes to RFC4301 ECN processing
900 Ingress: An RFC4301 IPsec encapsulator is not changed at all by the
901 present specification. It uses the normal mode of the present
902 specification, which defines packet encapsulation identically to
903 RFC4301.
905 Egress: An RFC4301 egress will need to be updated to the new
906 decapsulation behaviour in Figure 4, in order to comply with the
907 present specification. However, the changes are backward
908 compatible; combinations of inner and outer that result from any
909 protocol defined in the RFC series so far are unaffected. Only
910 combinations that have never been used have been changed,
911 effectively adding new behaviours to RFC4301 decapsulation without
912 altering existing behaviours. The following specific updates have
913 been made:
915 * The outer, not the inner, is propagated when the outer is
916 ECT(1) and the inner is ECT(0);
918 * A packet with Not-ECT in the inner and an outer of CE is
919 dropped rather than forwarded as Not-ECT;
921 * Certain combinations of inner and outer ECN field have been
922 identified as currently unused. These can trigger logging
923 and/or raise alarms.
925 Modes: RFC4301 tunnel endpoints do not need modes and are not
926 updated by the modes in the present specification. Effectively an
927 RFC4301 IPsec ingress solely uses the REQUIRED normal mode of
928 encapsulation, which is unchanged from RFC4301 encapsulation. It
929 will never [Note_Manual_Keying] need the OPTIONAL compatibility
930 mode as explained in Section 4.3.
932 5.2. Changes to RFC3168 ECN processing
933 Ingress: On encapsulation, the new rule in Figure 3 that a normal
934 mode tunnel ingress copies any ECN field into the outer header
935 updates the full functionality behaviour of an RFC3168 ingress.
936 Nonetheless, the new compatibility mode encapsulates packets
937 identically to the limited functionality mode of an RFC3168
938 ingress.
940 Egress: An RFC3168 egress will need to be updated to the new
941 decapsulation behaviour in Figure 4, in order to comply with the
942 present specification. However, the changes are backward
943 compatible; combinations of inner and outer that result from any
944 protocol defined in the RFC series so far are unaffected. Only
945 combinations that have never been used have been changed,
946 effectively adding new behaviours to RFC3168 decapsulation without
947 altering existing behaviours. The following specific updates have
948 been made:
950 * The outer, not the inner, is propagated when the outer is
951 ECT(1) and the inner is ECT(0);
953 * Certain combinations of inner and outer ECN field have been
954 identified as currently unused. These can trigger logging
955 and/or raise alarms.
957 Modes: An RFC3168 ingress will need to be updated if it is to comply
958 with the present specification, whether or not it implemented the
959 optional full functionality mode of RFC3168.
961 RFC3168 defined a (required) limited functionality mode and an
962 (optional) full functionality mode for a tunnel. In RFC3168,
963 modes applied to both ends of the tunnel, while in the present
964 specification, modes are only used at the ingress--a single egress
965 behaviour covers all cases.
967 The normal mode of encapsulation is an update to the encapsulation
968 behaviour of the full functionality mode of an RFC3168 ingress.
969 The compatibility mode of encapsulation is identical to the
970 encapsulation behaviour of the limited functionality mode of an
971 RFC3168 ingress, except it is optional.
973 The constraints on how tunnel discovery protocols set modes in
974 Section 4.3 and Section 4.4 are an update to RFC3168, but they are
975 unlikely to require code changes as they document safe practice.
977 5.3. Motivation for Changes
979 An overriding goal is to ensure the same ECN signals can mean the
980 same thing whatever tunnels happen to encapsulate an IP packet flow.
981 This removes gratuitous inconsistency, which otherwise constrains the
982 available design space and makes it harder to design networks and new
983 protocols that work predictably.
985 5.3.1. Motivation for Changing Encapsulation
987 The normal mode in Section 4 updates RFC3168 to make all IP in IP
988 encapsulation of the ECN field consistent--consistent with the way
989 both RFC4301 IPsec [RFC4301] and IP in MPLS or MPLS in MPLS
990 encapsulation [RFC5129] construct the ECN field.
992 Compatibility mode has also been defined so that a non-RFC4301
993 ingress can still switch to using drop across a tunnel for backwards
994 compatibility with legacy decapsulators that do not propagate ECN
995 correctly.
997 The trigger that motivated this update to RFC3168 encapsulation was a
998 standards track proposal for pre-congestion notification (PCN
999 [RFC5670]). PCN excess rate marking only works correctly if the ECN
1000 field is copied on encapsulation (as in RFC4301 and RFC5129); it does
1001 not work if ECN is reset (as in RFC3168). This is because PCN excess
1002 rate marking depends on the outer header revealing any congestion
1003 experienced so far on the whole path, not just since the last tunnel
1004 ingress [Note_PCN_ingress].
1006 PCN allows a network operator to add flow admission and termination
1007 for inelastic traffic at the edges of a Diffserv domain, but without
1008 any per-flow mechanisms in the interior and without the generous
1009 provisioning typical of Diffserv, aiming to significantly reduce
1010 costs. The PCN architecture [RFC5559] states that RFC3168 IP in IP
1011 tunnelling of the ECN field cannot be used for any tunnel ingress in
1012 a PCN domain. Prior to the present specification, this left a stark
1013 choice between not being able to use PCN for inelastic traffic
1014 control or not being able to use the many tunnels already deployed
1015 for Mobile IP, VPNs and so forth.
1017 The present specification provides a clean solution to this problem,
1018 so that network operators who want to use both PCN and tunnels can
1019 specify that every tunnel ingress in a PCN region must comply with
1020 this latest specification.
1022 Rather than allow tunnel specifications to fragment further into one
1023 for PCN, one for IPsec and one for other tunnels, the opportunity has
1024 been taken to consolidate the diverging specifications back into a
1025 single tunnelling behaviour. Resetting ECN was originally motivated
1026 by a covert channel concern that has been deliberately set aside in
1027 RFC4301 IPsec. Therefore the reset behaviour of RFC3168 is an
1028 anomaly that we do not need to keep. Copying ECN on encapsulation is
1029 anyway simpler than resetting. So, as more tunnel endpoints comply
1030 with this single consistent specification, encapsulation will be
1031 simpler as well as more predictable.
1033 Appendix B assesses whether copying rather than resetting CE on
1034 ingress will cause any unintended side-effects, from the three
1035 perspectives of security, control and management. In summary this
1036 analysis finds that:
1038 o From the control perspective either copying or resetting works for
1039 existing arrangements, but copying has more potential for
1040 simplifying control and resetting breaks at least one proposal
1041 already on the standards track.
1043 o From the management and monitoring perspective copying is
1044 preferable.
1046 o From the traffic security perspective (enforcing congestion
1047 control, mitigating denial of service etc) copying is preferable.
1049 o From the information security perspective resetting is preferable,
1050 but the IETF Security Area now considers copying acceptable given
1051 the bandwidth of a 2-bit covert channel can be managed.
1053 Therefore there are two points against resetting CE on ingress while
1054 copying CE causes no significant harm.
1056 5.3.2. Motivation for Changing Decapsulation
1058 The specification for decapsulation in Section 4 fixes three problems
1059 with the pre-existing behaviours of both RFC3168 and RFC4301:
1061 1. The pre-existing rules prevented the introduction of alternate
1062 ECN semantics to signal more than one severity level of
1063 congestion [RFC4774], [RFC5559]. The four states of the 2-bit
1064 ECN field provide room for signalling two severity levels in
1065 addition to not-congested and not-ECN-capable states. But, the
1066 pre-existing rules assumed that two of the states (ECT(0) and
1067 ECT(1)) are always equivalent. This unnecessarily restricts the
1068 use of one of four codepoints (half a bit) in the IP (v4 & v6)
1069 header. The new rules are designed to work in either case;
1070 whether ECT(1) is more severe than or equivalent to ECT(0).
1072 As explained in Appendix B.1, the original reason for not
1073 forwarding the outer ECT codepoints was to limit the covert
1074 channel across a decapsulator to 1 bit per packet. However, now
1075 that the IETF Security Area has deemed that a 2-bit covert
1076 channel through an encapsulator is a manageable risk, the same
1077 should be true for a decapsulator.
1079 As well as being useful for general future-proofing, this problem
1080 is immediately pressing for standardisation of pre-congestion
1081 notification (PCN), which uses two severity levels of congestion.
1082 If a congested queue used ECT(1) in the outer header to signal
1083 more severe congestion than ECT(0), the pre-existing
1084 decapsulation rules would have thrown away this congestion
1085 signal, preventing tunnelled traffic from ever knowing that it
1086 should reduce its load.
1088 The PCN working group has had to consider a number of wasteful or
1089 convoluted work-rounds to this problem [Note_PCN_egress]. But by
1090 far the simplest approach is just to remove the covert channel
1091 blockages from tunnelling behaviour--now deemed unnecessary
1092 anyway. Then network operators that want to support two
1093 congestion severity-levels for PCN can specify that every tunnel
1094 egress in a PCN region must comply with this latest
1095 specification.
1097 Not only does this make two congestion severity-levels available
1098 for PCN standardisation, but also for other potential uses of the
1099 extra ECN codepoint (e.g. [VCP]).
1101 2. Cases are documented where a middlebox (e.g. a firewall) drops
1102 packets with header values that were currently unused (CU) when
1103 the box was deployed, often on the grounds that anything
1104 unexpected might be an attack. This tends to bar future use of
1105 CU values. The new decapsulation rules specify optional logging
1106 and/or alarms for specific combinations of inner and outer header
1107 that are currently unused. The aim is to give implementers a
1108 recourse other than drop if they are concerned about the security
1109 of CU values. It recognises legitimate security concerns about
1110 CU values but still eases their future use. If the alarms are
1111 interpreted as an attack (e.g. by a management system) the
1112 offending packets can be dropped. But alarms can be turned off
1113 if these combinations come into regular use (e.g. through a
1114 future standards action).
1116 3. While reviewing currently unused combinations of inner and outer,
1117 the opportunity was taken to define a single consistent behaviour
1118 for the three cases with a Not-ECT inner header but a different
1119 outer. RFC3168 and RFC4301 had diverged in this respect and even
1120 their common behaviours had never been justified.
1122 None of these combinations should result from Internet protocols
1123 in the RFC series, but future standards actions might put any or
1124 all of them to good use. Therefore it was decided that a
1125 decapsulator must forward a Not-ECT inner unchanged when the
1126 arriving outer is ECT(0) or ECT(1). But for safety it must drop
1127 a combination of Not-ECT inner and CE outer. Then, if some
1128 unfortunate misconfiguration resulted in a congested router
1129 marking CE on a packet that was originally Not-ECT, drop would be
1130 the only appropriate signal for the egress to propagate--the only
1131 signal a non-ECN-capable transport (Not-ECT) would understand.
1133 It may seem contradictory that the same argument has not been
1134 applied to the ECT(1) codepoint, given it is being proposed as an
1135 intermediate level of congestion in a scheme progressing through
1136 the IETF [I-D.ietf-pcn-3-in-1-encoding]. Instead, a decapsulator
1137 must forward a Not-ECT inner unchanged when its outer is ECT(1).
1138 The rationale for not dropping this CU combination is to ensure
1139 it will be usable if needed in the future. If any
1140 misconfiguration led to ECT(1) congestion signals with a Not-ECT
1141 inner, it would not be disastrous for the tunnel egress to
1142 suppress them, because the congestion should then escalate to CE
1143 marking, which the egress would drop, thus at least preventing
1144 congestion collapse.
1146 Problems 2 & 3 alone would not warrant a change to decapsulation, but
1147 it was decided they are worth fixing and making consistent at the
1148 same time as decapsulation code is changed to fix problem 1 (two
1149 congestion severity-levels).
1151 6. Backward Compatibility
1153 A tunnel endpoint compliant with the present specification is
1154 backward compatible when paired with any tunnel endpoint compliant
1155 with any previous tunnelling RFC, whether RFC4301, RFC3168 (see
1156 Section 3) or the earlier RFCs summarised in Appendix A (RFC2481,
1157 RFC2401 and RFC2003). Each case is enumerated below.
1159 6.1. Non-Issues Updating Decapsulation
1161 At the egress, this specification only augments the per-packet
1162 calculation of the ECN field (RFC3168 and RFC4301) for combinations
1163 of inner and outer headers that have so far not been used in any IETF
1164 protocols.
1166 Therefore, all other things being equal, if an RFC4301 IPsec egress
1167 is updated to comply with the new rules, it will still interwork with
1168 any RFC4301 compliant ingress and the packet outputs will be
1169 identical to those it would have output before (fully backward
1170 compatible).
1172 And, all other things being equal, if an RFC3168 egress is updated to
1173 comply with the same new rules, it will still interwork with any
1174 ingress complying with any previous specification (both modes of
1175 RFC3168, both modes of RFC2481, RFC2401 and RFC2003) and the packet
1176 outputs will be identical to those it would have output before (fully
1177 backward compatible).
1179 A compliant tunnel egress merely needs to implement the one behaviour
1180 in Section 4 with no additional mode or option configuration at the
1181 ingress or egress nor any additional negotiation with the ingress.
1182 The new decapsulation rules have been defined in such a way that
1183 congestion control will still work safely if any of the earlier
1184 versions of ECN processing are used unilaterally at the encapsulating
1185 ingress of the tunnel (any of RFC2003, RFC2401, either mode of
1186 RFC2481, either mode of RFC3168, RFC4301 and this present
1187 specification).
1189 6.2. Non-Update of RFC4301 IPsec Encapsulation
1191 An RFC4301 IPsec ingress can comply with this new specification
1192 without any update and it has no need for any new modes, options or
1193 configuration. So, all other things being equal, it will continue to
1194 interwork identically with any egress it worked with before (fully
1195 backward compatible).
1197 6.3. Update to RFC3168 Encapsulation
1199 The encapsulation behaviour of the new normal mode copies the ECN
1200 field whereas RFC3168 full functionality mode reset it. However, all
1201 other things being equal, if RFC3168 ingress is updated to the
1202 present specification, the outgoing packets from any tunnel egress
1203 will still be unchanged. This is because all variants of tunnelling
1204 at either end (RFC4301, both modes of RFC3168, both modes of RFC2481,
1205 RFC2401, RFC2003 and the present specification) have always
1206 propagated an incoming CE marking through the inner header and onward
1207 into the outgoing header, whether the outer header is reset or
1208 copied. Therefore, If the tunnel is considered as a black box, the
1209 packets output from any egress will be identical with or without an
1210 update to the ingress. Nonetheless, if packets are observed within
1211 the black box (between the tunnel endpoints), CE markings copied by
1212 the updated ingress will be visible within the black box, whereas
1213 they would not have been before. Therefore, the update to
1214 encapsulation can be termed 'black-box backwards compatible' (i.e.
1215 identical unless you look inside the tunnel).
1217 This specification introduces no new backward compatibility issues
1218 when a compliant ingress talks with a legacy egress, but it has to
1219 provide similar safeguards to those already defined in RFC3168.
1220 RFC3168 laid down rules to ensure that an RFC3168 ingress turns off
1221 ECN (limited functionality mode) if it is paired with a legacy egress
1222 (RFC 2481, RFC2401 or RFC2003), which would not propagate ECN
1223 correctly. The present specification carries forward those rules
1224 (Section 4.3). It uses compatibility mode whenever RFC3168 would
1225 have used limited functionality mode, and their per-packet behaviours
1226 are identical. Therefore, all other things being equal, an ingress
1227 using the new rules will interwork with any legacy tunnel egress in
1228 exactly the same way as an RFC3168 ingress (still black-box backward
1229 compatible).
1231 7. Design Principles for Alternate ECN Tunnelling Semantics
1233 This section is informative not normative.
1235 S.5 of RFC3168 permits the Diffserv codepoint (DSCP)[RFC2474] to
1236 'switch in' alternative behaviours for marking the ECN field, just as
1237 it switches in different per-hop behaviours (PHBs) for scheduling.
1238 [RFC4774] gives best current practice for designing such alternative
1239 ECN semantics and very briefly mentions in section 5.4 that
1240 tunnelling should be considered. The guidance below extends RFC4774,
1241 giving additional guidance on designing any alternate ECN semantics
1242 that would also require alternate tunnelling semantics.
1244 The overriding guidance is: "Avoid designing alternate ECN tunnelling
1245 semantics, if at all possible." If a scheme requires tunnels to
1246 implement special processing of the ECN field for certain DSCPs, it
1247 will be hard to guarantee that every implementer of every tunnel will
1248 have added the required exception or that operators will have
1249 ubiquitously deployed the required updates. It is unlikely a single
1250 authority is even aware of all the tunnels in a network, which may
1251 include tunnels set up by applications between endpoints, or
1252 dynamically created in the network. Therefore it is highly likely
1253 that some tunnels within a network or on hosts connected to it will
1254 not implement the required special case.
1256 That said, if a non-default scheme for tunnelling the ECN field is
1257 really required, the following guidelines may prove useful in its
1258 design:
1260 On encapsulation in any alternate scheme:
1262 1. The ECN field of the outer header should be cleared to Not-ECT
1263 ("00") unless it is guaranteed that the corresponding tunnel
1264 egress will correctly propagate congestion markings introduced
1265 across the tunnel in the outer header.
1267 2. If it has established that ECN will be correctly propagated,
1268 an encapsulator should also copy incoming congestion
1269 notification into the outer header. The general principle
1270 here is that the outer header should reflect congestion
1271 accumulated along the whole upstream path, not just since the
1272 tunnel ingress (Appendix B.3 on management and monitoring
1273 explains).
1275 In some circumstances (e.g. pseudowires, PCN), the whole path
1276 is divided into segments, each with its own congestion
1277 notification and feedback loop. In these cases, the function
1278 that regulates load at the start of each segment will need to
1279 reset congestion notification for its segment. Often the
1280 point where congestion notification is reset will also be
1281 located at the start of a tunnel. However, the resetting
1282 function should be thought of as being applied to packets
1283 after the encapsulation function--two logically separate
1284 functions even though they might run on the same physical box.
1285 Then the code module doing encapsulation can keep to the
1286 copying rule and the load regulator module can reset
1287 congestion, without any code in either module being
1288 conditional on whether the other is there.
1290 On decapsulation in any new scheme:
1292 1. If the arriving inner header is Not-ECT it implies the
1293 transport will not understand other ECN codepoints. If the
1294 outer header carries an explicit congestion marking, the
1295 alternate scheme would be expected to drop the packet--the
1296 only indication of congestion the transport will understand.
1297 If the alternate scheme recommends forwarding rather than
1298 dropping such a packet, it must clearly justify this decision.
1299 If the inner is Not-ECT and the outer carries any other ECN
1300 codepoint that does not indicate congestion, the alternate
1301 scheme can forward the packet, but probably only as Not-ECT.
1303 2. If the arriving inner header is other than Not-ECT, the ECN
1304 field that the alternate decapsulation scheme forwards should
1305 reflect the more severe congestion marking of the arriving
1306 inner and outer headers.
1308 3. Any alternate scheme must define a behaviour for all
1309 combinations of inner and outer headers, even those that would
1310 not be expected to result from standards known at the time and
1311 even those that would not be expected from the tunnel ingress
1312 paired with the egress at run-time. Consideration should be
1313 given to logging such unexpected combinations and raising an
1314 alarm, particularly if there is a danger that the invalid
1315 combination implies congestion signals are not being
1316 propagated correctly. The presence of currently unused
1317 combinations may represent an attack, but the new scheme
1318 should try to define a way to forward such packets, at least
1319 if a safe outgoing codepoint can be defined.
1321 Raising an alarm allows a management system to decide whether
1322 the anomaly is indeed an attack, in which case it can decide
1323 to drop such packets. This is a preferable approach to hard-
1324 coded discard of packets that seem anomalous today, but may be
1325 needed tomorrow in future standards actions.
1327 IANA Considerations (to be removed on publication):
1329 This memo includes no request to IANA.
1331 8. Security Considerations
1333 Appendix B.1 discusses the security constraints imposed on ECN tunnel
1334 processing. The new rules for ECN tunnel processing (Section 4)
1335 trade-off between information security (covert channels) and traffic
1336 security (congestion monitoring & control). Ensuring congestion
1337 markings are not lost is itself an aspect of security, because if we
1338 allowed congestion notification to be lost, any attempt to enforce a
1339 response to congestion would be much harder.
1341 Specialist security issues:
1343 Tunnels intersecting Diffserv regions with alternate ECN semantics:
1344 If alternate congestion notification semantics are defined for a
1345 certain Diffserv PHB, the scope of the alternate semantics might
1346 typically be bounded by the limits of a Diffserv region or
1347 regions, as envisaged in [RFC4774] (e.g. the pre-congestion
1348 notification architecture [RFC5559]). The inner headers in
1349 tunnels crossing the boundary of such a Diffserv region but ending
1350 within the region can potentially leak the external congestion
1351 notification semantics into the region, or leak the internal
1352 semantics out of the region. [RFC2983] discusses the need for
1353 Diffserv traffic conditioning to be applied at these tunnel
1354 endpoints as if they are at the edge of the Diffserv region.
1355 Similar concerns apply to any processing or propagation of the ECN
1356 field at the endpoints of tunnels with one end inside and the
1357 other outside the domain. [RFC5559] gives specific advice on this
1358 for the PCN case, but other definitions of alternate semantics
1359 will need to discuss the specific security implications in each
1360 case.
1362 ECN nonce tunnel coverage: The new decapsulation rules improve the
1363 coverage of the ECN nonce [RFC3540] relative to the previous rules
1364 in RFC3168 and RFC4301. However, nonce coverage is still not
1365 perfect, as this would have led to a safety problem in another
1366 case. Both are corner-cases, so discussion of the compromise
1367 between them is deferred to Appendix F.
1369 Covert channel not turned off: A legacy (RFC3168) tunnel ingress
1370 could ask an RFC3168 egress to turn off ECN processing as well as
1371 itself turning off ECN. An egress compliant with the present
1372 specification will agree to such a request from a legacy ingress,
1373 but it relies on the ingress always sending Not-ECT in the outer.
1374 If the egress receives other ECN codepoints in the outer it will
1375 process them as normal, so it will actually still copy congestion
1376 markings from the outer to the outgoing header. Referring for
1377 example to Figure 5 (Appendix B.1), although the tunnel ingress
1378 'I' will set all ECN fields in outer headers to Not-ECT, 'M' could
1379 still toggle CE or ECT(1) on and off to communicate covertly with
1380 'B', because we have specified that 'E' only has one mode
1381 regardless of what mode it says it has negotiated. We could have
1382 specified that 'E' should have a limited functionality mode and
1383 check for such behaviour. But we decided not to add the extra
1384 complexity of two modes on a compliant tunnel egress merely to
1385 cater for an historic security concern that is now considered
1386 manageable.
1388 9. Conclusions
1390 This document allows tunnels to propagate an extra level of
1391 congestion severity. It uses previously unused combinations of inner
1392 and outer header to augment the rules for calculating the ECN field
1393 when decapsulating IP packets at the egress of IPsec (RFC4301) and
1394 non-IPsec (RFC3168) tunnels.
1396 This document also updates the ingress tunnelling encapsulation of
1397 RFC3168 ECN to bring all IP in IP tunnels into line with the new
1398 behaviour in the IPsec architecture of RFC4301, which copies rather
1399 than resets the ECN field when creating outer headers.
1401 The need for both these updated behaviours was triggered by the
1402 introduction of pre-congestion notification (PCN) onto the IETF
1403 standards track. Operators wanting to support PCN or other alternate
1404 ECN schemes that use an extra severity level can require that their
1405 tunnels comply with the present specification. This is not a fork in
1406 the RFC series, it is an update that can be deployed first by those
1407 that need it, and subsequently by all tunnel endpoint implementations
1408 during general code maintenance. It is backward compatible with all
1409 previous tunnelling behaviours, so existing single severity level
1410 schemes will continue to work as before, but support for two severity
1411 levels will gradually be added to the Internet.
1413 The new rules propagate changes to the ECN field across tunnel end-
1414 points that previously blocked them to restrict the bandwidth of a
1415 potential covert channel. Limiting the channel's bandwidth to 2 bits
1416 per packet is now considered sufficient.
1418 At the same time as removing these legacy constraints, the
1419 opportunity has been taken to draw together diverging tunnel
1420 specifications into a single consistent behaviour. Then any tunnel
1421 can be deployed unilaterally, and it will support the full range of
1422 congestion control and management schemes without any modes or
1423 configuration. Further, any host or router can expect the ECN field
1424 to behave in the same way, whatever type of tunnel might intervene in
1425 the path. This new certainty could enable new uses of the ECN field
1426 that would otherwise be confounded by ambiguity.
1428 10. Acknowledgements
1430 Thanks to David Black for his insightful reviews and patient
1431 explanations of better ways to think about function placement and
1432 alarms. Thanks to David and to Anil Agawaal for pointing out cases
1433 where it is safe to forward CU combinations of headers. Also thanks
1434 to Arnaud Jacquet for the idea for Appendix C. Thanks to Gorry
1435 Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster,
1436 Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson and
1437 Phil Eardley for their thoughts and careful review comments.
1439 Bob Briscoe is partly funded by Trilogy, a research project (ICT-
1440 216372) supported by the European Community under its Seventh
1441 Framework Programme. The views expressed here are those of the
1442 author only.
1444 Comments Solicited (to be removed by the RFC Editor):
1446 Comments and questions are encouraged and very welcome. They can be
1447 addressed to the IETF Transport Area working group mailing list
1448 , and/or to the authors.
1450 11. References
1452 11.1. Normative References
1454 [RFC2003] Perkins, C., "IP Encapsulation
1455 within IP", RFC 2003, October 1996.
1457 [RFC2119] Bradner, S., "Key words for use in
1458 RFCs to Indicate Requirement
1459 Levels", BCP 14, RFC 2119,
1460 March 1997.
1462 [RFC3168] Ramakrishnan, K., Floyd, S., and D.
1463 Black, "The Addition of Explicit
1464 Congestion Notification (ECN) to
1465 IP", RFC 3168, September 2001.
1467 [RFC4301] Kent, S. and K. Seo, "Security
1468 Architecture for the Internet
1469 Protocol", RFC 4301, December 2005.
1471 11.2. Informative References
1473 [I-D.ietf-pcn-3-in-1-encoding] Briscoe, B. and T. Moncaster, "PCN
1474 3-State Encoding Extension in a
1475 single DSCP",
1476 draft-ietf-pcn-3-in-1-encoding-01
1477 (work in progress), February 2010.
1479 [I-D.ietf-pcn-3-state-encoding] Briscoe, B., Moncaster, T., and M.
1480 Menth, "A PCN encoding using 2
1481 DSCPs to provide 3 or more states",
1482 draft-ietf-pcn-3-state-encoding-01
1483 (work in progress), February 2010.
1485 [I-D.ietf-pcn-psdm-encoding] Menth, M., Babiarz, J., Moncaster,
1486 T., and B. Briscoe, "PCN Encoding
1487 for Packet-Specific Dual Marking
1488 (PSDM)",
1489 draft-ietf-pcn-psdm-encoding-00
1490 (work in progress), June 2009.
1492 [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., Menth,
1493 M., and T. Taylor, "PCN Boundary
1494 Node Behaviour for the Single
1495 Marking (SM) Mode of Operation",
1496 draft-ietf-pcn-sm-edge-behaviour-01
1497 (work in progress), October 2009.
1499 [I-D.satoh-pcn-st-marking] Satoh, D., Ueno, H., Maeda, Y., and
1500 O. Phanachet, "Single PCN Threshold
1501 Marking by using PCN baseline
1502 encoding for both admission and
1503 termination controls",
1504 draft-satoh-pcn-st-marking-02 (work
1505 in progress), September 2009.
1507 [RFC2401] Kent, S. and R. Atkinson, "Security
1508 Architecture for the Internet
1509 Protocol", RFC 2401, November 1998.
1511 [RFC2474] Nichols, K., Blake, S., Baker, F.,
1512 and D. Black, "Definition of the
1513 Differentiated Services Field (DS
1514 Field) in the IPv4 and IPv6
1515 Headers", RFC 2474, December 1998.
1517 [RFC2481] Ramakrishnan, K. and S. Floyd, "A
1518 Proposal to add Explicit Congestion
1519 Notification (ECN) to IP",
1520 RFC 2481, January 1999.
1522 [RFC2983] Black, D., "Differentiated Services
1523 and Tunnels", RFC 2983,
1524 October 2000.
1526 [RFC3540] Spring, N., Wetherall, D., and D.
1527 Ely, "Robust Explicit Congestion
1528 Notification (ECN) Signaling with
1529 Nonces", RFC 3540, June 2003.
1531 [RFC4306] Kaufman, C., "Internet Key Exchange
1532 (IKEv2) Protocol", RFC 4306,
1533 December 2005.
1535 [RFC4774] Floyd, S., "Specifying Alternate
1536 Semantics for the Explicit
1537 Congestion Notification (ECN)
1538 Field", BCP 124, RFC 4774,
1539 November 2006.
1541 [RFC5129] Davie, B., Briscoe, B., and J. Tay,
1542 "Explicit Congestion Marking in
1543 MPLS", RFC 5129, January 2008.
1545 [RFC5559] Eardley, P., "Pre-Congestion
1546 Notification (PCN) Architecture",
1547 RFC 5559, June 2009.
1549 [RFC5670] Eardley, P., "Metering and Marking
1550 Behaviour of PCN-Nodes", RFC 5670,
1551 November 2009.
1553 [RFC5696] Moncaster, T., Briscoe, B., and M.
1554 Menth, "Baseline Encoding and
1555 Transport of Pre-Congestion
1556 Information", RFC 5696,
1557 November 2009.
1559 [VCP] Xia, Y., Subramanian, L., Stoica,
1560 I., and S. Kalyanaraman, "One more
1561 bit is enough", Proc. SIGCOMM'05,
1562 ACM CCR 35(4)37--48, 2005, .
1566 Editorial Comments
1568 [Note_Manual_Keying] Bob Briscoe: Note (To be removed by the RFC
1569 Editor): One corner case can exist where an
1570 RFC4301 ingress does not use IKEv2, but uses
1571 manual keying instead. Then an RFC4301 ingress
1572 could conceivably be configured to tunnel to an
1573 egress with limited functionality ECN handling.
1574 Strictly, for this corner-case, the requirement
1575 to use compatibility mode in this specification
1576 updates RFC4301. However, this is such a remote
1577 possibility that RFC4301 IPsec implementations
1578 are not required to implement compatibility
1579 mode. It is planned to remove this note after
1580 the review process has completed to avoid
1581 unnecessarily complicating the document with a
1582 largely theoretical corner case.
1584 [Note_PCN_egress] Bob Briscoe: During the review process Appendix
1585 D is provided to expand on this point, but it
1586 will be deleted before publication.
1588 [Note_PCN_ingress] Bob Briscoe: During the review process Appendix
1589 E is provided to expand on this point, but it
1590 will be deleted before publication.
1592 Appendix A. Early ECN Tunnelling RFCs
1594 IP in IP tunnelling was originally defined in [RFC2003]. On
1595 encapsulation, the incoming header was copied to the outer and on
1596 decapsulation the outer was simply discarded. Initially, IPsec
1597 tunnelling [RFC2401] followed the same behaviour.
1599 When ECN was introduced experimentally in [RFC2481], legacy (RFC2003
1600 or RFC2401) tunnels would have discarded any congestion markings
1601 added to the outer header, so RFC2481 introduced rules for
1602 calculating the outgoing header from a combination of the inner and
1603 outer on decapsulation. RC2481 also introduced a second mode for
1604 IPsec tunnels, which turned off ECN processing (Not-ECT) in the outer
1605 header on encapsulation because an RFC2401 decapsulator would discard
1606 the outer on decapsulation. For RFC2401 IPsec this had the side-
1607 effect of completely blocking the covert channel.
1609 In RFC2481 the ECN field was defined as two separate bits. But when
1610 ECN moved from the experimental to the standards track [RFC3168], the
1611 ECN field was redefined as four codepoints. This required a
1612 different calculation of the ECN field from that used in RFC2481 on
1613 decapsulation. RFC3168 also had two modes; a 'full functionality
1614 mode' that restricted the covert channel as much as possible but
1615 still allowed ECN to be used with IPsec, and another that completely
1616 turned off ECN processing across the tunnel. This 'limited
1617 functionality mode' both offered a way for operators to completely
1618 block the covert channel and allowed an RFC3168 ingress to interwork
1619 with a legacy tunnel egress (RFC2481, RFC2401 or RFC2003).
1621 The present specification includes a similar compatibility mode to
1622 interwork safely with tunnels compliant with any of these three
1623 earlier RFCs. However, unlike RFC3168, it is only a mode of the
1624 ingress, as decapsulation behaviour is the same in either case.
1626 Appendix B. Design Constraints
1628 Tunnel processing of a congestion notification field has to meet
1629 congestion control and management needs without creating new
1630 information security vulnerabilities (if information security is
1631 required). This appendix documents the analysis of the tradeoffs
1632 between these factors that led to the new encapsulation rules in
1633 Section 4.1.
1635 B.1. Security Constraints
1637 Information security can be assured by using various end to end
1638 security solutions (including IPsec in transport mode [RFC4301]), but
1639 a commonly used scenario involves the need to communicate between two
1640 physically protected domains across the public Internet. In this
1641 case there are certain management advantages to using IPsec in tunnel
1642 mode solely across the publicly accessible part of the path. The
1643 path followed by a packet then crosses security 'domains'; the ones
1644 protected by physical or other means before and after the tunnel and
1645 the one protected by an IPsec tunnel across the otherwise unprotected
1646 domain. The scenario in Figure 5 will be used where endpoints 'A'
1647 and 'B' communicate through a tunnel. The tunnel ingress 'I' and
1648 egress 'E' are within physically protected edge domains, while the
1649 tunnel spans an unprotected internetwork where there may be 'men in
1650 the middle', M.
1652 physically unprotected physically
1653 <-protected domain-><--domain--><-protected domain->
1654 +------------------+ +------------------+
1655 | | M | |
1656 | A-------->I=========>==========>E-------->B |
1657 | | | |
1658 +------------------+ +------------------+
1659 <----IPsec secured---->
1660 tunnel
1662 Figure 5: IPsec Tunnel Scenario
1664 IPsec encryption is typically used to prevent 'M' seeing messages
1665 from 'A' to 'B'. IPsec authentication is used to prevent 'M'
1666 masquerading as the sender of messages from 'A' to 'B' or altering
1667 their contents. 'I' can use IPsec tunnel mode to allow 'A' to
1668 communicate with 'B', but impose encryption to prevent 'A' leaking
1669 information to 'M'. Or 'E' can insist that 'I' uses tunnel mode
1670 authentication to prevent 'M' communicating information to 'B'.
1672 Mutable IP header fields such as the ECN field (as well as the TTL/
1673 Hop Limit and DS fields) cannot be included in the cryptographic
1674 calculations of IPsec. Therefore, if 'I' copies these mutable fields
1675 into the outer header that is exposed across the tunnel it will have
1676 allowed a covert channel from 'A' to M that bypasses its encryption
1677 of the inner header. And if 'E' copies these fields from the outer
1678 header to the inner, even if it validates authentication from 'I', it
1679 will have allowed a covert channel from 'M' to 'B'.
1681 ECN at the IP layer is designed to carry information about congestion
1682 from a congested resource towards downstream nodes. Typically a
1683 downstream transport might feed the information back somehow to the
1684 point upstream of the congestion that can regulate the load on the
1685 congested resource, but other actions are possible (see [RFC3168]
1686 S.6). In terms of the above unicast scenario, ECN effectively
1687 intends to create an information channel (for congestion signalling)
1688 from 'M' to 'B' (for 'B' to feed back to 'A'). Therefore the goals
1689 of IPsec and ECN are mutually incompatible, requiring some
1690 compromise.
1692 With respect to using the DS or ECN fields as covert channels,
1693 S.5.1.2 of RFC4301 says, "controls are provided to manage the
1694 bandwidth of this channel". Using the ECN processing rules of
1695 RFC4301, the channel bandwidth is two bits per datagram from 'A' to
1696 'M' and one bit per datagram from 'M' to 'A' (because 'E' limits the
1697 combinations of the 2-bit ECN field that it will copy). In both
1698 cases the covert channel bandwidth is further reduced by noise from
1699 any real congestion marking. RFC4301 implies that these covert
1700 channels are sufficiently limited to be considered a manageable
1701 threat. However, with respect to the larger (6b) DS field, the same
1702 section of RFC4301 says not copying is the default, but a
1703 configuration option can allow copying "to allow a local
1704 administrator to decide whether the covert channel provided by
1705 copying these bits outweighs the benefits of copying". Of course, an
1706 administrator considering copying of the DS field has to take into
1707 account that it could be concatenated with the ECN field giving an 8b
1708 per datagram covert channel.
1710 For tunnelling the 6b Diffserv field two conceptual models have had
1711 to be defined so that administrators can trade off security against
1712 the needs of traffic conditioning [RFC2983]:
1714 The uniform model: where the Diffserv field is preserved end-to-end
1715 by copying into the outer header on encapsulation and copying from
1716 the outer header on decapsulation.
1718 The pipe model: where the outer header is independent of that in the
1719 inner header so it hides the Diffserv field of the inner header
1720 from any interaction with nodes along the tunnel.
1722 However, for ECN, the new IPsec security architecture in RFC4301 only
1723 standardised one tunnelling model equivalent to the uniform model.
1724 It deemed that simplicity was more important than allowing
1725 administrators the option of a tiny increment in security, especially
1726 given not copying congestion indications could seriously harm
1727 everyone's network service.
1729 B.2. Control Constraints
1731 Congestion control requires that any congestion notification marked
1732 into packets by a resource will be able to traverse a feedback loop
1733 back to a function capable of controlling the load on that resource.
1734 To be precise, rather than calling this function the data source, it
1735 will be called the Load Regulator. This allows for exceptional cases
1736 where load is not regulated by the data source, but usually the two
1737 terms will be synonymous. Note the term "a function _capable of_
1738 controlling the load" deliberately includes a source application that
1739 doesn't actually control the load but ought to (e.g. an application
1740 without congestion control that uses UDP).
1742 A--->R--->I=========>M=========>E-------->B
1744 Figure 6: Simple Tunnel Scenario
1746 A similar tunnelling scenario to the IPsec one just described will
1747 now be considered, but without the different security domains,
1748 because the focus now shifts to whether the control loop and
1749 management monitoring work (Figure 6). If resources in the tunnel
1750 are to be able to explicitly notify congestion and the feedback path
1751 is from 'B' to 'A', it will certainly be necessary for 'E' to copy
1752 any CE marking from the outer header to the inner header for onward
1753 transmission to 'B', otherwise congestion notification from resources
1754 like 'M' cannot be fed back to the Load Regulator ('A'). But it does
1755 not seem necessary for 'I' to copy CE markings from the inner to the
1756 outer header. For instance, if resource 'R' is congested, it can
1757 send congestion information to 'B' using the congestion field in the
1758 inner header without 'I' copying the congestion field into the outer
1759 header and 'E' copying it back to the inner header. 'E' can still
1760 write any additional congestion marking introduced across the tunnel
1761 into the congestion field of the inner header.
1763 All this shows that 'E' can preserve the control loop irrespective of
1764 whether 'I' copies congestion notification into the outer header or
1765 resets it.
1767 That is the situation for existing control arrangements but, because
1768 copying reveals more information, it would open up possibilities for
1769 better control system designs. For instance, resetting CE marking on
1770 encapsulation breaks the standards track PCN congestion marking
1771 scheme [RFC5670]. It ends up removing excessive amounts of traffic
1772 unnecessarily. Whereas copying CE markings at ingress leads to the
1773 correct control behaviour.
1775 B.3. Management Constraints
1777 As well as control, there are also management constraints.
1778 Specifically, a management system may monitor congestion markings in
1779 passing packets, perhaps at the border between networks as part of a
1780 service level agreement. For instance, monitors at the borders of
1781 autonomous systems may need to measure how much congestion has
1782 accumulated so far along the path, perhaps to determine between them
1783 how much of the congestion is contributed by each domain.
1785 In this document the baseline of congestion marking (or the
1786 Congestion Baseline) is defined as the source of the layer that
1787 created (or most recently reset) the congestion notification field.
1788 When monitoring congestion it would be desirable if the Congestion
1789 Baseline did not depend on whether packets were tunnelled or not.
1790 Given some tunnels cross domain borders (e.g. consider M in Figure 6
1791 is monitoring a border), it would therefore be desirable for 'I' to
1792 copy congestion accumulated so far into the outer headers, so that it
1793 is exposed across the tunnel.
1795 For management purposes it might be useful for the tunnel egress to
1796 be able to monitor whether congestion occurred across a tunnel or
1797 upstream of it. Superficially it appears that copying congestion
1798 markings at the ingress would make this difficult, whereas it was
1799 straightforward when an RFC3168 ingress reset them. However,
1800 Appendix C gives a simple and precise method for a tunnel egress to
1801 infer the congestion level introduced across a tunnel. It works
1802 irrespective of whether the ingress copies or resets congestion
1803 markings.
1805 Appendix C. Contribution to Congestion across a Tunnel
1807 This specification mandates that a tunnel ingress determines the ECN
1808 field of each new outer tunnel header by copying the arriving header.
1809 Concern has been expressed that this will make it difficult for the
1810 tunnel egress to monitor congestion introduced only along a tunnel,
1811 which is easy if the outer ECN field is reset at a tunnel ingress
1812 (RFC3168 full functionality mode). However, in fact copying CE marks
1813 at ingress will still make it easy for the egress to measure
1814 congestion introduced across a tunnel, as illustrated below.
1816 Consider 100 packets measured at the egress. Say it measures that 30
1817 are CE marked in the inner and outer headers and 12 have additional
1818 CE marks in the outer but not the inner. This means packets arriving
1819 at the ingress had already experienced 30% congestion. However, it
1820 does not mean there was 12% congestion across the tunnel. The
1821 correct calculation of congestion across the tunnel is p_t = 12/
1822 (100-30) = 12/70 = 17%. This is easy for the egress to measure. It
1823 is simply the proportion of packets not marked in the inner header
1824 (70) that have a CE marking in the outer header (12). This technique
1825 works whether the ingress copies or resets CE markings, so it can be
1826 used by an egress that is not sure which RFC the ingress complies
1827 with.
1829 Figure 7 illustrates this in a combinatorial probability diagram.
1830 The square represents 100 packets. The 30% division along the bottom
1831 represents marking before the ingress, and the p_t division up the
1832 side represents marking introduced across the tunnel.
1834 ^ outer header marking
1835 |
1836 100% +-----+---------+ The large square
1837 | | | represents 100 packets
1838 | 30 | |
1839 | | | p_t = 12/(100-30)
1840 p_t + +---------+ = 12/70
1841 | | 12 | = 17%
1842 0 +-----+---------+--->
1843 0 30% 100% inner header marking
1845 Figure 7: Tunnel Marking of Packets Already Marked at Ingress
1847 Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN (to be
1848 removed before publication)
1850 Congestion notification with two severity levels is currently on the
1851 IETF's standards track agenda in the Congestion and Pre-Congestion
1852 Notification (PCN) working group. PCN needs all four possible states
1853 of congestion signalling in the 2-bit ECN field to be propagated at
1854 the egress, but pre-existing tunnels only propagate three. The four
1855 PCN states are: not PCN-enabled, not marked and two increasingly
1856 severe levels of congestion marking. The less severe marking means
1857 'stop admitting new traffic' and the more severe marking means
1858 'terminate some existing flows', which may be needed after reroutes
1859 (see [RFC5559] for more details). (Note on terminology: wherever
1860 this document counts four congestion states, the PCN working group
1861 would count this as three PCN states plus a not-PCN-enabled state.)
1863 Figure 2 (Section 3.2) shows that pre-existing decapsulation
1864 behaviour would have discarded any ECT(1) markings in outer headers
1865 if the inner was ECT(0). This prevented the PCN working group from
1866 using ECT(1) -- if a PCN node used ECT(1) to indicate one of the
1867 severity levels of congestion, any later tunnel egress would revert
1868 the marking to ECT(0) as if nothing had happened. Effectively the
1869 decapsulation rules of RFC4301 and RFC3168 waste one ECT codepoint;
1870 they treat the ECT(0) and ECT(1) codepoints as a single codepoint.
1872 A number of work-rounds to this problem were proposed in the PCN w-g;
1873 to add the fourth state another way or avoid needing it. Without
1874 wishing to disparage the ingenuity of these work-rounds, none were
1875 chosen for the standards track because they were either somewhat
1876 wasteful, imprecise or complicated:
1878 o One uses a pair of Diffserv codepoint(s) in place of each PCN DSCP
1879 to encode the extra state [I-D.ietf-pcn-3-state-encoding], using
1880 up the rapidly exhausting DSCP space while leaving an ECN
1881 codepoint unused.
1883 o Another survives tunnelling without an extra DSCP
1884 [I-D.ietf-pcn-psdm-encoding], but it requires the PCN edge
1885 gateways to share the initial state of a packet out of band.
1887 o Another proposes a more involved marking algorithm in forwarding
1888 elements to encode the three congestion notification states using
1889 only two ECN codepoints [I-D.satoh-pcn-st-marking].
1891 o Another takes a different approach; it compromises the precision
1892 of the admission control mechanism in some network scenarios, but
1893 manages to work with just three encoding states and a single
1894 marking algorithm [I-D.ietf-pcn-sm-edge-behaviour].
1896 Rather than require the IETF to bless any of these experimental
1897 encoding work-rounds, the present specification fixes the root cause
1898 of the problem so that operators deploying PCN can simply require
1899 that tunnel end-points within a PCN region should comply with this
1900 new ECN tunnelling specification. On the public Internet it would
1901 not be possible to know whether all tunnels complied with this new
1902 specification, but universal compliance is feasible for PCN, because
1903 it is intended to be deployed in a controlled Diffserv region.
1905 Given the present specification, the PCN w-g could progress a
1906 trivially simple four-state ECN encoding
1907 [I-D.ietf-pcn-3-in-1-encoding]. This would replace the interim
1908 standards track baseline encoding of just three states [RFC5696]
1909 which makes a fourth state available for any of the experimental
1910 alternatives.
1912 Appendix E. Why Resetting ECN on Encapsulation Impedes PCN (to be
1913 removed before publication)
1915 The PCN architecture says "...if encapsulation is done within the
1916 PCN-domain: Any PCN-marking is copied into the outer header. Note: A
1917 tunnel will not provide this behaviour if it complies with [RFC3168]
1918 tunnelling in either mode, but it will if it complies with [RFC4301]
1919 IPsec tunnelling. "
1921 The specific issue here concerns PCN excess rate marking [RFC5670].
1922 The purpose of excess rate marking is to provide a bulk mechanism for
1923 interior nodes within a PCN domain to mark traffic that is exceeding
1924 a configured threshold bit-rate, perhaps after an unexpected event
1925 such as a reroute, a link or node failure, or a more widespread
1926 disaster. Reroutes are a common cause of QoS degradation in IP
1927 networks. After reroutes it is common for multiple links in a
1928 network to become stressed at once. Therefore, PCN excess rate
1929 marking has been carefully designed to ensure traffic marked at one
1930 queue will not be counted again for marking at subsequent queues (see
1931 the `Excess traffic meter function' of [RFC5670]).
1933 However, if an RFC3168 tunnel ingress intervenes, it resets the ECN
1934 field in all the outer headers. This will cause excess traffic to be
1935 counted more than once, leading to many flows being removed that did
1936 not need to be removed at all. This is why the an RFC3168 tunnel
1937 ingress cannot be used in a PCN domain.
1939 The ECN reset in RFC3168 is no longer deemed necessary, it is
1940 inconsistent with RFC4301, it is not as simple as RFC4301 and it is
1941 impeding deployment of new protocols like PCN. The present
1942 specification corrects this perverse situation.
1944 Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0) Outer
1946 A packet with an ECT(1) inner and an ECT(0) outer should never arise
1947 from any known IETF protocol. Without giving a reason, RFC3168 and
1948 RFC4301 both say the outer should be ignored when decapsulating such
1949 a packet. This appendix explains why it was decided not to change
1950 this advice.
1952 In summary, ECT(0) always means 'not congested' and ECT(1) may imply
1953 the same [RFC3168] or it may imply a higher severity congestion
1954 signal [RFC4774], [I-D.ietf-pcn-3-in-1-encoding], depending on the
1955 transport in use. Whether they mean the same or not, at the ingress
1956 the outer should have started the same as the inner and only a broken
1957 or compromised router could have changed the outer to ECT(0).
1959 The decapsulator can detect this anomaly. But the question is,
1960 should it correct the anomaly by ignoring the outer, or should it
1961 reveal the anomaly to the end-to-end transport by forwarding the
1962 outer?
1964 On balance, it was decided that the decapsulator should correct the
1965 anomaly, but log the event and optionally raise an alarm. This is
1966 the safe action if ECT(1) is being used as a more severe marking than
1967 ECT(0), because it passes the more severe signal to the transport.
1968 However, it is not a good idea to hide anomalies, which is why an
1969 optional alarm is suggested. It should be noted that this anomaly
1970 may be the result of two changes to the outer: a broken or
1971 compromised router within the tunnel might be erasing congestion
1972 markings introduced earlier in the same tunnel by a congested router.
1973 In this case, the anomaly would be losing congestion signals, which
1974 needs immediate attention.
1976 The original reason for defining ECT(0) and ECT(1) as equivalent was
1977 so that the data source could use the ECN nonce [RFC3540] to detect
1978 if congestion signals were being erased. However, in this case, the
1979 decapsulator does not need a nonce to detect any anomalies introduced
1980 within the tunnel, because it has the inner as a record of the header
1981 at the ingress. Therefore, it was decided that the best compromise
1982 would be to give precedence to solving the safety issue over
1983 revealing the anomaly, because the anomaly could at least be detected
1984 and dealt with internally.
1986 Superficially, the opposite case where the inner and outer carry
1987 different ECT values, but with an ECT(1) outer and ECT(0) inner,
1988 seems to require a similar compromise. However, because that case is
1989 reversed, no compromise is necessary; it is best to forward the outer
1990 whether the transport expects the ECT(1) to mean a higher severity
1991 than ECT(0) or the same severity. Forwarding the outer either
1992 preserves a higher value (if it is higher) or it reveals an anomaly
1993 to the transport (if the two ECT codepoints mean the same severity).
1995 Appendix G. Open Issues
1997 The new decapsulation behaviour defined in Section 4.2 adds support
1998 for propagation of 2 severity levels of congestion. However
1999 transports have no way to discover whether there are any legacy
2000 tunnels on their path that will not propagate 2 severity levels. It
2001 would have been nice to add a feature for transports to check path
2002 support, but this remains an open issue that will have to be
2003 addressed in any future standards action to define an end-to-end
2004 scheme that requires 2-severity levels of congestion. PCN avoids
2005 this problem because it is only for a controlled region, so all
2006 legacy tunnels can be upgraded by the same operator that deploys PCN.
2008 Author's Address
2010 Bob Briscoe
2011 BT
2012 B54/77, Adastral Park
2013 Martlesham Heath
2014 Ipswich IP5 3RE
2015 UK
2017 Phone: +44 1473 645196
2018 EMail: bob.briscoe@bt.com
2019 URI: http://bobbriscoe.net/