TCP Robust Explicit Congestion Notification (ECN)

Robust ECN (Explicit Congestion Notification)

Robust ECN protects against attacks that sabotage the main congestion g control mechanism of the Internet, , namely, y, the TCP congestion control mechanism. Two forms of this type of attack are A malicious TCP receiver conceals packet losses from the TCP sender. This causes the sender to transmit at high bandwidth for the entire lifetime of the TCP session. A TCP accelerator sends optimistic p TCP acknowledgements g to "fast start" the TCP session to a preset bandwidth quickly and maintain this bandwidth for the entire lifetime of the TCP session. session

Robust ECN
Robust Explicit Congestion Notification, referred to as Robust ECN, is an Experimental Protocol for the Internet community. Robust ECN is defined in Request for Comments 3540 issued in June 2003. RFC 3540 is an optional addition to RFC 3168 (Explicit Congestion Notification, or ECN). The goal of ECN is to enhance the speed performance of TCP connections and reduce the severity y of Internet congestion. g The goal of the Robust ECN extension is to improve TCP robustness against malicious concealment of packet losses. To explain how Robust ECN works, a high-level understanding of ECN is needed.

Explicit Congestion Notification (ECN)

Explicit Congestion Notification (ECN) is an extension to the h Internet I Protocol P l and d is i defined d fi d in i RFC 3168 (2001). (2001) It I is i an optional feature, and is only used when both the sender and receiver agree g to use it and are ECN-capable. p The benefit of ECN increases with the increase of the number of deployed ECN-routers that can understand the ECN protocol. Types of Routers: Non ECN-capable router: drops incoming packets when fully congested. d ECN-capable router: tries to avoid congestion before it y before the router occurs and drops packets probabilistically becomes fully congested.

Active Queue Management

AQM Router FCFS scheduler Marker/ Dropper

Client

Server

Simultaneouslyachieveshighthroughputandlowaveragedelay AQMalgorithmscanmark(insteadofdrop)packets TherouterandbothendpointshavetobeECNenabled

ECN-Capable Routers
0 THmin THmax C

Donotdiscard

Discardwithincreasing probability

Discard

ECN-capable routers employ an active queue management (AQM) protocol that discards packets proactively upon detecting an incipient congestion. The most popular type of AQM routers is RED (Random Early Detection) routers, for example, Cisco WRED routers. The router drops packet probabilistically when the average size of the queue of packets is between two thresholds thresholds, THmin i and THmax where Thmax is less than the capacity of the buffer, C. For ECN-capable TCP connections, the router does not drop the packet at the time i of f incipient i i i congestion. i Instead I d , the h router marks k (tags) ( ) the h packet k by b setting a Congestion Experienced (CE) code in two bits in the IP header. When the receiver receives a marked bit, it should notify y the sender by y setting the ECN-Echo bit in the TCP header.

RED Algorithm Review

0 THmin THmax C

Donotdiscard

Markordiscardwith increasingprobabilityPa

Discard

Pa is called the packet dropping probability or packet marking probability if (avg < THmin) { accept and queue packet } else if (THmin avg THmax) {calculate probability Pa; with probability Pa Mark or discard p packet otherwise with probability 1 Pa queue packet } else if (avg > THmax) { discard packet } q = length of the queue avg = average length l h of f the h queue Computing Pa F = (avg - THmin)/(THmax THmin) Pb = F Pmax 0F1 Pa = Pb / (1 - count Pb) = 1/ ({1/ Pb} - count )

ECN-Capable Routers
Congestion is detected

Sender

Non ECN packet Non-ECN drop packet

ECN Router

Receiver

Congestion is detected

ECN packet

Sender

ECN-Echo is set

ECN Router

CE is set
ECN-Echo is set

Receiver

When the sender receives an ACK with ECN ECN-Echo Echo set, it should react to the congestion in the same way it would have reacted if the packet was lost, i.e., the sender should reduce its transmission rate by reducing its congestion window, cwnd.

ECN Bits in IP Header

ECN uses two bits in the IP header.

2 bits => 4 ECN Codepoints

Value 00 10 01 11 Name Not-ECT (Not ECN Capable Transport) ECT(0) (ECN Capable Transport (0) ) Nonce = 0 ECT(1) (ECN Capable Transport (1) ) Nonce = 1 CE (Congestion Experienced)

