Is DHCPSEC a thing?

Dynamic Host Configuration Protocol (DHCP) and the Domain Name System (DNS) are both foundational IP network services, enabling devices to connect to networks (via automated DHCP address and parameter assignment) and to navigate networks (via DNS name-to-IP resolution). DNSSEC refers to DNS security extensions, which is an Internet standard for signing and validating digital signatures on DNS response data. This process requires the signature-validating resolver to possess a trusted key which validates the response data signature, and by so doing, authenticates the data as published by the domain administrator and affirms the integrity of the data as matching that which was published. A single trusted key can be used to validate the entire Internet name space, thanks to the DNSSEC "chain of trust" mirroring the immanent DNS domain hierarchy up to the root zone. 

In the DHCP realm, there is no such hierarchy and a given mobile device could roam across multiple networks, each with its own independent DHCP services. Thus it would be impractical for each DHCP client to possess a trusted key for every possible DHCP server it may encounter. For this reason, the DHCP authentication mechanism defined in RFC 3118, which works similarly, requiring a priori knowledge of a given server's token (as opposed to a single trusted key), has seen few if any widespread implementations. Thus without a means to authenticate, the client must trust that its offered IP address is legitimate. Should this be of concern?

As with any risk analysis process, the initial step in formulating a security strategy, each organization must assess the relative risk of occurrence of such events and consequential outage costs against mitigation costs. While DHCP is a critical network service for initializing devices for operation on an IP network, DHCP is typically deployed within an organization to initialize internal or visitor devices. Nevertheless, insider threats and malware serve as possible attack origination points. 

If an attacker managed to establish a rogue DHCP server within your network, they could initialize DHCP clients perhaps with valid IP addresses but falsified supplemental information. For network boot clients, DHCP parameters could be supplied from the rogue DHCP server to load malware infested code. For general devices, forged  parameters could be supplied with the DNS servers option to direct devices to issue DNS queries to an attacker's DNS server. Presumably if an attacker can stand up a rogue DHCP server they could also configure a rogue DNS server even if you're diligent about applying ACLs to DNS queries traversing your Internet access points. A rogue DNS server might be configured to direct unsuspecting clients to forged sites to load malware or collect sensitive information for example.

If you are regularly monitoring your network for IP address occupancy and matching discovered addresses with known legitimate IP address assignments, you could easily detect such rogue devices, each of which require routable IP addresses themselves. Of course a smart attacker would disable ping responses, so your discovery mechanism must be broader to allow the option to check router ARP tables for recently active IP addresses as well.

You can also configure your legitimate DHCP and DNS servers to detect rogue activities. Configuring your DHCP servers as authoritative for configured subnets and pools enables the server to NAK IP lease requests or confirmations for which it did not offer. Investigation of NAK events can help with detection of rogue DHCP servers. From a DNS perspective, in addition to the ACLs on which legitimate servers can make queries within and outside of your network, configuring a DNS firewall feed can block queries to known malware domains and identify malware-infected devices. 

In addition to rogue DHCP servers, other risks to your DHCP services include server availability and integrity, address pool depletion, server operating system, API, and physical attacks, and denial of service. For each of these risks, you should assess the likelihood of the occurrence of each risk, impact of each occurrence, and alternative mitigation approaches and costs. Outage costs for DHCP could be severe, as any network device requiring a new or renewed DHCP lease could be left unserved and therefore unconnected. For this reason, most organizations mitigate server or network outage risks by deploying redundant DHCP servers. Other mitigation approaches to these various risk factors are outlined in our new Diamond IP white paper we'd be happy to share with you. Just contact me or our sales team for your copy. So while DHCPSEC isn't a thing (though it was actually proposed in a defunct Internet draft from 1997), securing DHCP merits careful consideration, as does securing other servers and protocols operating within your network.