Edge-based Inference, Control, and DoS Resilience for the Internet

1. Edge-based Inference, Control, and DoS Resilience for the Internet Ph.D. Thesis Presentation Aleksandar Kuzmanovic

2. 1969 2004 The Internet The system of astonishing scale and complexity

3. Internet Design Principles • Network as a black-box • Implications • Easy to upgrade the network • Easy to incrementally deploy new services • End-to-end argument [Clark84] • The core is simple • Intelligence at the endpoints

4. Why End-Point Approach Today? • Scalability e2e scalability • Deployability • IP and network core are not extensible and are slowly evolving: • IPv6 (10 years) • IP Multicast (domain dependent) Goal:Improve network performance right here – right now!

5. Network Performance • Internet traffic • HTTP (web browsing) • FTP (file transfer) • Fact: 95% of the traffic today is TCP-based • Performance • QoS differentiation • Net win for both HTTP and FTP flows • End-point-based two-level differentiation scheme • Denial of Service • DoS attacks can demolish network performance • Prevent DoS attacks via a robust end-point protocol design

6. End-Point Service Differentiation • TCP-Low Priority • Utilizes only the excess network bandwidth • Key mechanism • Early congestion indications: one-way packet delay • Performance • Can improve the HTTP file transfers for more than 90% when FTP flows use TCP-LP • Deployability • no changes in the network core • sender side modification of TCP • High-speed version developed in cooperation with SLAC • tested over Gb/s networks in US http://www.ece.rice.edu/networks/TCP-LP

7. Denial of Service • A malicious way to consume resources in a network, a server cluster or in an end host, thereby denying service to other legitimate users • Example • Well-known TCP’s vulnerability to high-rate non-responsive flows

8. Design Principles - Revisited • Design Principles • Intelligence at the endpoints • The core is simple • Trust and cooperation among the endpoints • Implications • Easy to incrementally implement new services • Implement more intelligence at routers? • Scalability issue • Detect misbehaving flows in routers is a hard problem • Needle in a haystack . • Easy to upgrade the network . • Large-scale system

9. Design Principles - Revisited • Design Principles • Intelligence at the endpoints • The core is simple • Trust and cooperation among the endpoints • Implications • Malicious clients may misuse the intelligence . • Easy to upgrade the network . • Large-scale system • Implement more intelligence at routers? • Scalability issue • Detect misbehaving flows in routers is a hard problem • Needle in a haystack

10. Design Principles - Revisited • Malicious clients may misuse the intelligence • Design Principles • Intelligence at the endpoints • The core is simple • Trust and cooperation among the endpoints • Implications . • Hard to detect endpoint misbehavior . • Large-scale system • Implement more intelligence at routers? • Scalability issue • Detect misbehaving flows in routers is a hard problem • Needle in a haystack

11. Design Principles - Revisited • Malicious clients may misuse the intelligence • Design Principles • Intelligence at the endpoints • The core is simple • Trust and cooperation among the endpoints • Implications . • Hard to detect endpoint misbehavior . • Large-scale system • Implement more intelligence at routers? • Scalability issue • Detect misbehaving flows in routers is a hard problem • Needle in a haystack

12. End-Point Protocol Design • Performance vs. Security • End-point protocols are designed to maximize performance, but ignore security • 95% of the Internet traffic is TCP traffic • Can have catastrophic consequences • DoS-resilient protocol design • Jointly optimize performance and security • Outperforms the core-based solutions

13. Remaining Outline • End-point protocol vulnerabilities • Low-rate TCP-targeted DoS attacks • Receiver-based TCP stacks with a misbehaving receiver • Limitations of network-based solutions • DoS-resilient end-point protocol design

14. Low-Rate Attacks • TCP is vulnerable to low-rate DoS attacks

15. 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 • Lower-bounding the RTO parameter: • [AllPax99]: minRTO = 1 sec • to avoid spurious retransmissions • RFC2988 recommends minRTO = 1 sec

16. The Low-Rate Attack

17. The Low-Rate Attack • At a random initial time • A short burst (~RTT)sufficient to create outage • Outage – event of correlated packet losses that forces TCP to enter RTO mechanism • The impact of outage is distributed to all TCP flows

18. The Low-Rate Attack • The outage synchronizes all TCP flows • All flows react simultaneously and identically • backoff for minRTO • The attacker stops transmitting to elude detection

19. The Low-Rate Attack • Once the TCP flows try to recover • hit them again • Exploit protocol determinism

20. The Low-Rate Attack • And keep repeating… • RTT-time-scale outages inter-spaced on minRTO periods can deny service to TCP traffic

21. Low-Rate Attacks • TCP is vulnerable to low-rate DoS attacks

22. Vulnerability of Receiver-Based TCP to Misbehaviors • Sender-based TCP • Control functions given to the sender

23. Receiver-Based TCP • Receiver decides how much data can be sent, and which data should be sent by the sender • DATA – ACK communication becomes REQ - DATA • Example protocols • TFRC [RFC3448], WebTP, and RCP

24. Why Receiver-Based TCP? • Example: Busy web server • Receiver-based TCP distributes the state management across a large number of clients • Generally • Whenever a feedback is needed from the receiver, receiver-based TCP has advantage over sender-based schemes due to the locality of information • Benefits [RCP03] PerformanceFunctionality - Loss recovery- Seamless handoffs - Congestion control - Server migration - Power management for - Bandwidth aggregation mobile devices - Web response times - Network-specific congestion control

25. Vulnerability • Receivers decide which packets and when to be sent • Receivers remotely control servers • Receivers have both means and incentive to manipulate the congestion control algorithm • Means: open source OS • Incentive: faster web browsing & file download

