A Hands-On Environment for Teaching Networks
Download
Report
Transcript 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