< draft-ietf-tsvwg-ecn-tunnel-08.txt   draft-ietf-tsvwg-ecn-tunnel-09b.txt >
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft BT Internet-Draft BT
Updates: 3168, 4301 March 03, 2010 Updates: 3168, 4301 June 25, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 4, 2010 Expires: December 27, 2010
Tunnelling of Explicit Congestion Notification Tunnelling of Explicit Congestion Notification
draft-ietf-tsvwg-ecn-tunnel-08 draft-ietf-tsvwg-ecn-tunnel-09
Abstract Abstract
This document redefines how the explicit congestion notification This document redefines how the explicit congestion notification
(ECN) field of the IP header should be constructed on entry to and (ECN) field of the IP header should be constructed on entry to and
exit from any IP in IP tunnel. On encapsulation it updates RFC3168 exit from any IP in IP tunnel. On encapsulation it updates RFC3168
to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec
ECN processing. On decapsulation it updates both RFC3168 and RFC4301 ECN processing. On decapsulation it updates both RFC3168 and RFC4301
to add new behaviours for previously unused combinations of inner and to add new behaviours for previously unused combinations of inner and
outer header. The new rules ensure the ECN field is correctly outer header. The new rules ensure the ECN field is correctly
propagated across a tunnel whether it is used to signal one or two propagated across a tunnel whether it is used to signal one or two
severity levels of congestion, whereas before only one severity level severity levels of congestion, whereas before only one severity level
was supported. Tunnel endpoints can be updated in any order without was supported. Tunnel endpoints can be updated in any order without
affecting pre-existing uses of the ECN field, providing backward affecting pre-existing uses of the ECN field, thus ensuring backward
compatibility. Nonetheless, operators wanting to support two compatibility. Nonetheless, operators wanting to support two
severity levels (e.g. for pre-congestion notification--PCN) can severity levels (e.g. for pre-congestion notification--PCN) can
require compliance with this new specification. A thorough analysis require compliance with this new specification. A thorough analysis
of the reasoning for these changes and the implications is included. of the reasoning for these changes and the implications is included.
In the unlikely event that the new rules do not meet a specific need, In the unlikely event that the new rules do not meet a specific need,
RFC4774 gives guidance on designing alternate ECN semantics and this RFC4774 gives guidance on designing alternate ECN semantics and this
document extends that to include tunnelling issues. document extends that to include tunnelling issues.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 27, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 12 3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 13
3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 12 3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 13
3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 13 3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 14
4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 14 4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 15
4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 15 4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 16
4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 15 4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 16
4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 17 4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 18
4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 19 4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 20
5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 20 5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 21
5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 20 5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 21
5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 20 5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 21
5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 22 5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 22
5.3.1. Motivation for Changing Encapsulation . . . . . . . . 22 5.3.1. Motivation for Changing Encapsulation . . . . . . . . 23
5.3.2. Motivation for Changing Decapsulation . . . . . . . . 23 5.3.2. Motivation for Changing Decapsulation . . . . . . . . 24
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 25 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 26
6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 25 6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 26
6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 26 6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 27
6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 26 6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 27
7. Design Principles for Alternate ECN Tunnelling Semantics . . . 27 7. Design Principles for Alternate ECN Tunnelling Semantics . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . . 33
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 34 Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 34
Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 35 Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 35
B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 35 B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 35
B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 37 B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 37
B.3. Management Constraints . . . . . . . . . . . . . . . . . . 38 B.3. Management Constraints . . . . . . . . . . . . . . . . . . 38
Appendix C. Contribution to Congestion across a Tunnel . . . . . 39 Appendix C. Contribution to Congestion across a Tunnel . . . . . 39
Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0)
(to be removed before publication) . . . . . . . . . 40 Outer . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix E. Why Resetting ECN on Encapsulation Impedes PCN Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . . 41
(to be removed before publication) . . . . . . . . . 41
Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0)
Outer . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . . 43
Request to the RFC Editor (to be removed on publication): Request to the RFC Editor (to be removed on publication):
In the RFC index, RFC3168 should be identified as an update to In the RFC index, RFC3168 should be identified as an update to
RFC2003. RFC4301 should be identified as an update to RFC3168. RFC2003. RFC4301 should be identified as an update to RFC3168.
Changes from previous drafts (to be removed by the RFC Editor) Changes from previous drafts (to be removed by the RFC Editor)
Full text differences between IETF draft versions are available at Full text differences between IETF draft versions are available at
<http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-tunnel/>, and <http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-tunnel/>, and
between earlier individual draft versions at between earlier individual draft versions at
<http://www.briscoe.net/pubs.html#ecn-tunnel> <http://www.briscoe.net/pubs.html#ecn-tunnel>
From ietf-06 to ietf-07 (current): From ietf-08 to ietf-09 (current): Added change log entry for -07 to
-08 that was previously omitted.
* Editorial changes:
+ Abstract: s/providing backward compatibility./thus ensuring
backward compatibility./
+ Moved PCN-related text motivating changes to decapsulation
from "Default Tunnel Egress Behaviour" (Section 4.2) to
"Motivation for Changing Decapsulation" (Section 5.3.2)
where it was merged with existing similar text.
+ Added Stephen Hanna to acks and corrected spelling of
Agarwal.
+ Deleted endnote discussing corner case with IKEv2 manual
keying (identified as "to be removed before publication
following Sec").
+ Deleted Appendices D & E on why existing ingress & egress
tunnelling behavour impede PCN and the endnotes that
referred to them (identified as "to be removed before
publication").
From ietf-07 to ietf-08:
* Changes to standards actions:
+ Section 4: Changed non-RFC2119 phrase 'NOT RECOMMENDED' to
'SHOULD be avoided', wrt alternate ECN tunnelling schemes.
+ Section 4.2: Used upper-case in 'Alarms SHOULD be rate-
limited'.
+ Section 7: Made bullet #1 in the decapsulation guidelines
for alternate schemes more precise. Also changed any upper-
case keywords in this informative section to lower case.
* Editorial changes:
+ Changed copyright notice to allow for pre-5378 material.
+ Shifted supporting text intended for deletion on publication
into editorial comments.
+ Explained how to read the decapsulation matrices in their
captions.
+ Minor clarifications throughout.
From ietf-06 to ietf-07:
* Emphasised that this is the opposite of a fork in the RFC * Emphasised that this is the opposite of a fork in the RFC
series. series.
* Altered Section 5 to focus on updates to implementations of * Altered Section 5 to focus on updates to implementations of
earlier RFCs, rather than on updates to the text of the RFCs. earlier RFCs, rather than on updates to the text of the RFCs.
* Removed potential loop-holes in normative text that * Removed potential loop-holes in normative text that
implementers might have used to claim compliance without implementers might have used to claim compliance without
implementing normal mode. Highlighted the deliberate implementing normal mode. Highlighted the deliberate
skipping to change at page 6, line 36 skipping to change at page 7, line 39
Schemes" after all the normative sections. Schemes" after all the normative sections.
+ Added Appendix A on early history of ECN tunnelling RFCs. + Added Appendix A on early history of ECN tunnelling RFCs.
+ Removed specialist appendix on "Relative Placement of + Removed specialist appendix on "Relative Placement of
Tunnelling and In-Path Load Regulation" (Appendix D in the Tunnelling and In-Path Load Regulation" (Appendix D in the
-02 draft) -02 draft)
+ Moved and updated specialist text on "Compromise on Decap + Moved and updated specialist text on "Compromise on Decap
with ECT(1) Inner and ECT(0) Outer" from Security with ECT(1) Inner and ECT(0) Outer" from Security
Considerations to Appendix F Considerations to Appendix D
* Textual changes: * Textual changes:
+ Simplified vocabulary for non-native-english speakers + Simplified vocabulary for non-native-english speakers
+ Simplified Introduction and defined regularly used terms in + Simplified Introduction and defined regularly used terms in
an expanded Terminology section. an expanded Terminology section.
+ More clearly distinguished statically configured tunnels + More clearly distinguished statically configured tunnels
from dynamic tunnel endpoint discovery, before explaining from dynamic tunnel endpoint discovery, before explaining
skipping to change at page 17, line 26 skipping to change at page 18, line 26
will not amplify into a flood of alarm messages. It MUST be will not amplify into a flood of alarm messages. It MUST be
possible to suppress alarms or logging, e.g. if it becomes possible to suppress alarms or logging, e.g. if it becomes
apparent that a combination that previously was not used has apparent that a combination that previously was not used has
started to be used for legitimate purposes such as a new standards started to be used for legitimate purposes such as a new standards
action. action.
The above logic allows for ECT(0) and ECT(1) to both represent the The above logic allows for ECT(0) and ECT(1) to both represent the
same severity of congestion marking (e.g. "not congestion marked"). same severity of congestion marking (e.g. "not congestion marked").
But it also allows future schemes to be defined where ECT(1) is a But it also allows future schemes to be defined where ECT(1) is a
more severe marking than ECT(0), in particular enabling the simplest more severe marking than ECT(0), in particular enabling the simplest
possible encoding for PCN [I-D.ietf-pcn-3-in-1-encoding]. Before the possible encoding for PCN [I-D.ietf-pcn-3-in-1-encoding] (see
present specification was written, the PCN working-group had proposed Section 5.3.2). Treating ECT(1) as either the same as ECT(0) or as a
a number of work-rounds to the problem of a tunnel egress not higher severity level is explained in the discussion of the ECN nonce
propagating two severity levels of congestion. Without wishing to [RFC3540] in Section 8, which in turn refers to Appendix D.
disparage the ingenuity of these work-rounds, none were chosen for
the standards track because they were either somewhat wasteful,
imprecise or complicated [Note_PCN_egress]. Treating ECT(1) as
either the same as ECT(0) or as a higher severity level is explained
in the discussion of the ECN nonce [RFC3540] in Section 8, which in
turn refers to Appendix F.
4.3. Encapsulation Modes 4.3. Encapsulation Modes
Section 4.1 introduces two encapsulation modes, normal mode and Section 4.1 introduces two encapsulation modes, normal mode and
compatibility mode, defining their encapsulation behaviour (i.e. compatibility mode, defining their encapsulation behaviour (i.e.
header copying or zeroing respectively). Note that these are modes header copying or zeroing respectively). Note that these are modes
of the ingress tunnel endpoint only, not the tunnel as a whole. of the ingress tunnel endpoint only, not the tunnel as a whole.
To comply with this specification, a tunnel ingress MUST at least To comply with this specification, a tunnel ingress MUST at least
implement `normal mode'. Unless it will never be used with legacy implement `normal mode'. Unless it will never be used with legacy
skipping to change at page 20, line 44 skipping to change at page 21, line 38
dropped rather than forwarded as Not-ECT; dropped rather than forwarded as Not-ECT;
* Certain combinations of inner and outer ECN field have been * Certain combinations of inner and outer ECN field have been
identified as currently unused. These can trigger logging identified as currently unused. These can trigger logging
and/or raise alarms. and/or raise alarms.
Modes: RFC4301 tunnel endpoints do not need modes and are not Modes: RFC4301 tunnel endpoints do not need modes and are not
updated by the modes in the present specification. Effectively an updated by the modes in the present specification. Effectively an
RFC4301 IPsec ingress solely uses the REQUIRED normal mode of RFC4301 IPsec ingress solely uses the REQUIRED normal mode of
encapsulation, which is unchanged from RFC4301 encapsulation. It encapsulation, which is unchanged from RFC4301 encapsulation. It
will never [Note_Manual_Keying] need the OPTIONAL compatibility will never need the OPTIONAL compatibility mode as explained in
mode as explained in Section 4.3. Section 4.3.
5.2. Changes to RFC3168 ECN processing 5.2. Changes to RFC3168 ECN processing
Ingress: On encapsulation, the new rule in Figure 3 that a normal Ingress: On encapsulation, the new rule in Figure 3 that a normal
mode tunnel ingress copies any ECN field into the outer header mode tunnel ingress copies any ECN field into the outer header
updates the full functionality behaviour of an RFC3168 ingress. updates the full functionality behaviour of an RFC3168 ingress.
Nonetheless, the new compatibility mode encapsulates packets Nonetheless, the new compatibility mode encapsulates packets
identically to the limited functionality mode of an RFC3168 identically to the limited functionality mode of an RFC3168
ingress. ingress.
Egress: An RFC3168 egress will need to be updated to the new Egress: An RFC3168 egress will need to be updated to the new
decapsulation behaviour in Figure 4, in order to comply with the decapsulation behaviour in Figure 4, in order to comply with the
present specification. However, the changes are backward present specification. However, the changes are backward
skipping to change at page 22, line 32 skipping to change at page 23, line 24
compatibility with legacy decapsulators that do not propagate ECN compatibility with legacy decapsulators that do not propagate ECN
correctly. correctly.
The trigger that motivated this update to RFC3168 encapsulation was a The trigger that motivated this update to RFC3168 encapsulation was a
standards track proposal for pre-congestion notification (PCN standards track proposal for pre-congestion notification (PCN
[RFC5670]). PCN excess rate marking only works correctly if the ECN [RFC5670]). PCN excess rate marking only works correctly if the ECN
field is copied on encapsulation (as in RFC4301 and RFC5129); it does field is copied on encapsulation (as in RFC4301 and RFC5129); it does
not work if ECN is reset (as in RFC3168). This is because PCN excess not work if ECN is reset (as in RFC3168). This is because PCN excess
rate marking depends on the outer header revealing any congestion rate marking depends on the outer header revealing any congestion
experienced so far on the whole path, not just since the last tunnel experienced so far on the whole path, not just since the last tunnel
ingress [Note_PCN_ingress]. ingress.
PCN allows a network operator to add flow admission and termination PCN allows a network operator to add flow admission and termination
for inelastic traffic at the edges of a Diffserv domain, but without for inelastic traffic at the edges of a Diffserv domain, but without
any per-flow mechanisms in the interior and without the generous any per-flow mechanisms in the interior and without the generous
provisioning typical of Diffserv, aiming to significantly reduce provisioning typical of Diffserv, aiming to significantly reduce
costs. The PCN architecture [RFC5559] states that RFC3168 IP in IP costs. The PCN architecture [RFC5559] states that RFC3168 IP in IP
tunnelling of the ECN field cannot be used for any tunnel ingress in tunnelling of the ECN field cannot be used for any tunnel ingress in
a PCN domain. Prior to the present specification, this left a stark a PCN domain. Prior to the present specification, this left a stark
choice between not being able to use PCN for inelastic traffic choice between not being able to use PCN for inelastic traffic
control or not being able to use the many tunnels already deployed control or not being able to use the many tunnels already deployed
skipping to change at page 24, line 19 skipping to change at page 25, line 11
As well as being useful for general future-proofing, this problem As well as being useful for general future-proofing, this problem
is immediately pressing for standardisation of pre-congestion is immediately pressing for standardisation of pre-congestion
notification (PCN), which uses two severity levels of congestion. notification (PCN), which uses two severity levels of congestion.
If a congested queue used ECT(1) in the outer header to signal If a congested queue used ECT(1) in the outer header to signal
more severe congestion than ECT(0), the pre-existing more severe congestion than ECT(0), the pre-existing
decapsulation rules would have thrown away this congestion decapsulation rules would have thrown away this congestion
signal, preventing tunnelled traffic from ever knowing that it signal, preventing tunnelled traffic from ever knowing that it
should reduce its load. should reduce its load.
The PCN working group has had to consider a number of wasteful or Before the present specification was written, the PCN working
convoluted work-rounds to this problem [Note_PCN_egress]. But by group had to consider a number of wasteful or convoluted work-
far the simplest approach is just to remove the covert channel rounds to this problem. Without wishing to disparage the
blockages from tunnelling behaviour--now deemed unnecessary ingenuity of these work-rounds, none were chosen for the
anyway. Then network operators that want to support two standards track because they were either somewhat wasteful,
congestion severity-levels for PCN can specify that every tunnel imprecise or complicated. Instead a baseline PCN encoding was
egress in a PCN region must comply with this latest specified [RFC5696] that supported only one severity level of
specification. congestion but allowed space for these work-rounds as
experimental extensions.
But by far the simplest approach is that taken by the current
specification: just to remove the covert channel blockages from
tunnelling behaviour--now deemed unnecessary anyway. Then
network operators that want to support two congestion severity-
levels for PCN can specify that every tunnel egress in a PCN
region must comply with this latest specification. Having taken
this step, the simplest possible encoding for PCN with two
severity levels of congestion [I-D.ietf-pcn-3-in-1-encoding] can
be used.
Not only does this make two congestion severity-levels available Not only does this make two congestion severity-levels available
for PCN standardisation, but also for other potential uses of the for PCN, but also for other potential uses of the extra ECN
extra ECN codepoint (e.g. [VCP]). codepoint (e.g. [VCP]).
2. Cases are documented where a middlebox (e.g. a firewall) drops 2. Cases are documented where a middlebox (e.g. a firewall) drops
packets with header values that were currently unused (CU) when packets with header values that were currently unused (CU) when
the box was deployed, often on the grounds that anything the box was deployed, often on the grounds that anything
unexpected might be an attack. This tends to bar future use of unexpected might be an attack. This tends to bar future use of
CU values. The new decapsulation rules specify optional logging CU values. The new decapsulation rules specify optional logging
and/or alarms for specific combinations of inner and outer header and/or alarms for specific combinations of inner and outer header
that are currently unused. The aim is to give implementers a that are currently unused. The aim is to give implementers a
recourse other than drop if they are concerned about the security recourse other than drop if they are concerned about the security
of CU values. It recognises legitimate security concerns about of CU values. It recognises legitimate security concerns about
skipping to change at page 29, line 16 skipping to change at page 30, line 24
combinations may represent an attack, but the new scheme combinations may represent an attack, but the new scheme
should try to define a way to forward such packets, at least should try to define a way to forward such packets, at least
if a safe outgoing codepoint can be defined. if a safe outgoing codepoint can be defined.
Raising an alarm allows a management system to decide whether Raising an alarm allows a management system to decide whether
the anomaly is indeed an attack, in which case it can decide the anomaly is indeed an attack, in which case it can decide
to drop such packets. This is a preferable approach to hard- to drop such packets. This is a preferable approach to hard-
coded discard of packets that seem anomalous today, but may be coded discard of packets that seem anomalous today, but may be
needed tomorrow in future standards actions. needed tomorrow in future standards actions.
IANA Considerations (to be removed on publication):
This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
Appendix B.1 discusses the security constraints imposed on ECN tunnel Appendix B.1 discusses the security constraints imposed on ECN tunnel
processing. The new rules for ECN tunnel processing (Section 4) processing. The new rules for ECN tunnel processing (Section 4)
trade-off between information security (covert channels) and traffic trade-off between information security (covert channels) and traffic
security (congestion monitoring & control). Ensuring congestion security (congestion monitoring & control). Ensuring congestion
markings are not lost is itself an aspect of security, because if we markings are not lost is itself an aspect of security, because if we
allowed congestion notification to be lost, any attempt to enforce a allowed congestion notification to be lost, any attempt to enforce a
response to congestion would be much harder. response to congestion would be much harder.
skipping to change at page 30, line 10 skipping to change at page 31, line 11
other outside the domain. [RFC5559] gives specific advice on this other outside the domain. [RFC5559] gives specific advice on this
for the PCN case, but other definitions of alternate semantics for the PCN case, but other definitions of alternate semantics
will need to discuss the specific security implications in each will need to discuss the specific security implications in each
case. case.
ECN nonce tunnel coverage: The new decapsulation rules improve the ECN nonce tunnel coverage: The new decapsulation rules improve the
coverage of the ECN nonce [RFC3540] relative to the previous rules coverage of the ECN nonce [RFC3540] relative to the previous rules
in RFC3168 and RFC4301. However, nonce coverage is still not in RFC3168 and RFC4301. However, nonce coverage is still not
perfect, as this would have led to a safety problem in another perfect, as this would have led to a safety problem in another
case. Both are corner-cases, so discussion of the compromise case. Both are corner-cases, so discussion of the compromise
between them is deferred to Appendix F. between them is deferred to Appendix D.
Covert channel not turned off: A legacy (RFC3168) tunnel ingress Covert channel not turned off: A legacy (RFC3168) tunnel ingress
could ask an RFC3168 egress to turn off ECN processing as well as could ask an RFC3168 egress to turn off ECN processing as well as
itself turning off ECN. An egress compliant with the present itself turning off ECN. An egress compliant with the present
specification will agree to such a request from a legacy ingress, specification will agree to such a request from a legacy ingress,
but it relies on the ingress always sending Not-ECT in the outer. but it relies on the ingress always sending Not-ECT in the outer.
If the egress receives other ECN codepoints in the outer it will If the egress receives other ECN codepoints in the outer it will
process them as normal, so it will actually still copy congestion process them as normal, so it will actually still copy congestion
markings from the outer to the outgoing header. Referring for markings from the outer to the outgoing header. Referring for
example to Figure 5 (Appendix B.1), although the tunnel ingress example to Figure 5 (Appendix B.1), although the tunnel ingress
skipping to change at page 31, line 26 skipping to change at page 32, line 28
congestion control and management schemes without any modes or congestion control and management schemes without any modes or
configuration. Further, any host or router can expect the ECN field configuration. Further, any host or router can expect the ECN field
to behave in the same way, whatever type of tunnel might intervene in to behave in the same way, whatever type of tunnel might intervene in
the path. This new certainty could enable new uses of the ECN field the path. This new certainty could enable new uses of the ECN field
that would otherwise be confounded by ambiguity. that would otherwise be confounded by ambiguity.
10. Acknowledgements 10. Acknowledgements
Thanks to David Black for his insightful reviews and patient Thanks to David Black for his insightful reviews and patient
explanations of better ways to think about function placement and explanations of better ways to think about function placement and
alarms. Thanks to David and to Anil Agawaal for pointing out cases alarms. Thanks to David and to Anil Agarwal for pointing out cases
where it is safe to forward CU combinations of headers. Also thanks where it is safe to forward CU combinations of headers. Also thanks
to Arnaud Jacquet for the idea for Appendix C. Thanks to Gorry to Arnaud Jacquet for the idea for Appendix C. Thanks to Gorry
Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster, Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster,
Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson and Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson and
Phil Eardley for their thoughts and careful review comments. Phil Eardley for their thoughts and careful review comments, and to
Stephen Hanna for conducting the Security Directorate review.
Bob Briscoe is partly funded by Trilogy, a research project (ICT- Bob Briscoe is partly funded by Trilogy, a research project (ICT-
216372) supported by the European Community under its Seventh 216372) supported by the European Community under its Seventh
Framework Programme. The views expressed here are those of the Framework Programme. The views expressed here are those of the
author only. author only.
Comments Solicited (to be removed by the RFC Editor): Comments Solicited (to be removed by the RFC Editor):
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list addressed to the IETF Transport Area working group mailing list
skipping to change at page 31, line 45 skipping to change at page 33, line 4
Framework Programme. The views expressed here are those of the Framework Programme. The views expressed here are those of the
author only. author only.
Comments Solicited (to be removed by the RFC Editor): Comments Solicited (to be removed by the RFC Editor):
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors. <tsvwg@ietf.org>, and/or to the authors.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2003] Perkins, C., "IP Encapsulation [RFC2003] Perkins, C., "IP Encapsulation within
within IP", RFC 2003, October 1996. IP", RFC 2003, October 1996.
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement RFCs to Indicate Requirement Levels",
Levels", BCP 14, RFC 2119, BCP 14, RFC 2119, March 1997.
March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. [RFC3168] Ramakrishnan, K., Floyd, S., and D.
Black, "The Addition of Explicit Black, "The Addition of Explicit
Congestion Notification (ECN) to Congestion Notification (ECN) to IP",
IP", RFC 3168, September 2001. RFC 3168, September 2001.
[RFC4301] Kent, S. and K. Seo, "Security [RFC4301] Kent, S. and K. Seo, "Security
Architecture for the Internet Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
11.2. Informative References 11.2. Informative References
[I-D.ietf-pcn-3-in-1-encoding] Briscoe, B. and T. Moncaster, "PCN [I-D.ietf-pcn-3-in-1-encoding] Briscoe, B. and T. Moncaster, "PCN
3-State Encoding Extension in a 3-State Encoding Extension in a
single DSCP", single DSCP",
draft-ietf-pcn-3-in-1-encoding-01 draft-ietf-pcn-3-in-1-encoding-02
(work in progress), February 2010. (work in progress), March 2010.
[I-D.ietf-pcn-3-state-encoding] Briscoe, B., Moncaster, T., and M.
Menth, "A PCN encoding using 2
DSCPs to provide 3 or more states",
draft-ietf-pcn-3-state-encoding-01
(work in progress), February 2010.
[I-D.ietf-pcn-psdm-encoding] Menth, M., Babiarz, J., Moncaster,
T., and B. Briscoe, "PCN Encoding
for Packet-Specific Dual Marking
(PSDM)",
draft-ietf-pcn-psdm-encoding-00
(work in progress), June 2009.
[I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., Menth,
M., and T. Taylor, "PCN Boundary
Node Behaviour for the Single
Marking (SM) Mode of Operation",
draft-ietf-pcn-sm-edge-behaviour-01
(work in progress), October 2009.
[I-D.satoh-pcn-st-marking] Satoh, D., Ueno, H., Maeda, Y., and
O. Phanachet, "Single PCN Threshold
Marking by using PCN baseline
encoding for both admission and
termination controls",
draft-satoh-pcn-st-marking-02 (work
in progress), September 2009.
[RFC2401] Kent, S. and R. Atkinson, "Security
Architecture for the Internet
Protocol", RFC 2401, November 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F.,
and D. Black, "Definition of the
Differentiated Services Field (DS
Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998.
[RFC2481] Ramakrishnan, K. and S. Floyd, "A
Proposal to add Explicit Congestion
Notification (ECN) to IP",
RFC 2481, January 1999.
[RFC2983] Black, D., "Differentiated Services
and Tunnels", RFC 2983,
October 2000.
[RFC3540] Spring, N., Wetherall, D., and D. [RFC2401] Kent, S. and R. Atkinson, "Security
Ely, "Robust Explicit Congestion Architecture for the Internet
Notification (ECN) Signaling with Protocol", RFC 2401, November 1998.
Nonces", RFC 3540, June 2003.
[RFC4306] Kaufman, C., "Internet Key Exchange [RFC2474] Nichols, K., Blake, S., Baker, F.,
(IKEv2) Protocol", RFC 4306, and D. Black, "Definition of the
December 2005. Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[RFC4774] Floyd, S., "Specifying Alternate [RFC2481] Ramakrishnan, K. and S. Floyd, "A
Semantics for the Explicit Proposal to add Explicit Congestion
Congestion Notification (ECN) Notification (ECN) to IP", RFC 2481,
Field", BCP 124, RFC 4774, January 1999.
November 2006.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, [RFC2983] Black, D., "Differentiated Services
"Explicit Congestion Marking in and Tunnels", RFC 2983, October 2000.
MPLS", RFC 5129, January 2008.
[RFC5559] Eardley, P., "Pre-Congestion [RFC3540] Spring, N., Wetherall, D., and D.
Notification (PCN) Architecture", Ely, "Robust Explicit Congestion
RFC 5559, June 2009. Notification (ECN) Signaling with
Nonces", RFC 3540, June 2003.
[RFC5670] Eardley, P., "Metering and Marking [RFC4306] Kaufman, C., "Internet Key Exchange
Behaviour of PCN-Nodes", RFC 5670, (IKEv2) Protocol", RFC 4306,
November 2009. December 2005.
[RFC5696] Moncaster, T., Briscoe, B., and M. [RFC4774] Floyd, S., "Specifying Alternate
Menth, "Baseline Encoding and Semantics for the Explicit Congestion
Transport of Pre-Congestion Notification (ECN) Field", BCP 124,
Information", RFC 5696, RFC 4774, November 2006.
November 2009.
[VCP] Xia, Y., Subramanian, L., Stoica, [RFC5129] Davie, B., Briscoe, B., and J. Tay,
I., and S. Kalyanaraman, "One more "Explicit Congestion Marking in
bit is enough", Proc. SIGCOMM'05, MPLS", RFC 5129, January 2008.
ACM CCR 35(4)37--48, 2005, <http://
doi.acm.org/10.1145/
1080091.1080098>.
Editorial Comments [RFC5559] Eardley, P., "Pre-Congestion
Notification (PCN) Architecture",
RFC 5559, June 2009.
[Note_Manual_Keying] Bob Briscoe: Note (To be removed by the RFC [RFC5670] Eardley, P., "Metering and Marking
Editor): One corner case can exist where an Behaviour of PCN-Nodes", RFC 5670,
RFC4301 ingress does not use IKEv2, but uses November 2009.
manual keying instead. Then an RFC4301 ingress
could conceivably be configured to tunnel to an
egress with limited functionality ECN handling.
Strictly, for this corner-case, the requirement
to use compatibility mode in this specification
updates RFC4301. However, this is such a remote
possibility that RFC4301 IPsec implementations
are not required to implement compatibility
mode. It is planned to remove this note after
the review process has completed to avoid
unnecessarily complicating the document with a
largely theoretical corner case.
[Note_PCN_egress] Bob Briscoe: During the review process Appendix [RFC5696] Moncaster, T., Briscoe, B., and M.
D is provided to expand on this point, but it Menth, "Baseline Encoding and
will be deleted before publication. Transport of Pre-Congestion
Information", RFC 5696,
November 2009.
[Note_PCN_ingress] Bob Briscoe: During the review process Appendix [VCP] Xia, Y., Subramanian, L., Stoica, I.,
E is provided to expand on this point, but it and S. Kalyanaraman, "One more bit is
will be deleted before publication. enough", Proc. SIGCOMM'05, ACM
CCR 35(4)37--48, 2005, <http://
doi.acm.org/10.1145/1080091.1080098>.
Appendix A. Early ECN Tunnelling RFCs Appendix A. Early ECN Tunnelling RFCs
IP in IP tunnelling was originally defined in [RFC2003]. On IP in IP tunnelling was originally defined in [RFC2003]. On
encapsulation, the incoming header was copied to the outer and on encapsulation, the incoming header was copied to the outer and on
decapsulation the outer was simply discarded. Initially, IPsec decapsulation the outer was simply discarded. Initially, IPsec
tunnelling [RFC2401] followed the same behaviour. tunnelling [RFC2401] followed the same behaviour.
When ECN was introduced experimentally in [RFC2481], legacy (RFC2003 When ECN was introduced experimentally in [RFC2481], legacy (RFC2003
or RFC2401) tunnels would have discarded any congestion markings or RFC2401) tunnels would have discarded any congestion markings
skipping to change at page 40, line 18 skipping to change at page 40, line 18
| | | represents 100 packets | | | represents 100 packets
| 30 | | | 30 | |
| | | p_t = 12/(100-30) | | | p_t = 12/(100-30)
p_t + +---------+ = 12/70 p_t + +---------+ = 12/70
| | 12 | = 17% | | 12 | = 17%
0 +-----+---------+---> 0 +-----+---------+--->
0 30% 100% inner header marking 0 30% 100% inner header marking
Figure 7: Tunnel Marking of Packets Already Marked at Ingress Figure 7: Tunnel Marking of Packets Already Marked at Ingress
Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN (to be Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0) Outer
removed before publication)
Congestion notification with two severity levels is currently on the
IETF's standards track agenda in the Congestion and Pre-Congestion
Notification (PCN) working group. PCN needs all four possible states
of congestion signalling in the 2-bit ECN field to be propagated at
the egress, but pre-existing tunnels only propagate three. The four
PCN states are: not PCN-enabled, not marked and two increasingly
severe levels of congestion marking. The less severe marking means
'stop admitting new traffic' and the more severe marking means
'terminate some existing flows', which may be needed after reroutes
(see [RFC5559] for more details). (Note on terminology: wherever
this document counts four congestion states, the PCN working group
would count this as three PCN states plus a not-PCN-enabled state.)
Figure 2 (Section 3.2) shows that pre-existing decapsulation
behaviour would have discarded any ECT(1) markings in outer headers
if the inner was ECT(0). This prevented the PCN working group from
using ECT(1) -- if a PCN node used ECT(1) to indicate one of the
severity levels of congestion, any later tunnel egress would revert
the marking to ECT(0) as if nothing had happened. Effectively the
decapsulation rules of RFC4301 and RFC3168 waste one ECT codepoint;
they treat the ECT(0) and ECT(1) codepoints as a single codepoint.
A number of work-rounds to this problem were proposed in the PCN w-g;
to add the fourth state another way or avoid needing it. Without
wishing to disparage the ingenuity of these work-rounds, none were
chosen for the standards track because they were either somewhat
wasteful, imprecise or complicated:
o One uses a pair of Diffserv codepoint(s) in place of each PCN DSCP
to encode the extra state [I-D.ietf-pcn-3-state-encoding], using
up the rapidly exhausting DSCP space while leaving an ECN
codepoint unused.
o Another survives tunnelling without an extra DSCP
[I-D.ietf-pcn-psdm-encoding], but it requires the PCN edge
gateways to share the initial state of a packet out of band.
o Another proposes a more involved marking algorithm in forwarding
elements to encode the three congestion notification states using
only two ECN codepoints [I-D.satoh-pcn-st-marking].
o Another takes a different approach; it compromises the precision
of the admission control mechanism in some network scenarios, but
manages to work with just three encoding states and a single
marking algorithm [I-D.ietf-pcn-sm-edge-behaviour].
Rather than require the IETF to bless any of these experimental
encoding work-rounds, the present specification fixes the root cause
of the problem so that operators deploying PCN can simply require
that tunnel end-points within a PCN region should comply with this
new ECN tunnelling specification. On the public Internet it would
not be possible to know whether all tunnels complied with this new
specification, but universal compliance is feasible for PCN, because
it is intended to be deployed in a controlled Diffserv region.
Given the present specification, the PCN w-g could progress a
trivially simple four-state ECN encoding
[I-D.ietf-pcn-3-in-1-encoding]. This would replace the interim
standards track baseline encoding of just three states [RFC5696]
which makes a fourth state available for any of the experimental
alternatives.
Appendix E. Why Resetting ECN on Encapsulation Impedes PCN (to be
removed before publication)
The PCN architecture says "...if encapsulation is done within the
PCN-domain: Any PCN-marking is copied into the outer header. Note: A
tunnel will not provide this behaviour if it complies with [RFC3168]
tunnelling in either mode, but it will if it complies with [RFC4301]
IPsec tunnelling. "
The specific issue here concerns PCN excess rate marking [RFC5670].
The purpose of excess rate marking is to provide a bulk mechanism for
interior nodes within a PCN domain to mark traffic that is exceeding
a configured threshold bit-rate, perhaps after an unexpected event
such as a reroute, a link or node failure, or a more widespread
disaster. Reroutes are a common cause of QoS degradation in IP
networks. After reroutes it is common for multiple links in a
network to become stressed at once. Therefore, PCN excess rate
marking has been carefully designed to ensure traffic marked at one
queue will not be counted again for marking at subsequent queues (see
the `Excess traffic meter function' of [RFC5670]).
However, if an RFC3168 tunnel ingress intervenes, it resets the ECN
field in all the outer headers. This will cause excess traffic to be
counted more than once, leading to many flows being removed that did
not need to be removed at all. This is why the an RFC3168 tunnel
ingress cannot be used in a PCN domain.
The ECN reset in RFC3168 is no longer deemed necessary, it is
inconsistent with RFC4301, it is not as simple as RFC4301 and it is
impeding deployment of new protocols like PCN. The present
specification corrects this perverse situation.
Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0) Outer
A packet with an ECT(1) inner and an ECT(0) outer should never arise A packet with an ECT(1) inner and an ECT(0) outer should never arise
from any known IETF protocol. Without giving a reason, RFC3168 and from any known IETF protocol. Without giving a reason, RFC3168 and
RFC4301 both say the outer should be ignored when decapsulating such RFC4301 both say the outer should be ignored when decapsulating such
a packet. This appendix explains why it was decided not to change a packet. This appendix explains why it was decided not to change
this advice. this advice.
In summary, ECT(0) always means 'not congested' and ECT(1) may imply In summary, ECT(0) always means 'not congested' and ECT(1) may imply
the same [RFC3168] or it may imply a higher severity congestion the same [RFC3168] or it may imply a higher severity congestion
signal [RFC4774], [I-D.ietf-pcn-3-in-1-encoding], depending on the signal [RFC4774], [I-D.ietf-pcn-3-in-1-encoding], depending on the
skipping to change at page 43, line 20 skipping to change at page 41, line 20
Superficially, the opposite case where the inner and outer carry Superficially, the opposite case where the inner and outer carry
different ECT values, but with an ECT(1) outer and ECT(0) inner, different ECT values, but with an ECT(1) outer and ECT(0) inner,
seems to require a similar compromise. However, because that case is seems to require a similar compromise. However, because that case is
reversed, no compromise is necessary; it is best to forward the outer reversed, no compromise is necessary; it is best to forward the outer
whether the transport expects the ECT(1) to mean a higher severity whether the transport expects the ECT(1) to mean a higher severity
than ECT(0) or the same severity. Forwarding the outer either than ECT(0) or the same severity. Forwarding the outer either
preserves a higher value (if it is higher) or it reveals an anomaly preserves a higher value (if it is higher) or it reveals an anomaly
to the transport (if the two ECT codepoints mean the same severity). to the transport (if the two ECT codepoints mean the same severity).
Appendix G. Open Issues Appendix E. Open Issues
The new decapsulation behaviour defined in Section 4.2 adds support The new decapsulation behaviour defined in Section 4.2 adds support
for propagation of 2 severity levels of congestion. However for propagation of 2 severity levels of congestion. However
transports have no way to discover whether there are any legacy transports have no way to discover whether there are any legacy
tunnels on their path that will not propagate 2 severity levels. It tunnels on their path that will not propagate 2 severity levels. It
would have been nice to add a feature for transports to check path would have been nice to add a feature for transports to check path
support, but this remains an open issue that will have to be support, but this remains an open issue that will have to be
addressed in any future standards action to define an end-to-end addressed in any future standards action to define an end-to-end
scheme that requires 2-severity levels of congestion. PCN avoids scheme that requires 2-severity levels of congestion. PCN avoids
this problem because it is only for a controlled region, so all this problem because it is only for a controlled region, so all
 End of changes. 43 change blocks. 
302 lines changed or deleted 189 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/