1

Secure Detection and Isolation of TCP-unfriendly Flows

Shuo Chen (Summer Intern)Jose C. Brustoloni (Mentor)Network Software Research

DepartmentBell Laboratories, Holmdel, New

Jersey, August, 2002

2

Motivations TCP congestion control

end-to-end mechanism assumes that end systems correctly

follow the protocol Coexistence of TCP flow and non-TCP

flow (or faked TCP flow) If one is greedy unfairness If one is malicious congestion, DoS

3

Determining if a flow is TCP-friendly

TCP Friendliness Characterizing TCP

throughput quantitatively RTT: round trip time p: packet loss event rate B: sender throughput

(rather than goodput) B<(RTT,p) ?

Yes follow TCP congestion avoidance rules

No not follow TCP congestion avoidance rules

Note: y axis: total no. of packet sent in 100 sec RTT: Average round trip time over 100 sec

4

Determining if a flow is TCP-friendly (cont.)

The TCP friendliness formula

• Wmax: the maximum buffer size advertised by the receiver, which determines sender’s maximum congestion window size.• b: the number of packets that are acknowledged by an ACK, typically 2• T0: timeout (0.5 sec resolution)• For security, we measure the RTT and p between access routers. • No safe way to calculate the first part, unless we trust the end systems.• Fortunately, in most cases, the second part is smaller. When Wmax=22 for example, the first upper bound is smaller only when

RTT=0.001 p<0.0007 RTT=0.01 p<0.0012RTT=0.1 p<0.002RTT=1 p<0.002RTT=10 p<0.002

• Especially when there is congestion, the first part can be ignored

5

Isolating TCP-unfriendly flows

TCP-friendly flows and TCP-unfriendly flows are forwarded in separate classes of service. Many queuing policies can be applied: priority, round robin, proportional sharing (e.g. Deficit Round Robin).

TCP-friendly

TCP-unfriendly

Access router router

Access router Serve

r

6

Isolating TCP-unfriendly flows

How to detect Denial of Service Attack? access routers detect and mark TCP-unfriendly

flows. How to mitigate Denial of Service Attack?

Drop the connection? No tolerance to false alarm. Need more graceful solutions.

2 classes of service Class 1: Well-behaved TCP flows Class 2: Non-TCP flows or the “TCP” flows which are

identified as TCP-unfriendly. Class 1 has privileges or bandwidth reservations

that limit the interference from class 2.

7

Detection and CoS Separation

Client 1

Client 2

R 1 R 3 R 2

Server1

Calculate RTT and packet loss event rate between R1 and R2 for each flow

Client 2 is detected to be TCP-unfriendly, and thus its packets are forwarded in class 2.

Note: For testing and measurement, we run dummynet in R3 to simulate different network conditions. Dummynet: (1) introduce propagation delay (2) limit the bandwidth (3) cause a certain number of packets to be dropped

Server 2

8

Implementing the System To measure the RTT, p and actual throughput

Keep a record for each flow (164 bytes) Piggyback some measurement information on the

flows Calculate the throughput upper bound

To implement CoS Duplicate the IP interrupt queue (ipintrq) Duplicate the output queue in each network

interface (if_snd queue) Make the hardware FIFO queue extremely short

9

Experimental Result – TCP-friendly Flow

0.01

0.1

1

10

100

0.01 0.1 1

Packet Loss Percentage

No.

of P

acke

t Sen

t per

Sec

0

1

2

3

4

5

6

7

8

9

10

Use scp to transfer a large file to the destinationDummynet settings: Bw=1.5 Mb/s, PLR=0.05, delay=50ms

10

01

23

45

67

89

10

1 52 103

154

205

256

307

358

409

460

511

562

613

664

715

766

Experimental Result – TCP-friendly Flow

0.01

0.1

1

10

0.001 0.01 0.1 1

Packet Loss Percentage

No. o

f Pac

ket S

ent p

er S

ec

Dummynet settings: Bw=150Kb/s, PLR=0.05, delay=50ms

11

0123456789

10

Experimental Result –TCP-unfriendly Flow

Aggressive sender (e.g. TCP without slow start mechanism)

Dummynet settings: Bw=1.5 Mb/s, delay=50ms, queue size=5

0.1

1

10

100

0.01 0.1 1

12

Experimental Result – TCP-unfriendly Flow

Aggressive sender (e.g. TCP without slow start mechanism)

Dummynet settings: Bw=150 Kb/s, PLR=0.05, delay=50ms

0.1

1

10

100

0.01 0.1 1

0

1

2

3

4

5

6

7

8

9

10

13

Experimental Result – Misbehaving Receiver

Misbehaving receiver can induce the good sender to be aggressive. Graphs below illustrate sender’s behavior when the receiver is good or misbehaving.

1

10

100

0.01 0.1 1

0.1

1

10

100

0.01 0.1 10123456789

10

0

1

2

3

4

5

6

7

8

9

10

Rcv

r sends 5

duplica

te A

CK

sG

ood re

ceiv

er

14

TCP Flow Under Congestion Attack

The attack: blast 1400-byte packets (measured rate 8000 pkt/s, insensitive to congestion)

The well-behaved application is affected as follows using conventional routers:

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

Thropughput

Beginning of the attack

15

TCP Flow Under Congestion Attack

With our access routers (TCP-unfriendly flow isolation):

0

20

40

60

80

100

120

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61

Throughput

Congestion and automatic recovery

16

Test the Network Bandwidth With TTCP

Using our access routers with priority queues Without congestion: 10487.26 KB/sec With congestion attack: 9439.91

KB/sec

Using conventional routers Without congestion: 10716.87 KB/sec With congestion attack: 82.73 KB/sec

17

Available Bandwidth of DRR Routers

Routers Average throughput (Mbit/s)

Standard Deviation (Mbit/s)

Priority queues 9455 22

DRR Q1=1000 Q2=1000 5191 8

DRR Q1=3000 Q2=1000 7208 24

DRR Q1=2000 Q2=500 7562 21

DRR Q1=2000 Q2=50 9106 63

•With different combinations of quantum1 and quantum2, which are parameters of DRR, the certain portion of bandwidth is preserved for class 1 flows, even when there is heave class 2 traffic load.

18

Conclusions The idea of detecting TCP-unfriendly

flows in access routers is feasible. The TCP-friendly flow is indeed

protected by the mechanism of separating classes of services. The interference of TCP-unfriendly flow to TCP-friendly flow is very limited.

19

Contributions Previous work does not realize that access routers

can collaborate in detecting TCP-unfriendliness. Therefore, TCP-unfriendliness detection was detectable only when a single router caused severe delay and packet loss events.

We can safely detect TCP-unfriendliness based on our protocol that samples p and RTT every 10 sec. Previous work uses 100-second sampling.

We provide tolerance to the unfriendly flows, not simply drop the suspected flows. The idea itself might be useful in developing other intrusion tolerance techniques.

20

Summary of Major Techniques in This Project

Manipulate kernel mbuf structure to insert measurement info in outgoing IP packets. (IP layer modification)

Implement CoS, duplicate the queue in IP layer and the queues in the hardware drivers (IP layer and driver modification)

Implement aggressive sender and misbehaving receiver (TCP layer modification)

21

Thanks Jose Brustoloni

Guided me through the implementation of the algorithms

John Lin Taught me how to set up the network Helped me install FreeBSD system