26. Receiver-Induced DoS Attacks • Request flood attack • A misbehaving receiver floods the server with requests, which replies and congests the network • Goals • Evaluate network-based schemes • Develop end-point solutions

27. Remaining Outline • End-Point protocol vulnerabilities • Limitations of network-based solutions • Low rate attacks • Misbehaving receivers • DoS-resilient end-point protocol design

28. Random Early Detection with Preferential Dropping • RED-PD [MFW01] designed to detect and thwart non-responsive flows • Monitors only a subset of flows at the router and compares their rates to the targeted bandwidth (TB) • TB is computed as a TCP-fair throughput for • Observed Ploss & RTT=40ms • If Ti > TB => flow i malicious • Key questions • Can algorithms intended to find high-rate attacks detect low-rate attacks? • Could we tune the algorithms to detect low-rate attacks without having too many false alarms?

29. The Time-Scale Issue • Scenario: 9 TCP Sack flows with RED and RED-PD • RED-PD detects high bandwidth flows • DoS inter-burst period < 500 ms

30. The Time-Scale Issue • Scenario: 9 TCP Sack flows with RED and RED-PD • RED-PD detects high but fails to detect low-rate attacks bandwidth flows DoS inter-burst period > 500 ms • DoS inter-burst period < 500 ms

31. CHOKe • CHOKe [PPP00] controls misbehaving flows by preventing a flow to monopolize buffer resources • Question: • Why don’t we use CHOKe against low-rate attacks?

32. Flow Filtering Scenario • Heterogeneous RTT environment: • Short-RTT flows are the most vulnerable to low-rate attacks • Implications: • Long-RTT flows ‘collaborate’ in the attack • Less-than bottleneck rates needed to attack short-RTT flows

33. CHOKe and Flow Filtering • DoS flow utilizes only 3.3% of the bottleneck capacity • CHOKe fails to throttle the low-rate attack against short-RTT flows

34. Request Flooding DoS Attack • Pushback [RFC3168] • Network nodes coordinate efforts to detect a malicious (flooding) node • But in the request flooding scenario, the flooding machine is not malicious • moreover, it is a victim…

35. Bandwidth Stealing • Fact • Network-based schemes lack the exact knowledge of end-point parameters • Example • RED-PD doesn’t know about RTT: TB=f(Ploss, RTT=40ms) • Implication • Clients with RTT > 40 ms can exploit this vulnerability • Algorithmic misbehavior • We generalized the TCP formula • T=f(Ploss, RTT, a, b) • Our algorithm tells how to re-tune AIMD parameters to steal bandwidth, yet elude detection

36. Summary of Limitations • Low rate attacks • RED-PD: issue of time-scales • CHOKe: flow filtering • Misbehaving receivers • Pushback: No distinction of causes and effects • RED-PD: No knowledge of endpoint parameters • Can we do better from the endpoints? • End-point parameter randomization • End-point TCP-fairness verification

37. End-point minRTO Randomization • Observe: • Low-rate attacks exploit protocol determinism • minRTO=1sec • Question: • Can minRTO randomization alleviate the problem? • Approach: • Randomize the minRTO parameter • Insight: • The most vulnerable time-scale is T=b • Wait for flows to recover and then hit them again

38. End-point minRTO Randomization • TCP throughput formula on T=b time-scale of the low-rate attack

39. End-point minRTO Randomization • TCP throughput formula on T=b time-scale of the Shrew attack • 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

40. An End-Point Solution • Sender-side verification: • Ping Agent: • Measures RTT without a cooperation from the receiver • TFRC Agent: • Computes “TCP-fair” rate • Control Agent: • Enforces the sending rate

41. Evaluation • Scenarios: • with behaving receiver (to study false positives) • with misbehaving receivers (to study detection) End-point scheme is able to detect even very moderate misbehaviors Slight inaccuracy for higher packet loss ratios (due to TFRC conservatism)

42. Summary • Denial of Service attacks represent a fundamental threat to today’s Internet • Network-based solutions are necessary, yet are quite often very limited • End-point protocols optimized for performance, not security • DoS-resilient protocol design • Parameter randomization • Ability to control the other end-point

43. Conclusions • Improve network performance via • End-point QoS differentiation • DoS-resilient protocol design • QoS differentiation • Developed, implemented, and tested TCP-LP • Can significantly improve the network performance • Denial of Service • Pro-active approach • Jointly consider both performance and security aspects

44. Publications [1] Measuring Service in Multi-Class Networks, In IEEE INFOCOM 2001. [2] Measurement Based Characterization and Classification of QoS-Enhanced Systems, In IEEE TPDS, 14(7): 671-685, 2003. [3] TCP-LP: A Distributed Algorithm for Low Priority Data Transfer, In IEEE INFOCOM 2003. [4] TCP-LP: Low-Priority Service via End-Point Congestion Control, To appear in IEEE/ACM ToN. [5]* HSTCP-LP: A Protocol for Low-Priority Bulk Data Transfer in High-Speed High-RTT Networks, In PFLDnet 2004. [6] Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants), In ACM SIGCOMM 2003. [7] Low-Rate TCP-Targeted Denial of Service Attacks and Counter Strategies, Submitted to IEEE/ACM ToN. [8] A Performance vs. Trust Perspective in the Design of End-Point Congestion Control Protocols, In IEEE ICNP 2004. [9] Receiver-based Congestion Control with a Misbehaving Receiver: Vulnerabilities and End-Point Solutions, Submitted to IEEE/ACM ToN. * With R. Les Cottrell, SLAC.