The sender sets ECT(1) or ECT(0) in the ECN field of the IP header on outgoing packets to indicate to routers that the TCP connection is ECN-Capable. ECN Capable Basically, Basically the sender is promising the router that the TCP connection will reduce its transmission rate if the router marks the packet instead of dropping it. This is a win-win win win situation because the TCP connection will save the overhead of retransmitting the packet but will also reduce its transmission rate, thereby helping in alleviating the congestion of the router.

ECN Bits in IP Header

2 bits => 4 ECN Codepoints
Value 00 10 01 11 Name Not-ECT (Not ECN Capable Transport) p ) ECT(0) (ECN Capable Transport (0) ) ECT(1) (ECN Capable Transport(1) ) CE (Congestion Experienced)

Bits 6 and 7 in the IPv4 Differentiated Services Field are designated g as the ECN field. The two bits have been approved for experimental use for ECN.

ECN Bits in TCP Header

ECN uses two bits in the TCP header. h d The Th two t bits bit are bits 8 and 9 of the unused Reserved bits in the FLAGS field. field When the receiver receives a packet with CE indication, it notifies the sender of the detected congestion g by y setting g the ECN-Echo (ECE) bit in the returned ACK.

ECE flag ECN-Echo flag

CWR flag Congestion Window Reduced flag
OnreceiptofECEACK,theTCPsenderSHOULDreactinthesamewayasit wouldforapacketlossinnonECNcapableTCP.

Negotiation between ECN TCP transport entities sender receiver

TCP Sender sets both ECE and CWR in SYN packet TCP Receiver sets only y ECE in SYN-ACK p packet A host must not set ECT in SYN or SYN-ACK packets
SomefaultyfirewallseitherdropanECNsetupSYNpacketorrespond withanRSTTCPpacket

// TCP header // TCP header // IP header

Rules of ECN- Receiver

When TCP receives a CE data packet at the destination end-system, the TCP data receiver sets the ECN-Echo flag in the TCP header of the subsequent ACK packet. To provide robustness against the possibility of a dropped ACK packet carrying an ECN-Echo flag, the TCP receiver sets the ECN-Echo flag in a series of ACK packets sent subsequently. The TCP receiver continues to set the ECN-Echo flag in its acknowledgments until it receives a data segment with the CWR flag set by the TCP sender. After the receipt of the CWR indication, acknowledgments for subsequent non-CE CE data d t packets k t do d not t have h the th ECN-Echo ECN E h flag fl set. t If another th CE packet is received by the receiver, the receiver would once again send ACK packets with the ECN-Echo flag set.

Rules of ECN: Sender

For a TCP connection using ECN, new data packets are transmitted with an ECT codepoint set, ECT(0) or ECT(1), in the IP header. If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with the ECN-Echo ECN Echo flag set in the TCP header), header) then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non-ECNCapable TCP. That is, the TCP sender halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh". This is done as follows ssthresh = cwnd/2; cwnd = ssthresh; TCP should not react to congestion indications more than once every window of data (i e once every round (i.e., round-trip trip time). time) That is, is the TCP sender sender's s congestion window should be reduced only once in response to a series of dropped and/or CE marked packets from a single window of data. When an ECN-Capable TCP sender reduces its congestion window the TCP sender sets the h CWR fl flag in i the h TCP header h d of f the h first fi new data d packet k sent after f the h window reduction. When the TCP data sender is ready to set the CWR bit after reducing the congestion window, it should set the CWR bit only on the first new data packet that it transmits.

Rules of ECN- Routers

ECN-capable routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis. For a router, the CE codepoint (binary code 11) of an ECN-Capable packet should only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes. When the router's buffer is not yet full and the router is prepared to drop a packet to inform end nodes of incipient congestion, the router should first check to see if the ECT codepoint d i t is i set t (i.e., (i binary bi code d 10 or 01) in i that th t packet's k t' IP header. h d If so, then instead of dropping the packet, the router sets the CE codepoint in the IP header.

Advantages of ECN
ECN p prevents unnecessary yp packet drops p at routers resulting g in less retransmissions and improvement in throughput ECN avoids timeouts by getting faster notification to end hosts Less retransmissions also means less traffic on the network

Robust ECN
The correct operation of ECN requires the cooperation of the receiver to return Congestion Experienced signals to the sender but the ECN protocol lacks a mechanism to enforce sender, this cooperation. This raises the possibility that a malicious or poorly implemented receiver could always clear ECN-Echo and d refuse f to return congestion i signals i l to the h sender. d This hi would give the receiver a performance advantage at the expense p of other TCP connections that behave p properly. p y The ECN-nonce is a simple, efficient mechanism to eliminate the potential abuse of TCP connections. connections

