8. Non-compliance in the Network
8. Non-compliance in the Network
This section considers the issue of routers that might maliciously manipulate either of the bits in the ECN field. We note that in IPv4, the IP header is protected against bit errors by a header checksum; this is not the case in IPv6. Therefore, for IPv6, the ECN field could be modified accidentally by bit errors in a link or router, without being detected by an IP header checksum.
By tampering with the bits in the ECN field, an adversary (or corrupted router) could do one or more of the following: falsely report congestion, disable ECN-capability for a single packet, clear an ECN congestion indication, or falsely indicate ECN-capability. Section 18 systematically examines the various ways in which the ECN field might be modified. The important criterion in determining the consequences of such modification is whether it is likely to result in behavior that is worse in any dimension (throughput, delay, fairness, or functionality) than if a router simply dropped a packet.
The first two of the possible changes, falsely reporting congestion or disabling ECN-capability for a single packet, are no worse than if the router simply dropped a packet. From a congestion control point of view, a non-compliant router that sets the CE codepoint in the absence of congestion is no worse than a router that unnecessarily drops packets. By "clearing" the ECT codepoint of a packet that is later dropped in the network, the router's behavior could result in unnecessary packet drops later in the network for that packet.
However, as discussed in Section 18, a router that clears the ECN congestion indication or falsely indicates ECN-capability could cause greater harm to a flow than simply dropping a packet. A rogue or corrupted router that clears the CE codepoint in an arriving CE packet would prevent that congestion indication from reaching the downstream receiver. This could result in the congestion control for that flow to fail and the network congestion to increase, ultimately resulting in subsequent packets from that flow being dropped, as the average queue size at the congested gateway increases.
Section 19 considers the potential consequences of subverting end-to-end congestion control by falsely indicating ECN-capability or clearing the congestion indication (the CE codepoint) in ECN. We observe in Section 19 that the consequence of subverting ECN-based congestion control could result in potential unfairness, but might not be worse than end nodes subverting either ECN-based or packet-based congestion control.