1 / 28

Practical Flood Protection (for TCP services)

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

dayo
Download Presentation

Practical Flood Protection (for TCP services)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Martin Casado (Stanford) Aditya Akaella (U. Wisconsin Madison) Pei Cao (Stanford) Niels Provos (Google) Scott Shenker (Berkeley/ICSI) Practical Flood Protection(for TCP services)

  2. 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

  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? request • 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? 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-wayhandshakewith 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 ACK+DATA+SYN_Cookie SYN DATA+SYN_Cookie ACK+DATA+Flow Cookie SYN_ACK+SYN_Cookie ACK+Data+Flow Cookie CookieBox 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

  12. Complications(2 ft view) • 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

  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 server’s 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 B C 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 1 D 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 1 D 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 AS’s 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

More Related