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 – Receivers express interest in packets by inserting triggers – Given a packet, i3 looks to see if there is an associated trigger 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