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

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

Trouble

Aleksandar Kuzmanovic

Northwestern University

http://networks.cs.northwestern.edu

2 A. Kuzmanovic Towards Robust Protocol Design

The Internet

1969

The system of astonishing scale and complexity

2007

UTAH

UCLAUCS B

S R


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


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


Outline

Brief background on TCP

Four ways to kill TCP– Shrew attacks– Padding misbehavior– TCP poisoning attacks– Receiver-driven TCP stacks


Se

nd

ing

Ra

te

T ime

packet loss• Slow-start phase • Double the sending ... ... rate each round-trip ... time • Reach high throughput ...quickly

TCP Congestion Control


TCP Congestion ControlS

en

din

g R

ate

T ime

packet loss

• Additive Increase – ...Multiplicative Decrease • Fairness among flows


TCP Congestion ControlS

en

din

g R

ate

T ime

packet loss

• Exponential•.backoff• System stability• Vulnerability to ... ..high-rate attacks


TCP is vulnerable to low-rate DoS attacks

DoSRate

DoS I nter- burst Period

TC P

DoS

Shrew Attacks


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


Discrepancy between RTO and RTT tim e- scales isa key source of vulnerability to low rate attacks

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


Victim

Attacker

TC

P S

en

din

g R

ate

Time

Do

S R

ate

Tim e

The Shrew Attack


A short burst (~RTT) sufficient to create outage

Outage – event of correlated packet losses that forces TCP to enter RTO mechanism

Victim

Attacker

Do

S R

ate

Tim e

short burst (~RTT)

random initial phase

TC

P S

en

din

g R

ate

Tim e

outage

The Shrew Attack


The outage synchronizes all TCP flows– All flows react

simultaneously and identically

• backoff for minRTO

Victim

Attacker

TC

P S

en

din

g R

ate

Tim e

minRTO

Do

S R

ate

Tim erandom initial phase

The Shrew Attack


Once the TCP flows try to recover – hit them again

Exploit protocol determinism

Victim

AttackerTC

P S

en

din

g R

ate

Time

minRTO

Do

S R

ate


The Shrew Attack


And keep repeating…

RTT-time-scale outages inter-spaced on minRTO periods can deny service to TCP traffic

Victim

Attacker

TC

P S

en

din

g R

ate

Tim e

minRTO minRTO

Do

S R

ate


The Shrew Attack


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)

DoSrate

magnitudeof theburst R

period of the attack T

length of the burst l

Shrews are Hard to Detect


Outline




The Source of the Problem

TCP optimized for throughput– Interactive applications may suffer

• telnet, ssh, games, chat…

RTO

improvement

A B C D


data packets

“dummy”packets

strict priority

TCP-fair rate

Padding misbehavior

Upgrading Mice to Elephants


Implication

Packet switched => Circuit switched


RED FIFO

TCP backlogged-fullyfor timeresponse Expected

TCP eInteractivfor timeresponse Expected Gain

Fully-backlogged flows always achieve gain relative to interactive flows

Gain


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 usersfrom using the fully-backlogged approach


Outline




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


Large-Scale TCP Poisoning Attacks

C1

C2

Cn

A1

A2

Server

Example– Poison clients instead of a server


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


Our Approach

Deferred protocol reaction– Attack detection

Forward nonces– Distinguish packet streams from different hosts

Self-clocking based correlation– Identify the valid packet stream


How long to defer?


Forward Nonces

FNPN FNPNFNPN FNPN …

PN FN PN FN …

• Chaining mechanism to distinguish among different packet sources

• Past and future nonce

• 8-bit random numbers

• Overhead: 2 bytes/packet


Server Client

IATi

IDTi+1

IDTi+2

IDTi

IATi+1

IATi+2

ACKiACKi+1

ACKi+2

ACKi+3

DATAiDATAi+1

DATAi+2DATAi+3

Self Clocking Based CorrelationIdea: Exploit strong correlation among inter-departure and inter-arrival times at an endpoint


Evaluation

Our approach dramatically improves performance over standard TCP


Outline




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


Vulnerability

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

Server(Sender)

Client(Receiver)

request

data?

Can HTTP, file, and stream ing servers in the I nternet safely deploy the receiver- driven TCP protocols?


An Example: Request-Flood Attack

Request flood attack– A misbehaving receiver floods the server with requests, which replies and congests the network Server

Requests

Malicious Client


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


Thank You!

More information available at– http://networks.cs.northwestern.edu

Questions?