Robust ECN

8/13/2019 Robust ECN

http://slidepdf.com/reader/full/robust-ecn 1/39



Robust ECN (Explicit Congestion Notification)

Robust ECN protects against attacks that sabotage the main

con estion control mechanism of the Internet namel the TCP

congestion control mechanism. Two forms of this type of attackare

A malicious TCP receiver conceals packet losses from the TCP

sender. This causes the sender to transmit at high bandwidth forthe entire lifetime of the TCP session.

A TCP accelerator sends o timistic TCP acknowled ements to

"fast start" the TCP session to a preset bandwidth quickly and

maintain this bandwidth for the entire lifetime of the TCP

.



Robust ECNRobust ECN

Robust Explicit Congestion Notification, referred to as Robust

ECN, is an Experimental Protocol for the Internet community.

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 severit of Internet con estion. 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) is an extension to

t e nternet rotoco an s e ne n . t s an

optional feature, and is only used when both the sender and

receiver a ree to use it and are ECN-ca able. 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

congeste .ECN-capable router: tries to avoid congestion before it

occurs and drops packets probabilistically before the router

becomes fully congested.



Server Client Marker/

FCFS scheduler

AQM Router

– Simultaneously achieves high throughput and low average delay

– AQM algorithms can mark (instead of drop) packets

– The router

and

both

endpoints

have

to

be

ECN

‐enabled



ECN-Capable Routers

0 min max C

DiscardDiscard with increasing

probability

Do not discard

ECN-capable routers employ an active queue management (AQM) protocolthat discards packets proactively upon detecting an incipient congestion. Themost 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 queueo pac e s s e ween wo res o s, m n an max w ere max s essthan the capacity of the buffer, C.

For ECN-capable TCP connections, the router does not drop the packet at the

t me o nc p ent congest on. Instea , t e router mar s tags t e pac et ysetting a Congestion Experienced (CE) code in two bits in the IP header.

When the receiver receives a marked bit, it should notify the sender by

setting the ECN-Echo bit in the TCP header.



RED Algorithm Review

0 THmin THmax C

DiscardMark or discard with

increasing probability Pa

Do not discard

if (avg < THmin)

Pa is called the packet dropping probability or packet marking probability

q = length of the queue

Computing Pa

else if (THmin ≤ avg ≤ THmax)

{calculate probability Pa;with probability Pa

Mark or discard acket

avg = average engt o t e queue

- min max – min P b = F P max 0 F 1

P a = P b / ( 1 - count P b )

= 1/ ( {1/ P b} - count )

otherwise with probability 1 – aqueue packet

}else if (avg > THmax)



ECN-Capable Routers

Sender Receiver Router

-

drop packet

Congestion is detected

Sender ECN

Receiver

CE is set

ECN-Echo is setECN-Echo is set

ECN packet

When the sender receives an ACK with ECN-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 uses two bits in the IP header.

ECN Bits in IP Header

2 bits => 4 ECN Codepoints

NameValue

Not-ECT (Not ECN Capable Transport)00

ECT(1) (ECN Capable Transport (1) )01

Nonce = 1

The sender sets ECT(1) or ECT(0) in the ECN field of the IP header on outgoing

CE (Congestion Experienced)11

- . ,

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 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 HeaderECN Bits in IP Header

2 bits => 4 ECN Codepoints

Not-ECT (Not ECN Capable

Trans ort

00

NameValue

ECT(0) (ECN Capable Transport (0) )10

ECT(1) (ECN Capable Transport(1) )01


Bits 6 and 7 in the IPv4 Differentiated Services Field are designated 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

ea er. e two ts

are bits 8 and 9 of the

unused Reserved bits in

.

When the receiver

indication, it notifies the

sender of the detected

congestion by setting the

ECN-Echo (ECE) bit in

the returned ACK.

ECE flag ECN-Echo flagCWR flag Congestion Window Reduced flag

On receipt of ECE ACK, the TCP sender SHOULD react in the same way as it

would for a packet loss in non‐ECN‐capable TCP.



sender receiver

• TCP Sender – sets both ECE and CWR in SYN packet // TCP header

• TCP Receiver – sets only ECE in SYN-ACK packet // TCP header

• A host must not set ECT in SYN or SYN-ACK packets // IP header

Some faulty firewalls either drop an ECN‐setup SYN packet or respond

with an RST TCP packet



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 subsequentnon- a a pac e s o no ave e - c o ag se . ano er

packet is received by the receiver, the receiver would once again send ACK

packets with the ECN-Echo flag set.



Rules of ECN: SenderRules 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

- ,

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-ECN-

Capable 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- '. ., . ,

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 t e CWR ag in t e TCP ea er o t e irst new ata pac et sent a ter t ewindow reduction.

• When the TCP data sender is ready to set the CWR bit after reducing the congestion

window it should set the CWR bit onl on the first new data acket 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 ECTco epo n s se .e., nary co e or n a pac e s ea er. so,

then instead of dropping the packet, the router sets the CE codepoint in the

IP header.



• ECN prevents unnecessary packet drops at routers resulting inless retransmissions and improvement in throughput

• ECN avoids timeouts by getting faster notification to end hosts



Robust ECN

The correct operation of ECN requires the cooperation of the

receiver to return Congestion Experienced signals to the

,

this cooperation. This raises the possibility that a malicious or poorly implemented receiver could always clear ECN-Echo

and refuse to return congestion signals to the sender. This

would give the receiver a performance advantage at the

ex ense of other TCP connections that behave ro erl .

The ECN-nonce is a simple, efficient mechanism to eliminate

.



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

concea s mar e or roppe pac e s n e rou ng pa . e

nonce protects against implementation errors and deliberate abuse.

The ECN nonce:

catches a misbehaving receiver with a high probability, and never

does not change other aspects of ECN, nor does it reduce the

benefits of ECN for behaving receivers.

-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).

