One document matched: draft-ietf-tsvwg-ecn-tunnel-10.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!-- Alterations to I-D/RFC boilerplate -->
<?rfc private="" ?>
<!-- Default private="" Produce an internal memo 2.5pp shorter than an I-D or RFC -->
<?rfc rfcprocack="yes" ?>
<!-- Default rfcprocack="no" add a short sentence acknowledging xml2rfc -->
<?rfc strict="no" ?>
<!-- Default strict="no" Don't check I-D nits -->
<?rfc rfcedstyle="yes" ?>
<!-- Default rfcedstyle="yes" attempt to closely follow finer details from the latest observable RFC-Editor style -->
<!-- IETF process -->
<?rfc iprnotified="no" ?>
<!-- Default iprnotified="no" I haven't disclosed existence of IPR to IETF -->
<!-- ToC format -->
<?rfc toc="yes" ?>
<!-- Default toc="no" No Table of Contents -->
<!-- Cross referencing, footnotes, comments -->
<?rfc symrefs="yes"?>
<!-- Default symrefs="no" Don't use anchors, but use numbers for refs -->
<?rfc sortrefs="yes"?>
<!-- Default sortrefs="no" Don't sort references into order -->
<?rfc comments="yes" ?>
<!-- Default comments="no" Don't render comments -->
<?rfc inline="no" ?>
<!-- Default inline="no" if comments is "yes", then render comments inline; otherwise render them in an `Editorial Comments' section -->
<!-- Pagination control -->
<?rfc compact="yes"?>
<!-- Default compact="no" Start sections on new pages -->
<?rfc subcompact="no"?>
<!-- Default subcompact="(as compact setting)" yes/no is not quite as compact as yes/yes -->
<!-- HTML formatting control -->
<?rfc emoticonic="yes" ?>
<!-- Default emoticonic="no" Doesn't prettify HTML format -->
<rfc category="std" docName="draft-ietf-tsvwg-ecn-tunnel-10" ipr="trust200902"
updates="3168, 4301, 4774">
<front>
<title abbrev="ECN Tunnelling">Tunnelling of Explicit Congestion
Notification</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization>
<address>
<postal>
<street>B54/77, Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<phone>+44 1473 645196</phone>
<email>bob.briscoe@bt.com</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<date day="26" month="August" year="2010" />
<area>Transport</area>
<workgroup>Transport Area Working Group</workgroup>
<keyword>Congestion Control and Management</keyword>
<keyword>Congestion Notification</keyword>
<keyword>Information Security</keyword>
<keyword>Tunnelling</keyword>
<keyword>Encapsulation & Decapsulation</keyword>
<keyword>Protocol</keyword>
<keyword>ECN</keyword>
<keyword>IPsec</keyword>
<abstract>
<t>This document redefines how the explicit congestion notification
(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 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 to add
new behaviours for previously unused combinations of inner and outer
header. The new rules ensure the ECN field is correctly propagated
across a tunnel whether it is used to signal one or two severity levels
of congestion, whereas before only one severity level was supported.
Tunnel endpoints can be updated in any order without affecting
pre-existing uses of the ECN field, thus ensuring backward
compatibility. Nonetheless, operators wanting to support two severity
levels (e.g. for pre-congestion notification—PCN) can require
compliance with this new specification. A thorough analysis 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, RFC4774
gives guidance on designing alternate ECN semantics and this document
extends that to include tunnelling issues.</t>
</abstract>
</front>
<!-- ================================================================ -->
<middle>
<note title="Request to the RFC Editor (to be removed on publication):">
<t>In the RFC index, RFC3168 should be identified as an update to
RFC2003. RFC4301 should be identified as an update to RFC3168.</t>
</note>
<note title="Changes from previous drafts (to be removed by the RFC Editor)">
<t>Full text differences between IETF draft versions are available at
<http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-tunnel/>, and
between earlier individual draft versions at
<http://www.briscoe.net/pubs.html#ecn-tunnel><list style="hanging">
<t hangText="From ietf-09 to ietf-10 (current):">
<list style="symbols">
<t>Editorial changes:<list style="symbols">
<t>Clarified couple of sentences in Introduction and one in
section 6.3 to distinguish whether the terms 'RFC3168' &
'RFC4301' refer to implementations or documents.</t>
<t>Corrected garbled sentence in the introduction about
backward compatibility.</t>
<t>Made it clear that 'drop' in Fig 2, Fig 4 and the
following para is an action, not a codepoint.</t>
<t>In sections 5.1 & 5.2, specifically identified the
updated sections of RFC3168 & RFC4301.</t>
<t>Avoided describing compatibility mode as 'optional' at
the end of section 5.2 where it should have said 'not always
obligatory' instead, because in section 4 compatibility mode
is normatively defined as obligatory in some circumstances
(rather than always optional).</t>
<t>Added RFC5659 as informative reference on pseudowires and
clarified only some pseudowires might be relevant
examples.</t>
<t>Deleted "The views expressed here are those of the author
only." in the acknowledgements.</t>
<t>Fixed a few nits.</t>
</list></t>
</list>
</t>
<t hangText="From ietf-08 to ietf-09:">Added change log entry for
-07 to -08 that was previously omitted.<list style="symbols">
<t>Changes to standards action text:<list style="symbols">
<t>Added RFC4774 to 'Updates:' header (the draft always has
extended the advice in RFC4774 (BCP124) which said very
little about tunnels. The GENART reviewer merely pointed out
that the header did not highlight this fact.)</t>
</list></t>
<t>Editorial changes:<list style="symbols">
<t>Abstract: s/providing backward compatibility./thus
ensuring backward compatibility./</t>
<t>Moved PCN-related text motivating changes to
decapsulation from "Default Tunnel Egress Behaviour" (<xref
target="ecntun_Default_Egress_Behaviour" />) to "Motivation
for Changing Decapsulation" (<xref
target="ecntun_Motivate_Decap" />) where it was merged with
existing similar text.</t>
<t>In the non-normative Design Principles avoided using
words in lower case where they were in contexts that might
make them confusable with upper case RFC2119 normative
language.</t>
<t>Added Stephen Hanna and Ben Campbell to acks and
corrected spelling of Agarwal.</t>
<t>Deleted endnote discussing corner case with IKEv2 manual
keying (identified as "to be removed before publication
following SecDir review").</t>
<t>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").</t>
<t>Various minor corrections pointed out by reviewers.</t>
</list></t>
</list></t>
<t hangText="From ietf-07 to ietf-08:">
<list style="symbols">
<t>Changes to standards actions:<list style="symbols">
<t><xref target="ecntun_ECN_Tunnel_Rules" />: Changed
non-RFC2119 phrase 'NOT RECOMMENDED' to 'SHOULD be avoided',
wrt alternate ECN tunnelling schemes.</t>
<t><xref target="ecntun_Default_Egress_Behaviour" />: Used
upper-case in 'Alarms SHOULD be rate-limited'.</t>
<t><xref target="ecntun_Design_Principles" />: 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.</t>
</list></t>
<t>Editorial changes:<list style="symbols">
<t>Changed copyright notice to allow for pre-5378
material.</t>
<t>Shifted supporting text intended for deletion on
publication into editorial comments.</t>
<t>Explained how to read the decapsulation matrices in their
captions.</t>
<t>Minor clarifications throughout.</t>
</list></t>
</list>
</t>
<t hangText="From ietf-06 to ietf-07:">
<list style="symbols">
<t>Emphasised that this is the opposite of a fork in the RFC
series.</t>
<t>Altered <xref target="ecntun_RFC_Changes" /> to focus on
updates to implementations of earlier RFCs, rather than on
updates to the text of the RFCs.</t>
<t>Removed potential loop-holes in normative text that
implementers might have used to claim compliance without
implementing normal mode. Highlighted the deliberate distinction
between "MUST implement" and "SHOULD use" normal mode.</t>
<t>Added question for Security Directorate reviewers on whether
to mention a corner-case concerning manual keying of IPsec
tunnels.</t>
<t>Minor clarifications, updated references and updated
acks.</t>
<t>Marked two appendices about PCN motivations for removal
before publication.</t>
</list>
</t>
<t hangText="From ietf-05 to ietf-06:">
<list style="symbols">
<t>Minor textual clarifications and corrections.</t>
</list>
</t>
<t hangText="From ietf-04 to ietf-05:">
<list style="symbols">
<t>Functional changes:<list style="symbols">
<t><xref target="ecntun_Default_Egress_Behaviour" />: ECT(1)
outer with Not-ECT inner: reverted to forwarding as Not-ECT
(as in RFC3168 & RFC4301), rather than dropping.</t>
<t>Altered rationale in bullet 3 of <xref
target="ecntun_Motivate_Decap" /> to justify this.</t>
<t>Distinguished alarms for dangerous and invalid
combinations and allowed combinations that are valid in some
tunnel configurations but dangerous in others to be alarmed
at the discretion of the implementer and/or operator.</t>
<t>Altered advice on designing alternate ECN tunnelling
semantics to reflect the above changes.</t>
</list></t>
<t>Textual changes:<list style="symbols">
<t>Changed "Future non-default schemes" to "Alternate ECN
Tunnelling Semantics" throughout.</t>
<t>Cut down Appendix D and Appendix E for brevity.</t>
<t>A number of clarifying edits & updated refs.</t>
</list></t>
</list>
</t>
<t hangText="From ietf-03 to ietf-04:">
<list style="symbols">
<t>Functional changes: none</t>
<t>Structural changes:<list style="symbols">
<t>Added "Open Issues" appendix</t>
</list></t>
<t>Textual changes:<list style="symbols">
<t>Section title: "Changes from Earlier RFCs" -> "Updates
to Earlier RFCs"</t>
<t>Emphasised that change on decap to previously unused
combinations will propagate PCN encoding.</t>
<t>Acknowledged additional reviewers and updated
references</t>
</list></t>
</list>
</t>
<t hangText="From ietf-02 to ietf-03:">
<list style="symbols">
<t>Functional changes:<list style="symbols">
<t>Corrected errors in recap of previous RFCs, which wrongly
stated the different decapsulation behaviours of RFC3168
& RFC4301 with a Not-ECT inner header. This also
required corrections to the "Changes from Earlier RFCs" and
the Motivations for these changes.</t>
<t>Mandated that any future standards action SHOULD NOT use
the ECT(0) codepoint as an indication of congestion, without
giving strong reasons.</t>
<t>Added optional alarm when decapsulating ECT(1) outer,
ECT(0), but noted it would need to be disabled for
2-severity level congestion (e.g. PCN).</t>
</list></t>
<t>Structural changes: <list style="symbols">
<t>Removed Document Roadmap which merely repeated the
Contents (previously Section 1.2).</t>
<t>Moved "Changes from Earlier RFCs" (<xref
target="ecntun_RFC_Changes" />) before <xref
target="ecntun_Backward_Compatibility" /> on Backward
Compatibility and internally organised both by RFC, rather
than by ingress then egress.</t>
<t>Moved motivation for changing existing RFCs (<xref
target="ecntun_Motivate_Changes" />) to after the changes
are specified.</t>
<t>Moved informative "Design Principles for Future
Non-Default Schemes" after all the normative sections.</t>
<t>Added <xref target="ecntun_Early_History" /> on early
history of ECN tunnelling RFCs.</t>
<t>Removed specialist appendix on "Relative Placement of
Tunnelling and In-Path Load Regulation" (Appendix D in the
-02 draft)</t>
<t>Moved and updated specialist text on "Compromise on Decap
with ECT(1) Inner and ECT(0) Outer" from Security
Considerations to <xref target="ecntun_Compromise" /></t>
</list></t>
<t>Textual changes:<list style="symbols">
<t>Simplified vocabulary for non-native-english speakers</t>
<t>Simplified Introduction and defined regularly used terms
in an expanded Terminology section.</t>
<t>More clearly distinguished statically configured tunnels
from dynamic tunnel endpoint discovery, before explaining
operating modes.</t>
<t>Simplified, cut-down and clarified throughout</t>
<t>Updated references.</t>
</list></t>
</list>
</t>
<t hangText="From ietf-01 to ietf-02:">
<list style="symbols">
<t>Scope reduced from any encapsulation of an IP packet to
solely IP in IP tunnelled encapsulation. Consequently changed
title and removed whole section 'Design Guidelines for New
Encapsulations of Congestion Notification' (to be included in a
future companion informational document).</t>
<t>Included a new normative decapsulation rule for ECT(0) inner
and ECT(1) outer that had previously only been outlined in the
non-normative appendix 'Comprehensive Decapsulation Rules'.
Consequently:<list style="symbols">
<t>The Introduction has been completely re-written to
motivate this change to decapsulation along with the
existing change to encapsulation.</t>
<t>The tentative text in the appendix that first proposed
this change has been split between normative standards text
in <xref target="ecntun_ECN_Tunnel_Rules" /> and Appendix D,
which explains specifically why this change would streamline
PCN. New text on the logic of the resulting decap rules
added.</t>
</list></t>
<t>If inner/outer is Not-ECT/ECT(0), changed decapsulation to
propagate Not-ECT rather than drop the packet; and added
reasoning.</t>
<t>Considerably restructured: <list style="symbols">
<t>"Design Constraints" analysis moved to an appendix (<xref
target="ecntun_Design_Constraints" />);</t>
<t>Added <xref target="ecntun_Existing_RFCs" /> to summarise
relevant existing RFCs;</t>
<t>Structured <xref target="ecntun_ECN_Tunnel_Rules" /> and
<xref target="ecntun_Backward_Compatibility" /> into
subsections.</t>
<t>Added tables to sections on old and new rules, for
precision and comparison.</t>
<t>Moved <xref target="ecntun_Design_Principles" /> on
Design Principles to the end of the section specifying the
new default normative tunnelling behaviour. Rewritten and
shifted text on identifiers and in-path load regulators to
Appendix B.1 [deleted in revision -03].</t>
</list></t>
</list>
</t>
<t hangText="From ietf-00 to ietf-01:">
<list style="symbols">
<t>Identified two additional alarm states in the decapsulation
rules (<xref target="ecntun_Tab_IP_IP_Decapsulation" />) if
ECT(X) in outer and inner contradict each other.</t>
<t>Altered Comprehensive Decapsulation Rules (Appendix D) so
that ECT(0) in the outer no longer overrides ECT(1) in the
inner. Used the term 'Comprehensive' instead of 'Ideal'. And
considerably updated the text in this appendix.</t>
<t>Added Appendix D.1 (removed again in a later revision) to
weigh up the various ways the Comprehensive Decapsulation Rules
might be introduced. This replaces the previous contradictory
statements saying complex backwards compatibility interactions
would be introduced while also saying there would be no
backwards compatibility issues.</t>
<t>Updated references.</t>
</list>
</t>
<t hangText="From briscoe-01 to ietf-00:">
<list style="symbols">
<t>Re-wrote <xref target="ecntun_Tunnel_Contribution" /> giving
much simpler technique to measure contribution to congestion
across a tunnel.</t>
<t>Added discussion of backward compatibility of the ideal
decapsulation scheme in Appendix D</t>
<t>Updated references. Minor corrections & clarifications
throughout.</t>
</list>
</t>
<t hangText="From briscoe-00 to briscoe-01:">
<list style="symbols">
<t>Related everything conceptually to the uniform and pipe
models of RFC2983 on Diffserv Tunnels, and completely removed
the dependence of tunnelling behaviour on the presence of any
in-path load regulation by using the [1 - Before] [2 - Outer]
function placement concepts from RFC2983;</t>
<t>Added specific cases where the existing standards limit new
proposals, particularly Appendix E;</t>
<t>Added sub-structure to Introduction (Need for
Rationalisation, Roadmap), added new Introductory subsection on
"Scope" and improved clarity;</t>
<t>Added Design Guidelines for New Encapsulations of Congestion
Notification;</t>
<t>Considerably clarified the Backward Compatibility section
(<xref target="ecntun_Backward_Compatibility" />);</t>
<t>Considerably extended the Security Considerations section
(<xref target="ecntun_Security_Considerations" />);</t>
<t>Summarised the primary rationale much better in the
conclusions;</t>
<t>Added numerous extra acknowledgements;</t>
<t>Added Appendix E. "Why resetting CE on encapsulation harms
PCN", <xref target="ecntun_Tunnel_Contribution" />.
"Contribution to Congestion across a Tunnel" and Appendix D.
"Ideal Decapsulation Rules";</t>
<t>Re-wrote Appendix B [deleted in a later revision], explaining
how tunnel encapsulation no longer depends on in-path
load-regulation (changed title from "In-path Load Regulation" to
"Non-Dependence of Tunnelling on In-path Load Regulation"), but
explained how an in-path load regulation function must be
carefully placed with respect to tunnel encapsulation (in a new
sub-section entitled "Dependence of In-Path Load Regulation on
Tunnelling").</t>
</list>
</t>
</list></t>
</note>
<!-- ================================================================ -->
<section anchor="ecntun_Introduction" title="Introduction">
<t>Explicit congestion notification (ECN <xref target="RFC3168" />)
allows a forwarding element (e.g. a router) to notify the onset of
congestion without having to drop packets. Instead it can explicitly
mark a proportion of packets in the 2-bit ECN field in the IP header
(<xref target="ecntun_ECN_Codepoints" /> recaps the ECN codepoints).</t>
<t>The outer header of an IP packet can encapsulate one or more IP
headers for tunnelling. A forwarding element using ECN to signify
congestion will only mark the immediately visible outer IP header. When
a tunnel decapsulator later removes this outer header, it follows rules
to propagate congestion markings by combining the ECN fields of the
inner and outer IP header into one outgoing IP header.</t>
<t>This document updates those rules for IPsec <xref target="RFC4301" />
and non-IPsec <xref target="RFC3168" /> tunnels to add new behaviours
for previously unused combinations of inner and outer header. It also
updates the ingress behaviour of RFC3168 tunnels to match that of
RFC4301 tunnels. Tunnel endpoints complying with the updated rules will
be backward compatible when interworking with tunnel endpoints complying
with RFC4301, RFC3168 or any earlier specification.</t>
<t>When ECN and its tunnelling was defined in RFC3168, only the minimum
necessary changes to the ECN field were propagated through tunnel
endpoints—just enough for the basic ECN mechanism to work. This
was due to concerns that the ECN field might be toggled to communicate
between a secure site and someone on the public Internet—a covert
channel. This was because a mutable field like ECN cannot be protected
by IPsec's integrity mechanisms—it has to be able to change as it
traverses the Internet.</t>
<t>Nonetheless, the latest IPsec architecture <xref target="RFC4301" />
considered a bandwidth limit of 2 bits per packet on a covert channel to
be a manageable risk. Therefore, for simplicity, an RFC4301 ingress
copied the whole ECN field to encapsulate a packet. RFC4301 dispensed
with the two modes of RFC3168, one which partially copied the ECN field,
and the other which blocked all propagation of ECN changes.</t>
<t>Unfortunately, this entirely reasonable sequence of standards actions
resulted in a perverse outcome; non-IPsec tunnels (RFC3168) blocked the
2-bit covert channel, while IPsec tunnels (RFC4301) did not—at
least not at the ingress. At the egress, both IPsec and non-IPsec
tunnels still partially restricted propagation of the full ECN
field.</t>
<t>The trigger for the changes in this document was the introduction of
pre-congestion notification (PCN <xref target="RFC5670" />) to the IETF
standards track. PCN needs the ECN field to be copied at a tunnel
ingress and it needs four states of congestion signalling to be
propagated at the egress, but pre-existing tunnels only propagate three
in the ECN field.</t>
<t>This document draws on currently unused (CU) combinations of inner
and outer headers to add tunnelling of four-state congestion signalling
to RFC3168 and RFC4301. Operators of tunnels who specifically want to
support four states can require that all their tunnels comply with this
specification. However, this is not a fork in the RFC series. It is an
update that can be deployed first by those that need it, and
subsequently by all tunnel endpoint implementations (RFC4301, RFC3168,
RFC2481, RFC2401, RFC2003), which can safely be updated to this new
specification as part of general code maintenance. This will gradually
add support for four congestion states to the Internet. Existing three
state schemes will continue to work as before.</t>
<t>In fact, this document is the opposite of a fork. At the same time as
supporting a fourth state, the opportunity has been taken to draw
together divergent ECN tunnelling specifications into a single
consistent behaviour, harmonising differences such as perverse covert
channel treatment. Then any tunnel can be deployed unilaterally, and it
will support the full range of congestion control and management schemes
without any modes or configuration. Further, any host or router can
expect the ECN field to behave in the same way, whatever type of tunnel
might intervene in the path.</t>
<section anchor="ecntun_Scope" title="Scope">
<t>This document only concerns wire protocol processing of the ECN
field at tunnel endpoints and makes no changes or recommendations
concerning algorithms for congestion marking or congestion
response.</t>
<t>This document specifies common ECN field processing at
encapsulation and decapsulation for any IP in IP tunnelling, whether
IPsec or non-IPsec tunnels. It applies irrespective of whether IPv4 or
IPv6 is used for either of the inner and outer headers. It applies for
packets with any destination address type, whether unicast or
multicast. It applies as the default for all Diffserv per-hop
behaviours (PHBs), unless stated otherwise in the specification of a
PHB (but <xref target="ecntun_ECN_Tunnel_Rules" /> strongly deprecates
such exceptions). It is intended to be a good trade off between
somewhat conflicting security, control and management
requirements.</t>
<t><xref target="RFC2983" /> is a comprehensive primer on
differentiated services and tunnels. Given ECN raises similar issues
to differentiated services when interacting with tunnels, useful
concepts introduced in RFC2983 are used throughout, with brief recaps
of the explanations where necessary.</t>
</section>
</section>
<!-- ================================================================ -->
<section anchor="ecntun_Reqs_Language" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref
target="RFC2119" />.</t>
<t><xref target="ecntun_ECN_Codepoints" /> recaps the names of the ECN
codepoints <xref target="RFC3168" />.</t>
<texttable anchor="ecntun_ECN_Codepoints"
title="Recap of Codepoints of the ECN Field [RFC3168] in the IP Header">
<ttcol align="center">Binary codepoint</ttcol>
<ttcol>Codepoint name</ttcol>
<ttcol>Meaning</ttcol>
<c>00</c>
<c>Not-ECT</c>
<c>Not ECN-capable transport</c>
<c>01</c>
<c>ECT(1)</c>
<c>ECN-capable transport</c>
<c>10</c>
<c>ECT(0)</c>
<c>ECN-capable transport</c>
<c>11</c>
<c>CE</c>
<c>Congestion experienced</c>
</texttable>
<t>Further terminology used within this document:<list style="hanging">
<t hangText="Encapsulator:">The tunnel endpoint function that adds
an outer IP header to tunnel a packet (also termed the 'ingress
tunnel endpoint' or just the 'ingress' where the context is
clear).</t>
<t hangText="Decapsulator:">The tunnel endpoint function that
removes an outer IP header from a tunnelled packet (also termed the
'egress tunnel endpoint' or just the 'egress' where the context is
clear).</t>
<t hangText="Incoming header:">The header of an arriving packet
before encapsulation.</t>
<t hangText="Outer header:">The header added to encapsulate a
tunnelled packet.</t>
<t hangText="Inner header:">The header encapsulated by the outer
header.</t>
<t hangText="Outgoing header:">The header constructed by the
decapsulator using logic that combines the fields in the outer and
inner headers.</t>
<t hangText="Copying ECN:">On encapsulation, setting the ECN field
of the new outer header to be a copy of the ECN field in the
incoming header.</t>
<t hangText="Zeroing ECN:">On encapsulation, clearing the ECN field
of the new outer header to Not-ECT (<spanx
style="verb">00</spanx>).</t>
<t hangText="Resetting ECN:">On encapsulation, setting the ECN field
of the new outer header to be a copy of the ECN field in the
incoming header except the outer ECN field is set to the ECT(0)
codepoint if the incoming ECN field is CE.</t>
</list></t>
</section>
<!-- ================================================================ -->
<section anchor="ecntun_Existing_RFCs"
title="Summary of Pre-Existing RFCs">
<t>This section is informative not normative, as it recaps pre-existing
RFCs. Earlier relevant RFCs that were either experimental or incomplete
with respect to ECN tunnelling (RFC2481, RFC2401 and RFC2003) are
briefly outlined in <xref target="ecntun_Early_History" />. The question
of whether tunnel implementations used in the Internet comply with any
of these RFCs is not discussed.</t>
<section anchor="ecntun_Existing_Ingress"
title="Encapsulation at Tunnel Ingress">
<t>At the encapsulator, the controversy has been over whether to
propagate information about congestion experienced on the path so far
into the outer header of the tunnel.</t>
<t>Specifically, RFC3168 says that, if a tunnel fully supports ECN
(termed a 'full-functionality' ECN tunnel in <xref
target="RFC3168" />), the encapsulator must not copy a CE marking from
the inner header into the outer header that it creates. Instead the
encapsulator must set the outer header to ECT(0) if the ECN field is
marked CE in the arriving IP header. We term this 'resetting' a CE
codepoint.</t>
<t>However, the new IPsec architecture in <xref target="RFC4301" />
reverses this rule, stating that the encapsulator must simply copy the
ECN field from the incoming header to the outer header.</t>
<t>RFC3168 also provided a Limited Functionality mode that turns off
ECN processing over the scope of the tunnel by setting the outer
header to Not-ECT (<spanx style="verb">00</spanx>). Then such packets
will be dropped to indicate congestion rather than marked with ECN.
This is necessary for the ingress to interwork with legacy
decapsulators (<xref target="RFC2481" />, <xref target="RFC2401" />
and <xref target="RFC2003" />) that do not propagate ECN markings
added to the outer header. Otherwise such legacy decapsulators would
throw away congestion notifications before they reached the transport
layer.</t>
<t>Neither Limited Functionality mode nor Full Functionality mode are
used by an RFC4301 IPsec encapsulator, which simply copies the
incoming ECN field into the outer header. An earlier key-exchange
phase ensures an RFC4301 ingress will not have to interwork with a
legacy egress that does not support ECN.</t>
<t>These pre-existing behaviours are summarised in <xref
target="ecntun_Tab_IP_IP_Encapsulation_Pre" />.</t>
<figure align="center" anchor="ecntun_Tab_IP_IP_Encapsulation_Pre"
title="IP in IP Encapsulation: Recap of Pre-existing Behaviours">
<artwork><![CDATA[+-----------------+-----------------------------------------------+
| Incoming Header | Outgoing Outer Header |
| (also equal to +---------------+---------------+---------------+
| Outgoing Inner | RFC3168 ECN | RFC3168 ECN | RFC4301 IPsec |
| Header) | Limited | Full | |
| | Functionality | Functionality | |
+-----------------+---------------+---------------+---------------+
| Not-ECT | Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) | ECT(1) |
| CE | Not-ECT | ECT(0) | CE |
+-----------------+---------------+---------------+---------------+
]]></artwork>
</figure>
<t />
</section>
<section anchor="ecntun_Existing_Egress"
title="Decapsulation at Tunnel Egress">
<t>RFC3168 and RFC4301 specify the decapsulation behaviour summarised
in <xref target="ecntun_Tab_IP_IP_Decapsulation_Pre" />. The ECN field
in the outgoing header is set to the codepoint at the intersection of
the appropriate incoming inner header (row) and incoming outer header
(column).</t>
<figure align="center" anchor="ecntun_Tab_IP_IP_Decapsulation_Pre"
title="IP in IP Decapsulation; Recap of Pre-existing Behaviour">
<artwork><![CDATA[ +---------+------------------------------------------------+
|Incoming | Incoming Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
RFC3168->| Not-ECT | Not-ECT |Not-ECT |Not-ECT | <drop> |
RFC4301->| Not-ECT | Not-ECT |Not-ECT |Not-ECT |Not-ECT |
| ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE |
| ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE |
| CE | CE | CE | CE | CE |
+---------+---------+------------+------------+------------+
]]></artwork>
<postamble>In pre-existing RFCs, the ECN field in the outgoing
header was set to the codepoint at the intersection of the
appropriate incoming inner header (row) and incoming outer header
(column) , or the packet was dropped where indicated.</postamble>
</figure>
<t>The behaviour in the table derives from the logic given in RFC3168
and RFC4301, briefly recapped as follows:<list style="symbols">
<t>On decapsulation, if the inner ECN field is Not-ECT the outer
is ignored. RFC3168 (but not RFC4301) also specified that the
decapsulator must drop a packet with a Not-ECT inner and CE in the
outer.</t>
<t>In all other cases, if the outer is CE, the outgoing ECN field
is set to CE, but otherwise the outer is ignored and the inner is
used for the outgoing ECN field.</t>
</list>Section 9.2.2 of RFC3168 also made it an auditable event for
an IPsec tunnel "if the ECN Field is changed inappropriately within an
IPsec tunnel...". Inappropriate changes were not specifically
enumerated. RFC4301 did not mention inappropriate ECN changes.</t>
</section>
</section>
<section anchor="ecntun_ECN_Tunnel_Rules" title="New ECN Tunnelling Rules">
<t>The standards actions below in <xref
target="ecntun_Default_Ingress_Behaviour" /> (ingress encapsulation) and
<xref target="ecntun_Default_Egress_Behaviour" /> (egress decapsulation)
define new default ECN tunnel processing rules for any IP packet (v4 or
v6) with any Diffserv codepoint.</t>
<t>If these defaults do not meet a particular requirement, an alternate
ECN tunnelling scheme can be introduced as part of the definition of an
alternate congestion marking scheme used by a specific Diffserv PHB (see
section 5 of <xref target="RFC3168" /> and <xref target="RFC4774" />).
When designing such alternate ECN tunnelling schemes, the principles in
<xref target="ecntun_Design_Principles" /> should be followed. However,
alternate ECN tunnelling schemes SHOULD be avoided whenever possible as
the deployment burden of handling exceptional PHBs in implementations of
all affected tunnels should not be underestimated. There is no
requirement for a PHB definition to state anything about ECN tunnelling
behaviour if the default behaviour in the present specification is
sufficient.</t>
<section anchor="ecntun_Default_Ingress_Behaviour"
title="Default Tunnel Ingress Behaviour">
<t>Two modes of encapsulation are defined here; a REQUIRED `normal
mode' and a `compatibility mode', which is for backward compatibility
with tunnel decapsulators that do not understand ECN. Note that these
are modes of the ingress tunnel endpoint only, not the whole tunnel.
<xref target="ecntun_Encap_Modes" /> explains why two modes are
necessary and specifies the circumstances in which it is sufficient to
solely implement normal mode.</t>
<t>Whatever the mode, an encapsulator forwards the inner header
without changing the ECN field.</t>
<t>In normal mode an encapsulator compliant with this specification
MUST construct the outer encapsulating IP header by copying the 2-bit
ECN field of the incoming IP header. In compatibility mode it clears
the ECN field in the outer header to the Not-ECT codepoint (the IPv4
header checksum also changes whenever the ECN field is changed). These
rules are tabulated for convenience in <xref
target="ecntun_Tab_IP_IP_Encapsulation" />.</t>
<figure align="center" anchor="ecntun_Tab_IP_IP_Encapsulation"
title="New IP in IP Encapsulation Behaviours">
<artwork><![CDATA[+-----------------+-------------------------------+
| Incoming Header | Outgoing Outer Header |
| (also equal to +---------------+---------------+
| Outgoing Inner | Compatibility | Normal |
| Header) | Mode | Mode |
+-----------------+---------------+---------------+
| Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) |
| CE | Not-ECT | CE |
+-----------------+---------------+---------------+
]]></artwork>
</figure>
<t />
</section>
<section anchor="ecntun_Default_Egress_Behaviour"
title="Default Tunnel Egress Behaviour">
<t>To decapsulate the inner header at the tunnel egress, a compliant
tunnel egress MUST set the outgoing ECN field to the codepoint at the
intersection of the appropriate incoming inner header (row) and outer
header (column) in <xref target="ecntun_Tab_IP_IP_Decapsulation" />
(the IPv4 header checksum also changes whenever the ECN field is
changed). There is no need for more than one mode of decapsulation, as
these rules cater for all known requirements.</t>
<figure align="center" anchor="ecntun_Tab_IP_IP_Decapsulation"
title="New IP in IP Decapsulation Behaviour">
<artwork><![CDATA[ +---------+------------------------------------------------+
|Incoming | Incoming Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE |
| CE | CE | CE | CE(!!!)| CE |
+---------+---------+------------+------------+------------+
]]></artwork>
<postamble>The ECN field in the outgoing header is set to the
codepoint at the intersection of the appropriate incoming inner
header (row) and incoming outer header (column) , or the packet is
dropped where indicated. Currently unused combinations are indicated
by '(!!!)' or '(!)'</postamble>
</figure>
<t>This table for decapsulation behaviour is derived from the
following logic:<list style="symbols">
<t>If the inner ECN field is Not-ECT the decapsulator MUST NOT
propagate any other ECN codepoint onwards. This is because the
inner Not-ECT marking is set by transports that rely on dropped
packets as an indication of congestion and would not understand or
respond to any other ECN codepoint <xref target="RFC4774" />.
Specifically:<list style="symbols">
<t>If the inner ECN field is Not-ECT and the outer ECN field
is CE the decapsulator MUST drop the packet.</t>
<t>If the inner ECN field is Not-ECT and the outer ECN field
is Not-ECT, ECT(0) or ECT(1) the decapsulator MUST forward the
outgoing packet with the ECN field cleared to Not-ECT.</t>
</list></t>
<t>In all other cases where the inner supports ECN, the
decapsulator MUST set the outgoing ECN field to the more severe
marking of the outer and inner ECN fields, where the ranking of
severity from highest to lowest is CE, ECT(1), ECT(0), Not-ECT.
This in no way precludes cases where ECT(1) and ECT(0) have the
same severity;</t>
<t>Certain combinations of inner and outer ECN fields cannot
result from any transition in any current or previous ECN
tunneling specification. These currently unused (CU) combinations
are indicated in <xref target="ecntun_Tab_IP_IP_Decapsulation" />
by '(!!!)' or '(!)', where '(!!!)' means the combination is CU and
always potentially dangerous, while '(!)' means it is CU and
possibly dangerous. In these cases, particularly the more
dangerous ones, the decapsulator SHOULD log the event and MAY also
raise an alarm.<vspace blankLines="1" />Just because the
highlighted combinations are currently unused, does not mean that
all the other combinations are always valid. Some are only valid
if they have arrived from a particular type of legacy ingress, and
dangerous otherwise. Therefore an implementation MAY allow an
operator to configure logging and alarms for such additional
header combinations known to be dangerous or CU for the particular
configuration of tunnel endpoints deployed at run-time. <vspace
blankLines="1" />Alarms SHOULD be rate-limited so that the
anomalous combinations will not amplify into a flood of alarm
messages. It MUST be possible to suppress alarms or logging, e.g.
if it becomes apparent that a combination that previously was not
used has started to be used for legitimate purposes such as a new
standards action.</t>
</list></t>
<t>The above logic allows for ECT(0) and ECT(1) to both represent the
same severity of congestion marking (e.g. "not congestion marked").
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
possible encoding for PCN <xref
target="I-D.ietf-pcn-3-in-1-encoding" /> (see <xref
target="ecntun_Motivate_Decap" />). 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 <xref target="RFC3540" /> in <xref
target="ecntun_Security_Considerations" />, which in turn refers to
<xref target="ecntun_Compromise" />.</t>
</section>
<section anchor="ecntun_Encap_Modes" title="Encapsulation Modes">
<t><xref target="ecntun_Default_Ingress_Behaviour" /> introduces two
encapsulation modes, normal mode and compatibility mode, defining
their encapsulation behaviour (i.e. header copying or zeroing
respectively). Note that these are modes of the ingress tunnel
endpoint only, not the tunnel as a whole.</t>
<t>To comply with this specification, a tunnel ingress MUST at least
implement `normal mode'. Unless it will never be used with legacy
tunnel egress nodes (RFC2003, RFC2401 or RFC2481 or the limited
functionality mode of RFC3168), an ingress MUST also implement
`compatibility mode' for backward compatibility with tunnel egresses
that do not propagate explicit congestion notifications <xref
target="RFC4774" />.</t>
<t>We can categorise the way that an ingress tunnel endpoint is paired
with an egress as either static or dynamically discovered:<list
style="hanging">
<t hangText="Static:">Tunnel endpoints paired together by prior
configuration. <vspace blankLines="1" />Some implementations of
encapsulator might always be statically deployed, and constrained
to never be paired with a legacy decapsulator (RFC2003, RFC2401 or
RFC2481 or the limited functionality mode of RFC3168). In such a
case, only normal mode needs to be implemented.<vspace
blankLines="1" />For instance, RFC4301-compatible IPsec tunnel
endpoints invariably use IKEv2 <xref target="RFC4306" /> for key
exchange, which was introduced alongside RFC4301. Therefore both
endpoints of an RFC4301 tunnel can be sure that the other end is
RFC4301-compatible, because the tunnel is only formed after IKEv2
key management has completed, at which point both ends will be
RFC4301-compliant by definition. Therefore an IPsec tunnel ingress
does not need compatibility mode, as it will never interact with
legacy ECN tunnels. To comply with the present specification, it
only needs to implement the required normal mode, which is
identical to the pre-existing RFC4301 behaviour.</t>
<t hangText="Dynamic Discovery:">Tunnel endpoints paired together
by some form of tunnel endpoint discovery, typically finding an
egress on the path taken by the first packet.<vspace
blankLines="1" />This specification does not require or recommend
dynamic discovery and it does not define how dynamic negotiation
might be done, but it recognises that proprietary tunnel endpoint
discovery protocols exist. It therefore sets down some constraints
on discovery protocols to ensure safe interworking.<vspace
blankLines="1" />If dynamic tunnel endpoint discovery might pair
an ingress with a legacy egress (RFC2003, RFC2401 or RFC2481 or
the limited functionality mode of RFC3168), the ingress MUST
implement both normal and compatibility mode. If the tunnel
discovery process is arranged to only ever find a tunnel egress
that propagates ECN (RFC3168 full functionality mode, RFC4301 or
this present specification), then a tunnel ingress can be
compliant with the present specification without implementing
compatibility mode.<vspace blankLines="1" />While a compliant
tunnel ingress is discovering an egress, it MUST send packets in
compatibility mode in case the egress it discovers is a legacy
egress. If, through the discovery protocol, the egress indicates
that it is compliant with the present specification, with RFC4301
or with RFC3168 full functionality mode, the ingress can switch
itself into normal mode. If the egress denies compliance with any
of these or returns an error that implies it does not understand a
request to work to any of these ECN specifications, the tunnel
ingress MUST remain in compatibility mode.</t>
</list></t>
<t>If an ingress claims compliance with this specification it MUST NOT
permanently disable ECN processing across the tunnel (i.e. only using
compatibility mode). It is true that such a tunnel ingress is at least
safe with the ECN behaviour of any egress it may encounter, but it
does not meet the central aim of this specification: introducing ECN
support to tunnels.</t>
<t>Instead, if the ingress knows that the egress does support
propagation of ECN (full functionality mode of RFC3168 or RFC4301 or
the present specification), it SHOULD use normal mode, in order to
support ECN where possible. Note that this section started by saying
an ingress "MUST implement "normal mode, while it has just said an
ingress "SHOULD use" normal mode. This distinction is deliberate, to
allow the mode to be turned off in exceptional circumstances but to
ensure all implementations make normal mode available.</t>
<t>
<list style="hanging">
<t hangText="Implementation note:">If a compliant node is the
ingress for multiple tunnels, a mode setting will need to be
stored for each tunnel ingress. However, if a node is the egress
for multiple tunnels, none of the tunnels will need to store a
mode setting, because a compliant egress only needs one mode.</t>
</list>
</t>
</section>
<section anchor="ecntun_Single_Decap_Mode"
title="Single Mode of Decapsulation">
<t>A compliant decapsulator only needs one mode of operation. However,
if a compliant egress is implemented to be dynamically discoverable,
it may need to respond to discovery requests from various types of
legacy tunnel ingress. This specification does not define how dynamic
negotiation might be done by (proprietary) discovery protocols, but it
sets down some constraints to ensure safe interworking.</t>
<t>Through the discovery protocol, a tunnel ingress compliant with the
present specification might ask if the egress is compliant with the
present specification, with RFC4301 or with RFC3168 full functionality
mode. Or an RFC3168 tunnel ingress might try to negotiate to use
limited functionality or full functionality mode <xref
target="RFC3168" />. In all these cases, a decapsulating tunnel egress
compliant with this specification MUST agree to any of these requests,
since it will behave identically in all these cases.</t>
<t>If no ECN-related mode is requested, a compliant tunnel egress MUST
continue without raising any error or warning, because its egress
behaviour is compatible with all the legacy ingress behaviours that do
not negotiate capabilities.</t>
<t>A compliant tunnel egress SHOULD raise a warning alarm about any
requests to enter modes it does not recognise but, for 'forward
compatibility' with standards actions possibly defined after it was
implemented, it SHOULD continue operating.</t>
</section>
</section>
<section anchor="ecntun_RFC_Changes" title="Updates to Earlier RFCs">
<section anchor="ecntun_Changes_RFC4301"
title="Changes to RFC4301 ECN processing">
<t>
<list style="hanging">
<t hangText="Ingress:">An RFC4301 IPsec encapsulator is not
changed at all by the present specification. It uses the normal
mode of the present specification, which defines packet
encapsulation identically to RFC4301.</t>
<t hangText="Egress:">An RFC4301 egress will need to be updated to
the new decapsulation behaviour in <xref
target="ecntun_Tab_IP_IP_Decapsulation" />, in order to comply
with the present specification. However, the changes are backward
compatible; combinations of inner and outer that result from any
protocol defined in the RFC series so far are unaffected. Only
combinations that have never been used have been changed,
effectively adding new behaviours to RFC4301 decapsulation without
altering existing behaviours. The following specific updates to
section 5.1.2 of RFC4301 have been made:<list style="symbols">
<t>The outer, not the inner, is propagated when the outer is
ECT(1) and the inner is ECT(0);</t>
<t>A packet with Not-ECT in the inner and an outer of CE is
dropped rather than forwarded as Not-ECT;</t>
<t>Certain combinations of inner and outer ECN field have been
identified as currently unused. These can trigger logging
and/or raise alarms.</t>
</list></t>
<t hangText="Modes:">RFC4301 tunnel endpoints do not need modes
and are not updated by the modes in the present specification.
Effectively an RFC4301 IPsec ingress solely uses the REQUIRED
normal mode of encapsulation, which is unchanged from RFC4301
encapsulation. It will never need the OPTIONAL compatibility mode
as explained in <xref target="ecntun_Encap_Modes" />.</t>
</list>
</t>
</section>
<section anchor="ecntun_Changes_RFC3168"
title="Changes to RFC3168 ECN processing">
<t>
<list style="hanging">
<t hangText="Ingress:">On encapsulation, the new rule in <xref
target="ecntun_Tab_IP_IP_Encapsulation" /> that a normal mode
tunnel ingress copies any ECN field into the outer header updates
the full functionality behaviour of an RFC3168 ingress [<xref
format="counter" target="RFC3168" />; section 9.1.1]. Nonetheless,
the new compatibility mode encapsulates packets identically to the
limited functionality mode of an RFC3168 ingress.</t>
<t hangText="Egress:">An RFC3168 egress will need to be updated to
the new decapsulation behaviour in <xref
target="ecntun_Tab_IP_IP_Decapsulation" />, in order to comply
with the present specification. However, the changes are backward
compatible; combinations of inner and outer that result from any
protocol defined in the RFC series so far are unaffected. Only
combinations that have never been used have been changed,
effectively adding new behaviours to RFC3168 decapsulation without
altering existing behaviours. The following specific updates to
section 9.1.1 of RFC3168 have been made:<list style="symbols">
<t>The outer, not the inner, is propagated when the outer is
ECT(1) and the inner is ECT(0);</t>
<t>Certain combinations of inner and outer ECN field have been
identified as currently unused. These can trigger logging
and/or raise alarms.</t>
</list></t>
<t hangText="Modes:">An RFC3168 ingress will need to be updated if
it is to comply with the present specification, whether or not it
implemented the optional full functionality mode of section 9.1.1
of RFC3168. <vspace blankLines="1" />Section 9.1 of RFC3168
defined a (required) limited functionality mode and an (optional)
full functionality mode for a tunnel. In RFC3168, modes applied to
both ends of the tunnel, while in the present specification, modes
are only used at the ingress—a single egress behaviour
covers all cases. <vspace blankLines="1" />The normal mode of
encapsulation is an update to the encapsulation behaviour of the
full functionality mode of an RFC3168 ingress. The compatibility
mode of encapsulation is identical to the encapsulation behaviour
of the limited functionality mode of an RFC3168 ingress, except it
is not always obligatory. <vspace blankLines="1" />The constraints
on how tunnel discovery protocols set modes in <xref
target="ecntun_Encap_Modes" /> and <xref
target="ecntun_Single_Decap_Mode" /> are an update to RFC3168, but
they are unlikely to require code changes as they document
existing safe practice.</t>
</list>
</t>
</section>
<section anchor="ecntun_Motivate_Changes" title="Motivation for Changes">
<t>An overriding goal is to ensure the same ECN signals can mean the
same thing whatever tunnels happen to encapsulate an IP packet flow.
This removes gratuitous inconsistency, which otherwise constrains the
available design space and makes it harder to design networks and new
protocols that work predictably.</t>
<section anchor="ecntun_Motivate_Encap"
title="Motivation for Changing Encapsulation">
<t>The normal mode in <xref target="ecntun_ECN_Tunnel_Rules" />
updates RFC3168 to make all IP in IP encapsulation of the ECN field
consistent—consistent with the way both RFC4301 IPsec <xref
target="RFC4301" /> and IP in MPLS or MPLS in MPLS encapsulation
<xref target="RFC5129" /> construct the ECN field.</t>
<t>Compatibility mode has also been defined so that a non-RFC4301
ingress can still switch to using drop across a tunnel for backwards
compatibility with legacy decapsulators that do not propagate ECN
correctly.</t>
<t>The trigger that motivated this update to RFC3168 encapsulation
was a standards track proposal for pre-congestion notification (PCN
<xref target="RFC5670" />). PCN excess rate marking only works
correctly if the ECN 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 rate marking depends on the outer header
revealing any congestion experienced so far on the whole path, not
just since the last tunnel ingress.</t>
<t>PCN allows a network operator to add flow admission and
termination for inelastic traffic at the edges of a Diffserv domain,
but without any per-flow mechanisms in the interior and without the
generous provisioning typical of Diffserv, aiming to significantly
reduce costs. The PCN architecture <xref target="RFC5559" /> states
that RFC3168 IP in IP 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 choice between not being able to
use PCN for inelastic traffic control or not being able to use the
many tunnels already deployed for Mobile IP, VPNs and so forth.</t>
<t>The present specification provides a clean solution to this
problem, so that network operators who want to use both PCN and
tunnels can specify that every tunnel ingress in a PCN region must
comply with this latest specification.</t>
<t>Rather than allow tunnel specifications to fragment further into
one for PCN, one for IPsec and one for other tunnels, the
opportunity has been taken to consolidate the diverging
specifications back into a single tunnelling behaviour. Resetting
ECN was originally motivated by a covert channel concern that has
been deliberately set aside in RFC4301 IPsec. Therefore the reset
behaviour of RFC3168 is an anomaly that we do not need to keep.
Copying ECN on encapsulation is anyway simpler than resetting. So,
as more tunnel endpoints comply with this single consistent
specification, encapsulation will be simpler as well as more
predictable.</t>
<t><xref target="ecntun_Design_Constraints" /> assesses whether
copying rather than resetting CE on ingress will cause any
unintended side-effects, from the three perspectives of security,
control and management. In summary this analysis finds that:<list
style="symbols">
<t>From the control perspective either copying or resetting
works for existing arrangements, but copying has more potential
for simplifying control and resetting breaks at least one
proposal already on the standards track.</t>
<t>From the management and monitoring perspective copying is
preferable.</t>
<t>From the traffic security perspective (enforcing congestion
control, mitigating denial of service etc) copying is
preferable.</t>
<t>From the information security perspective resetting is
preferable, but the IETF Security Area now considers copying
acceptable given the bandwidth of a 2-bit covert channel can be
managed.</t>
</list>Therefore there are two points against resetting CE on
ingress while copying CE causes no significant harm.</t>
</section>
<section anchor="ecntun_Motivate_Decap"
title="Motivation for Changing Decapsulation">
<t>The specification for decapsulation in <xref
target="ecntun_ECN_Tunnel_Rules" /> fixes three problems with the
pre-existing behaviours of both RFC3168 and RFC4301:</t>
<t><list style="numbers">
<t>The pre-existing rules prevented the introduction of
alternate ECN semantics to signal more than one severity level
of congestion <xref target="RFC4774" />, <xref
target="RFC5559" />. The four states of the 2-bit ECN field
provide room for signalling two severity levels in addition to
not-congested and not-ECN-capable states. But, the pre-existing
rules assumed that two of the states (ECT(0) and ECT(1)) are
always equivalent. This unnecessarily restricts the use of one
of four codepoints (half a bit) in the IP (v4 & v6) header.
The new rules are designed to work in either case; whether
ECT(1) is more severe than or equivalent to ECT(0).<vspace
blankLines="1" />As explained in <xref
target="ecntun_Security_Constraints" />, the original reason for
not forwarding the outer ECT codepoints was to limit the covert
channel across a decapsulator to 1 bit per packet. However, now
that the IETF Security Area has deemed that a 2-bit covert
channel through an encapsulator is a manageable risk, the same
should be true for a decapsulator.<vspace blankLines="1" />As
well as being useful for general future-proofing, this problem
is immediately pressing for standardisation of pre-congestion
notification (PCN), which uses two severity levels of
congestion. If a congested queue used ECT(1) in the outer header
to signal more severe congestion than ECT(0), the pre-existing
decapsulation rules would have thrown away this congestion
signal, preventing tunnelled traffic from ever knowing that it
should reduce its load.<vspace blankLines="1" />Before the
present specification was written, the PCN working group had to
consider a number of wasteful or convoluted work-rounds to this
problem. 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.
Instead a baseline PCN encoding was specified <xref
target="RFC5696" /> that supported only one severity level of
congestion but allowed space for these work-rounds as
experimental extensions.<vspace blankLines="1" />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 <xref
target="I-D.ietf-pcn-3-in-1-encoding" /> can be used.<vspace
blankLines="1" />Not only does this make two congestion
severity-levels available for PCN, but also for other potential
uses of the extra ECN codepoint (e.g. <xref
target="VCP" />).</t>
<t>Cases are documented where a middlebox (e.g. a firewall)
drops packets with header values that were currently unused (CU)
when the box was deployed, often on the grounds that anything
unexpected might be an attack. This tends to bar future use of
CU values. The new decapsulation rules specify optional logging
and/or alarms for specific combinations of inner and outer
header that are currently unused. The aim is to give
implementers a recourse other than drop if they are concerned
about the security of CU values. It recognises legitimate
security concerns about CU values but still eases their future
use. If the alarms are interpreted as an attack (e.g. by a
management system) the offending packets can be dropped. But
alarms can be turned off if these combinations come into regular
use (e.g. through a future standards action).</t>
<t>While reviewing currently unused combinations of inner and
outer, the opportunity was taken to define a single consistent
behaviour for the three cases with a Not-ECT inner header but a
different outer. RFC3168 and RFC4301 had diverged in this
respect and even their common behaviours had never been
justified.<vspace blankLines="1" />None of these combinations
should result from Internet protocols in the RFC series, but
future standards actions might put any or all of them to good
use. Therefore it was decided that a decapsulator must forward a
Not-ECT inner unchanged when the arriving outer is ECT(0) or
ECT(1). But for safety it must drop a combination of Not-ECT
inner and CE outer. Then, if some unfortunate misconfiguration
resulted in a congested router marking CE on a packet that was
originally Not-ECT, drop would be the only appropriate signal
for the egress to propagate—the only signal a
non-ECN-capable transport (Not-ECT) would understand. <vspace
blankLines="1" />It may seem contradictory that the same
argument has not been applied to the ECT(1) codepoint, given it
is being proposed as an intermediate level of congestion in a
scheme progressing through the IETF <xref
target="I-D.ietf-pcn-3-in-1-encoding" />. Instead, a
decapsulator must forward a Not-ECT inner unchanged when its
outer is ECT(1). The rationale for not dropping this CU
combination is to ensure it will be usable if needed in the
future. If any misconfiguration led to ECT(1) congestion signals
with a Not-ECT inner, it would not be disastrous for the tunnel
egress to suppress them, because the congestion should then
escalate to CE marking, which the egress would drop, thus at
least preventing congestion collapse.</t>
</list>Problems 2 & 3 alone would not warrant a change to
decapsulation, but it was decided they are worth fixing and making
consistent at the same time as decapsulation code is changed to fix
problem 1 (two congestion severity-levels).</t>
</section>
</section>
</section>
<section anchor="ecntun_Backward_Compatibility"
title="Backward Compatibility">
<t>A tunnel endpoint compliant with the present specification is
backward compatible when paired with any tunnel endpoint compliant with
any previous tunnelling RFC, whether RFC4301, RFC3168 (see <xref
target="ecntun_Existing_RFCs" />) or the earlier RFCs summarised in
<xref target="ecntun_Early_History" /> (RFC2481, RFC2401 and RFC2003).
Each case is enumerated below.</t>
<section title="Non-Issues Updating Decapsulation">
<t>At the egress, this specification only augments the per-packet
calculation of the ECN field (RFC3168 and RFC4301) for combinations of
inner and outer headers that have so far not been used in any IETF
protocols.</t>
<t>Therefore, all other things being equal, if an RFC4301 IPsec egress
is updated to comply with the new rules, it will still interwork with
any RFC4301 compliant ingress and the packet outputs will be identical
to those it would have output before (fully backward compatible).</t>
<t>And, all other things being equal, if an RFC3168 egress is updated
to comply with the same new rules, it will still interwork with any
ingress complying with any previous specification (both modes of
RFC3168, both modes of RFC2481, RFC2401 and RFC2003) and the packet
outputs will be identical to those it would have output before (fully
backward compatible).</t>
<t>A compliant tunnel egress merely needs to implement the one
behaviour in <xref target="ecntun_ECN_Tunnel_Rules" /> with no
additional mode or option configuration at the ingress or egress nor
any additional negotiation with the ingress. The new decapsulation
rules have been defined in such a way that congestion control will
still work safely if any of the earlier versions of ECN processing are
used unilaterally at the encapsulating ingress of the tunnel (any of
RFC2003, RFC2401, either mode of RFC2481, either mode of RFC3168,
RFC4301 and this present specification).</t>
</section>
<section title="Non-Update of RFC4301 IPsec Encapsulation">
<t>An RFC4301 IPsec ingress can comply with this new specification
without any update and it has no need for any new modes, options or
configuration. So, all other things being equal, it will continue to
interwork identically with any egress it worked with before (fully
backward compatible).</t>
</section>
<section title="Update to RFC3168 Encapsulation">
<t>The encapsulation behaviour of the new normal mode copies the ECN
field whereas an RFC3168 ingress in full functionality mode reset it.
However, all other things being equal, if an RFC3168 ingress is
updated to the present specification, the outgoing packets from any
tunnel egress will still be unchanged. This is because all variants of
tunnelling at either end (RFC4301, both modes of RFC3168, both modes
of RFC2481, RFC2401, RFC2003 and the present specification) have
always propagated an incoming CE marking through the inner header and
onward into the outgoing header, whether the outer header is reset or
copied. Therefore, If the tunnel is considered as a black box, the
packets output from any egress will be identical with or without an
update to the ingress. Nonetheless, if packets are observed within the
black box (between the tunnel endpoints), CE markings copied by the
updated ingress will be visible within the black box, whereas they
would not have been before. Therefore, the update to encapsulation can
be termed 'black-box backwards compatible' (i.e. identical unless you
look inside the tunnel).</t>
<t>This specification introduces no new backward compatibility issues
when a compliant ingress talks with a legacy egress, but it has to
provide similar safeguards to those already defined in RFC3168.
RFC3168 laid down rules to ensure that an RFC3168 ingress turns off
ECN (limited functionality mode) if it is paired with a legacy egress
(RFC 2481, RFC2401 or RFC2003), which would not propagate ECN
correctly. The present specification carries forward those rules
(<xref target="ecntun_Encap_Modes" />). It uses compatibility mode
whenever RFC3168 would have used limited functionality mode, and their
per-packet behaviours are identical. Therefore, all other things being
equal, an ingress using the new rules will interwork with any legacy
tunnel egress in exactly the same way as an RFC3168 ingress (still
black-box backward compatible).</t>
</section>
</section>
<section anchor="ecntun_Design_Principles"
title="Design Principles for Alternate ECN Tunnelling Semantics">
<t>This section is informative not normative.</t>
<t>Section 5 of RFC3168 permits the Diffserv codepoint (DSCP)<xref
target="RFC2474" /> to 'switch in' alternative behaviours for marking
the ECN field, just as it switches in different per-hop behaviours
(PHBs) for scheduling. <xref target="RFC4774" /> gives best current
practice for designing such alternative ECN semantics and very briefly
mentions in section 5.4 that tunnelling needs to be considered. The
guidance below complements and extends RFC4774, giving additional
guidance on designing any alternate ECN semantics that would also
require alternate tunnelling semantics.</t>
<t>The overriding guidance is: "Avoid designing alternate ECN tunnelling
semantics, if at all possible." If a scheme requires tunnels to
implement special processing of the ECN field for certain DSCPs, it will
be hard to guarantee that every implementer of every tunnel will have
added the required exception or that operators will have ubiquitously
deployed the required updates. It is unlikely a single authority is even
aware of all the tunnels in a network, which may include tunnels set up
by applications between endpoints, or dynamically created in the
network. Therefore it is highly likely that some tunnels within a
network or on hosts connected to it will not implement the required
special case.</t>
<t>That said, if a non-default scheme for tunnelling the ECN field is
really required, the following guidelines might prove useful in its
design:<list style="hanging">
<t hangText="On encapsulation in any alternate scheme:">
<list style="numbers">
<t>The ECN field of the outer header ought to be cleared to
Not-ECT (<spanx style="verb">00</spanx>) unless it is guaranteed
that the corresponding tunnel egress will correctly propagate
congestion markings introduced across the tunnel in the outer
header.</t>
<t>If it has established that ECN will be correctly propagated,
an encapsulator ought to also copy incoming congestion
notification into the outer header. The general principle here
is that the outer header should reflect congestion accumulated
along the whole upstream path, not just since the tunnel ingress
(<xref target="ecntun_Mgmt_Constraints" /> on management and
monitoring explains).<vspace blankLines="1" />In some
circumstances (e.g. PCN <xref target="RFC5559" /> and perhaps
some pseudowires <xref target="RFC5659" />), the whole path is
divided into segments, each with its own congestion notification
and feedback loop. In these cases, the function that regulates
load at the start of each segment will need to reset congestion
notification for its segment. Often the point where congestion
notification is reset will also be located at the start of a
tunnel. However, the resetting function can be thought of as
being applied to packets after the encapsulation
function—two logically separate functions even though they
might run on the same physical box. Then the code module doing
encapsulation can keep to the copying rule and the load
regulator module can reset congestion, without any code in
either module being conditional on whether the other is
there.</t>
</list>
</t>
<t hangText="On decapsulation in any new scheme:">
<list style="numbers">
<t>If the arriving inner header is Not-ECT it implies the
transport will not understand other ECN codepoints. If the outer
header carries an explicit congestion marking, the alternate
scheme would be expected to drop the packet—the only
indication of congestion the transport will understand. If the
alternate scheme recommends forwarding rather than dropping such
a packet, it will need to clearly justify this decision. If the
inner is Not-ECT and the outer carries any other ECN codepoint
that does not indicate congestion, the alternate scheme can
forward the packet, but probably only as Not-ECT.</t>
<t>If the arriving inner header is other than Not-ECT, the ECN
field that the alternate decapsulation scheme forwards ought to
reflect the more severe congestion marking of the arriving inner
and outer headers.</t>
<t>Any alternate scheme will need to define a behaviour for all
combinations of inner and outer headers, even those that would
not be expected to result from standards known at the time and
even those that would not be expected from the tunnel ingress
paired with the egress at run-time. Consideration should be
given to logging such unexpected combinations and raising an
alarm, particularly if there is a danger that the invalid
combination implies congestion signals are not being propagated
correctly. The presence of currently unused combinations may
represent an attack, but the new scheme should try to define a
way to forward such packets, at least if a safe outgoing
codepoint can be defined.<vspace blankLines="1" />Raising an
alarm allows a management system to decide whether the anomaly
is indeed an attack, in which case it can decide to drop such
packets. This is a preferable approach to hard-coded discard of
packets that seem anomalous today, but may be needed tomorrow in
future standards actions.</t>
</list>
</t>
</list></t>
</section>
<!-- ================================================================ -->
<section anchor="ecntun_IANA"
title="IANA Considerations (to be removed on publication):">
<t>This memo includes no request to IANA.</t>
</section>
<!-- ================================================================ -->
<section anchor="ecntun_Security_Considerations"
title="Security Considerations">
<t><xref target="ecntun_Security_Constraints" /> discusses the security
constraints imposed on ECN tunnel processing. The new rules for ECN
tunnel processing (<xref target="ecntun_ECN_Tunnel_Rules" />) trade-off
between information security (covert channels) and traffic security
(congestion monitoring & control). Ensuring congestion markings are
not lost is itself an aspect of security, because if we allowed
congestion notification to be lost, any attempt to enforce a response to
congestion would be much harder.</t>
<t>Security issues in unlikely but possible scenarios:<list
style="hanging">
<t
hangText="Tunnels intersecting Diffserv regions with alternate ECN semantics:">If
alternate congestion notification semantics are defined for a
certain Diffserv PHB, the scope of the alternate semantics might
typically be bounded by the limits of a Diffserv region or regions,
as envisaged in <xref target="RFC4774" /> (e.g. the pre-congestion
notification architecture <xref target="RFC5559" />). The inner
headers in tunnels crossing the boundary of such a Diffserv region
but ending within the region can potentially leak the external
congestion notification semantics into the region, or leak the
internal semantics out of the region. <xref target="RFC2983" />
discusses the need for Diffserv traffic conditioning to be applied
at these tunnel endpoints as if they are at the edge of the Diffserv
region. Similar concerns apply to any processing or propagation of
the ECN field at the endpoints of tunnels with one end inside and
the other outside the domain. <xref target="RFC5559" /> gives
specific advice on this for the PCN case, but other definitions of
alternate semantics will need to discuss the specific security
implications in each case.</t>
<t hangText="ECN nonce tunnel coverage:">The new decapsulation rules
improve the coverage of the ECN nonce <xref target="RFC3540" />
relative to the previous rules in RFC3168 and RFC4301. However,
nonce coverage is still not perfect, as this would have led to a
safety problem in another case. Both are corner-cases, so discussion
of the compromise between them is deferred to <xref
target="ecntun_Compromise" />.</t>
<t hangText="Covert channel not turned off:">A legacy (RFC3168)
tunnel ingress could ask an RFC3168 egress to turn off ECN
processing as well as itself turning off ECN. An egress compliant
with the present specification will agree to such a request from a
legacy ingress, 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 process them as normal, so it will actually still copy
congestion markings from the outer to the outgoing header. Referring
for example to <xref target="ecntun_Fig_IPsec_Tunnel_Scenario" />
(<xref target="ecntun_Security_Constraints" />), although the tunnel
ingress 'I' will set all ECN fields in outer headers to Not-ECT, 'M'
could still toggle CE or ECT(1) on and off to communicate covertly
with 'B', because we have specified that 'E' only has one mode
regardless of what mode it says it has negotiated. We could have
specified that 'E' should have a limited functionality mode and
check for such behaviour. But we decided not to add the extra
complexity of two modes on a compliant tunnel egress merely to cater
for an historic security concern that is now considered
manageable.</t>
</list></t>
</section>
<!-- ================================================================ -->
<section anchor="ecntun_Conclusions" title="Conclusions">
<t>This document allows tunnels to propagate an extra level of
congestion severity. It uses previously unused combinations of inner and
outer header to augment the rules for calculating the ECN field when
decapsulating IP packets at the egress of IPsec (RFC4301) and non-IPsec
(RFC3168) tunnels.</t>
<t>This document also updates the ingress tunnelling encapsulation of
RFC3168 ECN to bring all IP in IP tunnels into line with the new
behaviour in the IPsec architecture of RFC4301, which copies rather than
resets the ECN field when creating outer headers.</t>
<t>The need for both these updated behaviours was triggered by the
introduction of pre-congestion notification (PCN) onto the IETF
standards track. Operators wanting to support PCN or other alternate ECN
schemes that use an extra severity level can require that their tunnels
comply with the present specification. This is not a fork in the RFC
series, it is an update that can be deployed first by those that need
it, and subsequently by all tunnel endpoint implementations during
general code maintenance. It is backward compatible with all previous
tunnelling behaviours, so existing single severity level schemes will
continue to work as before, but support for two severity levels will
gradually be added to the Internet.</t>
<t>The new rules propagate changes to the ECN field across tunnel
end-points that previously blocked them to restrict the bandwidth of a
potential covert channel. Limiting the channel's bandwidth to 2 bits per
packet is now considered sufficient.</t>
<t>At the same time as removing these legacy constraints, the
opportunity has been taken to draw together diverging tunnel
specifications into a single consistent behaviour. Then any tunnel can
be deployed unilaterally, and it will support the full range of
congestion control and management schemes without any modes or
configuration. Further, any host or router can expect the ECN field 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 that
would otherwise be confounded by ambiguity.</t>
</section>
<!-- ================================================================ -->
<section anchor="ecntun_Acknowledgements" title="Acknowledgements">
<t>Thanks to David Black for his insightful reviews and patient
explanations of better ways to think about function placement and
alarms. Thanks to David and to Anil Agarwal for pointing out cases where
it is safe to forward CU combinations of headers. Also thanks to Arnaud
Jacquet for the idea for <xref target="ecntun_Tunnel_Contribution" />.
Thanks to Gorry Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby
Moncaster, Sally Floyd, Alfred Hönes, Gabriele Corliano, Ingemar
Johansson, Philip Eardley and David Harrington for their thoughts and
careful review comments, and to Stephen Hanna, Ben Campbell and members
of the IESG for respectively conducting the Security Directorate,
General Area and IESG reviews.</t>
<t>Bob Briscoe is partly funded by Trilogy, a research project
(ICT-216372) supported by the European Community under its Seventh
Framework Programme. </t>
</section>
<!-- ================================================================ -->
<note title="Comments Solicited (to be removed by the RFC Editor):">
<t>Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors.</t>
</note>
</middle>
<back>
<!-- ================================================================ -->
<references title="Normative References">
<?rfc include="reference.RFC.2003" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include='reference.RFC.3168'?>
<?rfc include='reference.RFC.4301'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2401'?>
<?rfc include='reference.RFC.2474'?>
<?rfc include='reference.RFC.2481'?>
<?rfc include='reference.RFC.2983'?>
<?rfc include='reference.RFC.3540'?>
<?rfc include='reference.RFC.4306'?>
<?rfc include='reference.RFC.4774'?>
<?rfc include='reference.RFC.5129'?>
<?rfc include='reference.RFC.5559'?>
<?rfc include='reference.RFC.5659'?>
<?rfc include='reference.RFC.5696'?>
<?rfc include='reference.RFC.5670'?>
<?rfc include='reference.I-D.ietf-pcn-3-in-1-encoding'?>
<reference anchor="VCP"
target="http://doi.acm.org/10.1145/1080091.1080098">
<front>
<title>One more bit is enough</title>
<author fullname="Yong Xia" initials="Y." surname="Xia">
<organization></organization>
</author>
<author fullname="Lakshminarayanan Subramanian" initials="L."
surname="Subramanian">
<organization></organization>
</author>
<author fullname="Ion Stoica" initials="I." surname="Stoica">
<organization></organization>
</author>
<author fullname="Shivkumar Kalyanaraman" initials="S."
surname="Kalyanaraman">
<organization></organization>
</author>
<date month="" year="2005" />
</front>
<seriesInfo name="Proc. SIGCOMM'05, ACM CCR" value="35(4)37--48" />
<format target="http://conferences.sigcomm.org/sigcomm/2005/paper-XiaSub.pdf"
type="PDF" />
</reference>
</references>
<section anchor="ecntun_Early_History" title="Early ECN Tunnelling RFCs">
<t>IP in IP tunnelling was originally defined in <xref
target="RFC2003"></xref>. On encapsulation, the incoming header was
copied to the outer and on decapsulation the outer was simply discarded.
Initially, IPsec tunnelling <xref target="RFC2401"></xref> followed the
same behaviour.</t>
<t>When ECN was introduced experimentally in <xref
target="RFC2481"></xref>, legacy (RFC2003 or RFC2401) tunnels would have
discarded any congestion markings added to the outer header, so RFC2481
introduced rules for calculating the outgoing header from a combination
of the inner and outer on decapsulation. RC2481 also introduced a second
mode for IPsec tunnels, which turned off ECN processing (Not-ECT) in the
outer header on encapsulation because an RFC2401 decapsulator would
discard the outer on decapsulation. For RFC2401 IPsec this had the
side-effect of completely blocking the covert channel.</t>
<t>In RFC2481 the ECN field was defined as two separate bits. But when
ECN moved from the experimental to the standards track <xref
target="RFC3168"></xref>, the ECN field was redefined as four
codepoints. This required a different calculation of the ECN field from
that used in RFC2481 on decapsulation. RFC3168 also had two modes; a
'full functionality mode' that restricted the covert channel as much as
possible but still allowed ECN to be used with IPsec, and another that
completely turned off ECN processing across the tunnel. This 'limited
functionality mode' both offered a way for operators to completely block
the covert channel and allowed an RFC3168 ingress to interwork with a
legacy tunnel egress (RFC2481, RFC2401 or RFC2003).</t>
<t>The present specification includes a similar compatibility mode to
interwork safely with tunnels compliant with any of these three earlier
RFCs. However, unlike RFC3168, it is only a mode of the ingress, as
decapsulation behaviour is the same in either case.</t>
</section>
<section anchor="ecntun_Design_Constraints" title="Design Constraints">
<t>Tunnel processing of a congestion notification field has to meet
congestion control and management needs without creating new information
security vulnerabilities (if information security is required). This
appendix documents the analysis of the tradeoffs between these factors
that led to the new encapsulation rules in <xref
target="ecntun_Default_Ingress_Behaviour"></xref>.</t>
<section anchor="ecntun_Security_Constraints"
title="Security Constraints">
<t>Information security can be assured by using various end to end
security solutions (including IPsec in transport mode <xref
target="RFC4301"></xref>), but a commonly used scenario involves the
need to communicate between two physically protected domains across
the public Internet. In this case there are certain management
advantages to using IPsec in tunnel mode solely across the publicly
accessible part of the path. The path followed by a packet then
crosses security 'domains'; the ones protected by physical or other
means before and after the tunnel and the one protected by an IPsec
tunnel across the otherwise unprotected domain. The scenario in <xref
target="ecntun_Fig_IPsec_Tunnel_Scenario"></xref> will be used where
endpoints 'A' and 'B' communicate through a tunnel. The tunnel ingress
'I' and egress 'E' are within physically protected edge domains, while
the tunnel spans an unprotected internetwork where there may be 'men
in the middle', M.</t>
<?rfc needLines="12"?>
<figure align="center" anchor="ecntun_Fig_IPsec_Tunnel_Scenario"
title="IPsec Tunnel Scenario">
<preamble></preamble>
<artwork><![CDATA[ physically unprotected physically
<-protected domain-><--domain--><-protected domain->
+------------------+ +------------------+
| | M | |
| A-------->I=========>==========>E-------->B |
| | | |
+------------------+ +------------------+
<----IPsec secured---->
tunnel
]]></artwork>
<postamble></postamble>
</figure>
<t>IPsec encryption is typically used to prevent 'M' seeing messages
from 'A' to 'B'. IPsec authentication is used to prevent 'M'
masquerading as the sender of messages from 'A' to 'B' or altering
their contents. 'I' can use IPsec tunnel mode to allow 'A' to
communicate with 'B', but impose encryption to prevent 'A' leaking
information to 'M'. Or 'E' can insist that 'I' uses tunnel mode
authentication to prevent 'M' communicating information to 'B'.</t>
<t>Mutable IP header fields such as the ECN field (as well as the
TTL/Hop Limit and DS fields) cannot be included in the cryptographic
calculations of IPsec. Therefore, if 'I' copies these mutable fields
into the outer header that is exposed across the tunnel it will have
allowed a covert channel from 'A' to M that bypasses its encryption of
the inner header. And if 'E' copies these fields from the outer header
to the inner, even if it validates authentication from 'I', it will
have allowed a covert channel from 'M' to 'B'.</t>
<t>ECN at the IP layer is designed to carry information about
congestion from a congested resource towards downstream nodes.
Typically a downstream transport might feed the information back
somehow to the point upstream of the congestion that can regulate the
load on the congested resource, but other actions are possible [<xref
format="counter" target="RFC3168"></xref>; section 6]. In terms of the
above unicast scenario, ECN effectively intends to create an
information channel (for congestion signalling) from 'M' to 'B' (for
'B' to feed back to 'A'). Therefore the goals of IPsec and ECN are
mutually incompatible, requiring some compromise.</t>
<t>With respect to using the DS or ECN fields as covert channels,
section 5.1.2 of RFC4301 says, "controls are provided to manage the
bandwidth of this channel". Using the ECN processing rules of RFC4301,
the channel bandwidth is two bits per datagram from 'A' to 'M' and one
bit per datagram from 'M' to 'A' (because 'E' limits the combinations
of the 2-bit ECN field that it will copy). In both cases the covert
channel bandwidth is further reduced by noise from any real congestion
marking. RFC4301 implies that these covert channels are sufficiently
limited to be considered a manageable threat. However, with respect to
the larger (6b) DS field, the same section of RFC4301 says not copying
is the default, but a configuration option can allow copying "to allow
a local administrator to decide whether the covert channel provided by
copying these bits outweighs the benefits of copying". Of course, an
administrator considering copying of the DS field has to take into
account that it could be concatenated with the ECN field giving an 8b
per datagram covert channel.</t>
<t>For tunnelling the 6b Diffserv field two conceptual models have had
to be defined so that administrators can trade off security against
the needs of traffic conditioning <xref target="RFC2983"></xref>:<list
style="hanging">
<t hangText="The uniform model:">where the Diffserv field is
preserved end-to-end by copying into the outer header on
encapsulation and copying from the outer header on
decapsulation.</t>
<t hangText="The pipe model:">where the outer header is
independent of that in the inner header so it hides the Diffserv
field of the inner header from any interaction with nodes along
the tunnel.</t>
</list></t>
<t>However, for ECN, the new IPsec security architecture in RFC4301
only standardised one tunnelling model equivalent to the uniform
model. It deemed that simplicity was more important than allowing
administrators the option of a tiny increment in security, especially
given not copying congestion indications could seriously harm
everyone's network service.</t>
</section>
<section anchor="ecntun_Ctrl_Constraints" title="Control Constraints">
<t>Congestion control requires that any congestion notification marked
into packets by a resource will be able to traverse a feedback loop
back to a function capable of controlling the load on that resource.
To be precise, rather than calling this function the data source, it
will be called the Load Regulator. This allows for exceptional cases
where load is not regulated by the data source, but usually the two
terms will be synonymous. Note the term "a function <spanx
style="emph">capable of</spanx> controlling the load" deliberately
includes a source application that doesn't actually control the load
but ought to (e.g. an application without congestion control that uses
UDP).</t>
<?rfc needLines="6"?>
<figure align="center" anchor="ecntun_Fig_Tunnel_Scenario"
title="Simple Tunnel Scenario">
<preamble></preamble>
<artwork><![CDATA[
A--->R--->I=========>M=========>E-------->B
]]></artwork>
<postamble></postamble>
</figure>
<t>A similar tunnelling scenario to the IPsec one just described will
now be considered, but without the different security domains, because
the focus now shifts to whether the control loop and management
monitoring work (<xref target="ecntun_Fig_Tunnel_Scenario"></xref>).
If resources in the tunnel are to be able to explicitly notify
congestion and the feedback path is from 'B' to 'A', it will certainly
be necessary for 'E' to copy any CE marking from the outer header to
the inner header for onward transmission to 'B', otherwise congestion
notification from resources like 'M' cannot be fed back to the Load
Regulator ('A'). But it does not seem necessary for 'I' to copy CE
markings from the inner to the outer header. For instance, if resource
'R' is congested, it can send congestion information to 'B' using the
congestion field in the inner header without 'I' copying the
congestion field into the outer header and 'E' copying it back to the
inner header. 'E' can still write any additional congestion marking
introduced across the tunnel into the congestion field of the inner
header.</t>
<t>All this shows that 'E' can preserve the control loop irrespective
of whether 'I' copies congestion notification into the outer header or
resets it.</t>
<t>That is the situation for existing control arrangements but,
because copying reveals more information, it would open up
possibilities for better control system designs. For instance,
resetting CE marking on encapsulation breaks the standards track PCN
congestion marking scheme <xref target="RFC5670"></xref>. It ends up
removing excessive amounts of traffic unnecessarily. Whereas copying
CE markings at ingress leads to the correct control behaviour.</t>
</section>
<section anchor="ecntun_Mgmt_Constraints" title="Management Constraints">
<t>As well as control, there are also management constraints.
Specifically, a management system may monitor congestion markings in
passing packets, perhaps at the border between networks as part of a
service level agreement. For instance, monitors at the borders of
autonomous systems may need to measure how much congestion has
accumulated so far along the path, perhaps to determine between them
how much of the congestion is contributed by each domain.</t>
<t>In this document the baseline of congestion marking (or the
Congestion Baseline) is defined as the source of the layer that
created (or most recently reset) the congestion notification field.
When monitoring congestion it would be desirable if the Congestion
Baseline did not depend on whether packets were tunnelled or not.
Given some tunnels cross domain borders (e.g. consider M in <xref
target="ecntun_Fig_Tunnel_Scenario"></xref> is monitoring a border),
it would therefore be desirable for 'I' to copy congestion accumulated
so far into the outer headers, so that it is exposed across the
tunnel.</t>
<t>For management purposes it might be useful for the tunnel egress to
be able to monitor whether congestion occurred across a tunnel or
upstream of it. Superficially it appears that copying congestion
markings at the ingress would make this difficult, whereas it was
straightforward when an RFC3168 ingress reset them. However, <xref
target="ecntun_Tunnel_Contribution"></xref> gives a simple and precise
method for a tunnel egress to infer the congestion level introduced
across a tunnel. It works irrespective of whether the ingress copies
or resets congestion markings.</t>
</section>
</section>
<section anchor="ecntun_Tunnel_Contribution"
title="Contribution to Congestion across a Tunnel">
<t>This specification mandates that a tunnel ingress determines the ECN
field of each new outer tunnel header by copying the arriving header.
Concern has been expressed that this will make it difficult for the
tunnel egress to monitor congestion introduced only along a tunnel,
which is easy if the outer ECN field is reset at a tunnel ingress
(RFC3168 full functionality mode). However, in fact copying CE marks at
ingress will still make it easy for the egress to measure congestion
introduced across a tunnel, as illustrated below.</t>
<t>Consider 100 packets measured at the egress. Say it measures that 30
are CE marked in the inner and outer headers and 12 have additional CE
marks in the outer but not the inner. This means packets arriving at the
ingress had already experienced 30% congestion. However, it does not
mean there was 12% congestion across the tunnel. The correct calculation
of congestion across the tunnel is p_t = 12/(100-30) = 12/70 = 17%. This
is easy for the egress to measure. It is simply the proportion of
packets not marked in the inner header (70) that have a CE marking in
the outer header (12). This technique works whether the ingress copies
or resets CE markings, so it can be used by an egress that is not sure
which RFC the ingress complies with.</t>
<t><xref target="ecntun_Fig_Tunnel_Contrib"></xref> illustrates this in
a combinatorial probability diagram. The square represents 100 packets.
The 30% division along the bottom represents marking before the ingress,
and the p_t division up the side represents marking introduced across
the tunnel.</t>
<figure anchor="ecntun_Fig_Tunnel_Contrib"
title="Tunnel Marking of Packets Already Marked at Ingress">
<preamble></preamble>
<artwork><![CDATA[ ^ outer header marking
|
100% +-----+---------+ The large square
| | | represents 100 packets
| 30 | |
| | | p_t = 12/(100-30)
p_t + +---------+ = 12/70
| | 12 | = 17%
0 +-----+---------+--->
0 30% 100% inner header marking]]></artwork>
<postamble></postamble>
</figure>
<t></t>
</section>
<section anchor="ecntun_Compromise"
title="Compromise on Decap with ECT(1) Inner and ECT(0) Outer">
<t>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
RFC4301 both say the outer should be ignored when decapsulating such a
packet. This appendix explains why it was decided not to change this
advice.</t>
<t>In summary, ECT(0) always means 'not congested' and ECT(1) may imply
the same <xref target="RFC3168"></xref> or it may imply a higher
severity congestion signal <xref target="RFC4774"></xref>, <xref
target="I-D.ietf-pcn-3-in-1-encoding"></xref>, depending on the
transport in use. Whether they mean the same or not, at the ingress the
outer should have started the same as the inner and only a broken or
compromised router could have changed the outer to ECT(0).</t>
<t>The decapsulator can detect this anomaly. But the question is, should
it correct the anomaly by ignoring the outer, or should it reveal the
anomaly to the end-to-end transport by forwarding the outer?</t>
<t>On balance, it was decided that the decapsulator should correct the
anomaly, but log the event and optionally raise an alarm. This is the
safe action if ECT(1) is being used as a more severe marking than
ECT(0), because it passes the more severe signal to the transport.
However, it is not a good idea to hide anomalies, which is why an
optional alarm is suggested. It should be noted that this anomaly may be
the result of two changes to the outer: a broken or compromised router
within the tunnel might be erasing congestion markings introduced
earlier in the same tunnel by a congested router. In this case, the
anomaly would be losing congestion signals, which needs immediate
attention.</t>
<t>The original reason for defining ECT(0) and ECT(1) as equivalent was
so that the data source could use the ECN nonce <xref
target="RFC3540"></xref> to detect if congestion signals were being
erased. However, in this case, the decapsulator does not need a nonce to
detect any anomalies introduced within the tunnel, because it has the
inner as a record of the header at the ingress. Therefore, it was
decided that the best compromise would be to give precedence to solving
the safety issue over revealing the anomaly, because the anomaly could
at least be detected and dealt with internally.</t>
<t>Superficially, the opposite case where the inner and outer carry
different ECT values, but with an ECT(1) outer and ECT(0) inner, seems
to require a similar compromise. However, because that case is reversed,
no compromise is necessary; it is best to forward the outer whether the
transport expects the ECT(1) to mean a higher severity than ECT(0) or
the same severity. Forwarding the outer either 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).</t>
</section>
<section title="Open Issues">
<t>The new decapsulation behaviour defined in <xref
target="ecntun_Default_Egress_Behaviour"></xref> adds support for
propagation of 2 severity levels of congestion. However transports have
no way to discover whether there are any legacy 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 support, but this remains an
open issue that will have to be addressed in any future standards action
to define an end-to-end scheme that requires 2-severity levels of
congestion. PCN avoids this problem because it is only for a controlled
region, so all legacy tunnels can be upgraded by the same operator that
deploys PCN.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 01:03:37 |