Secure Detection and Isolation of
TCP-unfriendly Flows
Shuo Chen (Summer Intern)
Jose C. Brustoloni (Mentor)
Network Software Research Department
Bell Laboratories, Holmdel, New Jersey,
August, 2002
1
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
2
Determining if a flow is TCPfriendly

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
3
Determining if a flow is TCPfriendly (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
RTT=0.01
RTT=0.1
RTT=1
RTT=10
p<0.0007
p<0.0012
p<0.002
p<0.002
p<0.002
• Especially when there is congestion, the first part can be ignored
4
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).
TCPfriendly
TCPunfriendly
Access
router
router
Access
router
Server
5
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.
6
Detection and CoS Separation
Calculate RTT and packet loss event rate between
R1 and R2 for each flow
Client 1
Server1
R1
Client 2
R3
R2
Server 2
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
7
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
8
Experimental Result
– TCP-friendly Flow
No. of Packet Sent per Sec
Use scp to transfer a large file to the destination
Dummynet settings: Bw=1.5 Mb/s, PLR=0.05, delay=50ms
100
10
1
0.01
0.1
1
0.1
0.01
Packet Loss Percentage
9
Experimental Result
– TCP-friendly Flow
766
715
664
613
562
511
460
Packet Loss Percentage
409
0.01
358
0.1
307
1
256
0.1
205
0.01
154
0.001
103
1
10
9
8
7
6
5
4
3
2
1
0
52
10
1
No. of Packet Sent per Sec
Dummynet settings: Bw=150Kb/s, PLR=0.05, delay=50ms
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
100
10
1
0.01
0.1
1
0.1
11
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
100
10
1
0.01
0.1
1
0.1
12
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.
Rcvr sends 5
duplicate ACKs
100
10
1
0.01
0.1
1
10
1
0.01
0.1
1
Good receiver
100
0.1
13
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:
120
100
80
Thropughput
60
40
20
0
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
Beginning of the attack
14
TCP Flow Under Congestion Attack
With our access routers (TCP-unfriendly flow isolation):
120
100
80
Throughput
60
40
20
Congestion
and automatic
recovery
61
57
53
49
45
41
37
33
29
25
21
17
13
9
5
0
1

15
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
16
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.
17
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 TCPunfriendly flow to TCP-friendly flow is
very limited.
18
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.
19
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)
20
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
21