Download A Hands-On Environment for Teaching Networks

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 support
server
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


The Good:



E.g. NAT, only allow packets belonging to outbound flows
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
Capability OK?
request
Packet | 1011
client


Request | 10
Packet | 1011
Request | 1011
Accept | 1011
server
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?
SRUTI 2006
Our Goal
Compatibility 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-Cookies
Our 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)
X
server
Cookie
Box
client




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
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)
?
ACK+DATA+SYN_Cookie
SYN
•Check IP Revocation List
•Validate Flow Cookie
•Validate
SYNtoCookie
•Add
flow cookie
•Check
Cookie
Blacklist
timestamp
DATA+SYN_Cookie
ACK+DATA+Flow Cookie
ACK+Data+Flow
Cookie
SYN_ACK+SYN_Cookie
Cookie
Box



ACK+DATA+Flow Cookie
ACK+Data
Web Server
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
SRUTI 2006
Complications
(2 ft view)

RSTs don’t carry timestamps


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?



Set aside some bandwidth for RSTs
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
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
the trust region – transitive closure of all
ISPs with which a web-server has an economic
Relationship

Assumption: If ISP in trust region has cookie
box, server can rely on correct management
SRUTI 2006
The Trust Region
G
C
B
A
F
E
D
Peering link
Client/provider
SRUTI 2006
The Trust Region
G
C
B
A
F
E
D
Peering link
Client/provider
SRUTI 2006
Filtering in Trust Regions

Only need to handshake/filter on the boundary
but …
Have to define boundary per source
Some ISPs may not support flow-cookies

Want to determine these boundaries dynamically

Can be done with simple modification to BGP


 As
relationships change
 As cookie support is added
SRUTI 2006
Problem: Who Does the
Handshake?
G
C
B
A
F
E
D
Peering link
Client/provider
SRUTI 2006
Problem: Who Does the Handshake?
G
B
A
F
C
E
D
Peering link
Client/provider
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
1111000000


Perform handshake
Each ISP checks to see if it is on the boundary
for the given prefix
If so, will perform handshake for that prefix
SRUTI 2006
Problem: Who Does the
Handshake?
G
0
B
1
0
1
A
11
1
C
F
0
E
D
Peering link
Client/provider
1
SRUTI 2006
Problem: Who Does the
Handshake?
G
0
B
0
A
11
1
C
F
0
0
0
E
D
Peering link
Client/provider
1
SRUTI 2006
Summary

Flow-Cookies

Broader/Incremental Deployment
 Offload
TCP handshake in network
 Use ISN and timestamp to hold cookies
 Allow web-server to pass IP filtration requests to
cookie-box
 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

Tested against many popular websites
(320 additional lines for core functionality)
 News
 Education
 Entertainment


etc.
Software only tests operate at Gig speeds
(assuming MTU sized packets)
IP blacklist implemented as p-trie
 Supports
entries
Gig speeds while containing 1,000,000
SRUTI 2006