1. The Taming of The Shrew: Mitigating Low-Rate TCP-targeted Attack
Chia-Wei Chang, Seungjoon Lee,
Bill Lin, Jia Wang

2. Shrew Attack [Kuzmanovic03]
TCP-targeted low-rate denial-of-service attack
Exploits TCP’s retransmission timeout
Periodic burst (with period T) synchronized with TCP minRTO
R: large enough to cause packet drops
L: long enough to induce timeouts
Victims experience repeated loss of retransmissions
Near-zero throughput
Shrew attack
TCP victim

3. Related Work BGP (Border Gateway Protocol) runs on top of TCP
Shrew attack can cause BGP session close [Zhang07]
Potentially can disrupt Internet routing
Detection/Mitigation Schemes
Active Queue Management, randomize minRTO
Insufficient to fully mitigate attack
Previous schemes to identify attack flows
Periodic pattern monitoring, auto-correlation analysis, wavelet-based approach, frequency domain spectrum analysis
Prohibitive to realize in high-speed networks

4. Outline SAP (Shrew Attack Protection) Design Overview
Deployment Consideration
Testbed Experiments
Simulation Experiments

5. Shrew Attack Protection
Priority-based filtering mechanism
Identifies victims and prioritizes their flows
Can help external systems identify attack flows
Router monitors drop rate for each potential “victim”
Low drop rate: Packets are treated normal (i.e., low priority)
High drop rate: Packets are tagged high priority, and preferentially admitted to output queue
Protects victims from losing consecutive packets

6. SAP Components Drop Rate Collector
Continuously monitors instantaneous per-aggregate drop rate
Counters for arrivals and drops for each potential victim
For the current time interval and recent history (e.g., total of 10 time intervals)
Fair Drop Rate Controller
Pavg: Average drop rate for all monitored aggregates
Pfair = max(Pavg, Pmin)
No intervention if drop rate is under a threshold
Differential Tagging & Preferential Drop
Packets are tagged high-priority if instantaneous drop rate is beyond Pfair
Relatively short sequence of losses can trigger differential tagging
E.g., Pfair = 5%, and 9 successful transmissions and one drop
Preferential dropping is implemented in modern routers (e.g., WRED)

7. SAP Maintains Statistics for Aggregates
Maintaining per-flow statistics for all flows is typically infeasible
SAP uses application-level aggregates
E.g., destination port
Maintaining aggregate-level information is feasible in hardware
E.g., TCP ports
20 counters * 4 bytes * 60K aggregates ~ 5MB of SRAM

8. Discussions Different flows can be treated as a single aggregate
Attacker may use protected TCP port
Shrew attack may use protected TCP port
Malicious flow may intentionally cause packet drops and trigger elevated priority
SAP still prevents session close and improves victim’s throughput
SAP can help external systems narrow down attack flows
Different aggregates may vary in the number of flows
SAP preserves per-flow throughput

9. Experiment Setup Simulation Study using FTP, HTTP, BGP flows
ns-2 simulator
augmented with SAP
Validation using real router testbed
1 Juniper router, 2 Ethernet switches, 3 PCs
BGP flow only (using Zebra and real BGP trace)
Simulation
Testbed

10. Simulation vs. Testbed
T = 1sec, L = 0.3sec, R = 15, 18, 20Mbps Packet drop rates are highly close
Juniper Testbed
ns-2 simulation
Attack rate
BGP
Attack flow
15 Mbps
17.4%
33.1%
18.1%
35.0%
18 Mbps
28.1%
45.2%
28.3%
44.8%
20 Mbps
28.2%
50.3%
29.0%
49.8%

11. Simulation: Throughput and Drop Rate
Throughput (in Kbps)
Drop Rate (in %)
FTP
HTTP
BGP
Attack
No-attack
4996
4995
4.5 -
0.2
5.8
RED ~0
3462
~100
22.7
SAP
Un-protected Port
Protected Port
R = 15Mbps, T = 1sec, L = 0.3sec
RED is not enough to mitigate Shrew attack
BGP session is closed

12. Simulation: Throughput and Drop Rate
Throughput (in Kbps)
Drop Rate (in %)
FTP
HTTP
BGP
Attack
No-attack
4996
4995
4.5 -
0.2
5.8
RED ~0
3462
~100
22.7
SAP
Un-protected Port
3975
3870
5.4
1784
3.0
6.1
57.0
Protected Port
SAP protects legitimate TCP flows from losing multiple packets
Thus, enables high throughput in the presence of attack

13. Simulation: Throughput and Drop Rate
Throughput (in Kbps)
Drop Rate (in %)
FTP
HTTP
BGP
Attack
No-attack
4996
4995
4.5 -
0.2
5.8
RED ~0
3462
~100
22.7
SAP
Un-protected Port
3975
3870
5.4
1784
3.0
6.1
57.0
Protected Port 83 76
1.8
3410
8.9
9.1 22 23
Shrew attack using protected port is more effective against SAP
Pavg becomes higher due to attack flow
Still, SAP keeps all TCP sessions alive
SAP prevents consecutive packet drops

14. Simulation: Throughput and Drop Rate
Throughput (in Kbps)
Drop Rate (in %)
FTP
HTTP
BGP
Attack
No-attack
4996
4995
4.5 -
0.2
5.8
RED ~0
3462
~100
22.7
SAP
Un-protected Port
3975
3870
5.4
1784
3.0
6.1
57.0
Protected Port 83 76
1.8
3410
8.9
9.1 22 23 75
1760
1.7
3281
9.0
1.1 28
HTTP flows get higher throughput when Shrew attack uses HTTP
SAP keeps all sessions alive

15. Conclusions SAP (Shrew Attack Protection)
Simple counter-based filtering mechanism
Priority-tagging and preferential drop
Uses application-level aggregates, not per-flow statistics
Implementable using today’s hardware
Identifies and protects victims
Can help identify attack flows
Mitigates Shrew attack in various attack scenarios