Check out the new USENIX Web site. next up previous
Next: Measurements Up: MULTOPS implementation Previous: Expansion and contraction


Memory exhaustion attacks

To defeat our mechanism, an attacker may try to exhaust a router's memory by making IPRateMonitor allocate many nodes. (Of course, memory exhaustion is only possible when IPRateMonitor has no imposed memory limit.) An attacker achieves this by sending packets with a wide variety of spoofed IP source addresses through that router. (This is a problem only when MULTOPS is in attacker-oriented mode.) Each stream of packets with a common IP source address needs to have a bandwidth higher than the expand threshold of MULTOPS--otherwise MULTOPS contracts the nodes, thereby defeating the attacker's goal to run it out of memory. If an attacker is not bound by any resource constraints, nor by ingress/egress filtering, he can create a worst-case scenario by sending spoofed IP packets such that the number of nodes in MULTOPS is maximized.

Given the structure of the MULTOPS tree, the size of a Table (1040 bytes), the size of a Record (28 bytes), a packet size of 34 bytes, and an expand threshold of 1000 packets per second, an attacker, launching such a worst-case scenario memory exhaustion attack, needs to generate traffic with a bandwidth of roughly 16 Gbit/s to make IPRateMonitor allocate 128MB of memory, provided that the network has the physical capability to carry this traffic to the target router. This number was derived by calculating the amount of allocated memory based on the number of different address prefixes stored in the tree. The expand threshold can be set to a value that ensures that memory will never run out. It is safe to conclude that, even without an imposed memory limit, it is impossible to run IPRateMonitor out of memory.


next up previous
Next: Measurements Up: MULTOPS implementation Previous: Expansion and contraction
2001-05-11