1 / 44

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

Edge-based Inference, Control, and DoS Resilience for the Internet. Ph.D. Thesis Presentation Aleksandar Kuzmanovic. 1969. 2004. The Internet. The system of astonishing scale and complexity. Internet Design Principles. Network as a black-box. Implications Easy to upgrade the network

iria
Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related