Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Secure Detection and Isolation of TCP-unfriendly Flows Shuo Chen (Summer Intern) Jose C. Brustoloni (Mentor) Network Software Research Department Bell.

Similar presentations


Presentation on theme: "1 Secure Detection and Isolation of TCP-unfriendly Flows Shuo Chen (Summer Intern) Jose C. Brustoloni (Mentor) Network Software Research Department Bell."— Presentation transcript:

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

2 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 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 4 Determining if a flow is TCP- friendly (cont.) The TCP friendliness formula W max : 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 T 0 : 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 W max =22 for example, the first upper bound is smaller only when RTT=0.001 p<0.0007 RTT=0.01 p<0.0012 RTT=0.1p<0.002 RTT=1p<0.002 RTT=10p<0.002 Especially when there is congestion, the first part can be ignored

5 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 Server

6 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 7 Detection and CoS Separation Client 1 Client 2 R 1R 3R 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 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 9 Experimental Result – TCP-friendly Flow Use scp to transfer a large file to the destination Dummynet settings: Bw=1.5 Mb/s, PLR=0.05, delay=50ms

10 10 Experimental Result – TCP-friendly Flow Dummynet settings: Bw=150Kb/s, PLR=0.05, delay=50ms

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

12 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

13 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. Rcvr sends 5 duplicate ACKs Good receiver

14 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: Beginning of the attack

15 15 TCP Flow Under Congestion Attack With our access routers (TCP-unfriendly flow isolation): Congestion and automatic recovery

16 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 17 Available Bandwidth of DRR Routers RoutersAverage throughput (Mbit/s) Standard Deviation (Mbit/s) Priority queues945522 DRR Q1=1000 Q2=100051918 DRR Q1=3000 Q2=1000720824 DRR Q1=2000 Q2=500756221 DRR Q1=2000 Q2=50910663 With different combinations of quantum 1 and quantum 2, 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 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 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 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 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


Download ppt "1 Secure Detection and Isolation of TCP-unfriendly Flows Shuo Chen (Summer Intern) Jose C. Brustoloni (Mentor) Network Software Research Department Bell."

Similar presentations


Ads by Google