DDoS Attack Prevention by Rate Limiting and Filtering d’Artagnan de Anda CS239 Network Security 26 Apr 04

 Pushback Paper  NetBouncer  D-WARD Paper  Questions for Discussion Overview

 Filtering – requires real time algorithms, and most likely pre- deployment of resources for trust  Rate Limiting – Hard to prevent collateral damage to “good” and “poor” traffic v. just bad traffic Overview

Pushback  Ioannidis and Bellovin attempt to implement Pushback  Problem: We can’t tell legitimate traffic from illegitimate traffic  Goal: Develop heuristics that try to identify most bad packets while not disturbing most good packets.  Aggregate-based Congestion Control  A subset of the traffic with an identifiable property, e.g.:  Packets to destination D  TCP SYN packets  IP packets with a bad checksum  Identify “attack signature” -> “congestion signature”  Sort of recursive – It tells the next level of routers to back off, as it is backing off.  Rationale: The packets will be dropped at the destination anyway, so why not just drop them at the routers above too?

Pushback  Good architecting by allowing the pushback daemon to exist out of band.  Router must have some sort of inherent traffic shaping capability to take advantage of this  Only logs packets dropped for queue discipline reasons  pushbackd processes the saved drop-set to try to detect congestion.  “The exact algorithm(s) to run will be an important research topic for some time to come.”  The algorithm detects aggregates based only on IP destination address – the simplest implementation

Pushback  The pushback daemon listens for requests from its downstream routers. => Necessitates greater deployment  Probability of keeping a packet is inversely proportional to its size – smart!  “In a real router with hardware-assisted fast switching paths for the common cases, the overhead of imposing a number of rate limiting sessions may be much higher.”

Pushback  “Even though the prefix garnered from the routing table will be shorter than 32 bits, the address of the selected aggregate will be the full 32 bits.” Why? Because a specific machine is targeted.  “It is likely that more than one attack is happening at the same time.” Why? More than one attack does happen at the same time and one should design a system that works for the real world.  The algorithm should run in less time than it takes to collect the packets. Why? Queuing system theory: You want the server to operate faster than the queue can fill up.  “Pushback is most effective when the attack is non-isotropic. (most attack traffic close to victim and from a subset of the in-links)” Why? Smaller area to graph. More likely to have a complete deployment of Pushback in that area.

NetBouncer  Claim: NetBouncer can tell the difference between legitimate and illegitimate traffic in a hardware implementation of a router.  “End-point-based solution to DDoS protection  Goals:  No changes in current network protocols  No administrator intervention for legitimacy tests  State safety: legitimacy tests do not become vulnerabilities  “A NetBouncer device maintains a large legitimacy list of clients that have been proven to be legitimate”  Not on the legitimacy list? Administer tests to prove legitimacy.

NetBouncer  Use of TCP SYN cookies was a good idea  Interception of SYN packets  Handles TCP connection in a “stateless manner”  Good job addressing Application and Session-oriented legitimacy tests (structured- and ad hoc- composite services i.e., SCS and ACS). But…  “The ACS subcategory is currently a topic if intense research and will be reported in the future.

NetBouncer  NetBouncer “should be placed upstream of potential chokepoints…” How is this location determined? There really aren’t great places to deploy NetBouncer. Must be placed where it can handle all of the attack traffic. Otherwise, rate limiting before NetBouncer will reduce the good and bad traffic it sees.  Use of ICMP echo messages touted, and then acknowledged as not likely to be effective…  How does the list of legitimate sources get instantiated? This is hard to do.  “We are currently exploring how ICWFQ can be supported within the IXP based hardware prototype of NetBouncer.”

D-WARD  DDoS defense mechanism intended to be deployed at the source to detect and stop attacks by evaluating traffic signatures  Problems:  Attack traffic is too aggregated at the victim so it makes on-the-fly packet dropping difficult.  Core routers cannot spare enough resources to do a good job so much collateral damage is suffered from implementation there.  Solution: Stop attacks at the source

D-WARD  Configure outgoing addresses to be policed  Monitor traffic between these addresses and the rest of the internet.  Compare traffic against historical data and curtail deviating behavior. Autonomous adjustment.  Addresses TCP, ICMP, and UDP –  Definitions provided for “normal, suspicious, or attack”  # of machines attacking is transparent to the system

D-WARD  “We assume that D-WARD is able to identify the police address set.” Probably not a simple task. Fairly easy to identify what machines are in your own network.  “We assume that all machines from the police address set use the source router as the exit router” (i.e., Asymmetric routes – you have to check between every possible pair, with secure communication and clock synchronization, exposing more points to be attacked.)  What would be the maintenance cost of keeping the police address set up to date? Not much.  Most networks DO have more than one border router. D-WARD would be most effective if deployed on each border router.  Possibly, the correct assumption is that if an ISP chooses to implement this system on one border router, they would do so for all…

D-WARD  Hardware vs. Software Router  “and enable us [to] test whether D-WARD can handle traffic at high speeds.” Implemented on IXP-1200  Legitimate flows that start during the attack  Hash table size limitation  Detection of UDP packets  Cannot detect “the shrew” attack from non-spoofed sources. Can now detect some UDP traffic flows too.

Questions for Discussion  Will any of these DDoS prevention schemes be deployed?  Of the three papers, which is the most scalable?  Is it better to filter at the source or at the destination  How do we expose the benefits of every one filtering at the source?  Are we stuck with DDoS attacks forever?