idnits 2.17.1
draft-ietf-tsvwg-ecn-tunnel-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. 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
== The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
does not include the phrase in its RFC 2119 key words list.
(Using the creation date from RFC3168, updated by this document, for
RFC5378 checks: 2000-11-17)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 24, 2009) is 5362 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-00
== Outdated reference: A later version (-02) exists of
draft-ietf-pcn-3-state-encoding-00
== Outdated reference: A later version (-07) exists of
draft-ietf-pcn-baseline-encoding-04
== Outdated reference: A later version (-05) exists of
draft-ietf-pcn-marking-behaviour-04
== 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-00
== Outdated reference: A later version (-02) exists of
draft-satoh-pcn-st-marking-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)
Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 6 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 July 24, 2009
5 (if approved)
6 Intended status: Standards Track
7 Expires: January 25, 2010
9 Tunnelling of Explicit Congestion Notification
10 draft-ietf-tsvwg-ecn-tunnel-03
12 Status of This Memo
14 This Internet-Draft is submitted to IETF in full conformance with the
15 provisions of BCP 78 and BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on January 25, 2010.
35 Copyright Notice
37 Copyright (c) 2009 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents in effect on the date of
42 publication of this document (http://trustee.ietf.org/license-info).
43 Please review these documents carefully, as they describe your rights
44 and restrictions with respect to this document.
46 Abstract
48 This document redefines how the explicit congestion notification
49 (ECN) field of the IP header should be constructed on entry to and
50 exit from any IP in IP tunnel. On encapsulation it updates RFC3168
51 to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec
52 ECN processing. On decapsulation it updates both RFC3168 and RFC4301
53 to add new behaviours for previously unused combinations of inner and
54 outer header. The new rules propagate the ECN field whether it is
55 used to signal one or two severity levels of congestion, whereas
56 before they propagated only one. Tunnel endpoints can be updated in
57 any order without affecting pre-existing uses of the ECN field
58 (backward compatible). Nonetheless, operators wanting to support two
59 severity levels (e.g. for pre-congestion notification--PCN) can
60 require compliance with this new specification. A thorough analysis
61 of the reasoning for these changes and the implications is included.
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8
66 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
68 3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 11
69 3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 11
70 3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 12
71 4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 13
72 4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 13
73 4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 14
74 4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 16
75 4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 17
76 5. Changes from Earlier RFCs . . . . . . . . . . . . . . . . . . 18
77 5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 18
78 5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 19
79 5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 19
80 5.3.1. Motivation for Changing Encapsulation . . . . . . . . 20
81 5.3.2. Motivation for Changing Decapsulation . . . . . . . . 21
82 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 23
83 6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 23
84 6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 23
85 6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 24
86 7. Design Principles for Future Non-Default Schemes . . . . . . . 24
87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
89 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
91 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 28
92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
93 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
94 13.2. Informative References . . . . . . . . . . . . . . . . . . 29
95 Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 31
96 Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 32
97 B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 32
98 B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 34
99 B.3. Management Constraints . . . . . . . . . . . . . . . . . . 35
100 Appendix C. Contribution to Congestion across a Tunnel . . . . . 36
101 Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN . . . 36
102 Appendix E. Why Resetting ECN on Encapsulation Impedes PCN . . . 38
103 Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0)
104 Outer . . . . . . . . . . . . . . . . . . . . . . . . 39
106 Request to the RFC Editor (to be removed on publication):
108 In the RFC index, RFC3168 should be identified as an update to
109 RFC2481, RFC2401 and RFC2003. RFC4301 should be identified as an
110 update to RFC3168.
112 Changes from previous drafts (to be removed by the RFC Editor)
114 Full text differences between IETF draft versions are available at
115 , and
116 between earlier individual draft versions at
117
119 From ietf-02 to ietf-03 (current):
121 * Functional changes:
123 + Corrected errors in recap of previous RFCs, which wrongly
124 stated the different decapsulation behaviours of RFC3168 &
125 RFC4301 with a Not-ECT inner header. This also required
126 corrections to the "Changes from Earlier RFCs" and the
127 Motivations for these changes.
129 + Mandated that any future standards action SHOULD NOT use the
130 ECT(0) codepoint as an indication of congestion, without
131 giving strong reasons.
133 + Added optional alarm when decapsulating ECT(1) outer,
134 ECT(0), but noted it would need to be disabled for
135 2-severity level congestion (e.g. PCN).
137 * Structural changes:
139 + Removed Document Roadmap which merely repeated the Contents
140 (previously Section 1.2).
142 + Moved "Changes from Earlier RFCs" (Section 5) before
143 Section 6 on Backward Compatibility and internally organised
144 both by RFC, rather than by ingress then egress.
146 + Moved motivation for changing existing RFCs (Section 5.3) to
147 after the changes are specified.
149 + Moved informative "Design Principles for Future Non-Default
150 Schemes" after all the normative sections.
152 + Added Appendix A on early history of ECN tunnelling RFCs.
154 + Removed specialist appendix on "Relative Placement of
155 Tunnelling and In-Path Load Regulation" (Appendix D in the
156 -02 draft)
158 + Moved and updated specialist text on "Compromise on Decap
159 with ECT(1) Inner and ECT(0) Outer" from Security
160 Considerations to Appendix F
162 * Textual changes:
164 + Simplified vocabulary for non-native-english speakers
166 + Simplified Introduction and defined regularly used terms in
167 an expanded Terminology section.
169 + More clearly distinguished statically configured tunnels
170 from dynamic tunnel endpoint discovery, before explaining
171 operating modes.
173 + Simplified, cut-down and clarified throughout
175 + Updated references.
177 From ietf-01 to ietf-02:
179 * Scope reduced from any encapsulation of an IP packet to solely
180 IP in IP tunnelled encapsulation. Consequently changed title
181 and removed whole section 'Design Guidelines for New
182 Encapsulations of Congestion Notification' (to be included in a
183 future companion informational document).
185 * Included a new normative decapsulation rule for ECT(0) inner
186 and ECT(1) outer that had previously only been outlined in the
187 non-normative appendix 'Comprehensive Decapsulation Rules'.
188 Consequently:
190 + The Introduction has been completely re-written to motivate
191 this change to decapsulation along with the existing change
192 to encapsulation.
194 + The tentative text in the appendix that first proposed this
195 change has been split between normative standards text in
196 Section 4 and Appendix D, which explains specifically why
197 this change would streamline PCN. New text on the logic of
198 the resulting decap rules added.
200 * If inner/outer is Not-ECT/ECT(0), changed decapsulation to
201 propagate Not-ECT rather than drop the packet; and added
202 reasoning.
204 * Considerably restructured:
206 + "Design Constraints" analysis moved to an appendix
207 (Appendix B);
209 + Added Section 3 to summarise relevant existing RFCs;
211 + Structured Section 4 and Section 6 into subsections.
213 + Added tables to sections on old and new rules, for precision
214 and comparison.
216 + Moved Section 7 on Design Principles to the end of the
217 section specifying the new default normative tunnelling
218 behaviour. Rewritten and shifted text on identifiers and
219 in-path load regulators to Appendix B.1 [deleted in revision
220 -03].
222 From ietf-00 to ietf-01:
224 * Identified two additional alarm states in the decapsulation
225 rules (Figure 4) if ECT(X) in outer and inner contradict each
226 other.
228 * Altered Comprehensive Decapsulation Rules (Appendix D) so that
229 ECT(0) in the outer no longer overrides ECT(1) in the inner.
230 Used the term 'Comprehensive' instead of 'Ideal'. And
231 considerably updated the text in this appendix.
233 * Added Appendix D.1 (removed again in a later revision) to weigh
234 up the various ways the Comprehensive Decapsulation Rules might
235 be introduced. This replaces the previous contradictory
236 statements saying complex backwards compatibility interactions
237 would be introduced while also saying there would be no
238 backwards compatibility issues.
240 * Updated references.
242 From briscoe-01 to ietf-00:
244 * Re-wrote Appendix C giving much simpler technique to measure
245 contribution to congestion across a tunnel.
247 * Added discussion of backward compatibility of the ideal
248 decapsulation scheme in Appendix D
250 * Updated references. Minor corrections & clarifications
251 throughout.
253 From briscoe-00 to briscoe-01:
255 * Related everything conceptually to the uniform and pipe models
256 of RFC2983 on Diffserv Tunnels, and completely removed the
257 dependence of tunnelling behaviour on the presence of any in-
258 path load regulation by using the [1 - Before] [2 - Outer]
259 function placement concepts from RFC2983;
261 * Added specific cases where the existing standards limit new
262 proposals, particularly Appendix E;
264 * Added sub-structure to Introduction (Need for Rationalisation,
265 Roadmap), added new Introductory subsection on "Scope" and
266 improved clarity;
268 * Added Design Guidelines for New Encapsulations of Congestion
269 Notification;
271 * Considerably clarified the Backward Compatibility section
272 (Section 6);
274 * Considerably extended the Security Considerations section
275 (Section 9);
277 * Summarised the primary rationale much better in the
278 conclusions;
280 * Added numerous extra acknowledgements;
282 * Added Appendix E. "Why resetting CE on encapsulation harms
283 PCN", Appendix C. "Contribution to Congestion across a Tunnel"
284 and Appendix D. "Ideal Decapsulation Rules";
286 * Re-wrote Appendix B [deleted in a later revision], explaining
287 how tunnel encapsulation no longer depends on in-path load-
288 regulation (changed title from "In-path Load Regulation" to
289 "Non-Dependence of Tunnelling on In-path Load Regulation"), but
290 explained how an in-path load regulation function must be
291 carefully placed with respect to tunnel encapsulation (in a new
292 sub-section entitled "Dependence of In-Path Load Regulation on
293 Tunnelling").
295 1. Introduction
297 Explicit congestion notification (ECN [RFC3168]) allows a forwarding
298 element to notify the onset of congestion without having to drop
299 packets. Instead it can explicitly mark a proportion of packets in
300 the 2-bit ECN field in the IP header (Table 1 recaps the ECN
301 codepoints).
303 The outer header of an IP packet can encapsulate one or more IP
304 headers for tunnelling. A forwarding element using ECN to signify
305 congestion will only mark the immediately visible outer IP header.
306 When a tunnel decapsulator later removes this outer header, it
307 follows rules to propagate congestion markings by combining the ECN
308 fields of the inner and outer IP header into one outgoing IP header.
310 This document updates those rules for IPsec [RFC4301] and non-IPsec
311 [RFC3168] tunnels to add new behaviours for previously unused
312 combinations of inner and outer header. It also updates the tunnel
313 ingress behaviour of RFC3168 to match that of RFC4301. The updated
314 rules are backward compatible with RFC4301 and RFC3168 when
315 interworking with any other tunnel endpoint complying with any
316 earlier specification.
318 When ECN and its tunnelling was defined in RFC3168, only the minimum
319 necessary changes to the ECN field were propagated through tunnel
320 endpoints--just enough for the basic ECN mechanism to work. This was
321 due to concerns that the ECN field might be toggled to communicate
322 between a secure site and someone on the public Internet--a covert
323 channel. This was because a mutable field like ECN cannot be
324 protected by IPsec's integrity mechanisms--it has to be able to
325 change as it traverses the Internet.
327 Nonetheless, the latest IPsec architecture [RFC4301] considers a
328 bandwidth limit of 2 bits per packet on a covert channel makes it a
329 manageable risk. Therefore, for simplicity, an RFC4301 ingress
330 copies the whole ECN field to encapsulate a packet. It also
331 dispenses with the two modes of RFC3168, one which partially copied
332 the ECN field, and the other which blocked all propagation of ECN
333 changes.
335 Unfortunately, this entirely reasonable sequence of standards actions
336 resulted in a perverse outcome; non-IPsec tunnels (RFC3168) blocked
337 the 2-bit covert channel, while IPsec tunnels (RFC4301) did not--at
338 least not at the ingress. At the egress, both IPsec and non-IPsec
339 tunnels still partially restricted propagation of the full ECN field.
341 The trigger for the changes in this document was the introduction of
342 pre-congestion notification (PCN [I-D.ietf-pcn-marking-behaviour]) to
343 the IETF standards track. PCN needs the ECN field to be copied at a
344 tunnel ingress and it needs four states of congestion signalling to
345 be propagated at the egress, but pre-existing tunnels only propagate
346 three in the ECN field.
348 This document draws on currently unused (CU) combinations of inner
349 and outer headers to add tunnelling of four-state congestion
350 signalling to RFC3168 and RFC4301. Operators of tunnels who
351 specifically want to support four states can require that all their
352 tunnels comply with this specification. Nonetheless, all tunnel
353 endpoint implementations (RFC4301, RFC3168, RFC2481, RFC2401,
354 RFC2003) can safely be updated to this new specification as part of
355 general code maintenance. This will gradually add support for four
356 congestion states to the Internet. Existing three state schemes will
357 continue to work as before.
359 At the same time as harmonising covert channel constraints, the
360 opportunity has been taken to draw together diverging tunnel
361 specifications into a single consistent behaviour. Then any tunnel
362 can be deployed unilaterally, and it will support the full range of
363 congestion control and management schemes without any modes or
364 configuration. Further, any host or router can expect the ECN field
365 to behave in the same way, whatever type of tunnel might intervene in
366 the path.
368 1.1. Scope
370 This document only concerns wire protocol processing of the ECN field
371 at tunnel endpoints and makes no changes or recommendations
372 concerning algorithms for congestion marking or congestion response.
374 This document specifies common ECN field processing at encapsulation
375 and decapsulation for any IP in IP tunnelling, whether IPsec or non-
376 IPsec tunnels. It applies irrespective of whether IPv4 or IPv6 is
377 used for either of the inner and outer headers. It applies for
378 packets with any destination address type, whether unicast or
379 multicast. It applies as the default for all Diffserv per-hop
380 behaviours (PHBs), unless stated otherwise in the specification of a
381 PHB. It is intended to be a good trade off between somewhat
382 conflicting security, control and management requirements.
384 [RFC2983] is a comprehensive primer on differentiated services and
385 tunnels. Given ECN raises similar issues to differentiated services
386 when interacting with tunnels, useful concepts introduced in RFC2983
387 are used throughout, with brief recaps of the explanations where
388 necessary.
390 2. Terminology
392 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
393 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
394 document are to be interpreted as described in RFC 2119 [RFC2119].
396 Table 1 recaps the names of the ECN codepoints [RFC3168].
398 +------------------+----------------+---------------------------+
399 | Binary codepoint | Codepoint name | Meaning |
400 +------------------+----------------+---------------------------+
401 | 00 | Not-ECT | Not ECN-capable transport |
402 | 01 | ECT(1) | ECN-capable transport |
403 | 10 | ECT(0) | ECN-capable transport |
404 | 11 | CE | Congestion experienced |
405 +------------------+----------------+---------------------------+
407 Table 1: Recap of Codepoints of the ECN Field [RFC3168] in the IP
408 Header
410 Further terminology used within this document:
412 Encapsulator: The tunnel endpoint function that adds an outer IP
413 header to tunnel a packet (also termed the 'ingress tunnel
414 endpoint' or just the 'ingress' where the context is clear).
416 Decapsulator: The tunnel endpoint function that removes an outer IP
417 header from a tunnelled packet (also termed the 'egress tunnel
418 endpoint' or just the 'egress' where the context is clear).
420 Incoming header: The header of an arriving packet before
421 encapsulation.
423 Outer header: The header added to encapsulate a tunnelled packet.
425 Inner header: The header encapsulated by the outer header.
427 Outgoing header: The header constructed by the decapsulator using
428 logic that combines the fields in the outer and inner headers.
430 Copying ECN: On encapsulation, setting the ECN field of the new
431 outer header to be a copy of the ECN field in the incoming header.
433 Zeroing ECN: On encapsulation, clearing the ECN field of the new
434 outer header to Not-ECT ("00").
436 Resetting ECN: On encapsulation, setting the ECN field of the new
437 outer header to be a copy of the ECN field in the incoming header
438 except the outer ECN field is set to the ECT(0) codepoint if the
439 incoming ECN field is CE ("11").
441 3. Summary of Pre-Existing RFCs
443 This section is informative not normative, as it recaps pre-existing
444 RFCs. Earlier relevant RFCs that were either experimental or
445 incomplete with respect to ECN tunnelling (RFC2481, RFC2401 and
446 RFC2003) are briefly outlined inAppendix A. The question of whether
447 tunnel implementations used in the Internet comply with any of these
448 RFCs is not discussed.
450 3.1. Encapsulation at Tunnel Ingress
452 At the encapsulator, the controversy has been over whether to
453 propagate information about congestion experienced on the path so far
454 into the outer header of the tunnel.
456 Specifically, RFC3168 says that, if a tunnel fully supports ECN
457 (termed a 'full-functionality' ECN tunnel in [RFC3168]), the
458 encapsulator must not copy a CE marking from the inner header into
459 the outer header that it creates. Instead the encapsulator must set
460 the outer header to ECT(0) if the ECN field is marked CE in the
461 arriving IP header. We term this 'resetting' a CE codepoint.
463 However, the new IPsec architecture in [RFC4301] reverses this rule,
464 stating that the encapsulator must simply copy the ECN field from the
465 incoming header to the outer header.
467 RFC3168 also provided a Limited Functionality mode that turns off ECN
468 processing over the scope of the tunnel by setting the outer header
469 to Not-ECT ("00"). Then such packets will be dropped to indicate
470 congestion rather than marked with ECN. This is necessary for the
471 ingress to interwork with legacy decapsulators ([RFC2481], [RFC2401]
472 and [RFC2003]) that do not propagate ECN markings added to the outer
473 header. Otherwise such legacy decapsulators would throw away
474 congestion notifications before they reached the transport layer.
476 Neither Limited Functionality mode nor Full Functionality mode are
477 used by an RFC4301 IPsec encapsulator, which simply copies the
478 incoming ECN field into the outer header. An earlier key-exchange
479 phase ensures an RFC4301 ingress will not have to interwork with a
480 legacy egress that does not support ECN.
482 These pre-existing behaviours are summarised in Figure 1.
484 +-----------------+-----------------------------------------------+
485 | Incoming Header | Outgoing Outer Header |
486 | (also equal to +---------------+---------------+---------------+
487 | Outgoing Inner | RFC3168 ECN | RFC3168 ECN | RFC4301 IPsec |
488 | Header) | Limited | Full | |
489 | | Functionality | Functionality | |
490 +-----------------+---------------+---------------+---------------+
491 | Not-ECT | Not-ECT | Not-ECT | Not-ECT |
492 | ECT(0) | Not-ECT | ECT(0) | ECT(0) |
493 | ECT(1) | Not-ECT | ECT(1) | ECT(1) |
494 | CE | Not-ECT | ECT(0) | CE |
495 +-----------------+---------------+---------------+---------------+
497 Figure 1: IP in IP Encapsulation: Recap of Pre-existing Behaviours
499 3.2. Decapsulation at Tunnel Egress
501 RFC3168 and RFC4301 specify the decapsulation behaviour summarised in
502 Figure 2. The ECN field in the outgoing header is set to the
503 codepoint at the intersection of the appropriate incoming inner
504 header (row) and incoming outer header (column).
505 +---------+------------------------------------------------+
506 |Incoming | Incoming Outer Header |
507 | Inner +---------+------------+------------+------------+
508 | Header | Not-ECT | ECT(0) | ECT(1) | CE |
509 +---------+---------+------------+------------+------------+
510 RFC3168->| Not-ECT | Not-ECT |Not-ECT |Not-ECT | drop |
511 RFC4301->| Not-ECT | Not-ECT |Not-ECT |Not-ECT |Not-ECT |
512 | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE |
513 | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE |
514 | CE | CE | CE | CE | CE |
515 +---------+---------+------------+------------+------------+
516 | Outgoing Header |
517 +------------------------------------------------+
519 Figure 2: IP in IP Decapsulation; Recap of Pre-existing Behaviour
521 The behaviour in the table derives from the logic given in RFC3168
522 and RFC4301, briefly recapped as follows:
524 o On decapsulation, if the inner ECN field is Not-ECT the outer is
525 discarded. RFC3168 (but not RFC4301) also specified that the
526 decapsulator must drop a packet with a Not-ECT inner and CE in the
527 outer.
529 o In all other cases, if the outer is CE, the outgoing ECN field is
530 set to CE, but otherwise the outer is ignored and the inner is
531 used for the outgoing ECN field.
533 RFC3168 also made it an auditable event for an IPsec tunnel "if the
534 ECN Field is changed inappropriately within an IPsec tunnel...".
535 Inappropriate changes were not specifically enumerated. RFC4301 did
536 not mention inappropriate ECN changes.
538 4. New ECN Tunnelling Rules
540 The standards actions below in Section 4.1 (ingress encapsulation)
541 and Section 4.2 (egress decapsulation) define new default ECN tunnel
542 processing rules for any IP packet (v4 or v6) with any Diffserv
543 codepoint.
545 If absolutely necessary, an alternate congestion encapsulation
546 behaviour can be introduced as part of the definition of an alternate
547 congestion marking scheme used by a specific Diffserv PHB (see S.5 of
548 [RFC3168] and [RFC4774]). When designing such new encapsulation
549 schemes, the principles in Section 7 should be followed. However,
550 alternate ECN tunnelling schemes are NOT RECOMMENDED as the
551 deployment burden of handling exceptional PHBs in implementations of
552 all affected tunnels should not be underestimated. There is no
553 requirement for a PHB definition to state anything about ECN
554 tunnelling behaviour if the default behaviour in the present
555 specification is sufficient.
557 4.1. Default Tunnel Ingress Behaviour
559 Two modes of encapsulation are defined here; `normal mode' and
560 `compatibility mode', which is for backward compatibility with tunnel
561 decapsulators that do not understand ECN. Section 4.3 explains why
562 two modes are necessary and specifies the circumstances in which it
563 is sufficient to solely implement normal mode. Note that these are
564 modes of the ingress tunnel endpoint only, not the whole tunnel.
566 Whatever the mode, an encapsulator forwards the inner header without
567 changing the ECN field.
569 In normal mode an encapsulator compliant with this specification MUST
570 construct the outer encapsulating IP header by copying the 2-bit ECN
571 field of the incoming IP header. In compatibility mode it clears the
572 ECN field in the outer header to the Not-ECT codepoint. These rules
573 are tabulated for convenience in Figure 3.
575 +-----------------+-------------------------------+
576 | Incoming Header | Outgoing Outer Header |
577 | (also equal to +---------------+---------------+
578 | Outgoing Inner | Compatibility | Normal |
579 | Header) | Mode | Mode |
580 +-----------------+---------------+---------------+
581 | Not-ECT | Not-ECT | Not-ECT |
582 | ECT(0) | Not-ECT | ECT(0) |
583 | ECT(1) | Not-ECT | ECT(1) |
584 | CE | Not-ECT | CE |
585 +-----------------+---------------+---------------+
587 Figure 3: New IP in IP Encapsulation Behaviours
589 An ingress in compatibility mode encapsulates packets identically to
590 an ingress in RFC3168's limited functionality mode. An ingress in
591 normal mode encapsulates packets identically to an RFC4301 IPsec
592 ingress.
594 4.2. Default Tunnel Egress Behaviour
596 To decapsulate the inner header at the tunnel egress, a compliant
597 tunnel egress MUST set the outgoing ECN field to the codepoint at the
598 intersection of the appropriate incoming inner header (row) and outer
599 header (column) in Figure 4 (the IPv4 header checksum also changes
600 whenever the ECN field is changed). There is no need for more than
601 one mode of decapsulation, as these rules cater for all known
602 requirements.
603 +---------+------------------------------------------------+
604 |Incoming | Incoming Outer Header |
605 | Inner +---------+------------+------------+------------+
606 | Header | Not-ECT | ECT(0) | ECT(1) | CE |
607 +---------+---------+------------+------------+------------+
608 | Not-ECT | Not-ECT |Not-ECT(!!!)| drop(!!!)| drop(!!!)|
609 | ECT(0) | ECT(0) | ECT(0) | ECT(1)(!!!)| CE |
610 | ECT(1) | ECT(1) | ECT(1)(!!!)| ECT(1) | CE |
611 | CE | CE | CE | CE(!!!)| CE |
612 +---------+---------+------------+------------+------------+
613 | Outgoing Header |
614 +------------------------------------------------+
615 Unexpected combinations are indicated by '(!!!)'
617 Figure 4: New IP in IP Decapsulation Behaviour
619 This table for decapsulation behaviour is derived from the following
620 logic:
622 o If the inner ECN field is Not-ECT the decapsulator MUST NOT
623 propagate any other ECN codepoint onwards. This is because the
624 inner Not-ECT marking is set by transports that use drop as an
625 indication of congestion and would not understand or respond to
626 any other ECN codepoint [RFC4774]. In addition:
628 * If the inner ECN field is Not-ECT and the outer ECN field is
629 ECT(1) or CE the decapsulator MUST drop the packet.
631 * If the inner ECN field is Not-ECT and the outer ECN field is
632 ECT(0) or Not-ECT the decapsulator MUST forward the outgoing
633 packet with the ECN field cleared to Not-ECT.
635 * This specification mandates that any future standards action
636 SHOULD NOT use the ECT(0) codepoint as an indication of
637 congestion, without giving strong reasons, given the above rule
638 forwards an ECT(0) outer as Not-ECT.
640 o In all other cases where the inner supports ECN, the outgoing ECN
641 field is set to the more severe marking of the outer and inner ECN
642 fields, where the ranking of severity from highest to lowest is
643 CE, ECT(1), ECT(0), Not-ECT. This in no way precludes cases where
644 ECT(1) and ECT(0) have the same severity;
646 o Certain combinations of inner and outer ECN fields cannot result
647 from any currently used transition in any current or previous ECN
648 tunneling specification. These cases are indicated in Figure 4 by
649 '(!!!)'). In these cases, the decapsulator SHOULD log the event
650 and MAY also raise an alarm. Alarms should be rate-limited so
651 that the illegal combinations will not amplify into a flood of
652 alarm messages. It MUST be possible to suppress alarms or
653 logging, e.g. if it becomes apparent that a combination that
654 previously was not used has started to be used for legitimate
655 purposes such as a new standards action. An example is an ECT(0)
656 inner combined with an ECT(1) outer, which is proposed as a legal
657 combination for PCN [I-D.ietf-pcn-3-in-1-encoding], so an operator
658 that deploys support for PCN should turn off logging and alarms in
659 this case.
661 The above logic allows for ECT(0) and ECT(1) to both represent the
662 same severity of congestion marking (e.g. "not congestion marked").
663 But it also allows future schemes to be defined where ECT(1) is a
664 more severe marking than ECT(0). This approach is discussed in
665 Appendix D and in the discussion of the ECN nonce [RFC3540] in
666 Section 9, which in turn refers to Appendix F.
668 4.3. Encapsulation Modes
670 Section 4.1 introduces two encapsulation modes, normal mode and
671 compatibility mode, defining their encapsulation behaviour (i.e.
672 header copying or zeroing respectively). Note that these are modes
673 of the ingress tunnel endpoint only, not the tunnel as a whole.
675 A tunnel ingress MUST at least implement `normal mode' and, if it
676 might be used with legacy tunnel egress nodes (RFC2003, RFC2401 or
677 RFC2481 or the limited functionality mode of RFC3168), it MUST also
678 implement `compatibility mode' for backward compatibility with tunnel
679 egresses that do not propagate explicit congestion notifications
680 [RFC4774]. If the egress does support propagation of ECN (full
681 functionality mode of RFC3168 or RFC4301 or the present
682 specification), the ingress SHOULD use normal mode, in order to
683 support ECN where possible.
685 We can categorise the way that an ingress tunnel endpoint is paired
686 with an egress as either:
688 static: those paired together by prior configuration or;
690 dynamically discovered: those paired together by some form of tunnel
691 endpoint discovery, typically driven by the path taken by arriving
692 packets.
694 Static: Some implementations of encapsulator might be constrained to
695 be statically deployed, and constrained to never be paired with a
696 legacy decapsulator (RFC2003, RFC2401 or RFC2481 or the limited
697 functionality mode of RFC3168). In such a case, only normal mode
698 needs to be implemented.
700 For instance, RFC4301-compatible IPsec tunnel endpoints invariably
701 use IKEv2 [RFC4306] for key exchange, which was introduced alongside
702 RFC4301. Therefore both endpoints of an RFC4301 tunnel can be sure
703 that the other end is RFC4301-compatible, because the tunnel is only
704 formed after IKEv2 key management has completed, at which point both
705 ends will be RFC4301-compliant by definition. Further, an RFC4301
706 encapsulator behaves identically to the normal mode of the present
707 specification and does not need to implement compatibility mode as it
708 will never interact with legacy ECN tunnels.
710 Dynamic Discovery: This specification does not require or recommend
711 dynamic discovery and it does not define how dynamic negotiation
712 might be done, but it recognises that proprietary tunnel endpoint
713 discovery protocols exist. It therefore sets down some constraints
714 on discovery protocols to ensure safe interworking.
716 If dynamic tunnel endpoint discovery might pair an ingress with a
717 legacy egress (RFC2003, RFC2401 or RFC2481 or the limited
718 functionality mode of RFC3168), the ingress MUST implement both
719 normal and compatibility mode. If the tunnel discovery process is
720 arranged to only ever find a tunnel egress that propagates ECN
721 (RFC3168 full functionality mode, RFC4301 or this present
722 specification), then a tunnel ingress can be complaint with the
723 present specification without implementing compatibility mode.
725 If a compliant tunnel ingress is discovering an egress, it MUST send
726 packets in compatibility mode in case the egress it discovers is a
727 legacy egress. If, through the discovery protocol, the egress
728 indicates that it is compliant with the present specification, with
729 RFC4301 or with RFC3168 full functionality mode, the ingress can
730 switch itself into normal mode. If the egress denies compliance with
731 any of these or returns an error that implies it does not understand
732 a request to work to any of these ECN specifications, the tunnel
733 ingress MUST remain in compatibility mode.
735 An ingress cannot claim compliance with this specification simply by
736 disabling ECN processing across the tunnel (i.e. only implementing
737 compatibility mode). It is true that such a tunnel ingress is at
738 least safe with the ECN behaviour of any egress it may encounter, but
739 it does not meet the aim of introducing ECN support to tunnels.
741 Implementation note: if a compliant node is the ingress for multiple
742 tunnels, a mode setting will need to be stored for each tunnel
743 ingress. However, if a node is the egress for multiple tunnels, none
744 of the tunnels will need to store a mode setting, because a compliant
745 egress can only be in one mode.
747 4.4. Single Mode of Decapsulation
749 A compliant decapsulator only has one mode of operation. However, if
750 a complaint egress is implemented to be dynamically discoverable, it
751 may need to respond to discovery requests from various types of
752 legacy tunnel ingress. This specification does not define how
753 dynamic negotiation might be done by (proprietary) discovery
754 protocols, but it sets down some constraints to ensure safe
755 interworking.
757 Through the discovery protocol, a tunnel ingress compliant with the
758 present specification might ask if the egress is compliant with the
759 present specification, with RFC4301 or with RFC3168 full
760 functionality mode. Or an RFC3168 tunnel ingress might try to
761 negotiate to use limited functionality or full functionality mode
762 [RFC3168]. In all these cases, a decapsulating tunnel egress
763 compliant with this specification MUST agree to any of these
764 requests, since it will behave identically in all these cases.
766 If no ECN-related mode is requested, a compliant tunnel egress MUST
767 continue without raising any error or warning as its egress behaviour
768 is compatible with all the legacy ingress behaviours that do not
769 negotiate capabilities.
771 For 'forward compatibility', a compliant tunnel egress SHOULD raise a
772 warning alarm about any requests to enter modes it does not
773 recognise, but it SHOULD continue operating.
775 5. Changes from Earlier RFCs
777 5.1. Changes to RFC4301 ECN processing
779 Ingress: An RFC4301 IPsec encapsulator is not changed at all by the
780 present specification
782 Egress: The new decapsulation behaviour in Figure 4 updates RFC4301.
783 However, it solely updates combinations of inner and outer that
784 have never been used on the Internet, even though they were
785 defined in RFC4301 for completeness. Therefore, the present
786 specification adds new behaviours to RFC4301 decapsulation without
787 altering existing behaviours. The following specific updates have
788 been made:
790 * The outer, not the inner, is propagated when the outer is
791 ECT(1) and the inner is ECT(0);
793 * A packet with Not-ECT in the inner and an outer of ECT(1) or CE
794 is dropped rather than forwarded as Not-ECT;
796 * Certain combinations of inner and outer ECN field have been
797 identified as currently unused. These can trigger logging
798 and/or raise alarms.
800 Modes: RFC4301 does not need modes and is not updated by the modes
801 in the present specification. The normal mode of encapsulation is
802 unchanged from RFC4301 encapsulation and an RFC4301 IPsec ingress
803 will never need compatibility mode as explained in Section 4.3
804 (except in one corner-case described below).
805 One corner case can exist where an RFC4301 ingress does not use
806 IKEv2, but uses manual keying instead. Then an RFC4301 ingress
807 could conceivably be configured to tunnel to an egress with
808 limited functionality ECN handling. Strictly, for this corner-
809 case, the requirement to use compatibility mode in this
810 specification updates RFC4301. However, this is such a remote
811 possibility that in general RFC4301 IPsec implementations are NOT
812 REQUIRED to implement compatibility mode.
814 5.2. Changes to RFC3168 ECN processing
816 Ingress: On encapsulation, the new rule in Figure 3 that a normal
817 mode tunnel ingress copies any ECN field into the outer header
818 updates the ingress behaviour of RFC3168. Nonetheless, the new
819 compatibility mode is identical to the limited functionality mode
820 of RFC3168.
822 Egress: The new decapsulation behaviour in Figure 4 updates RFC3168.
823 However, the present specification solely updates combinations of
824 inner and outer that have never been used on the Internet, even
825 though they were defined in RFC3168 for completeness. Therefore,
826 the present specification adds new behaviours to RFC3168
827 decapsulation without altering existing behaviours. The following
828 specific updates have been made:
830 * The outer, not the inner, is propagated when the outer is
831 ECT(1) and the inner is ECT(0);
833 * A packet with Not-ECT in the inner and an outer of ECT(1) is
834 dropped rather than forwarded as Not-ECT;
836 * Certain combinations of inner and outer ECN field have been
837 identified as currently unused. These can trigger logging
838 and/or raise alarms.
840 Modes: RFC3168 defines a (required) limited functionality mode and
841 an (optional) full functionality mode for a tunnel. In RFC3168,
842 modes applied to both ends of the tunnel, while in the present
843 specification, modes are only used at the ingress--a single egress
844 behaviour covers all cases. The normal mode of encapsulation
845 updates the encapsulation behaviour of the full functionality mode
846 of RFC3168. The compatibility mode of encapsulation is identical
847 to the encapsulation behaviour of the limited functionality mode
848 of RFC3168. The constraints on how tunnel discovery protocols set
849 modes in Section 4.3 and Section 4.4 are an update to RFC3168.
851 5.3. Motivation for Changes
853 An overriding goal is to ensure the same ECN signals can mean the
854 same thing whatever tunnels happen to encapsulate an IP packet flow.
855 This removes gratuitous inconsistency, which otherwise constrains the
856 available design space and makes it harder to design networks and new
857 protocols that work predictably.
859 5.3.1. Motivation for Changing Encapsulation
861 The normal mode in Section 4 updates RFC3168 to make all IP in IP
862 encapsulation of the ECN field consistent--consistent with the way
863 both RFC4301 IPsec [RFC4301] and IP in MPLS or MPLS in MPLS
864 encapsulation [RFC5129] construct the ECN field.
866 Compatibility mode has also been defined so a non-RFC4301 ingress can
867 still switch to using drop across a tunnel for backwards
868 compatibility with legacy decapsulators that do not propagate ECN
869 correctly.
871 The trigger that motivated this update to RFC3168 encapsulation was a
872 standards track proposal for pre-congestion notification (PCN
873 [I-D.ietf-pcn-marking-behaviour]). PCN excess rate marking only
874 works correctly if the ECN field is copied on encapsulation (as in
875 RFC4301 and RFC5129); it does not work if ECN is reset (as in
876 RFC3168). This is because PCN excess rate marking depends on the
877 outer header revealing any congestion experienced so far on the whole
878 path, not just since the last tunnel ingress (see Appendix E for a
879 full explanation).
881 PCN allows a network operator to add flow admission and termination
882 for inelastic traffic at the edges of a Diffserv domain, but without
883 any per-flow mechanisms in the interior and without the generous
884 provisioning typical of Diffserv, aiming to significantly reduce
885 costs. The PCN architecture [RFC5559] states that RFC3168 IP in IP
886 tunnelling of the ECN field cannot be used for any tunnel ingress in
887 a PCN domain. Prior to the present specification, this left a stark
888 choice between not being able to use PCN for inelastic traffic
889 control or not being able to use the many tunnels already deployed
890 for Mobile IP, VPNs and so forth.
892 The present specification provides a clean solution to this problem,
893 so that network operators who want to use both PCN and tunnels can
894 specify that every tunnel ingress in a PCN region must comply with
895 this latest specification.
897 Rather than allow tunnel specifications to fragment further into one
898 for PCN, one for IPsec and one for other tunnels, the opportunity has
899 been taken to consolidate the diverging specifications back into a
900 single tunnelling behaviour. Resetting ECN was originally motivated
901 by a covert channel concern that has been deliberately set aside in
902 RFC4301 IPsec. Therefore the reset behaviour of RFC3168 is an
903 anomaly that we do not need to keep. Copying ECN on encapsulation is
904 anyway simpler than resetting. So, as more tunnel endpoints comply
905 with this single consistent specification, encapsulation will be
906 simpler as well as more predictable.
908 Appendix B assesses whether copying rather than resetting CE on
909 ingress will cause any unintended side-effects, from the three
910 perspectives of security, control and management. In summary this
911 analysis finds that:
913 o From the control perspective either copying or resetting works for
914 existing arrangements, but copying has more potential for
915 simplifying control and resetting breaks at least one proposal
916 already on the standards track.
918 o From the management and monitoring perspective copying is
919 preferable.
921 o From the traffic security perspective (enforcing congestion
922 control, mitigating denial of service etc) copying is preferable.
924 o From the information security perspective resetting is preferable,
925 but the IETF Security Area now considers copying acceptable given
926 the bandwidth of a 2-bit covert channel can be managed.
928 Therefore there are two points against resetting CE on ingress while
929 copying CE causes no harm (other than opening a 2-bit covert channel
930 that is deemed manageable).
932 5.3.2. Motivation for Changing Decapsulation
934 The specification for decapsulation in Section 4 fixes three problems
935 with the pre-existing behaviours of both RFC3168 and RFC4301:
937 1. The pre-existing rules prevented the introduction of alternate
938 ECN semantics to signal more than one severity level of
939 congestion [RFC4774], [RFC5559]. The four states of the 2-bit
940 ECN field provide room for signalling two severity levels in
941 addition to not-congested and not-ECN-capable states. But, the
942 pre-existing rules assumed that two of the states (ECT(0) and
943 ECT(1)) are always equivalent. This unnecessarily restricts the
944 use of one of four codepoints (half a bit) in the IP (v4 & v6)
945 header. The new rules are designed to work in either case;
946 whether ECT(1) is more severe than or equivalent to ECT(0).
948 As explained in Appendix B.1, the original reason for not
949 forwarding the outer ECT codepoints was to limit the covert
950 channel across a decapsulator to 1 bit per packet. However, now
951 that the IETF Security Area has deemed that a 2-bit covert
952 channel through an encapsulator is a manageable risk, the same
953 should be true for a decapsulator.
955 As well as being useful for general future-proofing, this problem
956 is immediately pressing for standardisation of pre-congestion
957 notification (PCN), which uses two severity levels of congestion.
958 If a congested queue used ECT(1) in the outer header to signal
959 more severe congestion than ECT(0), the pre-existing
960 decapsulation rules would have thrown away this congestion
961 signal, preventing tunnelled traffic from ever knowing that it
962 should reduce its load.
964 The PCN working group has had to consider a number of wasteful or
965 convoluted work-rounds to this problem (see Appendix D). But by
966 far the simplest approach is just to remove the covert channel
967 blockages from tunnelling behaviour--now deemed unnecessary
968 anyway. Then network operators that want to support two
969 congestion severity-levels for PCN can specify that every tunnel
970 egress in a PCN region must comply with this latest
971 specification.
973 Not only does this make two congestion severity-levels available
974 for PCN standardisation, but also for other potential uses of the
975 extra ECN codepoint (e.g. [VCP]).
977 2. Cases are documented where a middlebox (e.g. a firewall) drops
978 packets with header values that were currently unused (CU) when
979 the box was deployed, often on the grounds that anything
980 unexpected might be an attack. This tends to bar future use of
981 CU values. The new decapsulation rules specify optional logging
982 and/or alarms for specific combinations of inner and outer header
983 that are currently unused. The aim is to give implementers a
984 recourse other than drop if they are concerned about the security
985 of CU values. It recognises legitimate security concerns about
986 CU values but still eases their future use. If the alarms are
987 interpreted as an attack (e.g. by a management system) the
988 offending packets can be dropped. But alarms can be turned off
989 if these combinations come into use (e.g. a through a future
990 standards action).
992 3. While reviewing currently unused combinations of inner and outer,
993 the opportunity was taken to define a single consistent behaviour
994 for the cases with a Not-ECT inner header but a different outer.
995 RFC3168 and RFC4301 had diverged in this respect. These
996 combinations should not result from known Internet protocols.
997 So, for safety, it was decided to drop a packet if the outer
998 carries codepoints CE or ECT(1) that respectively signal
999 congestion or could potentially signal congestion in a scheme
1000 progressing through the IETF [I-D.ietf-pcn-3-in-1-encoding].
1001 Given an inner of Not-ECT implies the transport only understands
1002 drop as a signal of congestion, this was the safest course of
1003 action.
1005 Problems 2 & 3 alone would not warrant a change to decapsulation, but
1006 it was decided they are worth fixing and making consistent at the
1007 same time as decapsulation code is changed to fix problem 1 (two
1008 congestion severity-levels).
1010 6. Backward Compatibility
1012 A tunnel endpoint compliant with the present specification is
1013 backward compatible when paired with any tunnel endpoint compliant
1014 with any previous tunnelling RFC, whether RFC4301, RFC3168 (see
1015 Section 3) or the earlier RFCs summarised in Appendix A (RFC2481,
1016 RFC2401 and RFC2003). Each case is enumerated below.
1018 6.1. Non-Issues Updating Decapsulation
1020 At the egress, this specification only augments the per-packet
1021 calculation of the ECN field (RFC3168 and RFC4301) for combinations
1022 of inner and outer headers that have so far not been used in any IETF
1023 protocols.
1025 Therefore, all other things being equal, if an RFC4301 IPsec egress
1026 is updated to comply with the new rules, it will still interwork with
1027 any RFC4301 compliant ingress and the packet outputs will be
1028 identical to those it would have output before (fully backward
1029 compatible).
1031 And, all other things being equal, if an RFC3168 egress is updated to
1032 comply with the same new rules, it will still interwork with any
1033 ingress complying with any previous specification (both modes of
1034 RFC3168, both modes of RFC2481, RFC2401 and RFC2003) and the packet
1035 outputs will be identical to those it would have output before (fully
1036 backward compatible).
1038 A compliant tunnel egress merely needs to implement the one behaviour
1039 in Section 4 with no additional mode or option configuration at the
1040 ingress or egress nor any additional negotiation with the ingress.
1041 The new decapsulation rules have been defined in such a way that
1042 congestion control will still work safely if any of the earlier
1043 versions of ECN processing are used unilaterally at the encapsulating
1044 ingress of the tunnel (any of RFC2003, RFC2401, either mode of
1045 RFC2481, either mode of RFC3168, RFC4301 and this present
1046 specification).
1048 6.2. Non-Update of RFC4301 IPsec Encapsulation
1050 An RFC4301 IPsec ingress can comply with this new specification
1051 without any update and it has no need for any new modes, options or
1052 configuration. So, all other things being equal, it will continue to
1053 interwork identically with any egress it worked with before (fully
1054 backward compatible).
1056 6.3. Update to RFC3168 Encapsulation
1058 The encapsulation behaviour of the new normal mode copies the ECN
1059 field whereas RFC3168 full functionality mode reset it. However, all
1060 other things being equal, if RFC3168 ingress is updated to the
1061 present specification, the outgoing packets from any tunnel egress
1062 will still be unchanged. This is because all variants of tunnelling
1063 at either end (RFC4301, both modes of RFC3168, both modes of RFC2481,
1064 RFC2401, RFC2003 and the present specification) have always
1065 propagated an incoming CE marking through the inner header and onward
1066 into the outgoing header, whether the outer header is reset or
1067 copied. Therefore, If the tunnel is considered as a black box, the
1068 packets output from any egress will be identical with or without an
1069 update to the ingress. Nonetheless, if packets are observed within
1070 the black box (between the tunnel endpoints), CE markings copied by
1071 the updated ingress will be visible within the black box, whereas
1072 they would not have been before. Therefore, the update to
1073 encapsulation can be termed 'black-box backwards compatible' (i.e.
1074 identical unless you look inside the tunnel).
1076 This specification introduces no new backward compatibility issues
1077 when a compliant ingress talks with a legacy egress, but it has to
1078 provide similar safeguards to those already defined in RFC3168.
1079 RFC3168 laid down rules to ensure that an RFC3168 ingress turns off
1080 ECN (limited functionality mode) if it is paired with a legacy egress
1081 (RFC 2481, RFC2401 or RFC2003), which would not propagate ECN
1082 correctly. The present specification carries forward those rules
1083 (Section 4.3). It uses compatibility mode whenever RFC3168 would
1084 have used limited functionality mode, and their per-packet behaviours
1085 are identical. Therefore, all other things being equal, an ingress
1086 using the new rules will interwork with any legacy tunnel egress in
1087 exactly the same way as an RFC3168 ingress (still black-box backward
1088 compatible).
1090 7. Design Principles for Future Non-Default Schemes
1092 This section is informative not normative.
1094 S.5 of RFC3168 permits the Diffserv codepoint (DSCP)[RFC2474] to
1095 'switch in' alternative behaviours for marking the ECN field, just as
1096 it switches in different per-hop behaviours (PHBs) for scheduling.
1097 [RFC4774] gives best current practice for designing such alternative
1098 ECN semantics and very briefly mentions that tunnelling should be
1099 considered. Here we give additional guidance on designing alternate
1100 ECN semantics that would also require alternate tunnelling semantics.
1102 In one word the guidance is "Don't". If a scheme requires tunnels to
1103 implement special processing of the ECN field for certain DSCPs, it
1104 is highly unlikely that every implementer of every tunnel will want
1105 to add the required exception and that operators will want to deploy
1106 the required configuration options. Therefore it is highly likely
1107 that some tunnels within a network will not implement the required
1108 special case. Therefore, designers of new protocols should avoid
1109 non-default tunnelling schemes if at all possible.
1111 That said, if a non-default scheme for tunnelling the ECN field is
1112 really required, the following guidelines may prove useful in its
1113 design:
1115 On encapsulation in any new scheme:
1117 1. The ECN field of the outer header should be cleared to Not-ECT
1118 ("00") unless it is guaranteed that the corresponding tunnel
1119 egress will correctly propagate congestion markings introduced
1120 across the tunnel in the outer header.
1122 2. If it has established that ECN will be correctly propagated,
1123 an encapsulator should also copy incoming congestion
1124 notification into the outer header. The general principle
1125 here is that the outer header should reflect congestion
1126 accumulated along the whole upstream path, not just since the
1127 tunnel ingress (Appendix B.3 on management and monitoring
1128 explains).
1130 In some circumstances (e.g. pseudowires, PCN), the whole path
1131 is divided into segments, each with its own congestion
1132 notification and feedback loop. In these cases, the function
1133 that regulates load at the start of each segment will need to
1134 reset congestion notification for its segment. Often the
1135 point where congestion notification is reset will also be
1136 located at the start of a tunnel. However, the resetting
1137 function should be thought of as being applied to packets
1138 after the encapsulation function--two logically separate
1139 functions even though they might run on the same physical box.
1140 Then the code module doing encapsulation can keep to the
1141 copying rule and the load regulator module can reset
1142 congestion, without any code in either module being
1143 conditional on whether the other is there.
1145 On decapsulation in any new scheme:
1147 1. If the arriving inner header is Not-ECT it implies the
1148 transport will not understand other ECN codepoints. If the
1149 outer header carries an explicit congestion marking, the
1150 packet should be dropped--the only indication of congestion
1151 the transport will understand. If the outer carries any other
1152 ECN codepoint the packet can be forwarded, but only as Not-
1153 ECT.
1155 2. If the arriving inner header is other than Not-ECT, the ECN
1156 field that the tunnel egress forwards should reflect the more
1157 severe congestion marking of the arriving inner and outer
1158 headers.
1160 3. If a combination of inner and outer headers is encountered
1161 that is not currently used in known standards, this event
1162 should be logged and an alarm raised. This is a preferable
1163 approach to dropping currently unused combinations in case
1164 they represent an attack. The new scheme should try to define
1165 a way to forward such packets, but only if a safe outgoing
1166 codepoint can be defined.
1168 8. IANA Considerations
1170 This memo includes no request to IANA.
1172 9. Security Considerations
1174 Appendix B.1 discusses the security constraints imposed on ECN tunnel
1175 processing. The new rules for ECN tunnel processing (Section 4)
1176 trade-off between information security (covert channels) and
1177 congestion monitoring & control. In fact, ensuring congestion
1178 markings are not lost is itself another aspect of security, because
1179 if we allowed congestion notification to be lost, any attempt to
1180 enforce a response to congestion would be much harder.
1182 Specialist security issues:
1184 Tunnels intersecting Diffserv regions with alternate ECN semantics:
1185 If alternate congestion notification semantics are defined for a
1186 certain Diffserv PHB, the scope of the alternate semantics might
1187 typically be bounded by the limits of a Diffserv region or
1188 regions, as envisaged in [RFC4774] (e.g. the pre-congestion
1189 notification architecture [RFC5559]). The inner headers in
1190 tunnels crossing the boundary of such a Diffserv region but ending
1191 within the region can potentially leak the external congestion
1192 notification semantics into the region, or leak the internal
1193 semantics out of the region. [RFC2983] discusses the need for
1194 Diffserv traffic conditioning to be applied at these tunnel
1195 endpoints as if they are at the edge of the Diffserv region.
1196 Similar concerns apply to any processing or propagation of the ECN
1197 field at the edges of a Diffserv region with alternate ECN
1198 semantics. Such edge processing must also be applied at the
1199 endpoints of tunnels with one end inside and the other outside the
1200 domain. [RFC5559] gives specific advice on this for the PCN case,
1201 but other definitions of alternate semantics will need to discuss
1202 the specific security implications in each case.
1204 ECN nonce tunnel coverage: The new decapsulation rules improve the
1205 coverage of the ECN nonce [RFC3540] relative to the previous rules
1206 in RFC3168 and RFC4301. However, nonce coverage is still not
1207 perfect, as this would have led to a safety problem in another
1208 case. Both are corner-cases, so discussion of the compromise
1209 between them is deferred to Appendix F.
1211 Covert channel not turned off: A legacy (RFC3168) tunnel ingress
1212 could ask an RFC3168 egress to turn off ECN processing as well as
1213 itself turning off ECN. An egress compliant with the present
1214 specification will agree to such a request from a legacy ingress,
1215 but it relies on the ingress solely sending Not-ECT in the outer.
1216 If the egress receives other ECN codepoints in the outer it will
1217 process them as normal, so it will actually still copy congestion
1218 markings from the outer to the outgoing header. Referring for
1219 example to Figure 5 (Appendix B.1), although the tunnel ingress
1220 'I' will set all ECN fields in outer headers to Not-ECT, 'M' could
1221 still toggle CE or ECT(1) on and off to communicate covertly with
1222 'B', because we have specified that 'E' only has one mode
1223 regardless of what mode it says it has negotiated. We could have
1224 specified that 'E' should have a limited functionality mode and
1225 check for such behaviour. But we decided not to add the extra
1226 complexity of two modes on a compliant tunnel egress merely to
1227 cater for an historic security concern that is now considered
1228 manageable.
1230 10. Conclusions
1232 This document uses previously unused combinations of inner and outer
1233 header to augment the rules for calculating the ECN field when
1234 decapsulating IP packets at the egress of IPsec (RFC4301) and non-
1235 IPsec (RFC3168) tunnels. In this way it allows tunnels to propagate
1236 an extra level of congestion severity.
1238 This document also updates the ingress tunnelling encapsulation of
1239 RFC3168 ECN to bring all IP in IP tunnels into line with the new
1240 behaviour in the IPsec architecture of RFC4301, which copies rather
1241 than resets the ECN field when creating outer headers.
1243 The need for both these updated behaviours was triggered by the
1244 introduction of pre-congestion notification (PCN) onto the IETF
1245 standards track. Operators wanting to support PCN or other alternate
1246 ECN schemes that use an extra severity level can require that their
1247 tunnels comply with the present specification. Nonetheless, as part
1248 of general code maintenance, any tunnel can safely be updated to
1249 comply with this specification, because it is backward compatible
1250 with all previous tunnelling behaviours which will continue to work
1251 as before--just using one severity level.
1253 The new rules propagate changes to the ECN field across tunnel end-
1254 points that previously blocked them to restrict the bandwidth of a
1255 potential covert channel. But limiting the channel's bandwidth to 2
1256 bits per packet is now considered sufficient.
1258 At the same time as removing these legacy constraints, the
1259 opportunity has been taken to draw together diverging tunnel
1260 specifications into a single consistent behaviour. Then any tunnel
1261 can be deployed unilaterally, and it will support the full range of
1262 congestion control and management schemes without any modes or
1263 configuration. Further, any host or router can expect the ECN field
1264 to behave in the same way, whatever type of tunnel might intervene in
1265 the path. This new certainty could enable new uses of the ECN field
1266 that would otherwise be confounded by ambiguity.
1268 11. Acknowledgements
1270 Thanks to Anil Agawaal for pointing out a case where it's safe for a
1271 tunnel decapsulator to forward a combination of headers it does not
1272 understand. Thanks to David Black for explaining a better way to
1273 think about function placement. Also thanks to Arnaud Jacquet for
1274 the idea for Appendix C. Thanks to Michael Menth, Bruce Davie, Toby
1275 Moncaster, Gorry Fairhurst, Sally Floyd, Alfred Hoenes, Gabriele
1276 Corliano, Ingemar Johansson and David Black for their thoughts and
1277 careful review comments.
1279 Bob Briscoe is partly funded by Trilogy, a research project (ICT-
1280 216372) supported by the European Community under its Seventh
1281 Framework Programme. The views expressed here are those of the
1282 author only.
1284 12. Comments Solicited
1286 Comments and questions are encouraged and very welcome. They can be
1287 addressed to the IETF Transport Area working group mailing list
1288 , and/or to the authors.
1290 13. References
1291 13.1. Normative References
1293 [RFC2003] Perkins, C., "IP Encapsulation
1294 within IP", RFC 2003, October 1996.
1296 [RFC2119] Bradner, S., "Key words for use in
1297 RFCs to Indicate Requirement
1298 Levels", BCP 14, RFC 2119,
1299 March 1997.
1301 [RFC3168] Ramakrishnan, K., Floyd, S., and D.
1302 Black, "The Addition of Explicit
1303 Congestion Notification (ECN) to
1304 IP", RFC 3168, September 2001.
1306 [RFC4301] Kent, S. and K. Seo, "Security
1307 Architecture for the Internet
1308 Protocol", RFC 4301, December 2005.
1310 13.2. Informative References
1312 [I-D.ietf-pcn-3-in-1-encoding] Briscoe, B. and T. Moncaster, "PCN
1313 3-State Encoding Extension in a
1314 single DSCP",
1315 draft-ietf-pcn-3-in-1-encoding-00
1316 (work in progress), July 2009.
1318 [I-D.ietf-pcn-3-state-encoding] Moncaster, T., Briscoe, B., and M.
1319 Menth, "A PCN encoding using 2
1320 DSCPs to provide 3 or more states",
1321 draft-ietf-pcn-3-state-encoding-00
1322 (work in progress), April 2009.
1324 [I-D.ietf-pcn-baseline-encoding] Moncaster, T., Briscoe, B., and M.
1325 Menth, "Baseline Encoding and
1326 Transport of Pre-Congestion
1327 Information",
1328 draft-ietf-pcn-baseline-encoding-04
1329 (work in progress), May 2009.
1331 [I-D.ietf-pcn-marking-behaviour] Eardley, P., "Metering and marking
1332 behaviour of PCN-nodes",
1333 draft-ietf-pcn-marking-behaviour-04
1334 (work in progress), June 2009.
1336 [I-D.ietf-pcn-psdm-encoding] Menth, M., Babiarz, J., Moncaster,
1337 T., and B. Briscoe, "PCN Encoding
1338 for Packet-Specific Dual Marking
1339 (PSDM)",
1340 draft-ietf-pcn-psdm-encoding-00
1341 (work in progress), June 2009.
1343 [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., Menth,
1344 M., and T. Taylor, "PCN Boundary
1345 Node Behaviour for the Single
1346 Marking (SM) Mode of Operation",
1347 draft-ietf-pcn-sm-edge-behaviour-00
1348 (work in progress), July 2009.
1350 [I-D.satoh-pcn-st-marking] Satoh, D., Maeda, Y., Phanachet,
1351 O., and H. Ueno, "Single PCN
1352 Threshold Marking by using PCN
1353 baseline encoding for both
1354 admission and termination
1355 controls",
1356 draft-satoh-pcn-st-marking-01 (work
1357 in progress), March 2009.
1359 [RFC2401] Kent, S. and R. Atkinson, "Security
1360 Architecture for the Internet
1361 Protocol", RFC 2401, November 1998.
1363 [RFC2474] Nichols, K., Blake, S., Baker, F.,
1364 and D. Black, "Definition of the
1365 Differentiated Services Field (DS
1366 Field) in the IPv4 and IPv6
1367 Headers", RFC 2474, December 1998.
1369 [RFC2481] Ramakrishnan, K. and S. Floyd, "A
1370 Proposal to add Explicit Congestion
1371 Notification (ECN) to IP",
1372 RFC 2481, January 1999.
1374 [RFC2983] Black, D., "Differentiated Services
1375 and Tunnels", RFC 2983,
1376 October 2000.
1378 [RFC3540] Spring, N., Wetherall, D., and D.
1379 Ely, "Robust Explicit Congestion
1380 Notification (ECN) Signaling with
1381 Nonces", RFC 3540, June 2003.
1383 [RFC4306] Kaufman, C., "Internet Key Exchange
1384 (IKEv2) Protocol", RFC 4306,
1385 December 2005.
1387 [RFC4774] Floyd, S., "Specifying Alternate
1388 Semantics for the Explicit
1389 Congestion Notification (ECN)
1390 Field", BCP 124, RFC 4774,
1391 November 2006.
1393 [RFC5129] Davie, B., Briscoe, B., and J. Tay,
1394 "Explicit Congestion Marking in
1395 MPLS", RFC 5129, January 2008.
1397 [RFC5559] Eardley, P., "Pre-Congestion
1398 Notification (PCN) Architecture",
1399 RFC 5559, June 2009.
1401 [VCP] Xia, Y., Subramanian, L., Stoica,
1402 I., and S. Kalyanaraman, "One more
1403 bit is enough", Proc. SIGCOMM'05,
1404 ACM CCR 35(4)37--48, 2005, .
1408 Appendix A. Early ECN Tunnelling RFCs
1410 IP in IP tunnelling was originally defined in [RFC2003]. On
1411 encapsulation, the incoming header was copied to the outer and on
1412 decapsulation the outer was simply discarded. Initially, IPsec
1413 tunnelling [RFC2401] followed the same behaviour.
1415 When ECN was introduced experimentally in [RFC2481], legacy (RFC2003
1416 or RFC2401) tunnels would have discarded any congestion markings
1417 added to the outer header, so RFC2481 introduced rules for
1418 calculating the outgoing header from a combination of the inner and
1419 outer on decapsulation. RC2481 also introduced a second mode for
1420 IPsec tunnels, which turned off ECN processing in the outer header
1421 (Not-ECT) on encapsulation because an RFC2401 decapsulator would
1422 discard the outer on decapsulation. For RFC2401 IPsec this had the
1423 side-effect of completely blocking the covert channel.
1425 In RFC2481 the ECN field was defined as two separate bits. But when
1426 ECN moved from the experimental to the standards track [RFC3168], the
1427 ECN field was redefined as four codepoints. This required a
1428 different calculation of the ECN field from that used in RFC2481 on
1429 decapsulation. RFC3168 also had two modes; a 'full functionality
1430 mode' that restricted the covert channel as much as possible but
1431 still allowed ECN to be used with IPsec, and another that completely
1432 turned off ECN processing across the tunnel. This 'limited
1433 functionality mode' both offered a way for operators to completely
1434 block the covert channel and allowed an RFC3168 ingress to interwork
1435 with a legacy tunnel egress (RFC2481, RFC2401 or RFC2003).
1437 The present specification includes a similar compatibility mode to
1438 interwork safely with tunnels compliant with any of these three
1439 earlier RFCs. However, unlike RFC3168, it is only a mode of the
1440 ingress, as decapsulation behaviour is the same in either case.
1442 Appendix B. Design Constraints
1444 Tunnel processing of a congestion notification field has to meet
1445 congestion control and management needs without creating new
1446 information security vulnerabilities (if information security is
1447 required). This appendix documents the analysis of the tradeoffs
1448 between these factors that led to the new encapsulation rules in
1449 Section 4.1.
1451 B.1. Security Constraints
1453 Information security can be assured by using various end to end
1454 security solutions (including IPsec in transport mode [RFC4301]), but
1455 a commonly used scenario involves the need to communicate between two
1456 physically protected domains across the public Internet. In this
1457 case there are certain management advantages to using IPsec in tunnel
1458 mode solely across the publicly accessible part of the path. The
1459 path followed by a packet then crosses security 'domains'; the ones
1460 protected by physical or other means before and after the tunnel and
1461 the one protected by an IPsec tunnel across the otherwise unprotected
1462 domain. We will use the scenario in Figure 5 where endpoints 'A' and
1463 'B' communicate through a tunnel. The tunnel ingress 'I' and egress
1464 'E' are within physically protected edge domains, while the tunnel
1465 spans an unprotected internetwork where there may be 'men in the
1466 middle', M.
1468 physically unprotected physically
1469 <-protected domain-><--domain--><-protected domain->
1470 +------------------+ +------------------+
1471 | | M | |
1472 | A-------->I=========>==========>E-------->B |
1473 | | | |
1474 +------------------+ +------------------+
1475 <----IPsec secured---->
1476 tunnel
1478 Figure 5: IPsec Tunnel Scenario
1480 IPsec encryption is typically used to prevent 'M' seeing messages
1481 from 'A' to 'B'. IPsec authentication is used to prevent 'M'
1482 masquerading as the sender of messages from 'A' to 'B' or altering
1483 their contents. But 'I' can also use IPsec tunnel mode to allow 'A'
1484 to communicate with 'B', but impose encryption to prevent 'A' leaking
1485 information to 'M'. Or 'E' can insist that 'I' uses tunnel mode
1486 authentication to prevent 'M' communicating information to 'B'.
1487 Mutable IP header fields such as the ECN field (as well as the TTL/
1488 Hop Limit and DS fields) cannot be included in the cryptographic
1489 calculations of IPsec. Therefore, if 'I' copies these mutable fields
1490 into the outer header that is exposed across the tunnel it will have
1491 allowed a covert channel from 'A' to M that bypasses its encryption
1492 of the inner header. And if 'E' copies these fields from the outer
1493 header to the inner, even if it validates authentication from 'I', it
1494 will have allowed a covert channel from 'M' to 'B'.
1496 ECN at the IP layer is designed to carry information about congestion
1497 from a congested resource towards downstream nodes. Typically a
1498 downstream transport might feed the information back somehow to the
1499 point upstream of the congestion that can regulate the load on the
1500 congested resource, but other actions are possible (see [RFC3168]
1501 S.6). In terms of the above unicast scenario, ECN effectively
1502 intends to create an information channel (for congestion signalling)
1503 from 'M' to 'B' (for 'B' to feed back to 'A'). Therefore the goals
1504 of IPsec and ECN are mutually incompatible.
1506 With respect to the DS or ECN fields, S.5.1.2 of RFC4301 says,
1507 "controls are provided to manage the bandwidth of this [covert]
1508 channel". Using the ECN processing rules of RFC4301, the channel
1509 bandwidth is two bits per datagram from 'A' to 'M' and one bit per
1510 datagram from 'M' to 'A' (because 'E' limits the combinations of the
1511 2-bit ECN field that it will copy). In both cases the covert channel
1512 bandwidth is further reduced by noise from any real congestion
1513 marking. RFC4301 implies that these covert channels are sufficiently
1514 limited to be considered a manageable threat. However, with respect
1515 to the larger (6b) DS field, the same section of RFC4301 says not
1516 copying is the default, but a configuration option can allow copying
1517 "to allow a local administrator to decide whether the covert channel
1518 provided by copying these bits outweighs the benefits of copying".
1519 Of course, an administrator considering copying of the DS field has
1520 to take into account that it could be concatenated with the ECN field
1521 giving an 8b per datagram covert channel.
1523 For tunnelling the 6b Diffserv field two conceptual models have had
1524 to be defined so that administrators can trade off security against
1525 the needs of traffic conditioning [RFC2983]:
1527 The uniform model: where the Diffserv field is preserved end-to-end
1528 by copying into the outer header on encapsulation and copying from
1529 the outer header on decapsulation.
1531 The pipe model: where the outer header is independent of that in the
1532 inner header so it hides the Diffserv field of the inner header
1533 from any interaction with nodes along the tunnel.
1535 However, for ECN, the new IPsec security architecture in RFC4301 only
1536 standardised one tunnelling model equivalent to the uniform model.
1537 It deemed that simplicity was more important than allowing
1538 administrators the option of a tiny increment in security, especially
1539 given not copying congestion indications could seriously harm
1540 everyone's network service.
1542 B.2. Control Constraints
1544 Congestion control requires that any congestion notification marked
1545 into packets by a resource will be able to traverse a feedback loop
1546 back to a function capable of controlling the load on that resource.
1547 To be precise, rather than calling this function the data source, we
1548 will call it the Load Regulator. This will allow us to deal with
1549 exceptional cases where load is not regulated by the data source, but
1550 usually the two terms will be synonymous. Note the term "a function
1551 _capable of_ controlling the load" deliberately includes a source
1552 application that doesn't actually control the load but ought to (e.g.
1553 an application without congestion control that uses UDP).
1555 A--->R--->I=========>M=========>E-------->B
1557 Figure 6: Simple Tunnel Scenario
1559 We now consider a similar tunnelling scenario to the IPsec one just
1560 described, but without the different security domains so we can just
1561 focus on ensuring the control loop and management monitoring can work
1562 (Figure 6). If we want resources in the tunnel to be able to
1563 explicitly notify congestion and the feedback path is from 'B' to
1564 'A', it will certainly be necessary for 'E' to copy any CE marking
1565 from the outer header to the inner header for onward transmission to
1566 'B', otherwise congestion notification from resources like 'M' cannot
1567 be fed back to the Load Regulator ('A'). But it does not seem
1568 necessary for 'I' to copy CE markings from the inner to the outer
1569 header. For instance, if resource 'R' is congested, it can send
1570 congestion information to 'B' using the congestion field in the inner
1571 header without 'I' copying the congestion field into the outer header
1572 and 'E' copying it back to the inner header. 'E' can still write any
1573 additional congestion marking introduced across the tunnel into the
1574 congestion field of the inner header.
1576 It might be useful for the tunnel egress to be able to tell whether
1577 congestion occurred across a tunnel or upstream of it. If outer
1578 header congestion marking was reset by the tunnel ingress ('I'), at
1579 the end of a tunnel ('E') the outer headers would indicate congestion
1580 experienced across the tunnel ('I' to 'E'), while the inner header
1581 would indicate congestion upstream of 'I'. But similar information
1582 can be gleaned even if the tunnel ingress copies the inner to the
1583 outer headers. At the end of the tunnel ('E'), any packet with an
1584 _extra_ mark in the outer header relative to the inner header
1585 indicates congestion across the tunnel ('I' to 'E'), while the inner
1586 header would still indicate congestion upstream of ('I'). Appendix C
1587 gives a simple and precise method for a tunnel egress to infer the
1588 congestion level introduced across a tunnel.
1590 All this shows that 'E' can preserve the control loop irrespective of
1591 whether 'I' copies congestion notification into the outer header or
1592 resets it.
1594 That is the situation for existing control arrangements but, because
1595 copying reveals more information, it would open up possibilities for
1596 better control system designs. For instance, Appendix E describes
1597 how resetting CE marking on encapsulation breaks a proposed
1598 congestion marking scheme on the standards track. It ends up
1599 removing excessive amounts of traffic unnecessarily. Whereas copying
1600 CE markings at ingress leads to the correct control behaviour.
1602 B.3. Management Constraints
1604 As well as control, there are also management constraints.
1605 Specifically, a management system may monitor congestion markings in
1606 passing packets, perhaps at the border between networks as part of a
1607 service level agreement. For instance, monitors at the borders of
1608 autonomous systems may need to measure how much congestion has
1609 accumulated so far along the path, perhaps to determine between them
1610 how much of the congestion is contributed by each domain.
1612 In this document we define the baseline of congestion marking (or the
1613 Congestion Baseline) as the source of the layer that created (or most
1614 recently reset) the congestion notification field. When monitoring
1615 congestion it would be desirable if the Congestion Baseline did not
1616 depend on whether packets were tunnelled or not. Given some tunnels
1617 cross domain borders (e.g. consider M in Figure 6 is monitoring a
1618 border), it would therefore be desirable for 'I' to copy congestion
1619 accumulated so far into the outer headers, so that it is exposed
1620 across the tunnel.
1622 Appendix C. Contribution to Congestion across a Tunnel
1624 This specification mandates that a tunnel ingress determines the ECN
1625 field of each new outer tunnel header by copying the arriving header.
1626 Concern has been expressed that this will make it difficult for the
1627 tunnel egress to monitor congestion introduced only along a tunnel,
1628 which is easy if the outer ECN field is reset at a tunnel ingress
1629 (RFC3168 full functionality mode). However, in fact copying CE marks
1630 at ingress will still make it easy for the egress to measure
1631 congestion introduced across a tunnel, as illustrated below.
1633 Consider 100 packets measured at the egress. Say it measures that 30
1634 are CE marked in the inner and outer headers and 12 have additional
1635 CE marks in the outer but not the inner. This means packets arriving
1636 at the ingress had already experienced 30% congestion. However, it
1637 does not mean there was 12% congestion across the tunnel. The
1638 correct calculation of congestion across the tunnel is p_t = 12/
1639 (100-30) = 12/70 = 17%. This is easy for the egress to measure. It
1640 is simply the packets with additional CE marking in the outer header
1641 (12) as a proportion of packets not marked in the inner header (70).
1643 Figure 7 illustrates this in a combinatorial probability diagram.
1644 The square represents 100 packets. The 30% division along the bottom
1645 represents marking before the ingress, and the p_t division up the
1646 side represents marking introduced across the tunnel.
1648 ^ outer header marking
1649 |
1650 100% +-----+---------+ The large square
1651 | | | represents 100 packets
1652 | 30 | |
1653 | | | p_t = 12/(100-30)
1654 p_t + +---------+ = 12/70
1655 | | 12 | = 17%
1656 0 +-----+---------+--->
1657 0 30% 100% inner header marking
1659 Figure 7: Tunnel Marking of Packets Already Marked at Ingress
1661 Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN
1663 Congestion notification with two severity levels is currently on the
1664 IETF's standards track agenda in the Congestion and Pre-Congestion
1665 Notification (PCN) working group. The PCN working group requires
1666 four congestion states (not PCN-enabled, not marked and two
1667 increasingly severe levels of congestion marking--see [RFC5559]).
1668 The aim is for the less severe level of marking to stop admitting new
1669 traffic and the more severe level to terminate sufficient existing
1670 flows to bring a network back to its operating point after a link
1671 failure.
1673 (Note on terminology: wherever this document counts four congestion
1674 states, the PCN working group would count this as three PCN states
1675 plus a not-PCN-enabled state.)
1677 Although the ECN field gives sufficient codepoints for four states,
1678 pre-existing ECN tunnelling RFCs prevented the PCN working group from
1679 using four ECN states in case any tunnel decapsulations occur within
1680 a PCN region. If a node in a tunnel changes the ECN field to ECT(0)
1681 or ECT(1), this change would be discarded by a tunnel egress
1682 compliant with RFC4301 or RFC3168. This can be seen in Figure 2
1683 (Section 3.2), where ECT values in the outer header are ignored
1684 unless the inner header is the same. Effectively the decapsulation
1685 rules of RFC4301 and RFC3168 waste one ECT codepoint; they treat the
1686 ECT(0) and ECT(1) codepoints as a single codepoint.
1688 As a consequence, the PCN w-g initially took the approach of a
1689 standards track baseline encoding for three states
1690 [I-D.ietf-pcn-baseline-encoding] and a number of experimental
1691 alternatives to add or avoid the fourth state. Without wishing to
1692 disparage the ingenuity of these work-rounds, none were chosen for
1693 the standards track because they were either somewhat wasteful,
1694 imprecise or complicated. One uses a pair of Diffserv codepoint(s)
1695 in place of each PCN DSCP to encode the extra state
1696 [I-D.ietf-pcn-3-state-encoding], using up the rapidly exhausting DSCP
1697 space while leaving an ECN codepoint unused. Another PCN encoding
1698 has been proposed that would survive tunnelling without an extra DSCP
1699 [I-D.ietf-pcn-psdm-encoding], but it requires the PCN edge gateways
1700 to share state out of band so the egress edge can know which marking
1701 a packet started with at the ingress edge. Yet another work-round to
1702 the ECN tunnelling problem proposes a more involved marking algorithm
1703 in forwarding elements to encode the three congestion notification
1704 states using only two ECN codepoints [I-D.satoh-pcn-st-marking]. One
1705 work-round takes a different approach; it compromises the precision
1706 of the admission control mechanism in some network scenarios, but
1707 manages to work with just three encoding states and a single marking
1708 algorithm [I-D.ietf-pcn-sm-edge-behaviour].
1710 Rather than require the IETF to bless any of these experimental
1711 encoding work-rounds, the present specification fixes the root cause
1712 of the problem so that operators deploying PCN can simply require
1713 that tunnel end-points within a PCN region should comply with this
1714 new ECN tunnelling specification. Universal compliance is feasible
1715 for PCN, because it is intended to be deployed in a controlled
1716 Diffserv region. Assuming tunnels within a PCN region will be
1717 required to comply with the present specification, the PCN w-g is
1718 progressing a trivially simple four-state ECN encoding
1719 [I-D.ietf-pcn-3-in-1-encoding].
1721 Appendix E. Why Resetting ECN on Encapsulation Impedes PCN
1723 The PCN architecture says "...if encapsulation is done within the
1724 PCN-domain: Any PCN-marking is copied into the outer header. Note: A
1725 tunnel will not provide this behaviour if it complies with [RFC3168]
1726 tunnelling in either mode, but it will if it complies with [RFC4301]
1727 IPsec tunnelling. "
1729 The specific issue here concerns PCN excess rate marking
1730 [I-D.ietf-pcn-marking-behaviour]. The purpose of excess rate marking
1731 is to provide a bulk mechanism for interior nodes within a PCN domain
1732 to mark traffic that is exceeding a configured threshold bit-rate,
1733 perhaps after an unexpected event such as a reroute, a link or node
1734 failure, or a more widespread disaster. PCN is intended for
1735 inelastic flows, so just removing marked packets would degrade every
1736 flow to the point of uselessness. Instead, the edge nodes around a
1737 PCN domain terminate an equivalent amount of traffic, but at flow
1738 granularity. As well as protecting the surviving inelastic flows,
1739 this also protects the share of capacity set aside for elastic
1740 traffic. But users are very sensitive to their flows being
1741 terminated while in progress, therefore no more flows should be
1742 terminated than absolutely necessary.
1744 Re-routes are a common cause of QoS degradation in IP networks.
1745 After re-routes it is common for multiple links in a network to
1746 become stressed at once. Therefore, PCN excess rate marking has been
1747 carefully designed to ensure traffic marked at one queue will not be
1748 counted again for marking at subsequent queues (see the `Excess
1749 traffic meter function' of [I-D.ietf-pcn-marking-behaviour]).
1751 However, if an RFC3168 tunnel ingress intervenes, it resets the ECN
1752 field in all the outer headers. This will cause excess traffic to be
1753 counted more than once, leading to many flows being removed that did
1754 not need to be removed at all. This is why the an RFC3168 tunnel
1755 ingress cannot be used in a PCN domain.
1757 The original reason an RFC3168 encapsulator reset the ECN field was
1758 to block a covert channel (Appendix B.1), with the overriding aim of
1759 consistent behaviour between IPsec and non-IPsec tunnels. But later
1760 RFC4301 IPsec encapsulation placed simplicity above the need to block
1761 the covert channel, simply copying the ECN field.
1763 The ECN reset in RFC3168 is no longer deemed necessary, it is
1764 inconsistent with RFC4301, it is not as simple as RFC4301 and it is
1765 impeding deployment of new protocols like PCN. The present
1766 specification corrects this perverse situation.
1768 Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0) Outer
1770 A packet with an ECT(1) inner and an ECT(0) outer should never arise
1771 from any known IETF protocol. Without giving a reason, RFC3168 and
1772 RFC4301 both say the outer should be ignored when decapsulating such
1773 a packet. This appendix explains why it was decided not to change
1774 this advice.
1776 In summary, ECT(0) always means 'not congested' and ECT(1) may imply
1777 the same [RFC3168] or it may imply a higher severity congestion
1778 signal [RFC4774], [I-D.ietf-pcn-3-in-1-encoding], depending on the
1779 transport in use. Whether they mean the same or not, at the ingress
1780 the outer should have started the same as the inner and only a broken
1781 or compromised router could have changed the outer to ECT(0).
1783 The decapsulator can detect this anomaly. But the question is,
1784 should it correct the anomaly by ignoring the outer, or should it
1785 reveal the anomaly to the end-to-end transport by forwarding the
1786 outer?
1788 On balance, it was decided that the decapsulator should correct the
1789 anomaly, but log the event and optionally raise an alarm. This is
1790 the safe action if ECT(1) is being used as a more severe marking than
1791 ECT(0), because it passes the more severe signal to the transport.
1792 However, it is not a good idea to hide anomalies, which is why an
1793 optional alarm is suggested. It should be noted that this anomaly
1794 may be the result of two changes to the outer: a broken or
1795 compromised router within the tunnel might be erasing congestion
1796 markings introduced earlier in the same tunnel by a congested router.
1797 In this case, the anomaly would be losing congestion signals, which
1798 needs immediate attention.
1800 The original reason for defining ECT(0) and ECT(1) as equivalent was
1801 so that the data source could use the ECN nonce [RFC3540] to detect
1802 if congestion signals were being erased. However, in this case, the
1803 decapsulator does not need a nonce to detect any anomalies introduced
1804 within the tunnel, because it has the inner as a record of the header
1805 at the ingress. Therefore, it was decided that the best compromise
1806 would be to give precedence to solving the safety issue over
1807 revealing the anomaly, because the anomaly could at least be detected
1808 and dealt with internally.
1810 Superficially, the opposite case where the inner and outer carry
1811 different ECT values, but with an ECT(1) outer and ECT(0) inner seems
1812 to require a similar compromise. However, because that case is
1813 reversed, no compromise is necessary; it is best to forward the outer
1814 whether the transport expects the ECT(1) to mean a higher severity
1815 than ECT(0) or the same severity. Forwarding the outer either
1816 preserves a higher value (if it is higher) or it reveals an anomaly
1817 to the transport (if the two ECT codepoints mean the same severity).
1819 Author's Address
1821 Bob Briscoe
1822 BT
1823 B54/77, Adastral Park
1824 Martlesham Heath
1825 Ipswich IP5 3RE
1826 UK
1828 Phone: +44 1473 645196
1829 EMail: bob.briscoe@bt.com
1830 URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/