,

from the sender.

Robust ECN prevents optimistic TCP acknowledgements , inw c segmen s are ac now e ge e ore ey ave een

received.

The above benefits also serve to increase the

robustness of congestion control from attacks.



• Receiver hides dropped and marked packets and continuously sends

normal ACKs without enabling the ECN‐Echo bit.

• Sender

is

not

aware

of

the

congestion

and

keeps

increasing

its

sending rate.

Congestion!!!I will not report it

to the sender

There is no congestion.I will increase cwnd

CE setECN packet

ECN enabled

Congested

ECN enabled

Normal ACK

ECN-Echo is not set

ECN-Echo is not set

rece ver Congested ECN enabled router sen er



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-Ca able Trans ort is set in the ECN

field of the IP header on outgoing packets. Congested routers change thisfield to CE (Congestion Experienced). When the TCP receiver notices

-, .

The ECN nonce enables the receiver to demonstrate to the sender that

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

.

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

. ,

the correct nonce sum implies receipt of only unmarked packets.




The sender can verify the nonce sum returned by the receiver to

ensure that congestion indications in the form of marked or dropped

pac ets are not e ng concea e . Because t e nonce sum s on y one

bit long, senders have a 50-50 chance of catching a lying receiverwhenever an acknowled ement conceals a dro ed or marked

packet. Because each acknowledgement is an independent trial,

cheaters will be caught quickly if there are repeated congestion

.

Each acknowledgement carries a nonce sum, which is the one bit

sum xc us ve- o nary nonces over t e yte rangerepresented by the acknowledgement.



The sender uses the two ECN bits in the IP header to attach a nonce with

Illustration

each packet.

NameValue

Not-ECT (Not ECN Capable Transport)00

ECT(1) (ECN Capable Transport(1) )01

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 tothe 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: Malicious Receiver

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

Number

transmitted

in path

received

at receiver

in TCP ACK header

1 10 0 No 10 0 0 & 0

2 01 1 No 01 1 1 & 0

3 01 1 No 01 0 0 & 0

5 10 0 No 10 1 1 & 0

6 10 0 Yes 11 unknown guessed

For packet 6, the malicious TCP receiver hides the CE indication and does not

.

the value of NS.




Sender Behavior

To place a one bit nonce value on every ECN-capable IP packet, the

sen er uses e wo co epo n s as o ows: represen s

a nonce of 0, and ECT(1) a nonce of 1. As in ECN, retransmissionsare 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

ac on removes e or g na va ue o e nonce represen e yECT(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.



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

rre evant an t e sen er w not ot er to c ec ts

correctness. The sender will simply reduce its congestionwindow and will re-synchronize 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 ncorrec y. e sen er s response o an ncorrecnonce (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 b checkin that dro ed and marked ackets

are not falsely acknowledged to the sender by a cheatingreceiver.



Behavior of TCP Congestion Control

Congestion

Packet lossPacket loss

Fast Recovery

20 Time-out &

standardrecovery

i o n w i n d o15 Time-out &

standard

recovery

C o n g e s

10

Slow

5

s ar

0

Round-trip timesPlot of TCP Congestion Window vs. Time



Protecting Against Other Misbehaviors

The ECN-nonce can provide robustness beyond checking that

dropped and marked packets are not falsely acknowledged to the

sender by a cheating receiver.

Packet drops could potentially be concealed by a faulty TCPimplementation, 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 multipleconnections 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 rovidin the sender the abilit to continue checkin .



Sender begins with congestion Sender Receiver

packet.

cwn

2

1

only after receiving it correctly.

In the Slow Start hase the sender

3

4

5 doubles cwnd, i.e., doubles itssending rate after each round triptime (RTT) if there are no packet

678

.



TCP Receiver Accelerator

Sender begins with cwnd = 1 andsends a single packet. Sender Receiver

Receiver acknowledges the first packetafter receiving it correctly, but

cwn 1

receiving them.

doubles cwnd, i.e., doubles its sendingrate much earlier than RTT and reachesits maximum sending rate very quickly.

maximum sending rate for the entirelifetime of the connection because thereceiver never reports packet losses.



Attack by Receiver Accelerator

s t i o n w

i n d o

s t i o n w i n d o

C o n g

C o n g

Time(s) Time(s)

Honest Receiver Receiver Accelerator

e ma c ous acce era or causes e sen er o ou e e conges on w n ow anthus 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

s rong ran om num er genera or may comprom se e

speed performance of the TCP sender.

But the pseudo-random bit sequence should not be

generated by an oversimplified scheme such as a linear

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

sen er. Because eac new ac now e gement is an in epen ent tria , a c eating

receiver is likely to be caught after a small number of lies.

The binar nonce a roach is used in some other securit rotocols such 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 forau en ca ng success u y n eac roun . s ng roun s, e c ances o

success is reduced to approximately 1 in one million.

802.11i protocol used for Wireless LAN Security. In the EAP Exchange of

the 802.11i Authentication Phase, the challenge from AS and the response

from STA may be repeated multiple times (often requiring 10 to 20 roundtrips for TLS tunneling).

EAP = Extensible Authentication Protocol

=

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

Incompatibility and Implementation Problems

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 port-

scanning tool that could be used in a denial-of- service attack. Problems withnon-ECN-compatible equipment were identified in the early stages of ECN

eve opment.

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

.

http://gtf.org/garzik/ecn/

owever, e a ove we page was os n a ar r ve s orm cras an s no

longer maintained.

Robust ECN

Documents

Transcript of Robust ECN