draft-ietf-tsvwg-ecn-tunnel-05.txt   draft-ietf-tsvwg-ecn-tunnel-06.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft BT Internet-Draft BT
Updates: 3168, 4301 December 18, 2009 Updates: 3168, 4301 December 20, 2009
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: June 21, 2010 Expires: June 23, 2010
Tunnelling of Explicit Congestion Notification Tunnelling of Explicit Congestion Notification
draft-ietf-tsvwg-ecn-tunnel-05 draft-ietf-tsvwg-ecn-tunnel-06
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 21, 2010. This Internet-Draft will expire on June 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . 18
5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 19 5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 19
5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 19 5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 19
5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 20 5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 20
skipping to change at page 3, line 39 skipping to change at page 3, line 39
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 33 Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 33
Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 33 Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 33
B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 33 B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 33
B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 35 B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 35
B.3. Management Constraints . . . . . . . . . . . . . . . . . . 37 B.3. Management Constraints . . . . . . . . . . . . . . . . . . 36
Appendix C. Contribution to Congestion across a Tunnel . . . . . 37 Appendix C. Contribution to Congestion across a Tunnel . . . . . 37
Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN . . . 38 Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN . . . 38
Appendix E. Why Resetting ECN on Encapsulation Impedes PCN . . . 39 Appendix E. Why Resetting ECN on Encapsulation Impedes PCN . . . 39
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 . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . . 41 Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . . 41
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-04 to ietf-05 (current): From ietf-05 to ietf-06 (current):
* Minor textual clarifications and corrections.
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.
+ Altered rationale in bullet 3 of Section 5.3.2 to justify + Altered rationale in bullet 3 of Section 5.3.2 to justify
this. this.
skipping to change at page 9, line 30 skipping to change at page 9, line 41
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] considers a Nonetheless, the latest IPsec architecture [RFC4301] considered a
bandwidth limit of 2 bits per packet on a covert channel makes 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
copies the whole ECN field to encapsulate a packet. It also copied the whole ECN field to encapsulate a packet. It also
dispenses with the two modes of RFC3168, one which partially copied dispensed with the two modes of RFC3168, one which partially copied
the ECN field, and the other which blocked all propagation of ECN the 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
skipping to change at page 14, line 18 skipping to change at page 14, line 21
Inappropriate changes were not specifically enumerated. RFC4301 did Inappropriate changes were not specifically enumerated. RFC4301 did
not mention inappropriate ECN changes. not mention inappropriate ECN changes.
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 unavoidable, an alternate congestion encapsulation behaviour can If these defaults do not meet a particular requirement, an alternate
be introduced as part of the definition of an alternate congestion ECN tunnelling scheme can be introduced as part of the definition of
marking scheme used by a specific Diffserv PHB (see S.5 of [RFC3168] an alternate congestion marking scheme used by a specific Diffserv
and [RFC4774]). When designing such new encapsulation schemes, the PHB (see S.5 of [RFC3168] and [RFC4774]). When designing such
principles in Section 7 should be followed. However, alternate ECN alternate ECN tunnelling schemes, the principles in Section 7 should
tunnelling schemes are NOT RECOMMENDED as the deployment burden of be followed. However, alternate ECN tunnelling schemes are NOT
handling exceptional PHBs in implementations of all affected tunnels RECOMMENDED as the deployment burden of handling exceptional PHBs in
should not be underestimated. There is no requirement for a PHB implementations of all affected tunnels should not be underestimated.
definition to state anything about ECN tunnelling behaviour if the There is no requirement for a PHB definition to state anything about
default behaviour in the present specification is sufficient. ECN tunnelling behaviour if the default behaviour in the present
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; `normal mode' and
`compatibility mode', which is for backward compatibility with tunnel `compatibility mode', which is for backward compatibility with tunnel
decapsulators that do not understand ECN. Section 4.3 explains why decapsulators that do not understand ECN. Section 4.3 explains why
two modes are necessary and specifies the circumstances in which it two modes are necessary and specifies the circumstances in which it
is sufficient to solely implement normal mode. Note that these are 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.
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. These rules ECN field in the outer header to the Not-ECT codepoint (the IPv4
are tabulated for convenience in Figure 3. header checksum also changes whenever the ECN field is changed).
These rules are tabulated for convenience in Figure 3.
+-----------------+-------------------------------+ +-----------------+-------------------------------+
| Incoming Header | Outgoing Outer Header | | Incoming Header | Outgoing Outer Header |
| (also equal to +---------------+---------------+ | (also equal to +---------------+---------------+
| Outgoing Inner | Compatibility | Normal | | Outgoing Inner | Compatibility | Normal |
| 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) |
skipping to change at page 15, line 45 skipping to change at page 15, line 45
| 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 |
+---------+---------+------------+------------+------------+ +---------+---------+------------+------------+------------+
| Outgoing Header | | Outgoing Header |
+------------------------------------------------+ +------------------------------------------------+
Unexpected combinations are indicated by '(!!!)' 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 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]. In addition:
* 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 outgoing ECN o In all other cases where the inner supports ECN, the decapsulator
field is set to the more severe marking of the outer and inner ECN MUST set the outgoing ECN field to the more severe marking of the
fields, where the ranking of severity from highest to lowest is outer and inner ECN fields, where the ranking of severity from
CE, ECT(1), ECT(0), Not-ECT. This in no way precludes cases where highest to lowest is CE, ECT(1), ECT(0), Not-ECT. This in no way
ECT(1) and ECT(0) have the same severity; precludes cases where ECT(1) and ECT(0) have the same severity;
o Certain combinations of inner and outer ECN fields cannot result o Certain combinations of inner and outer ECN fields cannot result
from any currently used transition in any current or previous ECN from any transition in any current or previous ECN tunneling
tunneling specification. These cases are indicated in Figure 4 by specification. These currently unused (CU) combinations are
'(!!!)' or '(!)', where '(!!!)' means the combination is both indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the
invalid and always potentially dangerous, while '(!)' means it is combination is CU and always potentially dangerous, while '(!)'
invalid and possibly dangerous. In these cases, particularly the means it is CU and possibly dangerous. In these cases,
more dangerous ones, the decapsulator SHOULD log the event and MAY particularly the more dangerous ones, the decapsulator SHOULD log
also raise an alarm. Just because the highlighted combinations the event and MAY also raise an alarm.
are always invalid, does not mean that all the other combinations
are always valid. Some are only valid if they have arrived from a
particular type of legacy ingress, and dangerous otherwise.
Therefore an implementation MAY allow an operator to configure
logging and alarms for such additional header combinations known
to be dangerous or invalid for the particular configuration of
tunnel endpoints deployed at run-time.
Alarms should be rate-limited so that the illegal combinations Just because the highlighted combinations are currently unused,
does not mean that all the other combinations are always valid.
Some are only valid if they have arrived from a particular type of
legacy ingress, and dangerous otherwise. Therefore an
implementation MAY allow an operator to configure logging and
alarms for such additional header combinations known to be
dangerous or CU for the particular configuration of tunnel
endpoints deployed at run-time.
Alarms should be rate-limited so that the anomalous combinations
will not amplify into a flood of alarm messages. It MUST be will not amplify into a flood of alarm messages. It MUST be
possible to suppress alarms or logging, e.g. if it becomes possible to suppress alarms or logging, e.g. if it becomes
apparent that a combination that previously was not used has apparent that a combination that previously was not used has
started to be used for legitimate purposes such as a new standards started to be used for legitimate purposes such as a new standards
action. action.
The above logic allows for ECT(0) and ECT(1) to both represent the The above logic allows for ECT(0) and ECT(1) to both represent the
same severity of congestion marking (e.g. "not congestion marked"). same severity of congestion marking (e.g. "not congestion marked").
But it also allows future schemes to be defined where ECT(1) is a But it also allows future schemes to be defined where ECT(1) is a
more severe marking than ECT(0), in particular enabling the simplest more severe marking than ECT(0), in particular enabling the simplest
skipping to change at page 18, line 26 skipping to change at page 18, line 28
packets in compatibility mode in case the egress it discovers is a packets in compatibility mode in case the egress it discovers is a
legacy egress. If, through the discovery protocol, the egress legacy egress. If, through the discovery protocol, the egress
indicates that it is compliant with the present specification, with indicates that it is compliant with the present specification, with
RFC4301 or with RFC3168 full functionality mode, the ingress can RFC4301 or with RFC3168 full functionality mode, the ingress can
switch itself into normal mode. If the egress denies compliance with switch itself into normal mode. If the egress denies compliance with
any of these or returns an error that implies it does not understand any of these or returns an error that implies it does not understand
a request to work to any of these ECN specifications, the tunnel a request to work to any of these ECN specifications, the tunnel
ingress MUST remain in compatibility mode. ingress MUST remain in compatibility mode.
An ingress cannot claim compliance with this specification simply by An ingress cannot claim compliance with this specification simply by
disabling ECN processing across the tunnel (i.e. only implementing permanently disabling ECN processing across the tunnel (i.e. only
compatibility mode). It is true that such a tunnel ingress is at implementing compatibility mode). It is true that such a tunnel
least safe with the ECN behaviour of any egress it may encounter, but ingress is at least safe with the ECN behaviour of any egress it may
it does not meet the aim of introducing ECN support to tunnels. encounter, but it does not meet the aim of introducing ECN support to
tunnels.
Implementation note: if a compliant node is the ingress for multiple Implementation note: if a compliant node is the ingress for multiple
tunnels, a mode setting will need to be stored for each tunnel tunnels, a mode setting will need to be stored for each tunnel
ingress. However, if a node is the egress for multiple tunnels, none 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 of the tunnels will need to store a mode setting, because a compliant
egress can only be in one mode. egress can only be in 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 has one mode of operation. However, if
skipping to change at page 19, line 4 skipping to change at page 19, line 7
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
[RFC3168]. In all these cases, a decapsulating tunnel egress [RFC3168]. In all these cases, a decapsulating tunnel egress
compliant with this specification MUST agree to any of these compliant with this specification MUST agree to any of these
requests, since it will behave identically in all these cases. requests, since it will behave identically in all these cases.
If no ECN-related mode is requested, a compliant tunnel egress MUST If no ECN-related mode is requested, a compliant tunnel egress MUST
continue without raising any error or warning as its egress behaviour continue without raising any error or warning as its egress behaviour
is compatible with all the legacy ingress behaviours that do not is compatible with all the legacy ingress behaviours that do not
negotiate capabilities. negotiate capabilities.
For 'forward compatibility', a compliant tunnel egress SHOULD raise a A compliant tunnel egress SHOULD raise a warning alarm about any
warning alarm about any requests to enter modes it does not requests to enter modes it does not recognise but, for 'forward
recognise, but it SHOULD continue operating. compatibility' with standards actions possibly defined after it was
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
Egress: The new decapsulation behaviour in Figure 4 updates RFC4301. Egress: The new decapsulation behaviour in Figure 4 updates RFC4301.
However, it solely updates combinations of inner and outer that However, it solely updates combinations of inner and outer that
skipping to change at page 20, line 20 skipping to change at page 20, line 24
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 ingress behaviour of RFC3168. Nonetheless, the new
compatibility mode is identical to the limited functionality mode compatibility mode is identical to the limited functionality mode
of RFC3168. of RFC3168.
Egress: The new decapsulation behaviour in Figure 4 updates RFC3168. Egress: The new decapsulation behaviour in Figure 4 updates RFC3168.
However, the present specification solely updates combinations of However, the present specification solely updates combinations of
inner and outer that would never result from any protocol defined inner and outer that would never result from any protocol defined
in the RFC series so far, even though they were catered for in in the RFC series so far, even though they were catered for in
RFC4301 for completeness. Therefore, the present specification RFC3168 for completeness. Therefore, the present specification
adds new behaviours to RFC3168 decapsulation without altering adds new behaviours to RFC3168 decapsulation without altering
existing behaviours. The following specific updates have been existing behaviours. The following specific updates have been
made: 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.
skipping to change at page 23, line 36 skipping to change at page 23, line 39
the box was deployed, often on the grounds that anything the box was deployed, often on the grounds that anything
unexpected might be an attack. This tends to bar future use of unexpected might be an attack. This tends to bar future use of
CU values. The new decapsulation rules specify optional logging CU values. The new decapsulation rules specify optional logging
and/or alarms for specific combinations of inner and outer header and/or alarms for specific combinations of inner and outer header
that are currently unused. The aim is to give implementers a that are currently unused. The aim is to give implementers a
recourse other than drop if they are concerned about the security recourse other than drop if they are concerned about the security
of CU values. It recognises legitimate security concerns about of CU values. It recognises legitimate security concerns about
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. a 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. None
of these combinations should result from Internet protocols in of these combinations should result from Internet protocols in
the RFC series, but future standards actions might put any or all the RFC series, but future standards actions might put any or all
of them to good use. Therefore it was decided that a of them to good use. Therefore it was decided that a
decapsulator must forward a Not-ECT inner unchanged, even if the decapsulator must forward a Not-ECT inner unchanged, even if the
arriving outer was ECT(0) or ECT(1). But for safety it should arriving outer was ECT(0) or ECT(1). But for safety it should
drop the Not-ECT inner if the arriving outer was CE. Then, if drop a combination of Not-ECT inner and CE outer. Then, if some
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.
ECT(1) is being proposed as an intermediate level of congestion A decapsulator can forward a Not-ECT inner unchanged if its outer
in a scheme progressing through the IETF is ECT(1), even though ECT(1) is being proposed as an
[I-D.ietf-pcn-3-in-1-encoding]. But it was decided that it would intermediate level of congestion in a scheme progressing through
still be safe to mandate forwarding as Not-ECT for a Not-ECT the IETF [I-D.ietf-pcn-3-in-1-encoding]. The rationale is to
inner with an ECT(1) outer, thus keeping this combination ensure this CU combination will be usable if needed in the
available for future use. The rationale was as follows: if any future. If any misconfiguration led to ECT(1) congestion signals
misconfiguration led to ECT(1) congestion signals with a Not-ECT with a Not-ECT inner, it would not be disastrous for the tunnel
inner, it would be safe for the egress to suppress these signals. egress to suppress them, because the congestion should then
This is because the congestion would then escalate to CE marking, escalate to CE marking, which the egress would drop, thus at
which the egress would drop, thus avoiding any risk of congestion least preventing congestion collapse.
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 26, line 36 skipping to change at page 26, line 37
authority is even aware of all the tunnels in a network, which may authority is even aware of all the tunnels in a network, which may
include tunnels set up by applications between endpoints, or include tunnels set up by applications between endpoints, or
dynamically created in the network. Therefore it is highly likely dynamically created in the network. Therefore it is highly likely
that some tunnels within a network or on hosts connected to it will that some tunnels within a network or on hosts connected to it will
not implement the required special case. not implement the required special case.
That said, if a non-default scheme for tunnelling the ECN field is That said, if a non-default scheme for tunnelling the ECN field is
really required, the following guidelines may prove useful in its really required, the following guidelines may prove useful in its
design: design:
On encapsulation in any new scheme: On encapsulation in any alternate scheme:
1. The ECN field of the outer header should be cleared to Not-ECT 1. The ECN field of the outer header should be cleared to Not-ECT
("00") unless it is guaranteed that the corresponding tunnel ("00") unless it is guaranteed that the corresponding tunnel
egress will correctly propagate congestion markings introduced egress will correctly propagate congestion markings introduced
across the tunnel in the outer header. 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 should also copy incoming congestion an encapsulator should 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
skipping to change at page 27, line 36 skipping to change at page 27, line 38
indicate congestion, the alternate scheme can forward the indicate congestion, the alternate scheme can forward the
packet, but probably only as Not-ECT. packet, but probably only as Not-ECT.
2. If the arriving inner header is other than Not-ECT, the ECN 2. If the arriving inner header is other than Not-ECT, the ECN
field that the alternate decapsulation scheme forwards should field that the alternate decapsulation scheme forwards should
reflect the more severe congestion marking of the arriving reflect the more severe congestion marking of the arriving
inner and outer headers. inner and outer headers.
3. Any alternate scheme MUST define a behaviour for all 3. Any alternate scheme MUST define a behaviour for all
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 or not be expected to result from standards known at the time and
from the expected behaviour of the tunnel ingress paired with even those that would not be expected from the tunnel ingress
the egress at run-time. Consideration should be given to paired with the egress at run-time. Consideration should be
logging such unexpected combinations and raising an alarm, given to logging such unexpected combinations and raising an
particularly if there is a danger that the invalid combination alarm, particularly if there is a danger that the invalid
implies congestion signals are not being propagated correctly. combination implies congestion signals are not being
The presence of currently unused combinations may represent an propagated correctly. The presence of currently unused
attack, but the new scheme should try to define a way to combinations may represent an attack, but the new scheme
forward such packets, at least if a safe outgoing codepoint should try to define a way to forward such packets, at least
can be defined. Raising an alarm to warn of the possibility if a safe outgoing codepoint can be defined. Raising an alarm
of an attack is a preferable approach to dropping that ensures to warn of the possibility of an attack is a preferable
these combinations can be usable in future standards actions. approach to dropping that ensures these combinations can be
usable 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
skipping to change at page 33, line 17 skipping to change at page 33, line 17
IP in IP tunnelling was originally defined in [RFC2003]. On IP in IP tunnelling was originally defined in [RFC2003]. On
encapsulation, the incoming header was copied to the outer and on encapsulation, the incoming header was copied to the outer and on
decapsulation the outer was simply discarded. Initially, IPsec decapsulation the outer was simply discarded. Initially, IPsec
tunnelling [RFC2401] followed the same behaviour. tunnelling [RFC2401] followed the same behaviour.
When ECN was introduced experimentally in [RFC2481], legacy (RFC2003 When ECN was introduced experimentally in [RFC2481], legacy (RFC2003
or RFC2401) tunnels would have discarded any congestion markings or RFC2401) tunnels would have discarded any congestion markings
added to the outer header, so RFC2481 introduced rules for added to the outer header, so RFC2481 introduced rules for
calculating the outgoing header from a combination of the inner and calculating the outgoing header from a combination of the inner and
outer on decapsulation. RC2481 also introduced a second mode for outer on decapsulation. RC2481 also introduced a second mode for
IPsec tunnels, which turned off ECN processing(Not-ECT) in the outer IPsec tunnels, which turned off ECN processing (Not-ECT) in the outer
header on encapsulation because an RFC2401 decapsulator would discard header on encapsulation because an RFC2401 decapsulator would discard
the outer on decapsulation. For RFC2401 IPsec this had the side- the outer on decapsulation. For RFC2401 IPsec this had the side-
effect of completely blocking the covert channel. effect of completely blocking the covert channel.
In RFC2481 the ECN field was defined as two separate bits. But when In RFC2481 the ECN field was defined as two separate bits. But when
ECN moved from the experimental to the standards track [RFC3168], the ECN moved from the experimental to the standards track [RFC3168], the
ECN field was redefined as four codepoints. This required a ECN field was redefined as four codepoints. This required a
different calculation of the ECN field from that used in RFC2481 on different calculation of the ECN field from that used in RFC2481 on
decapsulation. RFC3168 also had two modes; a 'full functionality decapsulation. RFC3168 also had two modes; a 'full functionality
mode' that restricted the covert channel as much as possible but mode' that restricted the covert channel as much as possible but
skipping to change at page 34, line 23 skipping to change at page 34, line 23
spans an unprotected internetwork where there may be 'men in the spans an unprotected internetwork where there may be 'men in the
middle', M. middle', M.
physically unprotected physically physically unprotected physically
<-protected domain-><--domain--><-protected domain-> <-protected domain-><--domain--><-protected domain->
+------------------+ +------------------+ +------------------+ +------------------+
| | M | | | | M | |
| A-------->I=========>==========>E-------->B | | A-------->I=========>==========>E-------->B |
| | | | | | | |
+------------------+ +------------------+ +------------------+ +------------------+
<----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. But 'I' can also use IPsec tunnel mode to allow 'A' their contents. In addition 'I' can use IPsec tunnel mode to allow
to communicate with 'B', but impose encryption to prevent 'A' leaking 'A' to communicate with 'B', but impose encryption to prevent 'A'
information to 'M'. Or 'E' can insist that 'I' uses tunnel mode leaking information to 'M'. Or 'E' can insist that 'I' uses tunnel
authentication to prevent 'M' communicating information to 'B'. mode 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'.
ECN at the IP layer is designed to carry information about congestion ECN at the IP layer is designed to carry information about congestion
skipping to change at page 36, line 29 skipping to change at page 36, line 30
'B', otherwise congestion notification from resources like 'M' cannot 'B', otherwise congestion notification from resources like 'M' cannot
be fed back to the Load Regulator ('A'). But it does not seem be fed back to the Load Regulator ('A'). But it does not seem
necessary for 'I' to copy CE markings from the inner to the outer necessary for 'I' to copy CE markings from the inner to the outer
header. For instance, if resource 'R' is congested, it can send header. For instance, if resource 'R' is congested, it can send
congestion information to 'B' using the congestion field in the inner congestion information to 'B' using the congestion field in the inner
header without 'I' copying the congestion field into the outer header header without 'I' copying the congestion field into the outer header
and 'E' copying it back to the inner header. 'E' can still write any and 'E' copying it back to the inner header. 'E' can still write any
additional congestion marking introduced across the tunnel into the additional congestion marking introduced across the tunnel into the
congestion field of the inner header. congestion field of the inner header.
It might be useful for the tunnel egress to be able to tell whether
congestion occurred across a tunnel or upstream of it. If outer
header congestion marking was reset by the tunnel ingress ('I'), at
the end of a tunnel ('E') the outer headers would indicate congestion
experienced across the tunnel ('I' to 'E'), while the inner header
would indicate congestion upstream of 'I'. But similar information
can be gleaned even if the tunnel ingress copies the inner to the
outer headers. At the end of the tunnel ('E'), any packet with an
_extra_ mark in the outer header relative to the inner header
indicates congestion across the tunnel ('I' to 'E'), while the inner
header would still indicate congestion upstream of ('I'). Appendix C
gives a simple and precise method for a tunnel egress to infer the
congestion level introduced across a tunnel.
All this shows that 'E' can preserve the control loop irrespective of All this shows that 'E' can preserve the control loop irrespective of
whether 'I' copies congestion notification into the outer header or whether 'I' copies congestion notification into the outer header or
resets it. resets it.
That is the situation for existing control arrangements but, because That is the situation for existing control arrangements but, because
copying reveals more information, it would open up possibilities for copying reveals more information, it would open up possibilities for
better control system designs. For instance, Appendix E describes better control system designs. For instance, Appendix E describes
how resetting CE marking on encapsulation breaks a proposed how resetting CE marking on encapsulation breaks a proposed
congestion marking scheme on the standards track. It ends up congestion marking scheme on the standards track. It ends up
removing excessive amounts of traffic unnecessarily. Whereas copying removing excessive amounts of traffic unnecessarily. Whereas copying
skipping to change at page 37, line 29 skipping to change at page 37, line 16
In this document we define the baseline of congestion marking (or the In this document we define the baseline of congestion marking (or the
Congestion Baseline) as the source of the layer that created (or most Congestion Baseline) as the source of the layer that created (or most
recently reset) the congestion notification field. When monitoring recently reset) the congestion notification field. When monitoring
congestion it would be desirable if the Congestion Baseline did not congestion it would be desirable if the Congestion Baseline did not
depend on whether packets were tunnelled or not. Given some tunnels depend on whether packets were tunnelled or not. Given some tunnels
cross domain borders (e.g. consider M in Figure 6 is monitoring a cross domain borders (e.g. consider M in Figure 6 is monitoring a
border), it would therefore be desirable for 'I' to copy congestion border), it would therefore be desirable for 'I' to copy congestion
accumulated so far into the outer headers, so that it is exposed accumulated so far into the outer headers, so that it is exposed
across the tunnel. across the tunnel.
For management purposes it might be useful for the tunnel egress to
be able to monitor whether congestion occurred across a tunnel or
upstream of it. Superficially it appears that copying congestion
markings at the ingress would make this difficult, whereas it was
straightforward when an RFC3168 ingress reset them. However,
Appendix C gives a simple and precise method for a tunnel egress to
infer the congestion level introduced across a tunnel. It works
irrespective of whether the ingress copies or resets congestion
markings.
Appendix C. Contribution to Congestion across a Tunnel Appendix C. Contribution to Congestion across a Tunnel
This specification mandates that a tunnel ingress determines the ECN This specification mandates that a tunnel ingress determines the ECN
field of each new outer tunnel header by copying the arriving header. field of each new outer tunnel header by copying the arriving header.
Concern has been expressed that this will make it difficult for the Concern has been expressed that this will make it difficult for the
tunnel egress to monitor congestion introduced only along a tunnel, tunnel egress to monitor congestion introduced only along a tunnel,
which is easy if the outer ECN field is reset at a tunnel ingress which is easy if the outer ECN field is reset at a tunnel ingress
(RFC3168 full functionality mode). However, in fact copying CE marks (RFC3168 full functionality mode). However, in fact copying CE marks
at ingress will still make it easy for the egress to measure at ingress will still make it easy for the egress to measure
congestion introduced across a tunnel, as illustrated below. congestion introduced across a tunnel, as illustrated below.
Consider 100 packets measured at the egress. Say it measures that 30 Consider 100 packets measured at the egress. Say it measures that 30
are CE marked in the inner and outer headers and 12 have additional are CE marked in the inner and outer headers and 12 have additional
CE marks in the outer but not the inner. This means packets arriving CE marks in the outer but not the inner. This means packets arriving
at the ingress had already experienced 30% congestion. However, it at the ingress had already experienced 30% congestion. However, it
does not mean there was 12% congestion across the tunnel. The does not mean there was 12% congestion across the tunnel. The
correct calculation of congestion across the tunnel is p_t = 12/ correct calculation of congestion across the tunnel is p_t = 12/
(100-30) = 12/70 = 17%. This is easy for the egress to measure. It (100-30) = 12/70 = 17%. This is easy for the egress to measure. It
is simply the packets with additional CE marking in the outer header is simply the proportion of packets not marked in the inner header
(12) as a proportion of packets not marked in the inner header (70). (70) that have a CE marking in the outer header (12). This technique
works whether the ingress copies or resets CE markings, so it can be
used by an egress that is not sure which RFC the ingress complies
with.
Figure 7 illustrates this in a combinatorial probability diagram. Figure 7 illustrates this in a combinatorial probability diagram.
The square represents 100 packets. The 30% division along the bottom The square represents 100 packets. The 30% division along the bottom
represents marking before the ingress, and the p_t division up the represents marking before the ingress, and the p_t division up the
side represents marking introduced across the tunnel. side represents marking introduced across the tunnel.
^ outer header marking ^ outer header marking
| |
100% +-----+---------+ The large square 100% +-----+---------+ The large square
| | | represents 100 packets | | | represents 100 packets
skipping to change at page 41, line 14 skipping to change at page 41, line 14
so that the data source could use the ECN nonce [RFC3540] to detect so that the data source could use the ECN nonce [RFC3540] to detect
if congestion signals were being erased. However, in this case, the if congestion signals were being erased. However, in this case, the
decapsulator does not need a nonce to detect any anomalies introduced decapsulator does not need a nonce to detect any anomalies introduced
within the tunnel, because it has the inner as a record of the header within the tunnel, because it has the inner as a record of the header
at the ingress. Therefore, it was decided that the best compromise at the ingress. Therefore, it was decided that the best compromise
would be to give precedence to solving the safety issue over would be to give precedence to solving the safety issue over
revealing the anomaly, because the anomaly could at least be detected revealing the anomaly, because the anomaly could at least be detected
and dealt with internally. and dealt with internally.
Superficially, the opposite case where the inner and outer carry Superficially, the opposite case where the inner and outer carry
different ECT values, but with an ECT(1) outer and ECT(0) inner seems different ECT values, but with an ECT(1) outer and ECT(0) inner,
to require a similar compromise. However, because that case is seems to require a similar compromise. However, because that case is
reversed, no compromise is necessary; it is best to forward the outer reversed, no compromise is necessary; it is best to forward the outer
whether the transport expects the ECT(1) to mean a higher severity whether the transport expects the ECT(1) to mean a higher severity
than ECT(0) or the same severity. Forwarding the outer either than ECT(0) or the same severity. Forwarding the outer either
preserves a higher value (if it is higher) or it reveals an anomaly preserves a higher value (if it is higher) or it reveals an anomaly
to the transport (if the two ECT codepoints mean the same severity). to the transport (if the two ECT codepoints mean the same severity).
Appendix G. Open Issues Appendix 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
 End of changes. 32 change blocks. 
107 lines changed or deleted 116 lines changed or added

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