DHCP is theoretically very susceptible to Denial of Service attacks, although they don't seem to be all that common in practice. An attacker can broadcast a DHCPDISCOVER, wait for a response, send a DHCPNAK, and repeat until the server is out of addresses. A more clever attacker can pretend to be a DHCP server and provide a false address to a client so that it finds itself unable to actually use the network. A really clever attacker can provide the client with mostly correct network information, but tell the client that it is the local subnet router, so that the client sends all of its off-subnet traffic through the attacker.

In an environment where network users are generally trustworthy, it's possible to limit the likelihood of some of these attacks through the use of firewall filtering rules - don't allow DHCP packets to be sent into your network from the outside, and you can be sure that no outsiders will be able to perpetrate DoS attacks against you. Sites that have to be concerned about internal attackers have a much harder time. It's possible to come up with ways to combat relatively trivial attacks, but a really sophisticated attacker is likely to be able to overcome these obstacles. Even if the site is successful in preventing attackers from completing some of the attacks described above, there's always the incredibly trivial attack of just repeatedly sending DHCPDISCOVER packets to the server in hopes of chewing up so much computing power that the server is unable to respond to legitimate users. The good news is that attacks like this are relatively easy to isolate, since the the attacker must be present on the network for a long period of time in order for the attack to have any useful effect. A clever network administrator should be able to quickly track down the attacker and apply an appropriate LART.

It should be pointed out that a DHCP authentication protocol would not solve all Denial of Service attack problems. It does make it much harder for an attacker to exhaust the address space. What it does not do is to prevent an attacker from doing a resource exhaustion attack - in fact, it makes it easier. Cryptographically signing a message takes time - a lot of time. Verifying a signature likewise takes a lot of time. So an underpowered server that's perfectly adequate to the task of serving regular DHCP clients could well be brought to its knees by a clever attacker that just sends it huge numbers of signed messages for which the signature is not valid. The server has to verify the signature before it can discard the message, so a steady stream of these messages can prevent the server from properly serving legitimate clients, as well as causing resource starvation for other services that may be running on the same server machine.