Upload
dayo
View
34
Download
0
Embed Size (px)
DESCRIPTION
Martin Casado (Stanford) Aditya Akaella (U. Wisconsin Madison) Pei Cao (Stanford) Niels Provos (Google) Scott Shenker (Berkeley/ICSI). Practical Flood Protection (for TCP services). Flooding. What: attacker attempts to exhaust downlink bandwidth - PowerPoint PPT Presentation
Citation preview
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