towards robust protocol design: 4 ways to kill tcp without much trouble aleksandar kuzmanovic...

38
Towards Robust Protocol Design: 4 Ways to Kill TCP without Much Trouble Aleksandar Kuzmanovic Northwestern University http://networks.cs.northwestern.ed u

Post on 21-Dec-2015

227 views

Category:

Documents


1 download

TRANSCRIPT

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

3 A. Kuzmanovic Towards Robust Protocol Design

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

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

Outline

Brief background on TCP

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

6 A. Kuzmanovic Towards Robust Protocol Design

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

7 A. Kuzmanovic Towards Robust Protocol Design

TCP Congestion ControlS

en

din

g R

ate

T ime

packet loss

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

8 A. Kuzmanovic Towards Robust Protocol Design

TCP Congestion ControlS

en

din

g R

ate

T ime

packet loss

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

9 A. Kuzmanovic Towards Robust Protocol Design

TCP is vulnerable to low-rate DoS attacks

DoSRate

DoS I nter- burst Period

TC P

DoS

Shrew Attacks

10 A. Kuzmanovic Towards Robust Protocol Design

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

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

12 A. Kuzmanovic Towards Robust Protocol Design

Victim

Attacker

TC

P S

en

din

g R

ate

Time

Do

S R

ate

Tim e

The Shrew Attack

13 A. Kuzmanovic Towards Robust Protocol Design

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

14 A. Kuzmanovic Towards Robust Protocol Design

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

15 A. Kuzmanovic Towards Robust Protocol Design

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

Tim erandom initial phase

The Shrew Attack

16 A. Kuzmanovic Towards Robust Protocol Design

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

Tim erandom initial phase

The Shrew Attack

17 A. Kuzmanovic Towards Robust Protocol Design

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

18 A. Kuzmanovic Towards Robust Protocol Design

Outline

Brief background on TCP

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

19 A. Kuzmanovic Towards Robust Protocol Design

The Source of the Problem

TCP optimized for throughput– Interactive applications may suffer

• telnet, ssh, games, chat…

RTO

improvement

A B C D

20 A. Kuzmanovic Towards Robust Protocol Design

data packets

“dummy”packets

strict priority

TCP-fair rate

Padding misbehavior

Upgrading Mice to Elephants

21 A. Kuzmanovic Towards Robust Protocol Design

Implication

Packet switched => Circuit switched

22 A. Kuzmanovic Towards Robust Protocol Design

RED FIFO

TCP backlogged-fullyfor timeresponse Expected

TCP eInteractivfor timeresponse Expected Gain

Fully-backlogged flows always achieve gain relative to interactive flows

Gain

23 A. Kuzmanovic Towards Robust Protocol Design

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

24 A. Kuzmanovic Towards Robust Protocol Design

Outline

Brief background on TCP

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

25 A. Kuzmanovic Towards Robust Protocol Design

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

Large-Scale TCP Poisoning Attacks

C1

C2

Cn

A1

A2

Server

Example– Poison clients instead of a server

27 A. Kuzmanovic Towards Robust Protocol Design

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

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

How long to defer?

30 A. Kuzmanovic Towards Robust Protocol Design

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

31 A. Kuzmanovic Towards Robust Protocol Design

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

32 A. Kuzmanovic Towards Robust Protocol Design

Evaluation

Our approach dramatically improves performance over standard TCP

33 A. Kuzmanovic Towards Robust Protocol Design

Outline

Brief background on TCP

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

34 A. Kuzmanovic Towards Robust Protocol Design

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

35 A. Kuzmanovic Towards Robust Protocol Design

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?

36 A. Kuzmanovic Towards Robust Protocol Design

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

37 A. Kuzmanovic Towards Robust Protocol Design

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

Thank You!

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

Questions?