1 / 40

Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants)

Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants). Aleksandar Kuzmanovic Edward W. Knightly. Rice Networks Group http://www.ece.rice.edu/networks. Background. Traditional view of DoS attacks

melody
Download Presentation

Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants)

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. Low-Rate TCP-Targeted Denial of Service Attacks(The Shrew vs. the Mice and Elephants) Aleksandar Kuzmanovic Edward W. Knightly Rice Networks Group http://www.ece.rice.edu/networks

  2. Background • Traditional view of DoS attacks • Attacker consumes resources and denies service to legitimate users • Ex. traffic floods, DDoS • Result: TCP backs off • Observe: statistical anomalies that are relatively easily detectable • Due to attacker’s high rate

  3. Thesis: TCP is Vulnerable to Low-rate Attacks • Shrew: low-rate TCP-targeted attacks • Elude detection by counter-DoS mechanisms • Able to severely deny service to legitimate users • Goals • Analyze TCP mechanisms that can be exploited by DoS attackers • Explore TCP frequency response to Shrews • Evaluate detection mechanisms • Analyze effectiveness of randomization strategies • Methodology: modeling, simulations, Internet experiments

  4. Shrew • Very small but aggressive mammal that ferociously attacks and kills much larger animals with a venomous bite • Reviewer 3: “only some shrews are venomous and the amount of venom in even the venomous species is very mild.”

  5. TCP: a Dual Time-Scale Perspective • Two time-scales fundamentally required • RTT time-scales (~10-100 ms) • AIMD control • RTO time-scales (RTO=SRTT+4*RTTVAR) • Avoid congestion collapse • RTO must be lower bounded to avoid spurious retransmissions • [AllPax99] and RFC2988 recommends minRTO = 1 sec

  6. TCP Timeline • Timeline of TCP congestion window • AIMD control

  7. The Shrew Attack (1/3) • Pulse-induced outage – multiple losses force TCP to enter RTO mechanism Short outages (~RTT)force TCP to timeout All flows simultaneously enter this state

  8. The Shrew Attack (2/3) • When flows attempt to simultaneously exit timeout and enter slow-start… • Shrew pulses again and forces flows synchronously back into timeout state

  9. The Shrew Attack (3/3) • Shrew periodically repeats pulse • RTT-time-scale outages inter-spaced on minRTO periods can deny service to TCP • Flows synchronize their state to the Shrew

  10. Shrew Principles • Shrews exploit protocol homogeneity and determinism • Protocols react in a pre-defined way • Tradeoff of vulnerability vs. predictability • Periodic outages synchronize TCP flow states and deny their service • Slow time scale protocol mechanisms enable low-rate attacks • Outages at RTO scale, pulses at RTT scale imply low average rate

  11. Creating Outages in the Network • Shrew: square-wave stream (l~RTT, T~minRTO) • Optimal pattern in paper • Low-rate “TCP friendly” DoS  hard to detect • Counter-DOS mechanisms tuned for high rate attacks • Detecting Shrews may have unacceptably many false alarms (due to legitimate bursty flows)

  12. Outline • Shrew attack • Simulation and Internet experiments • DoS detection mechanisms • minRTO randomization

  13. The Shrew in Action • How much is TCP throughput degraded? • DoS stream: • R=C=1.5Mb/s; • l=70ms (~TCP RTT)

  14. The Shrew in Action • Shrews induce null frequency near RTO • Shrew has low average rate  .08C • Analytical model accurately predicts degradation

  15. Challenges for Shrews • Aggregation • Vulnerable due to Shrew-induced flow synchronization • RTT heterogeneity • Shrews are high-RTT pass filters • DoS peak rate • Less-than-bottleneck bursts can damage short-RTT flows • Short-lived TCP flows • Web browsing • Internet experiments • Can Shrews be successful on the Internet?

  16. Shrews vs. Short-lived TCP Traffic • Scenario: Web browsing [FGHW99] • Average damage to • a mouse (<100pkts) =400% delay increase • an elephant (>100pkts) =24500%delay increase

  17. Shrews vs. Short-lived TCP Traffic • Scenario: Web browsing • Larger files more vulnerable • most suffer • some benefit

  18. Internet Experiments: Scenario • Scenario: victim on a lightly loaded 10 Mb/sec LAN • Attacker on same LAN, nearby LAN, or over WAN • WAN path: • EPFLETH, 8 hops (10/100/OC-12)

  19. Internet Experiments: Results • Shrew average rate: 909 kb/sec • R = 10 Mb/sec, l = 100 msec, T = 1.1 sec • TCP throughput • 9.8 Mb/sec without Shrew • 1.2 Mb/sec with Shrew, 87.8% degradation

  20. Outline • Shrew attack • Simulation and Internet experiments • Counter DoS mechanisms • Robust TCP variants (NewReno, Sack…) • Router detection mechanisms (RED, RED-PD, …) • minRTO randomization

  21. Detecting Shrews • Shrews have low average rate, yet send high-rate bursts on short time-scales • Key questions • Can algorithms intended to find high-rate attacks detect Shrews? • Can we tune the algorithms to detect Shrews without having too many false alarms? • A number of schemes can detect malicious flows • E.g., RED-PD: • use the packet drop history to detect high-bandwidth flows and preferentially drop packets from these flows

  22. Router-Assisted Mechanisms • Scenario: 9 TCP Sack flows with RED and RED-PD • RED-PD only detects Shrews with unnecessarily high rate • Reducing RED-PD measurement time scale results in excessive false positives

  23. Outline • Shrew attack • Simulation and Internet experiments • Counter DoS mechanisms • minRTO randomization

  24. End-point minRTO Randomization • Observe • Shrews exploit protocol homogeneity and determinism • Question • Can minRTO randomization alleviate threat of Shrews? • TCP flows’ approach • Randomize the minRTO = uniform(a,b) • Shrews’ counter approach • Given flows randomize minRTO, the optimal Shrew pulses at time-scale T=b • Wait for all flows to recover and then pulse again

  25. End-point minRTO Randomization • TCP throughput for T=b time-scale of the Shrew attack • a small  spurious retransmissions [AllPax99] • b large  bad for short-lived (HTTP) traffic • Randomizing the minRTO parameter shifts and smoothes TCP’s null time-scales • Fundamental tradeoff between TCP performance and vulnerability to low-rate DoS attacks remains

  26. Conclusions • Shrew principles • Exploit slow-time-scale protocol homogeneity and determinism • Real-world vulnerability to Shrew attacks • Internet experiment: 87.8% throughput loss without detection • Shrews are difficult to detect • Low average rate and “TCP friendly” • Cannot filter short bursts • Fundamental mismatch of attack/defense timescales

  27. Open Questions • Can filters specific to Shrews be designed without excessive false positives? • Can end-point algorithms be sufficiently randomized, so that • attackers cannot exploit their known reactions • performance is not sacrificed • Reconsider “TCP friendly” definition

  28. Backup Slides

  29. Aggregation • Homogeneous TCP aggregates are vulnerable • Shrews induce flow synchronization • Analytical model accurately predicts degradation Scenario: 5 TCP flows, homogenous RTTs

  30. DoS Peak Rate • Less-than-bottleneck bursts can damage short-RTT flows • Scenario: 4 TCP flows + DoS • 1 short-RTT & 3 long-RTT flows • DoS outage ~ RTT of the short-RTT flow

  31. DoS Peak Rate • Long-RTT flows inadvertently collaborate in the attack • DoS flow is masked with long-RTT TCP flows

  32. TCP Variants • TCP Reno is the most fragile • NewReno? Sack? • Scenario: • TCP variants • Reno • New Reno • Tahoe • SACK • DoS stream • Burst rate equals the bottleneck capacity • Burst length:30ms, 50ms, 70ms, and 90ms

  33. TCP Variants • Burst length = 30ms • TCP Reno is the most fragile

  34. TCP Variants • Burst length = 50ms • TCP is the most vulnerable in 1-1.2 sec time-scale region due to slow start

  35. TCP Variants • All TCP variants obtain the same profile • Sufficient pulse width ensures timeout • Windows remain small

  36. TCP Variants • Burst length = 90ms • When burst length is severe enough -> all TCP stacks are equally fragile

  37. The Role of Time-Scales • Scenario: R=2 Mb/s; T=1 sec; l~50-450 ms

  38. The Role of Time-Scales • RED-PD detects l=300 ms shrews • Recall that 30 ms enough for DoS • A fundamental mismatch • If shorter time-scales are used => • high false alarm probability (bursty TCP flows)

  39. Shrews vs. Heterogeneous RTTs • Hypothesis: Shrews are high-RTT-pass filters • Service is denied to short-RTT flows

  40. Flow Filtering • Shrews damage short-RTT flows the most • Scenario • 20 TCP flows; RTT ~ 20-460 ms • Cut-off time scale ~ 180 ms

More Related