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.