Papers covered

1. Papers covered • K. Lakshminarayanan, D. Adkins, A. Perrig, I. Stoica, “Taming IP Packet Flooding Attacks”, HotNets-II. • M. Handley, A. Greenhalgh, “Steps Towards a DoS-resistant Internet Architecture”, FDNA 2004.

2. Goals • Host-based control over packets received • Avoid receiving packets at arbitrary ports • Contain traffic of an application under a flooding attack to protect other traffic (isolation) • Protect traffic of established connections • Throttle rate of opening new connections

3. Two main approaches • More radical, more elegant • Use indirection layer (i3-based) • Less radical, less elegant • Use special filters at edge ISP (IP-based)

4. i3 • Rendezvous primitive built on top of a DHT (content-addressable network) • Key lookup done in a distributed p2p manner

5. i3-based approach • Sources send packets to logical identifier <id,data> • Receivers express interest in packets by inserting triggers <id,addr> • Given a packet <id,data>, i3 looks to see if there is an associated trigger <id,addr> to forward packet to • Receiver removes trigger if not interested in packet • Example use • Servers have well-known public triggers • Clients contact servers via public triggers to establish dynamic private triggers • Subsequent communication via private triggers

6. i3-based goals achieved • Avoid receiving packets at arbitrary ports • IP addresses hidden and identifiers of public triggers are the only information exposed • Contain traffic of an application under a flooding attack to protect other traffic (isolation) • Differential dropping/prioritization of public triggers under attack (similar to WFQ or CBQ) • Protect traffic of established connections • Differential dropping/prioritization of private vs public triggers • Throttle rate of opening new connections • Redirect public trigger to a gatekeeper that issues puzzles (approach in paper is weak => see last week's IP puzzle paper)

7. IP-based approach • Provide configurable white lists of allowed communication at edge ISP (akin to NAT traversal) • Edge routers maintain per-flow state for destinations • Effectively placing a customer “firewall” upstream • Assumptions • Edge ISP with enough bandwidth to support arbitrary volumes of attack traffic • Edge ISP willing to allow dynamic customer filters

8. IP-based goals achieved • Avoid receiving packets at arbitrary ports • Port forward only those on white-list (i.e. firewall) • Contain traffic of an application under a flooding attack to protect other traffic (isolation) • Differential dropping/prioritization of flows (similar to WFQ or CBQ) • Protect traffic of established connections • Differential dropping/prioritization of established vs. new traffic (via per-flow state kept in router) • Throttle rate of opening new connections • Redirect via DNS to send traffic to a puzzle-issuing gatekeeper

9. i3 vs IP • i3 good • Filtering done at arbitrary points in network versus at access link • Does not require help from ISP • i3 bad • Need support for i3 • Can i3 itself be flooded? May not be efficient enough

10. Papers covered • K. Lakshminarayanan, D. Adkins, A. Perrig, I. Stoica, “Taming IP Packet Flooding Attacks”, HotNets-II. • M. Handley, A. Greenhalgh, “Steps Towards a DoS-resistant Internet Architecture”, FDNA 2004.

11. Defenses • Increase end-system software security • Reduce ability for worms/viruses to spread • Prevent source-address spoofing • Prevent reflection attacks • Router-based push-back (need previous two defenses) • Wide-area service distribution • Receiver control of incoming connection attempts • Traffic isolation of critical communication (i.e. route updates)

12. Model • Should be a separation between route advertisement and service advertisement • Routers should have a model that routes only valid service requests (not just valid IP addresses) and nothing else • Removes client-to-client worms since clients should not advertise any services • Prevents reflector attacks since routers can throw out invalid service requests

13. Step 1 • Separate client and server addresses • Only allow client to server communication (no client-client or server-server) • Formalize asymmetry and enforce in the network • Impact • Slows worm propagation • Must go from client to server to client to server • Prevents reflector attacks on servers • Must have server=>client=>server • But, client can throw out requests from bogus servers since it knows all valid requests it has • Some benefits lost when hosts need both client and server addresses (p2p, VoIP)

14. Step 2 • Non-global client addresses • Prevents clients from giving up their location and becoming targets themselves • Construct address domain-to-domain as packets travel to server (easy traceback) • Impact • Source-address spoofing impossible for clients (packet always reveals path making traceback/pushback easy) • Makes paths symmetric at the domain level • Allows ISP to determine attacks via asymmetry in requests and responses (?) • Reflection attacks prevented (since no spoofing) • Changeable client addresses require some stable ID above IP (i.e. HIP)

15. Step 3 • RPF checking of server addresses • Path-based client addresses do not prevent servers from spoofing servers • Server-to-client communication must follow reverse of domains from client-to-server • Allows boundary routers to perform a reverse-path forwarding check on source address of server-to-client packets • Prevents one server from spoofing a response of another server • Impact • Makes it hard to launch blind DoS attacks on on-going communications even if connection ID can be inferred (i.e. TCP RST)

16. Step 4 • State setup bit • Separate out traffic that requires state to be set up (i.e. TCP SYNs) • Provides generic protocol-independent indication of special packets • Stateful firewalls can validate packets before instantiating state • Packets without this bit set can be dropped if no state found • Impact • Server addresses can not send packets with state-setup bit set (mechanism to enforce separation of clients and servers) • Sites might rate-limit outgoing packets with bit set (?) • Problem: Who is setting this bit? Can they be trusted?

17. Step 5 • Nonce exchange and puzzles • Nonce echoing • IP puzzles based on state-setup bit • See last week's slides

18. Step 6 • Middlewalls • Firewalls are too close to systems being protected • Use pushback to put filters into the core • Have it also issue puzzles • Path symmetry enables middlewalls to validate that filtering requests are authentic (i.e. not spoofed) • Problems • Lots of network state to keep track of bad flows • Problems with multiple firewalls in a path interacting • Multiple round-trips per request • Same problems with IP puzzles and multiple issuers

19. Step 7 • Source-specific multicast+ • Traditional IP multicast impossible to protect • Senders with ability to instantiate forwarding state • Senders sending to existing mcast group without consent of receivers • Use source-specific multicast groups • Receivers join to specific source (no way for sender to be malicious without participation from many receivers) • Problem • Receivers joining a lot of non-existent groups • Receivers joining a bunch of high-bandwidth sources • Solutions • Cryptographically generated addresses • Two-pass join mechanism (validate group liveness before instantiating state) • Threshold for number of SSM groups one can join

20. Collateral damage • Loss of symmetry • Clients vs. servers (P2P, VoIP) • Require client-client communication • Ugly workaround using brokers and borrowed server addresses • Reintroduces some of the DoS vlunerabilities that were removed • Tranisition • Evolve to explicit separation (start with client, server, unrestricted) • DNS • Distribute top level entries via multicast • Minimize relaying • SMTP, NNTP, SIP • Same as with DNS