Towards Robust Protocol Design: 4 Ways to Kill TCP without Much Trouble Aleksandar Kuzmanovic Northwestern University

A. Kuzmanovic Towards Robust Protocol Design 2 The Internet 1969 The system of astonishing scale and complexity 2007

A. Kuzmanovic Towards Robust Protocol Design 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

A. Kuzmanovic Towards Robust Protocol Design 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

A. Kuzmanovic Towards Robust Protocol Design 5 Outline Brief background on TCP Four ways to kill TCP –Shrew attacks –Padding misbehavior –TCP poisoning attacks –Receiver-driven TCP stacks

A. Kuzmanovic Towards Robust Protocol Design 6 Slow-start phase Double the sending rate each round-trip... time Reach high throughput...quickly TCP Congestion Control

A. Kuzmanovic Towards Robust Protocol Design 7 TCP Congestion Control Additive Increase –...Multiplicative Decrease Fairness among flows

A. Kuzmanovic Towards Robust Protocol Design 8 TCP Congestion Control Exponential.backoff System stability Vulnerability to.....high-rate attacks

A. Kuzmanovic Towards Robust Protocol Design 9 TCP is vulnerable to low-rate DoS attacks Shrew Attacks

A. Kuzmanovic Towards Robust Protocol Design 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.”

A. Kuzmanovic Towards Robust Protocol Design 11 TCP: a Dual Time-Scale Perspective Two time-scales fundamentally required –RTT time-scales (~ 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 secRFC2988

A. Kuzmanovic Towards Robust Protocol Design 12 The Shrew Attack

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

A. Kuzmanovic Towards Robust Protocol Design 14 The outage synchronizes all TCP flows –All flows react simultaneously and identically backoff for minRTO The Shrew Attack

A. Kuzmanovic Towards Robust Protocol Design 15 Once the TCP flows try to recover – hit them again Exploit protocol determinism The Shrew Attack

A. Kuzmanovic Towards Robust Protocol Design 16 And keep repeating… RTT-time-scale outages inter-spaced on minRTO periods can deny service to TCP traffic The Shrew Attack

A. Kuzmanovic Towards Robust Protocol Design 17 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) Shrews are Hard to Detect

A. Kuzmanovic Towards Robust Protocol Design 18 Outline Brief background on TCP Four ways to kill TCP –Shrew attacks –Padding misbehavior –TCP poisoning attacks –Receiver-driven TCP stacks

A. Kuzmanovic Towards Robust Protocol Design 19 The Source of the Problem TCP optimized for throughput –Interactive applications may suffer telnet, ssh, games, chat… RTO improvement A B CD Incentive for misbehavior!

A. Kuzmanovic Towards Robust Protocol Design 20 data packets “dummy” packets strict priority TCP-fair rate Padding misbehavior Upgrading Mice to Elephants

A. Kuzmanovic Towards Robust Protocol Design 21 Implication Packet switched => Circuit switched

A. Kuzmanovic Towards Robust Protocol Design 22 REDFIFO Fully-backlogged flows always achieve gain relative to interactive flows Gain

A. Kuzmanovic Towards Robust Protocol Design 23 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 Sustainable Countermeasures Both approaches de-motivate greedy users from using the fully-backlogged approach

A. Kuzmanovic Towards Robust Protocol Design 24 Outline Brief background on TCP Four ways to kill TCP –Shrew attacks –Padding misbehavior –TCP poisoning attacks –Receiver-driven TCP stacks

A. Kuzmanovic Towards Robust Protocol Design 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

A. Kuzmanovic Towards Robust Protocol Design 26 Large-Scale TCP Poisoning Attacks C1 C2 Cn A1 A2 Server Example –Poison clients instead of a server

A. Kuzmanovic Towards Robust Protocol Design 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

A. Kuzmanovic Towards Robust Protocol Design 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

A. Kuzmanovic Towards Robust Protocol Design 29 How long to defer?

A. Kuzmanovic Towards Robust Protocol Design 30 Forward Nonces FNPNFNPNFNPNFNPN … FNPNFN … Chaining mechanism to distinguish among different packet sources Past and future nonce 8-bit random numbers Overhead: 2 bytes/packet

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

A. Kuzmanovic Towards Robust Protocol Design 32 Evaluation Our approach dramatically improves performance over standard TCP

A. Kuzmanovic Towards Robust Protocol Design 33 Outline Brief background on TCP Four ways to kill TCP –Shrew attacks –Padding misbehavior –TCP poisoning attacks –Receiver-driven TCP stacks

A. Kuzmanovic Towards Robust Protocol Design 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] Performance Functionality - Loss recovery- Seamless handoffs - Congestion control- Server migration - Power management for - Bandwidth aggregation mobile devices - Web response times - Network-specific congestion control

A. Kuzmanovic Towards Robust Protocol Design 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

A. Kuzmanovic Towards Robust Protocol Design 36 An Example: Request-Flood Attack Request flood attack –A misbehaving receiver floods the server with requests, which replies and congests the network

A. Kuzmanovic Towards Robust Protocol Design 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

A. Kuzmanovic Towards Robust Protocol Design 38 Thank You! More information available at – Questions?