SRUTI 2006

Practical Flood Protection(for TCP services)

Martin Casado (Stanford) Aditya Akaella (U. Wisconsin Madison)Pei Cao (Stanford)Niels Provos (Google)Scott Shenker (Berkeley/ICSI)

SRUTI 2006

Flooding

What: attacker attempts to exhaust downlink bandwidth

However: downlink bandwidth not under victim’s control (unlike cpu, memory, uplink bandwidth etc.)

Therefore: need some sort of network supportserver

SRUTI 2006

Filtering as a Solution(blacklisting)

Filtering rules on data path determine which packets to drop

The Good: No change to clients Filters pushed up from the source to point of sufficient

bandwidth

The Bad: Source spoofing makes generating accurate filters

difficult Identifying attack “aggregates” somewhat of a heuristic

● To strict = large collateral● To permissive = some attacks get through

SRUTI 2006

Filtering as a Solution(whitelisting)

Filtering rules on data path determine which packets not to drop E.g. NAT, only allow packets belonging to outbound flows

The Good: No change to clients Filters pushed up from the source to point of sufficient

bandwidth

The Bad: Network state is a function of legitimate clients or flows Difficult for network to determine what is legitimate

SRUTI 2006

Capabilities as a Solution

The Good No per-flow state Signalling from server’s built in (no guessing by the network) Some resistance to source spoofing

The Bad Need to modify clients Generally require major changes to datapath (e.g. PKI) Security dependent on path length Capability setup requires global rate-limiting infrastructure?

serverclient

request Request | 10 Request | 1011

Accept | 1011Packet | 1011

Capability OK?

Packet | 1011

SRUTI 2006

Our GoalCompatibility of Filtering

and Properties of Capabilities Compatibility

No changes to clients Incremental infrastructure changes Realistic deployment strategy

● E.g. ISP filtering● E.g. third-party scrubbing (Prolexic)

Properties of Capabilities Scalable (no per-flow state) Resistant to source spoofing No guesswork in the network

SRUTI 2006

Flow-CookiesOur Solution at 10,000 ft

Clients must perform 3-way handshake with network to get initial capability

Only packets with capabilities are forwarded to server

Clients only continue to get capabilities if servers respond to them

Done with unmodified TCP

SRUTI 2006

Flow Cookies(5,000 ft view)

An in-network element (cookie-box) performs the TCP handshake

Clients that complete handshake are given a temporary capability

All incoming (non-SYN) packets are checked for valid capabilities Flows that get ACKs from the server continue to get capabilities

CookieBox

X server

client

SRUTI 2006

Filtering Packets to web-server not forged Web-server sends IP filtration requests to

cookie box Will not do 3-way handshake with filtered IPs

Web-server can send cookie revocation requests to cookie box Limit damage of outstanding cookies

SRUTI 2006

Properties of This Solution

Point deployable Benefit from limited (single) local deployment Ask ISP to deploy cookie-box Have third party deploy (e.g. Prolexic)

In-network state bounded by the trusted web site and proportional to # of attackers

Spoof Resistant Simple and fast

Can be done in backwards compatible fashion(can use unmodified TCP)

SRUTI 2006

Details(10 ft view)

CookieBox

Web Server

SYN

SYN_ACK+SYN_Cookie

ACK+DATA+SYN_Cookie

•Check IP Revocation List•Validate SYN Cookie?

DATA+SYN_Cookie

ACK+DataACK+Data+Flow Cookie

•Validate Flow Cookie•Check Cookie Blacklist

ACK+DATA+Flow CookieACK+DATA+Flow Cookie

Use a SYN cookie to carry the capability at first Place in timestamp of all subsequent ACKs from server Cookie is computed over connection 4-tuple

*MAC(Sr, Cr|srcip|dstip|srcprt) Sr A secret only known to the router (128 bits) Cr A counter incremented periodically to age cookies

•Add flow cookie to timestamp

SRUTI 2006

RSTs don’t carry timestamps Set aside some bandwidth for RSTs

Persistent connections may idle longer than cookie lifetime web site sends keep-alives at interval smaller than cookie

lifetime no persistent connections when under attack

What about path asymmetry? Assume AS level route symmetry Then just a matter of shared keys between cookie boxes

Does handshake affect RTO timers? Not as far as we can tell

Complications(2 ft view)

SRUTI 2006

Supporting Broader Deployment

Point solution is good but …

Want to leverage as much bandwidth as possible

Want to support incremental deployment

SRUTI 2006

Supporting Broader Deployment

Like filtering, can use existing relationships to spur deployment

Server can ask ISP to install cookie-box And server’s ISP and ask their ISP(s) to install

cookie-box

Assumption: If ISP in trust region has cookie box, server can rely on correct management

the trust region – transitive closure of all ISPs with which a web-server has an economic Relationship

SRUTI 2006

The Trust Region

Peering Peering linkClient/provider

A

B C

D E

FG

SRUTI 2006

The Trust Region

Peering Peering linkClient/provider

A

B C

D E

FG

SRUTI 2006

Filtering in Trust Regions

Only need to handshake/filter on the boundarybut …

Have to define boundary per source Some ISPs may not support flow-cookies Want to determine these boundaries

dynamically As relationships change As cookie support is added

Can be done with simple modification to BGP

SRUTI 2006

Problem: Who Does the Handshake?

Peering Peering linkClient/provider

A

B C

D E

FG

SRUTI 2006

Peering Peering linkClient/provider

A

C

D E

FB

Problem: Who Does the Handshake?

G

SRUTI 2006

Finding the Trust Boundary

Propagate ISP relationships and deployment status along with BGP advertisements 1 for client/provider relationship

and supports cookies 0 otherwise

1 1 1 1 0 0 0 0 0 0

Each ISP checks to see if it is on the boundary for the given prefix

If so, will perform handshake for that prefix

Perform handshake

SRUTI 2006

Problem: Who Does the Handshake?

Peering Peering linkClient/provider

A

B C

D E

FG

1

1

0

1

1

1 0

10

SRUTI 2006

Problem: Who Does the Handshake?

Peering Peering linkClient/provider

A

B C

D E

FG

1

0

0

1

0

1 0

10

SRUTI 2006

Summary Flow-Cookies

Offload TCP handshake in network Use ISN and timestamp to hold cookies Allow web-server to pass IP filtration requests to

cookie-box

Broader/Incremental Deployment Push “out” along existing trust relationships Use extension on top of BGP to dynamically

determine who manages the handshake

SRUTI 2006

Thanks

SRUTI 2006

Number of Links/ASes on Trust Boundary

SRUTI 2006

Percent of ASes on Trust Boundary Per Teir

SRUTI 2006

Percent of Routes that Go Through AS’s by Tier on Trust

Boundary

SRUTI 2006

Flow-Cookies Implementation

Implemented in software router (320 additional lines for core functionality)

Tested against many popular websites News Education Entertainment etc.

Software only tests operate at Gig speeds(assuming MTU sized packets)

IP blacklist implemented as p-trie Supports Gig speeds while containing 1,000,000

entries