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