1 / 21

Secure Detection and Isolation of TCP-unfriendly Flows

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. Motivations. TCP congestion control end-to-end mechanism

MikeCarlo
Download Presentation

Secure Detection and Isolation of TCP-unfriendly Flows

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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.0012 • RTT=0.1 p<0.002 • RTT=1 p<0.002 • RTT=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 Access router Access router router Server TCP-unfriendly

  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. Calculate RTT and packet loss event rate between R1 and R2 for each flow Detection and CoS Separation Client 1 Server1 R 1 R 3 R 2 Server 2 Client 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

  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 Use scp to transfer a large file to the destination Dummynet settings: Bw=1.5 Mb/s, PLR=0.05, delay=50ms

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

  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. 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. 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. 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. TCP Flow Under Congestion Attack • With our access routers (TCP-unfriendly flow isolation): 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 • 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

More Related