Robust ECN
The ECN-nonce enables the sender to verify the correct behavior of the ECN receiver and that there is no other interference that conceals l marked k d or dropped d d packets k t in i the th routing ti path. th The Th ECN nonce protects against implementation errors and deliberate abuse. The ECN nonce: catches a misbehaving receiver with a high probability, and never implicates an innocent receiver. does not change other aspects of ECN, nor does it reduce the benefits of ECN for behaving receivers. is cheap in both per-packet per packet overhead and processing requirements; it introduces only one new bit in the TCP header which is bit 7 of the unused Reserved bits in the TCP FLAGS field.

Robust ECN
The use of the ECN-nonce has two additional benefits, even when only non-ECN routers are used (i.e., even if all routers drop ECN packets and never mark them). With Robust ECN, ECN packet drops (losses) cannot be concealed from the sender. Robust ECN prevents optimistic TCP acknowledgements , in which hi h TCP segments t are acknowledged k l d d before b f they th have h been b received.

The above benefits also serve to increase the robustness of congestion control from attacks.

Abusing ECN

Receiverhidesdroppedandmarkedpacketsandcontinuouslysends gtheECNEchobit. normalACKswithoutenabling Senderisnotawareofthecongestionandkeepsincreasingits sendingrate.
There is no congestion. I will increase cwnd

Congestion!!! I will not report it to the sender

ECN packet
Congested

CE set Normal ACK

ECN-Echo is not set

ECN-Echo is not set

ECN enabled sender d

Congested ECN enabled router

ECN enabled receiver i

The Robust ECN Protocol

