Low rate tcp targeted denial of service attacks the shrew vs the mice and elephants
1 / 40

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

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants)' - melody

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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



  • 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

Thesis tcp is vulnerable to low rate attacks
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


  • 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.”

Tcp a dual time scale perspective
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

Tcp timeline
TCP Timeline

  • Timeline of TCP congestion window

    • AIMD control

The shrew attack 1 3
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

The shrew attack 2 3
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

The shrew attack 3 3
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

Shrew principles
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

Creating outages in the network
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)


  • Shrew attack

  • Simulation and Internet experiments

  • DoS detection mechanisms

  • minRTO randomization

The shrew in action
The Shrew in Action

  • How much is TCP

    throughput degraded?

  • DoS stream:

    • R=C=1.5Mb/s;

    • l=70ms (~TCP RTT)

The shrew in action1
The Shrew in Action

  • Shrews induce null frequency near RTO

  • Shrew has low average rate  .08C

  • Analytical model accurately predicts degradation

Challenges for shrews
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?

Shrews vs short lived tcp traffic
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

Shrews vs short lived tcp traffic1
Shrews vs. Short-lived TCP Traffic

  • Scenario: Web browsing

    • Larger files more


      • most suffer

      • some benefit

Internet experiments scenario
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)

Internet experiments results
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


  • Shrew attack

  • Simulation and Internet experiments

  • Counter DoS mechanisms

    • Robust TCP variants (NewReno, Sack…)

    • Router detection mechanisms (RED, RED-PD, …)

  • minRTO randomization

Detecting shrews
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

Router assisted mechanisms
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


  • Shrew attack

  • Simulation and Internet experiments

  • Counter DoS mechanisms

  • minRTO randomization

End point minrto randomization
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

End point minrto randomization1
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

  • 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

    Open questions
    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


    • Homogeneous TCP aggregates are vulnerable

    • Shrews induce flow synchronization

    • Analytical model accurately predicts degradation

    Scenario: 5 TCP flows, homogenous RTTs

    Dos peak rate
    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

    Dos peak rate1
    DoS Peak Rate

    • Long-RTT flows inadvertently collaborate in the attack

    • DoS flow is masked with long-RTT TCP flows

    Tcp variants
    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

    Tcp variants1
    TCP Variants

    • Burst length = 30ms

      • TCP Reno is the most fragile

    Tcp variants2
    TCP Variants

    • Burst length = 50ms

      • TCP is the most vulnerable in 1-1.2 sec time-scale region due to slow start

    Tcp variants3
    TCP Variants

    • All TCP variants obtain the same profile

      • Sufficient pulse width ensures timeout

      • Windows remain small

    Tcp variants4
    TCP Variants

    • Burst length = 90ms

      • When burst length is severe enough ->

        all TCP stacks are equally fragile

    The role of time scales
    The Role of Time-Scales

    • Scenario: R=2 Mb/s; T=1 sec; l~50-450 ms

    The role of time scales1
    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)

    Shrews vs heterogeneous rtts
    Shrews vs. Heterogeneous RTTs

    • Hypothesis: Shrews are high-RTT-pass filters

      • Service is denied to short-RTT flows

    Flow filtering
    Flow Filtering

    • Shrews damage short-RTT flows the most

      • Scenario

        • 20 TCP flows; RTT ~ 20-460 ms

        • Cut-off time scale ~ 180 ms