DHCP Starvation, A Trivial Solution?

I know there are a lot of solutions out there for mitigating DHCP starvation attacks. But wouldn't a really simple solution be to just set the DHCP address pool to 1.1.1.1 - 254.254.254.254 (or some other really large pool) so that the malicious entity cannot starve the entire pool within a practical time frame? Why is this not done?

Consider this in the context of a wireless network, with no encryption and no authentication (typical of free public wireless hotspots).

Solution 1:

Using the entire ip address space seems a bit excessive. Assuming you're talking about a contained environment (say behind a NAT) then you could use 10.0.0.0\8 without running into any routing related issues. Provided your actual network (ie the number of real machines) is small then the general problem of having a potentially huge broadcast domain is not really that relevant and if you set the lease time relatively low (a few minutes) you could ensure that it just wasn't practical for a single attacker to actually exhaust your range. However you would still have to fend off what might be a relatively large amount of traffic with millions of fake requests and it will be broadcast traffic remember so all the genuine devices on your network will see it too - so lots of spurious noise for everyone on the network to have to handle interrupts from. Your switches will start tracking all of these [fake] MAC\IP-address combinations now too so you're allowing your attacker to increase the amount of resources they consume, and those are finite too. For a serious attack I reckon DHCP exhaustion attack code probably push out requests faster than many DHCP servers can deal with if the scope is actually huge - the physical resources (CPU & RAM needed to handle the responses and tracking the table of active leases) on the DHCP server may eventually simply get consumed if the attacker can generate requests fast enough and the end result may be worse for you - you've now swapped a Denial of Service attack against new connections with an attack that might crash your DHCP server and Switches (and those might be exploitable).

If this is a valid concern, and you can't live with the possibility of DoS against clients you should use switches that have mechanisms to prevent this - there are specific DHCP starvation mitigation mechanisms like DHCP Snooping but just enabling controls to limit MAC address spoofing will generally help in this and also in CAM table flooding. The best approach is to enable port authentication but that is hard to implement in any large controlled environment and no use in an unmanaged scenario (such as a WiFi Hotspot). I don't believe there's a definitive general purpose solution, it's a case of balancing the risks of the various options available and selecting the one that works best in your environment.

Solution 2:

There are many issues with this approach.

First of all, if you do what you expressed, you'll be effectively cutting yourself off from the internet, as that range includes (nearly) all possible IPv4 addresses.

Secondly, by doing this, you're setting yourself up for having to deal with a huge broadcast domain. Typical networking best practices recommend using small-ish subnets (say those having /22 or longer netmasks) to limit the size of your broadcast domains. With subnets larger than that, your routing and switchgear (depending on how robust they are), could get swamped with having to deal with that much broadcast traffic.

Solution 3:

Switch to IPv6!

Especially if you just use ICMP auto-negotiation without a DHCP server. :)

Solution 4:

There's no trivial solution because it's not a trivial problem.

At the heart of it, DoS attacks on a wireless Ethernet installation, be they something "intelligent" like a DHCP scope exhaustion attack, or something "brainless" like a transmitter flooding the spectrum used by the radios, can't be stopped because radios can't selectively ignore signals from any given transmitter. The air is a shared medium, and that's just physics.

In a wired Ethernet, you could turn off the port that excessive DHCP requests (or other types of DoS attacks) are being sourced from. Short of disabling the access point where the excessive DHCP requests are coming from (and disabling every mobile unit associated with that AP), there's nothing "trivial" you can do.