1 / 38

Towards Robust Protocol Design: 4 Ways to Kill TCP without Much Trouble

This article explores the vulnerabilities of the TCP protocol and how various Denial of Service (DoS) attacks can effectively compromise its functionality. It outlines four main methods to disrupt TCP traffic, including Shrew attacks, padding misbehavior, TCP poisoning, and receiver-driven TCP stacks. The discussion emphasizes the need for robust countermeasures to mitigate these threats, particularly in an internet landscape where TCP accounts for over 90% of all traffic. With growing complexity in networks, anticipating novel DoS attacks is crucial for future-proofing internet protocols.

flo
Télécharger la présentation

Towards Robust Protocol Design: 4 Ways to Kill TCP without Much Trouble

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. Towards Robust Protocol Design: 4 Ways to Kill TCP without Much Trouble Aleksandar Kuzmanovic Northwestern University http://networks.cs.northwestern.edu

  2. The Internet • 1969 • 2007 The system of astonishing scale and complexity

  3. Denial of Service Problem • Assumption • Trust and cooperation among endpoints • Denial of Service Attacks • A malicious way to consume resources in a network, a server cluster or in an end host, thereby denying service to other legitimate users • FBI Computer Crime & Security Survey: • Overall financial losses: $201,000,000 • Denial of Service: $65,000,000

  4. Approach • Should we find ways to defend the Internet from DoS attacks? • Of course! • Anticipating novel types of DoS attacks is essential • More relevant and more challenging • My focus: TCP • More than 90% of traffic today is TCP

  5. Outline • Brief background on TCP • Four ways to kill TCP • Shrew attacks • Padding misbehavior • TCP poisoning attacks • Receiver-driven TCP stacks

  6. TCP Congestion Control • Slow-start phase • Double the sending ...... rate each round-trip ... time • Reach high throughput ...quickly

  7. TCP Congestion Control • Additive Increase –...Multiplicative Decrease • Fairness among flows

  8. TCP Congestion Control • Exponential • .backoff • System stability • Vulnerability to .....high-rate attacks

  9. Shrew Attacks • TCP is vulnerable to low-rate DoS attacks

  10. 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.”

  11. 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

  12. The Shrew Attack

  13. The Shrew Attack • A short burst (~RTT)sufficient to create outage • Outage – event of correlated packet losses that forces TCP to enter RTO mechanism

  14. The Shrew Attack • The outage synchronizes all TCP flows • All flows react simultaneouslyandidentically • backoff for minRTO

  15. The Shrew Attack • Once the TCP flows try to recover – hit them again • Exploit protocol determinism

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

  17. Shrews are Hard to Detect • l/T << 1 • Low-rate flow is hard to detect • Most counter-DOS mechanisms tuned for high-rate attacks • Detecting Shrews may have unacceptably many false alarms (due to legitimate bursty flows)

  18. Outline • Brief background on TCP • Four ways to kill TCP • Shrew attacks • Padding misbehavior • TCP poisoning attacks • Receiver-driven TCP stacks

  19. improvement C D A B The Source of the Problem • TCP optimized for throughput • Interactive applications may suffer • telnet, ssh, games, chat… RTO Incentive for misbehavior!

  20. Upgrading Mice to Elephants data packets strict priority TCP-fair rate “dummy” packets Padding misbehavior

  21. Implication Packet switched => Circuit switched

  22. RED FIFO Gain Fully-backlogged flows always achieve gain relative to interactive flows

  23. Sustainable Countermeasures • Short-term padding with dummy packets • Enable that a packet loss is detected via fast retransmit mechanism • Actual packet followed by three tiny dummy packets. • A diversity approach • TCP sends k (k>1, k is a small integer) copies of the packet without violating congestion control mechanism • In reality k=2 is sufficient Both approaches de-motivate greedy users from using the fully-backlogged approach

  24. Outline • Brief background on TCP • Four ways to kill TCP • Shrew attacks • Padding misbehavior • TCP poisoning attacks • Receiver-driven TCP stacks

  25. A TCP Poisoning Attack • Background • Mis-configured load balancers can reset TCP connections • Simply send a RST packet to an endpoint • Implication • Monitoring -> DoS attacks • Just send a bogus packet and poison an endpoint • TCP behaves as a dummy state machine • Both control and data planes are vulnerable

  26. Large-Scale TCP Poisoning Attacks • Example • Poison clients instead of a server A2 C1 C2 A1 Server Cn

  27. Why Not Cryptography? • Explicit monitoring required in networks • Advanced congestion control protocols (e.g., XCP) • Intrusion-detection mechanisms • Not implemented widely • E.g., IPSec • Even cryptography won’t help • Key exchange vulnerable to poisoning

  28. Our Approach • Deferred protocol reaction • Attack detection • Forward nonces • Distinguish packet streams from different hosts • Self-clocking based correlation • Identify the valid packet stream

  29. How long to defer?

  30. PN FN PN PN FN FN PN FN PN FN PN FN Forward Nonces … … • Chaining mechanism to distinguish among different packet sources • Past and future nonce • 8-bit random numbers • Overhead: 2 bytes/packet

  31. Client Server Self Clocking Based Correlation Idea: Exploit strong correlation among inter- departure and inter-arrival times at an endpoint IDTi ACKi ACKi+1 IDTi+1 ACKi+2 IDTi+2 ACKi+3 DATAi DATAi+1 IATi DATAi+2 DATAi+3 IATi+1 IATi+2

  32. Evaluation • Our approach dramatically improves performance over standard TCP

  33. Outline • Brief background on TCP • Four ways to kill TCP • Shrew attacks • Padding misbehavior • TCP poisoning attacks • Receiver-driven TCP stacks

  34. 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

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

  36. An Example: Request-Flood Attack • Request flood attack • A misbehaving receiver floods the server with requests, which replies and congests the network

  37. Conclusions • Think of attacks, not just defenses • More challenging and more relevant • Robust protocol design • Avoid determinism whenever you can • Understand extreme scenarios • Explore novel defense mechanisms • E.g., use measurements to achieve DoS resilience • Anticipate effects before applying a change

  38. Thank You! • More information available at • http://networks.cs.northwestern.edu • Questions?

More Related