The ECN protocol for TCP remains unchanged, except for the definition of a new binary field, the nonce sum (NS) bit, in the TCP header. As in ECN, ECT(0) or ECT(1) (ECN (ECN-Capable Capable Transport) is set in the ECN field of the IP header on outgoing packets. Congested routers change this field to CE (Congestion Experienced). When the TCP receiver notices CE the ECE (ECN-Echo) CE, (ECN Echo) flag is set in subsequent acknowledgements acknowledgements. The ECN nonce enables the receiver to demonstrate to the sender that segments (packets) being acknowledged were not dropped and were not received marked. A random one-bit value (a nonce) is encoded by the sender in the two ECT bits in the IP header. The one-bit sum of these nonces is returned in the nonce sum (NS) bit bit. Packet dropping destroys the nonce value because the entire IP header is lost. Packet marking erases the nonce value because CE overwrites the two ECN bits in the IP header. header Since each nonce is required to correctly calculate the sum, sum the correct nonce sum implies receipt of only unmarked packets.

The Robust ECN Protocol

The sender can verify the nonce sum returned by the receiver to ensure that congestion indications in the form of marked or dropped packets k are not b being i concealed. l d Because B the h nonce sum is i only l one bit long, senders have a 50-50 chance of catching a lying receiver g conceals a dropped pp or marked whenever an acknowledgement packet. Because each acknowledgement is an independent trial, cheaters will be caught quickly if there are repeated congestion signals. signals Each acknowledgement carries a nonce sum, which is the one bit sum (Exclusive-OR) (E l i OR) of f bi binary nonces over the h b byte range represented by the acknowledgement.

Illustration
The sender uses the two ECN bits in the IP header to attach a nonce with each packet.
Value 00 10 01 11 Name Not-ECT (Not ECN Capable Transport) ECT(0) (ECN Capable Transport (0) ) Nonce = 0 ECT(1) (ECN Capable Transport(1) ) CE (Congestion Experienced) Nonce = 1

The binary variable Nonce Sum is initially to zero in both the sender and receiver. When acknowledging a received packet, the receiver should return to the sender the current value of the Nonce Sum variable via the NS bit in the TCP header. The following slide shows different scenarios.

Example 1: Honest Receiver

Nonce Sum (NS) is initially set to zero in both the sender and receiver.

Packet Number

ECT bits transmitted

Nonce

Congestion inpath

ECTbits received

ValueofNS atreceiver

NS &ECE bits inTCPACK header

1 2 3 4 5 6

10 01 01 01 10 10

0 1 1 1 0 0

No No No No No Yes

10 01 01 01 10 11

0 1 0 1 1 unknown

0&0 1&0 0 &0 1&0 1&0 * &1

For packet 6, the honest TCP receiver gets a marked data packet with CE indication. The value of NS cannot be determined. The receiver sets the ECE fl i flag in th the TCP ACK h header d t to 1 1. ECE =1 1 i implies li th that t th the nonce sum bit (denoted by * in the above table) does not store a valid value.

Example 1: Malicious Receiver

Nonce Sum (NS) is initially set to zero in both the sender and receiver.

Packet Number

ECT bits transmitted

Nonce

Congestion inpath

ECTbits received

ValueofNS atreceiver

NS &ECE bits inTCPACK header

1 2 3 4 5 6

10 01 01 01 10 10

0 1 1 1 0 0

No No No No No Yes

10 01 01 01 10 11

0 1 0 1 1 unknown

0&0 1&0 0 &0 1&0 1&0 guessed value&0

For packet 6, the malicious TCP receiver hides the CE indication and does not echo it to the sender. sender The receiver sends normal ACK containing a guess for the value of NS.

The Robust ECN Protocol

Sender Behavior To place a one bit nonce value on every ECN-capable IP packet, the sender d uses the th two t ECT codepoints d i t as follows: f ll ECT(0) represents t a nonce of 0, and ECT(1) a nonce of 1. As in ECN, retransmissions are not ECN capable, so carry no nonce. The sender maintains a mapping from each packet's end sequence number to the expected nonce sum in the acknowledgement bearing that sequence number. Router Behavior An ECN router drops or marks a packet to signal congestion. This action ti removes the th original i i l value l of f the th nonce represented t d by b ECT(0) or ECT(1). Once the nonce is removed, the dishonest receiver cannot acknowledge this packet without successfully guessing the value of the original nonce.

The Robust ECN Protocol

Receiver Behavior The TCP receiver maintains and updates p the nonce sum whenever an in-order packet arrives with a new ECN nonce. The receiver fetches the new nonce from the IP header and adds it (modulo 2) to the current nonce sum. sum The receiver returns the current nonce sum in each TCP acknowledgement. When the TCP receiver gets a marked data packet with CE indication, it sets the ECN-Echo flag in the TCP header of the acknowledgement. g The ECN-Echo flag g implies p that the nonce sum bit does not store a valid value.

Summary of Robust ECN Protocol

The nonce sum is checked by the sender when an acknowledgement of new data is received. Checking consists of comparing the correct nonce sum stored in the mapping pp g maintained by y the sender to that carried in the acknowledgement. If ECN-Echo is not set, the receiver claims to have received no marked packets, and can therefore compute and return the correct nonce sum. To conceal a dropped packet or a marked packet, the receiver must successfully guess the sum of the nonces that it did not receive. Since the individual nonces are equally likely to be 0 or 1, their sum is equally likely to be 0 or 1. In other words, any guess is equally likely to be wrong and has a 50-50 chance of being caught by the sender. sender Because each new acknowledgement is an independent trial, a cheating y to be caught g after a small number of lies. receiver is likely

Summary of Robust ECN Protocol (continued)

If ECN-Echo is set, the receiver is honest and is sending a congestion signal. In this case, the value of the nonce sum is i l irrelevant and d the h sender d will ill not bother b h to check h k its i correctness. The sender will simply reduce its congestion window and will re-synchronize y the nonce sum value with the receiver. Details of this re-synchronization process are given RFC 3540. If the sender detects an incorrect nonce, it concludes that the receiver is attempting to hide packet losses and has guessed the nonce sum incorrectly. i tl The Th sender's d ' response to t an incorrect i t nonce (by punishing the receiver) is a matter of policy and does not need to be handled uniformly by all senders.

Protecting Against Congestion Control Attacks

The ECN nonce can provide robustness against congestion control attacks by checking that dropped and marked packets are not falsely acknowledged to the sender by a cheating receiver.

Behavior of TCP Congestion Control

Packet loss Congestion avoidance Time-out & standard recovery Packet loss Fast Recovery Packet loss

20

Congest tion window w

15

Time-out & standard recovery

10 Slow start t t 5

Plot of TCP Congestion Window vs. Time

Round-trip times

Attack Against Congestion Control

Packet losses are reported Packet losses are concealed

Congestionwind dow

Robust ECN protects against this type of attack

Time(s)

Honest Receiver

Malicious Receiver
The malicious TCP C receiver hides p packet losses. Multiple malicious TCP users could cooperate to congest the server.

Protecting Against Other Misbehaviors

The ECN-nonce can provide robustness beyond checking that dropped and marked packets are not falsely acknowledged to the sender d b by a cheating h i receiver. i Packet drops could potentially be concealed by a faulty TCP implementation, certain attacks, or even a hypothetical TCP accelerator. TCP accelerator could gamble that it can either successfully "fast start" to a preset bandwidth quickly or retry with multiple connections to provide reliability at the application level. If robustness against these faults is also desired, then disabling the ECN nonce mechanism should not be used as one of the options to punish the receiver. Instead, reducing the congestion window to one, or using a low-priority queue, would penalize the faulty receiver while p providing g the sender the ability y to continue checking. g

Proper TCP Behavior During Slow Start

Sender begins with congestion window cwnd = 1 and sends a single packet. Receiver acknowledges a packet only after receiving it correctly. In the Slow Start phase, the sender doubles cwnd, i.e., doubles its sending rate after each round trip time (RTT) if there are no packet losses losses.
Sender Receiver

cwnd d

2 3 4 5 6 7 8

TCP Receiver Accelerator

Sender begins with cwnd = 1 and sends a single packet. Receiver acknowledges the first packet after receiving it correctly, but acknowledges other packets before receiving them. In the Slow Start phase, the sender doubles cwnd, i.e., doubles its sending rate much earlier than RTT and reaches its maximum sending rate very quickly. The sender also maintains this maximum sending rate for the entire lifetime of the connection because the receiver never reports packet losses.
Sender Receiver

cwnd d

Attack by Receiver Accelerator

Conge estionwindow w

Time(s)

Conge estionwindow w

Time(s)

Honest Receiver

Receiver Accelerator

The malicious Th li i accelerator l t causes the th sender d to t double d bl the th congestion ti window i d and d thus double its sending rate much earlier than normal. The sender reaches its maximum sending rate very quickly and stays at this maximum rate.

Security Considerations for Robust ECN

The random one-bit nonces need not be from a cryptographic-quality pseudo-random number generator. A strong t random d number b generator t may compromise i the th speed performance of the TCP sender. But the pseudo-random bit sequence should not be generated by an oversimplified scheme such as a linear feedback shift register, or similar scheme that would allow an adversary who has seen several previous nonce bits to infer the generation function and thus its future output. It is important to notice that although the ECN nonce protects against concealment of congestion signals and optimistic acknowledgement, it provides no additional protection for the integrity of the connection.

Additional Remark
The approach of Robust ECN is to use binary nonces to detect if the receiver is cheating and is hiding packet losses by guessing the value of the nonce sum. Any guess is equally likely to be wrong and has a 50-50 chance of being caught by the sender. d Because each h new acknowledgement k l d is i an independent i d d trial, i l a cheating h i receiver is likely to be caught after a small number of lies. The e binary b a y nonce o ce approach app oac is s used in so some e ot other e secu security ty p protocols otoco s such suc as Fiat Shamir protocol used for entity authentication in real-time client server sessions. Each round consists of three message exchanges and uses a binary nonce . A dishonest claimant (attacker) has a probability of 0.5 for authenticating th ti ti successfully f ll in i each h round. d Using U i 20 rounds, d the th chances h of f success is reduced to approximately 1 in one million. 802.11i protocol used for Wireless LAN Security. In the EAP Exchange of g from AS and the response p the 802.11i Authentication Phase, the challenge from STA may be repeated multiple times (often requiring 10 to 20 round trips for TLS tunneling).
EAP = Extensible Authentication Protocol AS = Authentication Server STA = Station TLS = Transport Layer Security Protocol

Incompatibility and Implementation Problems

RFC 3540 defines bit 7 from the Reserved field of the TCP header to be used for the Nonce Sum. There exist some faulty firewalls, load balancers, and intrusion detection systems in the Internet that either drop an ECN-setup SYN packet or respond with a RST to establishing an ECN-capable TCP connection, in the belief that such a packet (with these bits set) is a signature for a portscanning tool that could be used in a denial-of- service attack. Problems with non-ECN-compatible equipment were identified in the early stages of ECN d l development. t

http://www.icir.org/floyd/ecn.html http://www.icir.org/floyd/ecnProblems.html
Many of the offending machines/products were identified, and an earlier web page was developed containing a list of non-compliant products and the fixes posted by the vendors vendors.

http://gtf.org/garzik/ecn/
However, the above web page was lost in a hard drive storm crash and is no However longer maintained.