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

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/networ
ks
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 attackers 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 (RTOSRTT4RTTVAR)
• 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 (lRTT, TminRTO)
• 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
• RC1.5Mb/s
• l70ms (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 (lt100pkts)
• 400 delay increase
• an elephant (gt100pkts)
• 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 Tb
• Wait for all flows to recover and then pulse
  again

25
End-point minRTO Randomization

• TCP throughput for Tb 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 TCPs 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 length30ms, 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 -gt
• all TCP stacks are equally fragile

37
The Role of Time-Scales

• Scenario R2 Mb/s T1 sec l50-450 ms

38
The Role of Time-Scales

• RED-PD detects l300 ms shrews
• Recall that 30 ms enough for DoS
• A fundamental mismatch
• If shorter time-scales are used gt
• 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