* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download A Hands-On Environment for Teaching Networks
Survey
Document related concepts
Internet protocol suite wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Distributed firewall wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Network tap wikipedia , lookup
Airborne Networking wikipedia , lookup
Dynamic Host Configuration Protocol wikipedia , lookup
TCP congestion control wikipedia , lookup
Cross-site scripting wikipedia , lookup
Deep packet inspection wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Real-Time Messaging Protocol wikipedia , lookup
Transcript
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