The Taming of The Shrew: Mitigating Low-Rate TCP-targeted Attack

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., 65536 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

11. Simulation: Throughput and Drop Rate • 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 • SAP protects legitimate TCP flows from losing multiple packets • Thus, enables high throughput in the presence of attack

13. Simulation: Throughput and Drop Rate • 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 • 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