< draft-ietf-tsvwg-ecn-tunnel-06.txt   draft-ietf-tsvwg-ecn-tunnel-07.txt >
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft BT Internet-Draft BT
Updates: 3168, 4301 December 20, 2009 Updates: 3168, 4301 February 11, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: June 23, 2010 Expires: August 15, 2010
Tunnelling of Explicit Congestion Notification Tunnelling of Explicit Congestion Notification
draft-ietf-tsvwg-ecn-tunnel-06 draft-ietf-tsvwg-ecn-tunnel-07
Abstract Abstract
This document redefines how the explicit congestion notification This document redefines how the explicit congestion notification
(ECN) field of the IP header should be constructed on entry to and (ECN) field of the IP header should be constructed on entry to and
exit from any IP in IP tunnel. On encapsulation it updates RFC3168 exit from any IP in IP tunnel. On encapsulation it updates RFC3168
to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec
ECN processing. On decapsulation it updates both RFC3168 and RFC4301 ECN processing. On decapsulation it updates both RFC3168 and RFC4301
to add new behaviours for previously unused combinations of inner and to add new behaviours for previously unused combinations of inner and
outer header. The new rules ensure the ECN field is correctly outer header. The new rules ensure the ECN field is correctly
skipping to change at page 2, line 9 skipping to change at page 2, line 9
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 23, 2010. This Internet-Draft will expire on August 15, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 12 3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 12
3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 12 3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 12
3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 13 3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 13
4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 14 4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 14
4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 14 4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 15
4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 15 4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 15
4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 17 4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 17
4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 18 4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 19
5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 19 5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 20
5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 19 5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 20
5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 20 5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 21
5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 20 5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 22
5.3.1. Motivation for Changing Encapsulation . . . . . . . . 21 5.3.1. Motivation for Changing Encapsulation . . . . . . . . 22
5.3.2. Motivation for Changing Decapsulation . . . . . . . . 22 5.3.2. Motivation for Changing Decapsulation . . . . . . . . 23
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 24 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 25
6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 24 6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 25
6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 25 6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 26
6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 25 6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 26
7. Design Principles for Alternate ECN Tunnelling Semantics . . . 26 7. Design Principles for Alternate ECN Tunnelling Semantics . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 33 Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 34
Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 33 Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 35
B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 33 B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 35
B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 35 B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 37
B.3. Management Constraints . . . . . . . . . . . . . . . . . . 36 B.3. Management Constraints . . . . . . . . . . . . . . . . . . 38
Appendix C. Contribution to Congestion across a Tunnel . . . . . 37 Appendix C. Contribution to Congestion across a Tunnel . . . . . 38
Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN . . . 38 Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN
Appendix E. Why Resetting ECN on Encapsulation Impedes PCN . . . 39 (to be removed before publication) . . . . . . . . . 39
Appendix E. Why Resetting ECN on Encapsulation Impedes PCN
(to be removed before publication) . . . . . . . . . 41
Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0) Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0)
Outer . . . . . . . . . . . . . . . . . . . . . . . . 40 Outer . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . . 41 Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . . 42
Request to the RFC Editor (to be removed on publication): Request to the RFC Editor (to be removed on publication):
In the RFC index, RFC3168 should be identified as an update to In the RFC index, RFC3168 should be identified as an update to
RFC2003. RFC4301 should be identified as an update to RFC3168. RFC2003. RFC4301 should be identified as an update to RFC3168.
Changes from previous drafts (to be removed by the RFC Editor) Changes from previous drafts (to be removed by the RFC Editor)
Full text differences between IETF draft versions are available at Full text differences between IETF draft versions are available at
<http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-tunnel/>, and <http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-tunnel/>, and
between earlier individual draft versions at between earlier individual draft versions at
<http://www.briscoe.net/pubs.html#ecn-tunnel> <http://www.briscoe.net/pubs.html#ecn-tunnel>
From ietf-05 to ietf-06 (current): From ietf-06 to ietf-07 (current):
* Emphasised that this is the opposite of a fork in the RFC
series.
* Altered Section 5 to focus on updates to implementations of
earlier RFCs, rather than on updates to the text of the RFCs.
* 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.
* Added question for Security Directorate reviewers on whether to
mention a corner-case concerning manual keying of IPsec
tunnels.
* Minor clarifications, updated references and updated acks.
* Marked two appendices about PCN motivations for removal before
publication.
From ietf-05 to ietf-06:
* Minor textual clarifications and corrections. * Minor textual clarifications and corrections.
From ietf-04 to ietf-05: From ietf-04 to ietf-05:
* Functional changes: * Functional changes:
+ Section 4.2: ECT(1) outer with Not-ECT inner: reverted to + Section 4.2: ECT(1) outer with Not-ECT inner: reverted to
forwarding as Not-ECT (as in RFC3168 & RFC4301), rather than forwarding as Not-ECT (as in RFC3168 & RFC4301), rather than
dropping. dropping.
skipping to change at page 9, line 44 skipping to change at page 10, line 15
endpoints--just enough for the basic ECN mechanism to work. This was endpoints--just enough for the basic ECN mechanism to work. This was
due to concerns that the ECN field might be toggled to communicate due to concerns that the ECN field might be toggled to communicate
between a secure site and someone on the public Internet--a covert between a secure site and someone on the public Internet--a covert
channel. This was because a mutable field like ECN cannot be channel. This was because a mutable field like ECN cannot be
protected by IPsec's integrity mechanisms--it has to be able to protected by IPsec's integrity mechanisms--it has to be able to
change as it traverses the Internet. change as it traverses the Internet.
Nonetheless, the latest IPsec architecture [RFC4301] considered a Nonetheless, the latest IPsec architecture [RFC4301] considered a
bandwidth limit of 2 bits per packet on a covert channel made it a bandwidth limit of 2 bits per packet on a covert channel made it a
manageable risk. Therefore, for simplicity, an RFC4301 ingress manageable risk. Therefore, for simplicity, an RFC4301 ingress
copied the whole ECN field to encapsulate a packet. It also copied the whole ECN field to encapsulate a packet. It dispensed
dispensed with the two modes of RFC3168, one which partially copied with the two modes of RFC3168, one which partially copied the ECN
the ECN field, and the other which blocked all propagation of ECN field, and the other which blocked all propagation of ECN changes.
changes.
Unfortunately, this entirely reasonable sequence of standards actions Unfortunately, this entirely reasonable sequence of standards actions
resulted in a perverse outcome; non-IPsec tunnels (RFC3168) blocked resulted in a perverse outcome; non-IPsec tunnels (RFC3168) blocked
the 2-bit covert channel, while IPsec tunnels (RFC4301) did not--at 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 least not at the ingress. At the egress, both IPsec and non-IPsec
tunnels still partially restricted propagation of the full ECN field. tunnels still partially restricted propagation of the full ECN field.
The trigger for the changes in this document was the introduction of The trigger for the changes in this document was the introduction of
pre-congestion notification (PCN [RFC5670]) to the IETF standards pre-congestion notification (PCN [RFC5670]) to the IETF standards
track. PCN needs the ECN field to be copied at a tunnel ingress and 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 it needs four states of congestion signalling to be propagated at the
egress, but pre-existing tunnels only propagate three in the ECN egress, but pre-existing tunnels only propagate three in the ECN
field. field.
This document draws on currently unused (CU) combinations of inner This document draws on currently unused (CU) combinations of inner
and outer headers to add tunnelling of four-state congestion and outer headers to add tunnelling of four-state congestion
signalling to RFC3168 and RFC4301. Operators of tunnels who signalling to RFC3168 and RFC4301. Operators of tunnels who
specifically want to support four states can require that all their specifically want to support four states can require that all their
tunnels comply with this specification. Nonetheless, all tunnel tunnels comply with this specification. However, this is not a fork
endpoint implementations (RFC4301, RFC3168, RFC2481, RFC2401, in the RFC series. It is an update that can be deployed first by
RFC2003) can safely be updated to this new specification as part of those that need it, and subsequently by all tunnel endpoint
general code maintenance. This will gradually add support for four 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 congestion states to the Internet. Existing three state schemes will
continue to work as before. continue to work as before.
At the same time as harmonising covert channel constraints, the In fact, this document is the opposite of a fork. At the same time
opportunity has been taken to draw together diverging tunnel as supporting a fourth state, the opportunity has been taken to draw
specifications into a single consistent behaviour. Then any tunnel together divergent ECN tunnelling specifications into a single
can be deployed unilaterally, and it will support the full range of consistent behaviour, harmonising differences such as perverse covert
congestion control and management schemes without any modes or channel treatment. Then any tunnel can be deployed unilaterally, and
configuration. Further, any host or router can expect the ECN field it will support the full range of congestion control and management
to behave in the same way, whatever type of tunnel might intervene in schemes without any modes or configuration. Further, any host or
the path. router can expect the ECN field to behave in the same way, whatever
type of tunnel might intervene in the path.
1.1. Scope 1.1. Scope
This document only concerns wire protocol processing of the ECN field This document only concerns wire protocol processing of the ECN field
at tunnel endpoints and makes no changes or recommendations at tunnel endpoints and makes no changes or recommendations
concerning algorithms for congestion marking or congestion response. concerning algorithms for congestion marking or congestion response.
This document specifies common ECN field processing at encapsulation This document specifies common ECN field processing at encapsulation
and decapsulation for any IP in IP tunnelling, whether IPsec or non- and decapsulation for any IP in IP tunnelling, whether IPsec or non-
IPsec tunnels. It applies irrespective of whether IPv4 or IPv6 is IPsec tunnels. It applies irrespective of whether IPv4 or IPv6 is
used for either of the inner and outer headers. It applies for used for either of the inner and outer headers. It applies for
packets with any destination address type, whether unicast or packets with any destination address type, whether unicast or
multicast. It applies as the default for all Diffserv per-hop multicast. It applies as the default for all Diffserv per-hop
behaviours (PHBs), unless stated otherwise in the specification of a behaviours (PHBs), unless stated otherwise in the specification of a
PHB. It is intended to be a good trade off between somewhat PHB (but Section 4 strongly deprecates such exceptions). It is
conflicting security, control and management requirements. intended to be a good trade off between somewhat conflicting
security, control and management requirements.
[RFC2983] is a comprehensive primer on differentiated services and [RFC2983] is a comprehensive primer on differentiated services and
tunnels. Given ECN raises similar issues to differentiated services tunnels. Given ECN raises similar issues to differentiated services
when interacting with tunnels, useful concepts introduced in RFC2983 when interacting with tunnels, useful concepts introduced in RFC2983
are used throughout, with brief recaps of the explanations where are used throughout, with brief recaps of the explanations where
necessary. necessary.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 12, line 11 skipping to change at page 12, line 32
Copying ECN: On encapsulation, setting the ECN field of the new 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. outer header to be a copy of the ECN field in the incoming header.
Zeroing ECN: On encapsulation, clearing the ECN field of the new Zeroing ECN: On encapsulation, clearing the ECN field of the new
outer header to Not-ECT ("00"). outer header to Not-ECT ("00").
Resetting ECN: On encapsulation, setting the ECN field of the new 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 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 except the outer ECN field is set to the ECT(0) codepoint if the
incoming ECN field is CE ("11"). incoming ECN field is CE.
3. Summary of Pre-Existing RFCs 3. Summary of Pre-Existing RFCs
This section is informative not normative, as it recaps pre-existing This section is informative not normative, as it recaps pre-existing
RFCs. Earlier relevant RFCs that were either experimental or RFCs. Earlier relevant RFCs that were either experimental or
incomplete with respect to ECN tunnelling (RFC2481, RFC2401 and incomplete with respect to ECN tunnelling (RFC2481, RFC2401 and
RFC2003) are briefly outlined in Appendix A. The question of whether RFC2003) are briefly outlined in Appendix A. The question of whether
tunnel implementations used in the Internet comply with any of these tunnel implementations used in the Internet comply with any of these
RFCs is not discussed. RFCs is not discussed.
skipping to change at page 13, line 47 skipping to change at page 14, line 25
+---------+---------+------------+------------+------------+ +---------+---------+------------+------------+------------+
| Outgoing Header | | Outgoing Header |
+------------------------------------------------+ +------------------------------------------------+
Figure 2: IP in IP Decapsulation; Recap of Pre-existing Behaviour Figure 2: IP in IP Decapsulation; Recap of Pre-existing Behaviour
The behaviour in the table derives from the logic given in RFC3168 The behaviour in the table derives from the logic given in RFC3168
and RFC4301, briefly recapped as follows: and RFC4301, briefly recapped as follows:
o On decapsulation, if the inner ECN field is Not-ECT the outer is o On decapsulation, if the inner ECN field is Not-ECT the outer is
discarded. RFC3168 (but not RFC4301) also specified that the ignored. RFC3168 (but not RFC4301) also specified that the
decapsulator must drop a packet with a Not-ECT inner and CE in the decapsulator must drop a packet with a Not-ECT inner and CE in the
outer. outer.
o In all other cases, if the outer is CE, the outgoing ECN field is o 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 set to CE, but otherwise the outer is ignored and the inner is
used for the outgoing ECN field. used for the outgoing ECN field.
RFC3168 also made it an auditable event for an IPsec tunnel "if the RFC3168 also made it an auditable event for an IPsec tunnel "if the
ECN Field is changed inappropriately within an IPsec tunnel...". ECN Field is changed inappropriately within an IPsec tunnel...".
Inappropriate changes were not specifically enumerated. RFC4301 did Inappropriate changes were not specifically enumerated. RFC4301 did
skipping to change at page 14, line 29 skipping to change at page 15, line 4
codepoint. codepoint.
If these defaults do not meet a particular requirement, an alternate If these defaults do not meet a particular requirement, an alternate
ECN tunnelling scheme can be introduced as part of the definition of ECN tunnelling scheme can be introduced as part of the definition of
an alternate congestion marking scheme used by a specific Diffserv an alternate congestion marking scheme used by a specific Diffserv
PHB (see S.5 of [RFC3168] and [RFC4774]). When designing such PHB (see S.5 of [RFC3168] and [RFC4774]). When designing such
alternate ECN tunnelling schemes, the principles in Section 7 should alternate ECN tunnelling schemes, the principles in Section 7 should
be followed. However, alternate ECN tunnelling schemes are NOT be followed. However, alternate ECN tunnelling schemes are NOT
RECOMMENDED as the deployment burden of handling exceptional PHBs in RECOMMENDED as the deployment burden of handling exceptional PHBs in
implementations of all affected tunnels should not be underestimated. implementations of all affected tunnels should not be underestimated.
There is no requirement for a PHB definition to state anything about There is no requirement for a PHB definition to state anything about
ECN tunnelling behaviour if the default behaviour in the present ECN tunnelling behaviour if the default behaviour in the present
specification is sufficient. specification is sufficient.
4.1. Default Tunnel Ingress Behaviour 4.1. Default Tunnel Ingress Behaviour
Two modes of encapsulation are defined here; `normal mode' and Two modes of encapsulation are defined here; a REQUIRED `normal mode'
`compatibility mode', which is for backward compatibility with tunnel and a `compatibility mode', which is for backward compatibility with
decapsulators that do not understand ECN. Section 4.3 explains why tunnel decapsulators that do not understand ECN. Note that these are
two modes are necessary and specifies the circumstances in which it
is sufficient to solely implement normal mode. Note that these are
modes of the ingress tunnel endpoint only, not the whole tunnel. modes of the ingress tunnel endpoint only, not the whole tunnel.
Section 4.3 explains why two modes are necessary and specifies the
circumstances in which it is sufficient to solely implement normal
mode.
Whatever the mode, an encapsulator forwards the inner header without Whatever the mode, an encapsulator forwards the inner header without
changing the ECN field. changing the ECN field.
In normal mode an encapsulator compliant with this specification MUST In normal mode an encapsulator compliant with this specification MUST
construct the outer encapsulating IP header by copying the 2-bit ECN construct the outer encapsulating IP header by copying the 2-bit ECN
field of the incoming IP header. In compatibility mode it clears the 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 ECN field in the outer header to the Not-ECT codepoint (the IPv4
header checksum also changes whenever the ECN field is changed). header checksum also changes whenever the ECN field is changed).
These rules are tabulated for convenience in Figure 3. These rules are tabulated for convenience in Figure 3.
skipping to change at page 15, line 19 skipping to change at page 15, line 42
| Header) | Mode | Mode | | Header) | Mode | Mode |
+-----------------+---------------+---------------+ +-----------------+---------------+---------------+
| Not-ECT | Not-ECT | Not-ECT | | Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) | | ECT(0) | Not-ECT | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) | | ECT(1) | Not-ECT | ECT(1) |
| CE | Not-ECT | CE | | CE | Not-ECT | CE |
+-----------------+---------------+---------------+ +-----------------+---------------+---------------+
Figure 3: New IP in IP Encapsulation Behaviours Figure 3: New IP in IP Encapsulation Behaviours
An ingress in compatibility mode encapsulates packets identically to
an ingress in RFC3168's limited functionality mode. An ingress in
normal mode encapsulates packets identically to an RFC4301 IPsec
ingress.
4.2. Default Tunnel Egress Behaviour 4.2. Default Tunnel Egress Behaviour
To decapsulate the inner header at the tunnel egress, a compliant To decapsulate the inner header at the tunnel egress, a compliant
tunnel egress MUST set the outgoing ECN field to the codepoint at the tunnel egress MUST set the outgoing ECN field to the codepoint at the
intersection of the appropriate incoming inner header (row) and outer intersection of the appropriate incoming inner header (row) and outer
header (column) in Figure 4 (the IPv4 header checksum also changes header (column) in Figure 4 (the IPv4 header checksum also changes
whenever the ECN field is changed). There is no need for more than whenever the ECN field is changed). There is no need for more than
one mode of decapsulation, as these rules cater for all known one mode of decapsulation, as these rules cater for all known
requirements. requirements.
+---------+------------------------------------------------+ +---------+------------------------------------------------+
|Incoming | Incoming Outer Header | |Incoming | Incoming Outer Header |
| Inner +---------+------------+------------+------------+ | Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE | | Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+ +---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| drop(!!!)| | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| drop(!!!)|
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE | | ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE |
| CE | CE | CE | CE(!!!)| CE | | CE | CE | CE | CE(!!!)| CE |
+---------+---------+------------+------------+------------+ +---------+---------+------------+------------+------------+
skipping to change at page 16, line 9 skipping to change at page 16, line 28
Figure 4: New IP in IP Decapsulation Behaviour Figure 4: New IP in IP Decapsulation Behaviour
This table for decapsulation behaviour is derived from the following This table for decapsulation behaviour is derived from the following
logic: logic:
o If the inner ECN field is Not-ECT the decapsulator MUST NOT o If the inner ECN field is Not-ECT the decapsulator MUST NOT
propagate any other ECN codepoint onwards. This is because the propagate any other ECN codepoint onwards. This is because the
inner Not-ECT marking is set by transports that use drop as an inner Not-ECT marking is set by transports that use drop as an
indication of congestion and would not understand or respond to indication of congestion and would not understand or respond to
any other ECN codepoint [RFC4774]. In addition: any other ECN codepoint [RFC4774]. Specifically:
* If the inner ECN field is Not-ECT and the outer ECN field is CE * If the inner ECN field is Not-ECT and the outer ECN field is CE
the decapsulator MUST drop the packet. the decapsulator MUST drop the packet.
* If the inner ECN field is Not-ECT and the outer ECN field is * 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 Not-ECT, ECT(0) or ECT(1) the decapsulator MUST forward the
outgoing packet with the ECN field cleared to Not-ECT. outgoing packet with the ECN field cleared to Not-ECT.
o In all other cases where the inner supports ECN, the decapsulator o In all other cases where the inner supports ECN, the decapsulator
MUST set the outgoing ECN field to the more severe marking of the MUST set the outgoing ECN field to the more severe marking of the
skipping to change at page 17, line 15 skipping to change at page 17, line 34
approach is discussed in Appendix D and in the discussion of the ECN approach is discussed in Appendix D and in the discussion of the ECN
nonce [RFC3540] in Section 8, which in turn refers to Appendix F. nonce [RFC3540] in Section 8, which in turn refers to Appendix F.
4.3. Encapsulation Modes 4.3. Encapsulation Modes
Section 4.1 introduces two encapsulation modes, normal mode and Section 4.1 introduces two encapsulation modes, normal mode and
compatibility mode, defining their encapsulation behaviour (i.e. compatibility mode, defining their encapsulation behaviour (i.e.
header copying or zeroing respectively). Note that these are modes header copying or zeroing respectively). Note that these are modes
of the ingress tunnel endpoint only, not the tunnel as a whole. of the ingress tunnel endpoint only, not the tunnel as a whole.
A tunnel ingress MUST at least implement `normal mode' and, if it To comply with this specification, a tunnel ingress MUST at least
might be used with legacy tunnel egress nodes (RFC2003, RFC2401 or implement `normal mode'. Unless it will never be used with legacy
RFC2481 or the limited functionality mode of RFC3168), it MUST also tunnel egress nodes (RFC2003, RFC2401 or RFC2481 or the limited
implement `compatibility mode' for backward compatibility with tunnel functionality mode of RFC3168), an ingress MUST also implement
egresses that do not propagate explicit congestion notifications `compatibility mode' for backward compatibility with tunnel egresses
[RFC4774]. If the egress does support propagation of ECN (full that do not propagate explicit congestion notifications [RFC4774].
functionality mode of RFC3168 or RFC4301 or the present
specification), the ingress SHOULD use normal mode, in order to
support ECN where possible.
We can categorise the way that an ingress tunnel endpoint is paired We can categorise the way that an ingress tunnel endpoint is paired
with an egress as either: with an egress as either:
static: those paired together by prior configuration or; static: those paired together by prior configuration or;
dynamically discovered: those paired together by some form of tunnel dynamically discovered: those paired together by some form of tunnel
endpoint discovery, typically driven by the path taken by arriving endpoint discovery, typically finding an egress on the path taken
packets. by the first packet.
Static: Some implementations of encapsulator might be constrained to Static: Some implementations of encapsulator might always be
be statically deployed, and constrained to never be paired with a statically deployed, and constrained to never be paired with a
legacy decapsulator (RFC2003, RFC2401 or RFC2481 or the limited legacy decapsulator (RFC2003, RFC2401 or RFC2481 or the limited
functionality mode of RFC3168). In such a case, only normal mode functionality mode of RFC3168). In such a case, only normal mode
needs to be implemented. needs to be implemented.
For instance, RFC4301-compatible IPsec tunnel endpoints invariably For instance, RFC4301-compatible IPsec tunnel endpoints invariably
use IKEv2 [RFC4306] for key exchange, which was introduced alongside use IKEv2 [RFC4306] for key exchange, which was introduced
RFC4301. Therefore both endpoints of an RFC4301 tunnel can be sure alongside RFC4301. Therefore both endpoints of an RFC4301 tunnel
that the other end is RFC4301-compatible, because the tunnel is only can be sure that the other end is RFC4301-compatible, because the
formed after IKEv2 key management has completed, at which point both tunnel is only formed after IKEv2 key management has completed, at
ends will be RFC4301-compliant by definition. Further, an RFC4301 which point both ends will be RFC4301-compliant by definition.
encapsulator behaves identically to the normal mode of the present Therefore an IPsec tunnel ingress does not need compatibility
specification and does not need to implement compatibility mode as it mode, as it will never interact with legacy ECN tunnels. To
will never interact with legacy ECN tunnels. comply with the present specification, it only needs to implement
the required normal mode, which is identical to the pre-existing
RFC4301 behaviour.
Dynamic Discovery: This specification does not require or recommend Dynamic Discovery: This specification does not require or recommend
dynamic discovery and it does not define how dynamic negotiation dynamic discovery and it does not define how dynamic negotiation
might be done, but it recognises that proprietary tunnel endpoint might be done, but it recognises that proprietary tunnel endpoint
discovery protocols exist. It therefore sets down some constraints discovery protocols exist. It therefore sets down some
on discovery protocols to ensure safe interworking. constraints on discovery protocols to ensure safe interworking.
If dynamic tunnel endpoint discovery might pair an ingress with a If dynamic tunnel endpoint discovery might pair an ingress with a
legacy egress (RFC2003, RFC2401 or RFC2481 or the limited legacy egress (RFC2003, RFC2401 or RFC2481 or the limited
functionality mode of RFC3168), the ingress MUST implement both functionality mode of RFC3168), the ingress MUST implement both
normal and compatibility mode. If the tunnel discovery process is normal and compatibility mode. If the tunnel discovery process is
arranged to only ever find a tunnel egress that propagates ECN arranged to only ever find a tunnel egress that propagates ECN
(RFC3168 full functionality mode, RFC4301 or this present (RFC3168 full functionality mode, RFC4301 or this present
specification), then a tunnel ingress can be complaint with the specification), then a tunnel ingress can be complaint with the
present specification without implementing compatibility mode. present specification without implementing compatibility mode.
If a compliant tunnel ingress is discovering an egress, it MUST send While a compliant tunnel ingress is discovering an egress, it MUST
packets in compatibility mode in case the egress it discovers is a send packets in compatibility mode in case the egress it discovers
legacy egress. If, through the discovery protocol, the egress is a legacy egress. If, through the discovery protocol, the
indicates that it is compliant with the present specification, with egress indicates that it is compliant with the present
RFC4301 or with RFC3168 full functionality mode, the ingress can specification, with RFC4301 or with RFC3168 full functionality
switch itself into normal mode. If the egress denies compliance with mode, the ingress can switch itself into normal mode. If the
any of these or returns an error that implies it does not understand egress denies compliance with any of these or returns an error
a request to work to any of these ECN specifications, the tunnel that implies it does not understand a request to work to any of
ingress MUST remain in compatibility mode. these ECN specifications, the tunnel ingress MUST remain in
compatibility mode.
An ingress cannot claim compliance with this specification simply by If an ingress claims compliance with this specification it MUST NOT
permanently disabling ECN processing across the tunnel (i.e. only permanently disable ECN processing across the tunnel (i.e. only using
implementing compatibility mode). It is true that such a tunnel compatibility mode). It is true that such a tunnel ingress is at
ingress is at least safe with the ECN behaviour of any egress it may least safe with the ECN behaviour of any egress it may encounter, but
encounter, but it does not meet the aim of introducing ECN support to it does not meet the central aim of this specification: introducing
tunnels. ECN support to tunnels.
Implementation note: if a compliant node is the ingress for multiple Instead, if the ingress knows that the egress does support
tunnels, a mode setting will need to be stored for each tunnel propagation of ECN (full functionality mode of RFC3168 or RFC4301 or
ingress. However, if a node is the egress for multiple tunnels, none the present specification), it SHOULD use normal mode, in order to
of the tunnels will need to store a mode setting, because a compliant support ECN where possible. Note that this section started by saying
egress can only be in one mode. 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.
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.
4.4. Single Mode of Decapsulation 4.4. Single Mode of Decapsulation
A compliant decapsulator only has one mode of operation. However, if A compliant decapsulator only needs one mode of operation. However,
a complaint egress is implemented to be dynamically discoverable, it if a complaint egress is implemented to be dynamically discoverable,
may need to respond to discovery requests from various types of it may need to respond to discovery requests from various types of
legacy tunnel ingress. This specification does not define how legacy tunnel ingress. This specification does not define how
dynamic negotiation might be done by (proprietary) discovery dynamic negotiation might be done by (proprietary) discovery
protocols, but it sets down some constraints to ensure safe protocols, but it sets down some constraints to ensure safe
interworking. interworking.
Through the discovery protocol, a tunnel ingress compliant with the Through the discovery protocol, a tunnel ingress compliant with the
present specification might ask if the egress is compliant with the present specification might ask if the egress is compliant with the
present specification, with RFC4301 or with RFC3168 full present specification, with RFC4301 or with RFC3168 full
functionality mode. Or an RFC3168 tunnel ingress might try to functionality mode. Or an RFC3168 tunnel ingress might try to
negotiate to use limited functionality or full functionality mode negotiate to use limited functionality or full functionality mode
skipping to change at page 19, line 26 skipping to change at page 20, line 10
A compliant tunnel egress SHOULD raise a warning alarm about any A compliant tunnel egress SHOULD raise a warning alarm about any
requests to enter modes it does not recognise but, for 'forward requests to enter modes it does not recognise but, for 'forward
compatibility' with standards actions possibly defined after it was compatibility' with standards actions possibly defined after it was
implemented, it SHOULD continue operating. implemented, it SHOULD continue operating.
5. Updates to Earlier RFCs 5. Updates to Earlier RFCs
5.1. Changes to RFC4301 ECN processing 5.1. Changes to RFC4301 ECN processing
Ingress: An RFC4301 IPsec encapsulator is not changed at all by the Ingress: An RFC4301 IPsec encapsulator is not changed at all by the
present specification present specification. It uses the normal mode of the present
specification, which defines packet encapsulation identically to
RFC4301.
Egress: The new decapsulation behaviour in Figure 4 updates RFC4301. Egress: An RFC4301 egress will need to be updated to the new
However, it solely updates combinations of inner and outer that decapsulation behaviour in Figure 4, in order to comply with the
would never result from any protocol defined in the RFC series so present specification. However, the changes are backward
far, even though they were catered for in RFC4301 for compatible; combinations of inner and outer that result from any
completeness. Therefore, the present specification adds new protocol defined in the RFC series so far are unaffected. Only
behaviours to RFC4301 decapsulation without altering existing combinations that have never been used have been changed,
behaviours. The following specific updates have been made: effectively adding new behaviours to RFC4301 decapsulation without
altering existing behaviours. The following specific updates have
been made:
* The outer, not the inner, is propagated when the outer is * The outer, not the inner, is propagated when the outer is
ECT(1) and the inner is ECT(0); ECT(1) and the inner is ECT(0);
* A packet with Not-ECT in the inner and an outer of CE is * A packet with Not-ECT in the inner and an outer of CE is
dropped rather than forwarded as Not-ECT; dropped rather than forwarded as Not-ECT;
* Certain combinations of inner and outer ECN field have been * Certain combinations of inner and outer ECN field have been
identified as currently unused. These can trigger logging identified as currently unused. These can trigger logging
and/or raise alarms. and/or raise alarms.
Modes: RFC4301 does not need modes and is not updated by the modes Modes: RFC4301 tunnel endpoints do not need modes and are not
in the present specification. The normal mode of encapsulation is updated by the modes in the present specification. Effectively an
unchanged from RFC4301 encapsulation and an RFC4301 IPsec ingress RFC4301 IPsec ingress solely uses the REQUIRED normal mode of
will never need compatibility mode as explained in Section 4.3 encapsulation, which is unchanged from RFC4301 encapsulation. It
(except in one corner-case described below). will never need the OPTIONAL compatibility mode as explained in
Section 4.3 (except in one corner-case described below).
{ToDo: Question to Security Directorate: Although this corner-case
theoretically exists, it would be preferable to delete any mention
of it for simplicity & clarity. Agree?}
One corner case can exist where an RFC4301 ingress does not use One corner case can exist where an RFC4301 ingress does not use
IKEv2, but uses manual keying instead. Then an RFC4301 ingress IKEv2, but uses manual keying instead. Then an RFC4301 ingress
could conceivably be configured to tunnel to an egress with could conceivably be configured to tunnel to an egress with
limited functionality ECN handling. Strictly, for this corner- limited functionality ECN handling. Strictly, for this corner-
case, the requirement to use compatibility mode in this case, the requirement to use compatibility mode in this
specification updates RFC4301. However, this is such a remote specification updates RFC4301. However, this is such a remote
possibility that RFC4301 IPsec implementations are NOT REQUIRED to possibility that RFC4301 IPsec implementations are NOT REQUIRED to
implement compatibility mode. implement compatibility mode.
5.2. Changes to RFC3168 ECN processing 5.2. Changes to RFC3168 ECN processing
Ingress: On encapsulation, the new rule in Figure 3 that a normal Ingress: On encapsulation, the new rule in Figure 3 that a normal
mode tunnel ingress copies any ECN field into the outer header mode tunnel ingress copies any ECN field into the outer header
updates the ingress behaviour of RFC3168. Nonetheless, the new updates the full functionality behaviour of an RFC3168 ingress.
compatibility mode is identical to the limited functionality mode Nonetheless, the new compatibility mode encapsulates packets
of RFC3168. identically to the limited functionality mode of an RFC3168
ingress.
Egress: The new decapsulation behaviour in Figure 4 updates RFC3168. Egress: An RFC3168 egress will need to be updated to the new
However, the present specification solely updates combinations of decapsulation behaviour in Figure 4, in order to comply with the
inner and outer that would never result from any protocol defined present specification. However, the changes are backward
in the RFC series so far, even though they were catered for in compatible; combinations of inner and outer that result from any
RFC3168 for completeness. Therefore, the present specification protocol defined in the RFC series so far are unaffected. Only
adds new behaviours to RFC3168 decapsulation without altering combinations that have never been used have been changed,
existing behaviours. The following specific updates have been effectively adding new behaviours to RFC3168 decapsulation without
made: altering existing behaviours. The following specific updates have
been made:
* The outer, not the inner, is propagated when the outer is * The outer, not the inner, is propagated when the outer is
ECT(1) and the inner is ECT(0); ECT(1) and the inner is ECT(0);
* Certain combinations of inner and outer ECN field have been * Certain combinations of inner and outer ECN field have been
identified as currently unused. These can trigger logging identified as currently unused. These can trigger logging
and/or raise alarms. and/or raise alarms.
Modes: RFC3168 defines a (required) limited functionality mode and Modes: An RFC3168 ingress will need to be updated if it is to comply
an (optional) full functionality mode for a tunnel. In RFC3168, with the present specification, whether or not it implemented the
optional full functionality mode of RFC3168.
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 modes applied to both ends of the tunnel, while in the present
specification, modes are only used at the ingress--a single egress specification, modes are only used at the ingress--a single egress
behaviour covers all cases. The normal mode of encapsulation behaviour covers all cases.
updates the encapsulation behaviour of the full functionality mode
of RFC3168. The compatibility mode of encapsulation is identical The normal mode of encapsulation is an update to the encapsulation
to the encapsulation behaviour of the limited functionality mode behaviour of the full functionality mode of an RFC3168 ingress.
of RFC3168. The constraints on how tunnel discovery protocols set The compatibility mode of encapsulation is identical to the
modes in Section 4.3 and Section 4.4 are an update to RFC3168. encapsulation behaviour of the limited functionality mode of an
RFC3168 ingress, except it is optional.
The constraints on how tunnel discovery protocols set modes in
Section 4.3 and Section 4.4 are an update to RFC3168, but they are
unlikely to require code changes as they document safe practice.
5.3. Motivation for Changes 5.3. Motivation for Changes
An overriding goal is to ensure the same ECN signals can mean the An overriding goal is to ensure the same ECN signals can mean the
same thing whatever tunnels happen to encapsulate an IP packet flow. same thing whatever tunnels happen to encapsulate an IP packet flow.
This removes gratuitous inconsistency, which otherwise constrains the This removes gratuitous inconsistency, which otherwise constrains the
available design space and makes it harder to design networks and new available design space and makes it harder to design networks and new
protocols that work predictably. protocols that work predictably.
5.3.1. Motivation for Changing Encapsulation 5.3.1. Motivation for Changing Encapsulation
The normal mode in Section 4 updates RFC3168 to make all IP in IP The normal mode in Section 4 updates RFC3168 to make all IP in IP
encapsulation of the ECN field consistent--consistent with the way encapsulation of the ECN field consistent--consistent with the way
both RFC4301 IPsec [RFC4301] and IP in MPLS or MPLS in MPLS both RFC4301 IPsec [RFC4301] and IP in MPLS or MPLS in MPLS
encapsulation [RFC5129] construct the ECN field. encapsulation [RFC5129] construct the ECN field.
Compatibility mode has also been defined so a non-RFC4301 ingress can Compatibility mode has also been defined so that a non-RFC4301
still switch to using drop across a tunnel for backwards ingress can still switch to using drop across a tunnel for backwards
compatibility with legacy decapsulators that do not propagate ECN compatibility with legacy decapsulators that do not propagate ECN
correctly. correctly.
The trigger that motivated this update to RFC3168 encapsulation was a The trigger that motivated this update to RFC3168 encapsulation was a
standards track proposal for pre-congestion notification (PCN standards track proposal for pre-congestion notification (PCN
[RFC5670]). PCN excess rate marking only works correctly if the ECN [RFC5670]). PCN excess rate marking only works correctly if the ECN
field is copied on encapsulation (as in RFC4301 and RFC5129); it does field is copied on encapsulation (as in RFC4301 and RFC5129); it does
not work if ECN is reset (as in RFC3168). This is because PCN excess not work if ECN is reset (as in RFC3168). This is because PCN excess
rate marking depends on the outer header revealing any congestion rate marking depends on the outer header revealing any congestion
experienced so far on the whole path, not just since the last tunnel experienced so far on the whole path, not just since the last tunnel
skipping to change at page 23, line 45 skipping to change at page 24, line 50
of CU values. It recognises legitimate security concerns about of CU values. It recognises legitimate security concerns about
CU values but still eases their future use. If the alarms are CU values but still eases their future use. If the alarms are
interpreted as an attack (e.g. by a management system) the interpreted as an attack (e.g. by a management system) the
offending packets can be dropped. But alarms can be turned off offending packets can be dropped. But alarms can be turned off
if these combinations come into regular use (e.g. through a if these combinations come into regular use (e.g. through a
future standards action). future standards action).
3. While reviewing currently unused combinations of inner and outer, 3. While reviewing currently unused combinations of inner and outer,
the opportunity was taken to define a single consistent behaviour the opportunity was taken to define a single consistent behaviour
for the three cases with a Not-ECT inner header but a different for the three cases with a Not-ECT inner header but a different
outer. RFC3168 and RFC4301 had diverged in this respect. None outer. RFC3168 and RFC4301 had diverged in this respect and even
of these combinations should result from Internet protocols in their common behaviours had never been justified.
the RFC series, but future standards actions might put any or all
of them to good use. Therefore it was decided that a None of these combinations should result from Internet protocols
decapsulator must forward a Not-ECT inner unchanged, even if the in the RFC series, but future standards actions might put any or
arriving outer was ECT(0) or ECT(1). But for safety it should all of them to good use. Therefore it was decided that a
drop a combination of Not-ECT inner and CE outer. Then, if some 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 unfortunate misconfiguration resulted in a congested router
marking CE on a packet that was originally Not-ECT, drop would be marking CE on a packet that was originally Not-ECT, drop would be
the only appropriate signal for the egress to propagate--the only the only appropriate signal for the egress to propagate--the only
signal a non-ECN-capable transport (Not-ECT) would understand. signal a non-ECN-capable transport (Not-ECT) would understand.
A decapsulator can forward a Not-ECT inner unchanged if its outer It may seem contradictory that the same argument has not been
is ECT(1), even though ECT(1) is being proposed as an applied to the ECT(1) codepoint, given it is being proposed as an
intermediate level of congestion in a scheme progressing through intermediate level of congestion in a scheme progressing through
the IETF [I-D.ietf-pcn-3-in-1-encoding]. The rationale is to the IETF [I-D.ietf-pcn-3-in-1-encoding]. Instead, a decapsulator
ensure this CU combination will be usable if needed in the must forward a Not-ECT inner unchanged when its outer is ECT(1).
future. If any misconfiguration led to ECT(1) congestion signals The rationale for not dropping this CU combination is to ensure
with a Not-ECT inner, it would not be disastrous for the tunnel it will be usable if needed in the future. If any
egress to suppress them, because the congestion should then misconfiguration led to ECT(1) congestion signals with a Not-ECT
escalate to CE marking, which the egress would drop, thus at inner, it would not be disastrous for the tunnel egress to
least preventing congestion collapse. suppress them, because the congestion should then escalate to CE
marking, which the egress would drop, thus at least preventing
congestion collapse.
Problems 2 & 3 alone would not warrant a change to decapsulation, but Problems 2 & 3 alone would not warrant a change to decapsulation, but
it was decided they are worth fixing and making consistent at the it was decided they are worth fixing and making consistent at the
same time as decapsulation code is changed to fix problem 1 (two same time as decapsulation code is changed to fix problem 1 (two
congestion severity-levels). congestion severity-levels).
6. Backward Compatibility 6. Backward Compatibility
A tunnel endpoint compliant with the present specification is A tunnel endpoint compliant with the present specification is
backward compatible when paired with any tunnel endpoint compliant backward compatible when paired with any tunnel endpoint compliant
skipping to change at page 27, line 47 skipping to change at page 29, line 6
combinations of inner and outer headers, even those that would combinations of inner and outer headers, even those that would
not be expected to result from standards known at the time and not be expected to result from standards known at the time and
even those that would not be expected from the tunnel ingress even those that would not be expected from the tunnel ingress
paired with the egress at run-time. Consideration should be paired with the egress at run-time. Consideration should be
given to logging such unexpected combinations and raising an given to logging such unexpected combinations and raising an
alarm, particularly if there is a danger that the invalid alarm, particularly if there is a danger that the invalid
combination implies congestion signals are not being combination implies congestion signals are not being
propagated correctly. The presence of currently unused propagated correctly. The presence of currently unused
combinations may represent an attack, but the new scheme combinations may represent an attack, but the new scheme
should try to define a way to forward such packets, at least should try to define a way to forward such packets, at least
if a safe outgoing codepoint can be defined. Raising an alarm if a safe outgoing codepoint can be defined.
to warn of the possibility of an attack is a preferable
approach to dropping that ensures these combinations can be Raising an alarm allows a management system to decide whether
usable in future standards actions. 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.
IANA Considerations (to be removed on publication): IANA Considerations (to be removed on publication):
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
Appendix B.1 discusses the security constraints imposed on ECN tunnel Appendix B.1 discusses the security constraints imposed on ECN tunnel
processing. The new rules for ECN tunnel processing (Section 4) processing. The new rules for ECN tunnel processing (Section 4)
trade-off between information security (covert channels) and trade-off between information security (covert channels) and traffic
congestion monitoring & control. In fact, ensuring congestion security (congestion monitoring & control). Ensuring congestion
markings are not lost is itself another aspect of security, because markings are not lost is itself an aspect of security, because if we
if we allowed congestion notification to be lost, any attempt to allowed congestion notification to be lost, any attempt to enforce a
enforce a response to congestion would be much harder. response to congestion would be much harder.
Specialist security issues: Specialist security issues:
Tunnels intersecting Diffserv regions with alternate ECN semantics: Tunnels intersecting Diffserv regions with alternate ECN semantics:
If alternate congestion notification semantics are defined for a If alternate congestion notification semantics are defined for a
certain Diffserv PHB, the scope of the alternate semantics might certain Diffserv PHB, the scope of the alternate semantics might
typically be bounded by the limits of a Diffserv region or typically be bounded by the limits of a Diffserv region or
regions, as envisaged in [RFC4774] (e.g. the pre-congestion regions, as envisaged in [RFC4774] (e.g. the pre-congestion
notification architecture [RFC5559]). The inner headers in notification architecture [RFC5559]). The inner headers in
tunnels crossing the boundary of such a Diffserv region but ending tunnels crossing the boundary of such a Diffserv region but ending
within the region can potentially leak the external congestion within the region can potentially leak the external congestion
notification semantics into the region, or leak the internal notification semantics into the region, or leak the internal
semantics out of the region. [RFC2983] discusses the need for semantics out of the region. [RFC2983] discusses the need for
Diffserv traffic conditioning to be applied at these tunnel Diffserv traffic conditioning to be applied at these tunnel
endpoints as if they are at the edge of the Diffserv region. endpoints as if they are at the edge of the Diffserv region.
Similar concerns apply to any processing or propagation of the ECN Similar concerns apply to any processing or propagation of the ECN
field at the edges of a Diffserv region with alternate ECN field at the endpoints of tunnels with one end inside and the
semantics. Such edge processing must also be applied at the other outside the domain. [RFC5559] gives specific advice on this
endpoints of tunnels with one end inside and the other outside the for the PCN case, but other definitions of alternate semantics
domain. [RFC5559] gives specific advice on this for the PCN case, will need to discuss the specific security implications in each
but other definitions of alternate semantics will need to discuss case.
the specific security implications in each case.
ECN nonce tunnel coverage: The new decapsulation rules improve the ECN nonce tunnel coverage: The new decapsulation rules improve the
coverage of the ECN nonce [RFC3540] relative to the previous rules coverage of the ECN nonce [RFC3540] relative to the previous rules
in RFC3168 and RFC4301. However, nonce coverage is still not in RFC3168 and RFC4301. However, nonce coverage is still not
perfect, as this would have led to a safety problem in another perfect, as this would have led to a safety problem in another
case. Both are corner-cases, so discussion of the compromise case. Both are corner-cases, so discussion of the compromise
between them is deferred to Appendix F. between them is deferred to Appendix F.
Covert channel not turned off: A legacy (RFC3168) tunnel ingress Covert channel not turned off: A legacy (RFC3168) tunnel ingress
could ask an RFC3168 egress to turn off ECN processing as well as could ask an RFC3168 egress to turn off ECN processing as well as
itself turning off ECN. An egress compliant with the present itself turning off ECN. An egress compliant with the present
specification will agree to such a request from a legacy ingress, specification will agree to such a request from a legacy ingress,
but it relies on the ingress solely sending Not-ECT in the outer. but it relies on the ingress always sending Not-ECT in the outer.
If the egress receives other ECN codepoints in the outer it will If the egress receives other ECN codepoints in the outer it will
process them as normal, so it will actually still copy congestion process them as normal, so it will actually still copy congestion
markings from the outer to the outgoing header. Referring for markings from the outer to the outgoing header. Referring for
example to Figure 5 (Appendix B.1), although the tunnel ingress example to Figure 5 (Appendix B.1), although the tunnel ingress
'I' will set all ECN fields in outer headers to Not-ECT, 'M' could '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 still toggle CE or ECT(1) on and off to communicate covertly with
'B', because we have specified that 'E' only has one mode 'B', because we have specified that 'E' only has one mode
regardless of what mode it says it has negotiated. We could have regardless of what mode it says it has negotiated. We could have
specified that 'E' should have a limited functionality mode and specified that 'E' should have a limited functionality mode and
check for such behaviour. But we decided not to add the extra check for such behaviour. But we decided not to add the extra
complexity of two modes on a compliant tunnel egress merely to complexity of two modes on a compliant tunnel egress merely to
cater for an historic security concern that is now considered cater for an historic security concern that is now considered
manageable. manageable.
9. Conclusions 9. Conclusions
This document uses previously unused combinations of inner and outer This document allows tunnels to propagate an extra level of
header to augment the rules for calculating the ECN field when congestion severity. It uses previously unused combinations of inner
decapsulating IP packets at the egress of IPsec (RFC4301) and non- and outer header to augment the rules for calculating the ECN field
IPsec (RFC3168) tunnels. In this way it allows tunnels to propagate when decapsulating IP packets at the egress of IPsec (RFC4301) and
an extra level of congestion severity. non-IPsec (RFC3168) tunnels.
This document also updates the ingress tunnelling encapsulation of This document also updates the ingress tunnelling encapsulation of
RFC3168 ECN to bring all IP in IP tunnels into line with the new RFC3168 ECN to bring all IP in IP tunnels into line with the new
behaviour in the IPsec architecture of RFC4301, which copies rather behaviour in the IPsec architecture of RFC4301, which copies rather
than resets the ECN field when creating outer headers. than resets the ECN field when creating outer headers.
The need for both these updated behaviours was triggered by the The need for both these updated behaviours was triggered by the
introduction of pre-congestion notification (PCN) onto the IETF introduction of pre-congestion notification (PCN) onto the IETF
standards track. Operators wanting to support PCN or other alternate standards track. Operators wanting to support PCN or other alternate
ECN schemes that use an extra severity level can require that their ECN schemes that use an extra severity level can require that their
tunnels comply with the present specification. Nonetheless, as part tunnels comply with the present specification. This is not a fork in
of general code maintenance, any tunnel can safely be updated to the RFC series, it is an update that can be deployed first by those
comply with this specification, because it is backward compatible that need it, and subsequently by all tunnel endpoint implementations
with all previous tunnelling behaviours which will continue to work during general code maintenance. It is backward compatible with all
as before--just using one severity level. 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.
The new rules propagate changes to the ECN field across tunnel end- The new rules propagate changes to the ECN field across tunnel end-
points that previously blocked them to restrict the bandwidth of a points that previously blocked them to restrict the bandwidth of a
potential covert channel. Limiting the channel's bandwidth to 2 bits potential covert channel. Limiting the channel's bandwidth to 2 bits
per packet is now considered sufficient. per packet is now considered sufficient.
At the same time as removing these legacy constraints, the At the same time as removing these legacy constraints, the
opportunity has been taken to draw together diverging tunnel opportunity has been taken to draw together diverging tunnel
specifications into a single consistent behaviour. Then any tunnel specifications into a single consistent behaviour. Then any tunnel
can be deployed unilaterally, and it will support the full range of can be deployed unilaterally, and it will support the full range of
congestion control and management schemes without any modes or congestion control and management schemes without any modes or
configuration. Further, any host or router can expect the ECN field configuration. Further, any host or router can expect the ECN field
to behave in the same way, whatever type of tunnel might intervene in to behave in the same way, whatever type of tunnel might intervene in
the path. This new certainty could enable new uses of the ECN field the path. This new certainty could enable new uses of the ECN field
that would otherwise be confounded by ambiguity. that would otherwise be confounded by ambiguity.
10. Acknowledgements 10. Acknowledgements
Thanks to Anil Agawaal for pointing out a case where it's safe for a Thanks to David Black for his insightful reviews and patient
tunnel decapsulator to forward a combination of headers it does not explanations of better ways to think about function placement and
understand. Thanks to David Black for explaining a better way to alarms. Thanks to David and to Anil Agawaal for pointing out cases
think about function placement. Also thanks to Arnaud Jacquet for where it is safe to forward CU combinations of headers. Also thanks
the idea for Appendix C. Thanks to Michael Menth, Bruce Davie, Toby to Arnaud Jacquet for the idea for Appendix C. Thanks to Gorry
Moncaster, Gorry Fairhurst, Sally Floyd, Alfred Hoenes, Gabriele Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster,
Corliano, Ingemar Johansson, David Black and Phil Eardley for their Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson and
thoughts and careful review comments. Phil Eardley for their thoughts and careful review comments.
Bob Briscoe is partly funded by Trilogy, a research project (ICT- Bob Briscoe is partly funded by Trilogy, a research project (ICT-
216372) supported by the European Community under its Seventh 216372) supported by the European Community under its Seventh
Framework Programme. The views expressed here are those of the Framework Programme. The views expressed here are those of the
author only. author only.
Comments Solicited (to be removed by the RFC Editor): Comments Solicited (to be removed by the RFC Editor):
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list addressed to the IETF Transport Area working group mailing list
skipping to change at page 31, line 10 skipping to change at page 32, line 22
[RFC4301] Kent, S. and K. Seo, "Security [RFC4301] Kent, S. and K. Seo, "Security
Architecture for the Internet Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
11.2. Informative References 11.2. Informative References
[I-D.ietf-pcn-3-in-1-encoding] Briscoe, B. and T. Moncaster, "PCN [I-D.ietf-pcn-3-in-1-encoding] Briscoe, B. and T. Moncaster, "PCN
3-State Encoding Extension in a 3-State Encoding Extension in a
single DSCP", single DSCP",
draft-ietf-pcn-3-in-1-encoding-00 draft-ietf-pcn-3-in-1-encoding-01
(work in progress), July 2009. (work in progress), February 2010.
[I-D.ietf-pcn-3-state-encoding] Moncaster, T., Briscoe, B., and M. [I-D.ietf-pcn-3-state-encoding] Briscoe, B., Moncaster, T., and M.
Menth, "A PCN encoding using 2 Menth, "A PCN encoding using 2
DSCPs to provide 3 or more states", DSCPs to provide 3 or more states",
draft-ietf-pcn-3-state-encoding-00 draft-ietf-pcn-3-state-encoding-01
(work in progress), April 2009. (work in progress), February 2010.
[I-D.ietf-pcn-psdm-encoding] Menth, M., Babiarz, J., Moncaster, [I-D.ietf-pcn-psdm-encoding] Menth, M., Babiarz, J., Moncaster,
T., and B. Briscoe, "PCN Encoding T., and B. Briscoe, "PCN Encoding
for Packet-Specific Dual Marking for Packet-Specific Dual Marking
(PSDM)", (PSDM)",
draft-ietf-pcn-psdm-encoding-00 draft-ietf-pcn-psdm-encoding-00
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., Menth, [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., Menth,
M., and T. Taylor, "PCN Boundary M., and T. Taylor, "PCN Boundary
skipping to change at page 34, line 31 skipping to change at page 35, line 46
| | | | | | | |
+------------------+ +------------------+ +------------------+ +------------------+
<----IPsec secured----> <----IPsec secured---->
tunnel tunnel
Figure 5: IPsec Tunnel Scenario Figure 5: IPsec Tunnel Scenario
IPsec encryption is typically used to prevent 'M' seeing messages IPsec encryption is typically used to prevent 'M' seeing messages
from 'A' to 'B'. IPsec authentication is used to prevent 'M' from 'A' to 'B'. IPsec authentication is used to prevent 'M'
masquerading as the sender of messages from 'A' to 'B' or altering masquerading as the sender of messages from 'A' to 'B' or altering
their contents. In addition 'I' can use IPsec tunnel mode to allow their contents. 'I' can use IPsec tunnel mode to allow 'A' to
'A' to communicate with 'B', but impose encryption to prevent 'A' communicate with 'B', but impose encryption to prevent 'A' leaking
leaking information to 'M'. Or 'E' can insist that 'I' uses tunnel information to 'M'. Or 'E' can insist that 'I' uses tunnel mode
mode authentication to prevent 'M' communicating information to 'B'. authentication to prevent 'M' communicating information to 'B'.
Mutable IP header fields such as the ECN field (as well as the TTL/ 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 Hop Limit and DS fields) cannot be included in the cryptographic
calculations of IPsec. Therefore, if 'I' copies these mutable fields calculations of IPsec. Therefore, if 'I' copies these mutable fields
into the outer header that is exposed across the tunnel it will have 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 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 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 header to the inner, even if it validates authentication from 'I', it
will have allowed a covert channel from 'M' to 'B'. will have allowed a covert channel from 'M' to 'B'.
skipping to change at page 38, line 20 skipping to change at page 39, line 34
| | | represents 100 packets | | | represents 100 packets
| 30 | | | 30 | |
| | | p_t = 12/(100-30) | | | p_t = 12/(100-30)
p_t + +---------+ = 12/70 p_t + +---------+ = 12/70
| | 12 | = 17% | | 12 | = 17%
0 +-----+---------+---> 0 +-----+---------+--->
0 30% 100% inner header marking 0 30% 100% inner header marking
Figure 7: Tunnel Marking of Packets Already Marked at Ingress Figure 7: Tunnel Marking of Packets Already Marked at Ingress
Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN (to be
removed before publication)
Congestion notification with two severity levels is currently on the Congestion notification with two severity levels is currently on the
IETF's standards track agenda in the Congestion and Pre-Congestion IETF's standards track agenda in the Congestion and Pre-Congestion
Notification (PCN) working group. PCN needs all four possible states Notification (PCN) working group. PCN needs all four possible states
of congestion signalling in the 2-bit ECN field to be propagated at of congestion signalling in the 2-bit ECN field to be propagated at
the egress, but pre-existing tunnels only propagate three. The four the egress, but pre-existing tunnels only propagate three. The four
PCN states are: not PCN-enabled, not marked and two increasingly PCN states are: not PCN-enabled, not marked and two increasingly
severe levels of congestion marking. The less severe marking means severe levels of congestion marking. The less severe marking means
'stop admitting new traffic' and the more severe marking means 'stop admitting new traffic' and the more severe marking means
'terminate some existing flows', which may be needed after reroutes 'terminate some existing flows', which may be needed after reroutes
skipping to change at page 39, line 36 skipping to change at page 41, line 5
specification, but universal compliance is feasible for PCN, because specification, but universal compliance is feasible for PCN, because
it is intended to be deployed in a controlled Diffserv region. it is intended to be deployed in a controlled Diffserv region.
Given the present specification, the PCN w-g could progress a Given the present specification, the PCN w-g could progress a
trivially simple four-state ECN encoding trivially simple four-state ECN encoding
[I-D.ietf-pcn-3-in-1-encoding]. This would replace the interim [I-D.ietf-pcn-3-in-1-encoding]. This would replace the interim
standards track baseline encoding of just three states [RFC5696] standards track baseline encoding of just three states [RFC5696]
which makes a fourth state available for any of the experimental which makes a fourth state available for any of the experimental
alternatives. alternatives.
Appendix E. Why Resetting ECN on Encapsulation Impedes PCN Appendix E. Why Resetting ECN on Encapsulation Impedes PCN (to be
removed before publication)
The PCN architecture says "...if encapsulation is done within the The PCN architecture says "...if encapsulation is done within the
PCN-domain: Any PCN-marking is copied into the outer header. Note: A PCN-domain: Any PCN-marking is copied into the outer header. Note: A
tunnel will not provide this behaviour if it complies with [RFC3168] tunnel will not provide this behaviour if it complies with [RFC3168]
tunnelling in either mode, but it will if it complies with [RFC4301] tunnelling in either mode, but it will if it complies with [RFC4301]
IPsec tunnelling. " IPsec tunnelling. "
The specific issue here concerns PCN excess rate marking [RFC5670]. The specific issue here concerns PCN excess rate marking [RFC5670].
The purpose of excess rate marking is to provide a bulk mechanism for The purpose of excess rate marking is to provide a bulk mechanism for
interior nodes within a PCN domain to mark traffic that is exceeding interior nodes within a PCN domain to mark traffic that is exceeding
skipping to change at page 41, line 32 skipping to change at page 42, line 49
Appendix G. Open Issues Appendix G. Open Issues
The new decapsulation behaviour defined in Section 4.2 adds support The new decapsulation behaviour defined in Section 4.2 adds support
for propagation of 2 severity levels of congestion. However for propagation of 2 severity levels of congestion. However
transports have no way to discover whether there are any legacy transports have no way to discover whether there are any legacy
tunnels on their path that will not propagate 2 severity levels. It tunnels on their path that will not propagate 2 severity levels. It
would have been nice to add a feature for transports to check path would have been nice to add a feature for transports to check path
support, but this remains an open issue that will have to be support, but this remains an open issue that will have to be
addressed in any future standards action to define an end-to-end addressed in any future standards action to define an end-to-end
scheme that requires 2-severity levels of congestion. PCN avoids scheme that requires 2-severity levels of congestion. PCN avoids
this problem, because it is only for a controlled region, so all this problem because it is only for a controlled region, so all
legacy tunnels can be upgraded by the same operator that deploys PCN. legacy tunnels can be upgraded by the same operator that deploys PCN.
Author's Address Author's Address
Bob Briscoe Bob Briscoe
BT BT
B54/77, Adastral Park B54/77, Adastral Park
Martlesham Heath Martlesham Heath
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
 End of changes. 57 change blocks. 
225 lines changed or deleted 290 lines changed or added

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