Practical Flood Protection for TCP services

1
Practical Flood Protection(for TCP services)

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

2
Flooding

• What attacker attempts to exhaust downlink
  bandwidth
• However downlink bandwidth not under victims
  control (unlike cpu, memory, uplink bandwidth
  etc.)
• Therefore need some sort of network support

server
3
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

4
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

5
Capabilities as a Solution
Capability OK?

• The Good
• No per-flow state
• Signalling from servers 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?

request
Request 10
Request 1011
Packet 1011
Packet 1011
Accept 1011
client
server
6
Our GoalCompatibility of Filteringand
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

7
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

8
Flow Cookies(5,000 ft view)
X
server
CookieBox
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

9
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

10
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)

11
Details(10 ft view)
?

• Check IP Revocation List
• Validate SYN Cookie

• Validate Flow Cookie
• Check Cookie Blacklist

• Add flow cookie to timestamp

ACKDATASYN_Cookie
SYN
DATASYN_Cookie
ACKDATAFlow Cookie
CookieBox
SYN_ACKSYN_Cookie
ACKDataFlow Cookie
ACKDATAFlow Cookie
ACKData
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, Crsrcipdstipsrcprt)
• Sr A secret
  only known to the router (128 bits)
• Cr A counter
  incremented periodically to age cookies

12
Complications(2 ft view)

• RSTs dont 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

13
Supporting Broader Deployment

• Point solution is good but
• Want to leverage as much bandwidth as possible
• Want to support incremental deployment

14
Supporting Broader Deployment

• Like filtering, can use existing relationships to
  spur deployment
• Server can ask ISP to install cookie-box
• And servers ISP and ask their ISP(s) to
  installcookie-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
15
The Trust Region
G
F
C
B
A
E
D
Peering link Client/provider
Peering
16
The Trust Region
G
F
C
B
A
E
D
Peering link Client/provider
Peering
17
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
• As relationships change
• As cookie support is added
• Can be done with simple modification to BGP

18
Problem Who Does the Handshake?
G
F
C
B
A
E
D
Peering link Client/provider
Peering
19
Problem Who Does the Handshake?
G
F
C
B
A
E
D
Peering link Client/provider
Peering
20
Finding the Trust Boundary

• Propagate ISP relationships and deployment status
  along with BGP advertisements
• 1 for client/provider relationshipand 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
21
Problem Who Does the Handshake?
G
0
F
C
B
0
1
1
1
A
E
D
1
1
0
Peering link Client/provider
Peering
1
22
Problem Who Does the Handshake?
G
0
F
B
C
0
1
0
0
A
E
D
1
1
0
Peering link Client/provider
Peering
1
23
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

24
Thanks
25
Number of Links/ASes on Trust Boundary
26
Percent of ASes on Trust Boundary Per Teir
27
Percent of Routes that Go Through ASs by Tier on
Trust Boundary
28
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