< draft-ietf-tsvwg-ecn-tunnel-09.txt   draft-ietf-tsvwg-ecn-tunnel-10a.txt >
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft BT Internet-Draft BT
Updates: 3168, 4301, 4774 July 30, 2010 Updates: 3168, 4301, 4774 August 26, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 31, 2011 Expires: February 27, 2011
Tunnelling of Explicit Congestion Notification Tunnelling of Explicit Congestion Notification
draft-ietf-tsvwg-ecn-tunnel-09 draft-ietf-tsvwg-ecn-tunnel-10
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 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2011. This Internet-Draft will expire on February 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 14 3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 14
3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 14 3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 14
3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 15 3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 15
4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 16 4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 16
4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 16 4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 17
4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 17 4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 17
4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 19 4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 19
4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 20 4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 21
5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 21 5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 22
5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 21 5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 22
5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 22 5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 22
5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 23 5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 23
5.3.1. Motivation for Changing Encapsulation . . . . . . . . 23 5.3.1. Motivation for Changing Encapsulation . . . . . . . . 24
5.3.2. Motivation for Changing Decapsulation . . . . . . . . 24 5.3.2. Motivation for Changing Decapsulation . . . . . . . . 25
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 27 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 27
6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 27 6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 27
6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 27 6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 28
6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 28 6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 28
7. Design Principles for Alternate ECN Tunnelling Semantics . . . 28 7. Design Principles for Alternate ECN Tunnelling Semantics . . . 29
8. IANA Considerations (to be removed on publication): . . . . . 30 8. IANA Considerations (to be removed on publication): . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 35 Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 35
Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 35 Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 36
B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 36 B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 36
B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 38 B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 38
B.3. Management Constraints . . . . . . . . . . . . . . . . . . 39 B.3. Management Constraints . . . . . . . . . . . . . . . . . . 39
Appendix C. Contribution to Congestion across a Tunnel . . . . . 39 Appendix C. Contribution to Congestion across a Tunnel . . . . . 40
Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0) Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0)
Outer . . . . . . . . . . . . . . . . . . . . . . . . 40 Outer . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . . 41 Appendix E. 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-08 to ietf-09 (current): Added change log entry for -07 to From ietf-09 to ietf-10 (current):
-08 that was previously omitted.
* Editorial changes:
+ Clarified couple of sentences in Introduction and one in
section 6.3 to distinguish whether the terms 'RFC3168' &
'RFC4301' refer to implementations or documents.
+ Corrected garbled sentence in the introduction about
backward compatibility.
+ Made it clear that 'drop' in Fig 2, Fig 4 and the following
para is an action, not a codepoint.
+ In sections 5.1 & 5.2, specifically identified the updated
sections of RFC3168 & RFC4301.
+ 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).
+ Added RFC5659 as informative reference on pseudowires and
clarified only some pseudowires might be relevant examples.
+ Deleted "The views expressed here are those of the author
only." in the acknowledgements.
+ Fixed a few nits.
From ietf-08 to ietf-09: Added change log entry for -07 to -08 that
was previously omitted.
* Changes to standards action text: * Changes to standards action text:
+ Added RFC4774 to 'Updates:' header (the draft always has + Added RFC4774 to 'Updates:' header (the draft always has
extended the advice in RFC4774 (BCP124) which said very extended the advice in RFC4774 (BCP124) which said very
little about tunnels. The GENART reviewer merely pointed little about tunnels. The GENART reviewer merely pointed
out that the header did not highlight this fact.) out that the header did not highlight this fact.)
* Editorial changes: * Editorial changes:
skipping to change at page 11, line 15 skipping to change at page 11, line 46
The outer header of an IP packet can encapsulate one or more IP The outer header of an IP packet can encapsulate one or more IP
headers for tunnelling. A forwarding element using ECN to signify headers for tunnelling. A forwarding element using ECN to signify
congestion will only mark the immediately visible outer IP header. congestion will only mark the immediately visible outer IP header.
When a tunnel decapsulator later removes this outer header, it When a tunnel decapsulator later removes this outer header, it
follows rules to propagate congestion markings by combining the ECN follows rules to propagate congestion markings by combining the ECN
fields of the inner and outer IP header into one outgoing IP header. fields of the inner and outer IP header into one outgoing IP header.
This document updates those rules for IPsec [RFC4301] and non-IPsec This document updates those rules for IPsec [RFC4301] and non-IPsec
[RFC3168] tunnels to add new behaviours for previously unused [RFC3168] tunnels to add new behaviours for previously unused
combinations of inner and outer header. It also updates the tunnel combinations of inner and outer header. It also updates the ingress
ingress behaviour of RFC3168 to match that of RFC4301. The updated behaviour of RFC3168 tunnels to match that of RFC4301 tunnels.
rules are backward compatible with RFC4301 and RFC3168 when Tunnel endpoints complying with the updated rules will be backward
interworking with any other tunnel endpoint complying with any compatible when interworking with tunnel endpoints complying with
earlier specification. RFC4301, RFC3168 or any earlier specification.
When ECN and its tunnelling was defined in RFC3168, only the minimum When ECN and its tunnelling was defined in RFC3168, only the minimum
necessary changes to the ECN field were propagated through tunnel necessary changes to the ECN field were propagated through tunnel
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 to be 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 dispensed copied the whole ECN field to encapsulate a packet. RFC4301
with the two modes of RFC3168, one which partially copied the ECN dispensed with the two modes of RFC3168, one which partially copied
field, and the other which blocked all propagation of ECN changes. the ECN field, and the other which blocked all propagation of ECN
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
skipping to change at page 15, line 26 skipping to change at page 16, line 4
+-----------------+---------------+---------------+---------------+ +-----------------+---------------+---------------+---------------+
Figure 1: IP in IP Encapsulation: Recap of Pre-existing Behaviours Figure 1: IP in IP Encapsulation: Recap of Pre-existing Behaviours
3.2. Decapsulation at Tunnel Egress 3.2. Decapsulation at Tunnel Egress
RFC3168 and RFC4301 specify the decapsulation behaviour summarised in RFC3168 and RFC4301 specify the decapsulation behaviour summarised in
Figure 2. The ECN field in the outgoing header is set to the Figure 2. The ECN field in the outgoing header is set to the
codepoint at the intersection of the appropriate incoming inner codepoint at the intersection of the appropriate incoming inner
header (row) and incoming outer header (column). header (row) and incoming outer header (column).
+---------+------------------------------------------------+ +---------+------------------------------------------------+
|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 |
+---------+---------+------------+------------+------------+ +---------+---------+------------+------------+------------+
RFC3168->| Not-ECT | Not-ECT |Not-ECT |Not-ECT | drop | RFC3168->| Not-ECT | Not-ECT |Not-ECT |Not-ECT | <drop> |
RFC4301->| Not-ECT | Not-ECT |Not-ECT |Not-ECT |Not-ECT | RFC4301->| Not-ECT | Not-ECT |Not-ECT |Not-ECT |Not-ECT |
| ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE | | ECT(0) | ECT(0) | ECT(0) | ECT(0) | 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 |
+---------+---------+------------+------------+------------+ +---------+---------+------------+------------+------------+
In pre-existing RFCs, the ECN field in the outgoing header was set to In pre-existing RFCs, the ECN field in the outgoing header was set to
the codepoint at the intersection of the appropriate incoming inner the codepoint at the intersection of the appropriate incoming inner
header (row) and incoming outer header (column). header (row) and incoming outer header (column) , or the packet was
dropped where indicated.
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
ignored. 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.
skipping to change at page 16, line 24 skipping to change at page 16, line 51
4. New ECN Tunnelling Rules 4. New ECN Tunnelling Rules
The standards actions below in Section 4.1 (ingress encapsulation) The standards actions below in Section 4.1 (ingress encapsulation)
and Section 4.2 (egress decapsulation) define new default ECN tunnel and Section 4.2 (egress decapsulation) define new default ECN tunnel
processing rules for any IP packet (v4 or v6) with any Diffserv processing rules for any IP packet (v4 or v6) with any Diffserv
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 section 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 SHOULD be be followed. However, alternate ECN tunnelling schemes SHOULD be
avoided whenever possible as the deployment burden of handling avoided whenever possible as the deployment burden of handling
exceptional PHBs in implementations of all affected tunnels should exceptional PHBs in implementations of all affected tunnels should
not be underestimated. There is no requirement for a PHB definition not be underestimated. There is no requirement for a PHB definition
to state anything about ECN tunnelling behaviour if the default to state anything about ECN tunnelling behaviour if the default
behaviour in the present specification is sufficient. behaviour in the present specification is sufficient.
4.1. Default Tunnel Ingress Behaviour 4.1. Default Tunnel Ingress Behaviour
skipping to change at page 17, line 33 skipping to change at page 18, line 11
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 |
+---------+---------+------------+------------+------------+ +---------+---------+------------+------------+------------+
The ECN field in the outgoing header is set to the codepoint at the The ECN field in the outgoing header is set to the codepoint at the
intersection of the appropriate incoming inner header (row) and intersection of the appropriate incoming inner header (row) and
incoming outer header (column). Currently unused combinations are incoming outer header (column) , or the packet is dropped where
indicated by '(!!!)' or '(!)' indicated. Currently unused combinations are indicated by '(!!!)' or
'(!)'
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 rely on dropped
indication of congestion and would not understand or respond to packets as an indication of congestion and would not understand or
any other ECN codepoint [RFC4774]. Specifically: respond to 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 21, line 43 skipping to change at page 22, line 26
specification, which defines packet encapsulation identically to specification, which defines packet encapsulation identically to
RFC4301. RFC4301.
Egress: An RFC4301 egress will need to be updated to the new Egress: An RFC4301 egress will need to be updated to the new
decapsulation behaviour in Figure 4, in order to comply with the decapsulation behaviour in Figure 4, in order to comply with the
present specification. However, the changes are backward present specification. However, the changes are backward
compatible; combinations of inner and outer that result from any compatible; combinations of inner and outer that result from any
protocol defined in the RFC series so far are unaffected. Only protocol defined in the RFC series so far are unaffected. Only
combinations that have never been used have been changed, combinations that have never been used have been changed,
effectively adding new behaviours to RFC4301 decapsulation without effectively adding new behaviours to RFC4301 decapsulation without
altering existing behaviours. The following specific updates have altering existing behaviours. The following specific updates to
been made: section 5.1.2 of RFC4301 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.
skipping to change at page 22, line 20 skipping to change at page 22, line 50
updated by the modes in the present specification. Effectively an updated by the modes in the present specification. Effectively an
RFC4301 IPsec ingress solely uses the REQUIRED normal mode of RFC4301 IPsec ingress solely uses the REQUIRED normal mode of
encapsulation, which is unchanged from RFC4301 encapsulation. It encapsulation, which is unchanged from RFC4301 encapsulation. It
will never need the OPTIONAL compatibility mode as explained in will never need the OPTIONAL compatibility mode as explained in
Section 4.3. Section 4.3.
5.2. Changes to RFC3168 ECN processing 5.2. Changes to RFC3168 ECN processing
Ingress: On encapsulation, the new rule in Figure 3 that a normal Ingress: On encapsulation, the new rule in Figure 3 that a normal
mode tunnel ingress copies any ECN field into the outer header mode tunnel ingress copies any ECN field into the outer header
updates the full functionality behaviour of an RFC3168 ingress. updates the full functionality behaviour of an RFC3168 ingress
Nonetheless, the new compatibility mode encapsulates packets [RFC3168; section 9.1.1]. Nonetheless, the new compatibility mode
identically to the limited functionality mode of an RFC3168 encapsulates packets identically to the limited functionality mode
ingress. of an RFC3168 ingress.
Egress: An RFC3168 egress will need to be updated to the new Egress: An RFC3168 egress will need to be updated to the new
decapsulation behaviour in Figure 4, in order to comply with the decapsulation behaviour in Figure 4, in order to comply with the
present specification. However, the changes are backward present specification. However, the changes are backward
compatible; combinations of inner and outer that result from any compatible; combinations of inner and outer that result from any
protocol defined in the RFC series so far are unaffected. Only protocol defined in the RFC series so far are unaffected. Only
combinations that have never been used have been changed, combinations that have never been used have been changed,
effectively adding new behaviours to RFC3168 decapsulation without effectively adding new behaviours to RFC3168 decapsulation without
altering existing behaviours. The following specific updates have altering existing behaviours. The following specific updates to
been made: section 9.1.1 of RFC3168 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: An RFC3168 ingress will need to be updated if it is to comply Modes: An RFC3168 ingress will need to be updated if it is to comply
with the present specification, whether or not it implemented the with the present specification, whether or not it implemented the
optional full functionality mode of RFC3168. optional full functionality mode of section 9.1.1 of RFC3168.
RFC3168 defined a (required) limited functionality mode and an Section 9.1 of RFC3168 defined a (required) limited functionality
(optional) full functionality mode for a tunnel. In RFC3168, mode and an (optional) full functionality mode for a tunnel. In
modes applied to both ends of the tunnel, while in the present RFC3168, modes applied to both ends of the tunnel, while in the
specification, modes are only used at the ingress--a single egress present specification, modes are only used at the ingress--a
behaviour covers all cases. single egress behaviour covers all cases.
The normal mode of encapsulation is an update to the encapsulation The normal mode of encapsulation is an update to the encapsulation
behaviour of the full functionality mode of an RFC3168 ingress. behaviour of the full functionality mode of an RFC3168 ingress.
The compatibility mode of encapsulation is identical to the The compatibility mode of encapsulation is identical to the
encapsulation behaviour of the limited functionality mode of an encapsulation behaviour of the limited functionality mode of an
RFC3168 ingress, except it is optional. RFC3168 ingress, except it is not always obligatory.
The constraints on how tunnel discovery protocols set modes in 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 Section 4.3 and Section 4.4 are an update to RFC3168, but they are
unlikely to require code changes as they document existing safe unlikely to require code changes as they document existing safe
practice. 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.
skipping to change at page 28, line 10 skipping to change at page 28, line 39
An RFC4301 IPsec ingress can comply with this new specification An RFC4301 IPsec ingress can comply with this new specification
without any update and it has no need for any new modes, options or 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 configuration. So, all other things being equal, it will continue to
interwork identically with any egress it worked with before (fully interwork identically with any egress it worked with before (fully
backward compatible). backward compatible).
6.3. Update to RFC3168 Encapsulation 6.3. Update to RFC3168 Encapsulation
The encapsulation behaviour of the new normal mode copies the ECN The encapsulation behaviour of the new normal mode copies the ECN
field whereas RFC3168 full functionality mode reset it. However, all field whereas an RFC3168 ingress in full functionality mode reset it.
other things being equal, if RFC3168 ingress is updated to the However, all other things being equal, if an RFC3168 ingress is
present specification, the outgoing packets from any tunnel egress updated to the present specification, the outgoing packets from any
will still be unchanged. This is because all variants of tunnelling tunnel egress will still be unchanged. This is because all variants
at either end (RFC4301, both modes of RFC3168, both modes of RFC2481, of tunnelling at either end (RFC4301, both modes of RFC3168, both
RFC2401, RFC2003 and the present specification) have always modes of RFC2481, RFC2401, RFC2003 and the present specification)
propagated an incoming CE marking through the inner header and onward have always propagated an incoming CE marking through the inner
into the outgoing header, whether the outer header is reset or header and onward into the outgoing header, whether the outer header
copied. Therefore, If the tunnel is considered as a black box, the is reset or copied. Therefore, If the tunnel is considered as a
packets output from any egress will be identical with or without an black box, the packets output from any egress will be identical with
update to the ingress. Nonetheless, if packets are observed within or without an update to the ingress. Nonetheless, if packets are
the black box (between the tunnel endpoints), CE markings copied by observed within the black box (between the tunnel endpoints), CE
the updated ingress will be visible within the black box, whereas markings copied by the updated ingress will be visible within the
they would not have been before. Therefore, the update to black box, whereas they would not have been before. Therefore, the
encapsulation can be termed 'black-box backwards compatible' (i.e. update to encapsulation can be termed 'black-box backwards
identical unless you look inside the tunnel). compatible' (i.e. identical unless you look inside the tunnel).
This specification introduces no new backward compatibility issues This specification introduces no new backward compatibility issues
when a compliant ingress talks with a legacy egress, but it has to when a compliant ingress talks with a legacy egress, but it has to
provide similar safeguards to those already defined in RFC3168. provide similar safeguards to those already defined in RFC3168.
RFC3168 laid down rules to ensure that an RFC3168 ingress turns off RFC3168 laid down rules to ensure that an RFC3168 ingress turns off
ECN (limited functionality mode) if it is paired with a legacy egress ECN (limited functionality mode) if it is paired with a legacy egress
(RFC 2481, RFC2401 or RFC2003), which would not propagate ECN (RFC 2481, RFC2401 or RFC2003), which would not propagate ECN
correctly. The present specification carries forward those rules correctly. The present specification carries forward those rules
(Section 4.3). It uses compatibility mode whenever RFC3168 would (Section 4.3). It uses compatibility mode whenever RFC3168 would
have used limited functionality mode, and their per-packet behaviours have used limited functionality mode, and their per-packet behaviours
are identical. Therefore, all other things being equal, an ingress are identical. Therefore, all other things being equal, an ingress
using the new rules will interwork with any legacy tunnel egress in using the new rules will interwork with any legacy tunnel egress in
exactly the same way as an RFC3168 ingress (still black-box backward exactly the same way as an RFC3168 ingress (still black-box backward
compatible). compatible).
7. Design Principles for Alternate ECN Tunnelling Semantics 7. Design Principles for Alternate ECN Tunnelling Semantics
This section is informative not normative. This section is informative not normative.
S.5 of RFC3168 permits the Diffserv codepoint (DSCP)[RFC2474] to Section 5 of RFC3168 permits the Diffserv codepoint (DSCP)[RFC2474]
'switch in' alternative behaviours for marking the ECN field, just as to 'switch in' alternative behaviours for marking the ECN field, just
it switches in different per-hop behaviours (PHBs) for scheduling. as it switches in different per-hop behaviours (PHBs) for scheduling.
[RFC4774] gives best current practice for designing such alternative [RFC4774] gives best current practice for designing such alternative
ECN semantics and very briefly mentions in section 5.4 that ECN semantics and very briefly mentions in section 5.4 that
tunnelling needs to be considered. The guidance below complements tunnelling needs to be considered. The guidance below complements
and extends RFC4774, giving additional guidance on designing any and extends RFC4774, giving additional guidance on designing any
alternate ECN semantics that would also require alternate tunnelling alternate ECN semantics that would also require alternate tunnelling
semantics. semantics.
The overriding guidance is: "Avoid designing alternate ECN tunnelling The overriding guidance is: "Avoid designing alternate ECN tunnelling
semantics, if at all possible." If a scheme requires tunnels to semantics, if at all possible." If a scheme requires tunnels to
implement special processing of the ECN field for certain DSCPs, it implement special processing of the ECN field for certain DSCPs, it
skipping to change at page 29, line 38 skipping to change at page 30, line 20
introduced across the tunnel in the outer header. introduced across the tunnel in the outer header.
2. If it has established that ECN will be correctly propagated, 2. If it has established that ECN will be correctly propagated,
an encapsulator ought to also copy incoming congestion an encapsulator ought to also copy incoming congestion
notification into the outer header. The general principle notification into the outer header. The general principle
here is that the outer header should reflect congestion here is that the outer header should reflect congestion
accumulated along the whole upstream path, not just since the accumulated along the whole upstream path, not just since the
tunnel ingress (Appendix B.3 on management and monitoring tunnel ingress (Appendix B.3 on management and monitoring
explains). explains).
In some circumstances (e.g. pseudowires, PCN), the whole path In some circumstances (e.g. PCN [RFC5559] and perhaps some
is divided into segments, each with its own congestion pseudowires [RFC5659]), the whole path is divided into
notification and feedback loop. In these cases, the function segments, each with its own congestion notification and
that regulates load at the start of each segment will need to feedback loop. In these cases, the function that regulates
reset congestion notification for its segment. Often the load at the start of each segment will need to reset
point where congestion notification is reset will also be congestion notification for its segment. Often the point
located at the start of a tunnel. However, the resetting where congestion notification is reset will also be located at
function can be thought of as being applied to packets after the start of a tunnel. However, the resetting function can be
the encapsulation function--two logically separate functions thought of as being applied to packets after the encapsulation
even though they might run on the same physical box. Then the function--two logically separate functions even though they
code module doing encapsulation can keep to the copying rule might run on the same physical box. Then the code module
and the load regulator module can reset congestion, without doing encapsulation can keep to the copying rule and the load
any code in either module being conditional on whether the regulator module can reset congestion, without any code in
other is there. either module being conditional on whether the other is there.
On decapsulation in any new scheme: On decapsulation in any new scheme:
1. If the arriving inner header is Not-ECT it implies the 1. If the arriving inner header is Not-ECT it implies the
transport will not understand other ECN codepoints. If the transport will not understand other ECN codepoints. If the
outer header carries an explicit congestion marking, the outer header carries an explicit congestion marking, the
alternate scheme would be expected to drop the packet--the alternate scheme would be expected to drop the packet--the
only indication of congestion the transport will understand. only indication of congestion the transport will understand.
If the alternate scheme recommends forwarding rather than If the alternate scheme recommends forwarding rather than
dropping such a packet, it will need to clearly justify this dropping such a packet, it will need to clearly justify this
skipping to change at page 33, line 7 skipping to change at page 33, line 36
that would otherwise be confounded by ambiguity. that would otherwise be confounded by ambiguity.
11. Acknowledgements 11. Acknowledgements
Thanks to David Black for his insightful reviews and patient Thanks to David Black for his insightful reviews and patient
explanations of better ways to think about function placement and explanations of better ways to think about function placement and
alarms. Thanks to David and to Anil Agarwal for pointing out cases alarms. Thanks to David and to Anil Agarwal for pointing out cases
where it is safe to forward CU combinations of headers. Also thanks where it is safe to forward CU combinations of headers. Also thanks
to Arnaud Jacquet for the idea for Appendix C. Thanks to Gorry to Arnaud Jacquet for the idea for Appendix C. Thanks to Gorry
Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster, Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster,
Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson and Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson,
Philip Eardley for their thoughts and careful review comments, and to Philip Eardley and David Harrington for their thoughts and careful
Stephen Hanna and Ben Campbell respectively for conducting the review comments, and to Stephen Hanna, Ben Campbell and members of
Security Directorate and General Area reviews. the IESG for respectively conducting the Security Directorate,
General Area and IESG reviews.
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.
author only.
Comments Solicited (to be removed by the RFC Editor): Comments Solicited (to be removed by the RFC Editor):
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors. <tsvwg@ietf.org>, and/or to the authors.
12. References 12. References
12.1. Normative References 12.1. Normative References
skipping to change at page 34, line 43 skipping to change at page 35, line 24
RFC 4774, November 2006. RFC 4774, November 2006.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, [RFC5129] Davie, B., Briscoe, B., and J. Tay,
"Explicit Congestion Marking in "Explicit Congestion Marking in
MPLS", RFC 5129, January 2008. MPLS", RFC 5129, January 2008.
[RFC5559] Eardley, P., "Pre-Congestion [RFC5559] Eardley, P., "Pre-Congestion
Notification (PCN) Architecture", Notification (PCN) Architecture",
RFC 5559, June 2009. RFC 5559, June 2009.
[RFC5659] Bocci, M. and S. Bryant, "An
Architecture for Multi-Segment
Pseudowire Emulation Edge-to-Edge",
RFC 5659, October 2009.
[RFC5670] Eardley, P., "Metering and Marking [RFC5670] Eardley, P., "Metering and Marking
Behaviour of PCN-Nodes", RFC 5670, Behaviour of PCN-Nodes", RFC 5670,
November 2009. November 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. [RFC5696] Moncaster, T., Briscoe, B., and M.
Menth, "Baseline Encoding and Menth, "Baseline Encoding and
Transport of Pre-Congestion Transport of Pre-Congestion
Information", RFC 5696, Information", RFC 5696,
November 2009. November 2009.
skipping to change at page 37, line 6 skipping to change at page 37, line 42
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'.
ECN at the IP layer is designed to carry information about congestion ECN at the IP layer is designed to carry information about congestion
from a congested resource towards downstream nodes. Typically a from a congested resource towards downstream nodes. Typically a
downstream transport might feed the information back somehow to the downstream transport might feed the information back somehow to the
point upstream of the congestion that can regulate the load on the point upstream of the congestion that can regulate the load on the
congested resource, but other actions are possible (see [RFC3168] congested resource, but other actions are possible [RFC3168; section
S.6). In terms of the above unicast scenario, ECN effectively 6]. In terms of the above unicast scenario, ECN effectively intends
intends to create an information channel (for congestion signalling) to create an information channel (for congestion signalling) from 'M'
from 'M' to 'B' (for 'B' to feed back to 'A'). Therefore the goals to 'B' (for 'B' to feed back to 'A'). Therefore the goals of IPsec
of IPsec and ECN are mutually incompatible, requiring some and ECN are mutually incompatible, requiring some compromise.
compromise.
With respect to using the DS or ECN fields as covert channels, With respect to using the DS or ECN fields as covert channels,
S.5.1.2 of RFC4301 says, "controls are provided to manage the section 5.1.2 of RFC4301 says, "controls are provided to manage the
bandwidth of this channel". Using the ECN processing rules of bandwidth of this channel". Using the ECN processing rules of
RFC4301, the channel bandwidth is two bits per datagram from 'A' to 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 '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 combinations of the 2-bit ECN field that it will copy). In both
cases the covert channel bandwidth is further reduced by noise from cases the covert channel bandwidth is further reduced by noise from
any real congestion marking. RFC4301 implies that these covert any real congestion marking. RFC4301 implies that these covert
channels are sufficiently limited to be considered a manageable channels are sufficiently limited to be considered a manageable
threat. However, with respect to the larger (6b) DS field, the same threat. However, with respect to the larger (6b) DS field, the same
section of RFC4301 says not copying is the default, but a section of RFC4301 says not copying is the default, but a
configuration option can allow copying "to allow a local configuration option can allow copying "to allow a local
 End of changes. 39 change blocks. 
106 lines changed or deleted 145 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/