"Salted" address pools for DHCPv6

Here is a simple change to the ISC DHCP server for IPv6 which provides protection from one type of host scanning attack.

1. Background

Anyone who administers externally-accessible networks is keenly aware of the continual flood of scans and probes from the outside, searching for vulnerable hosts. Often the first notification we get of a new vulnerability in some service is a spate of scans searching for it.

Host scans may roughly be divided into two groups: (1) those relying on some previous knowledge of the hosts, as for example from DNS information, or from previously recorded external connections; and (2) "blind" scans, which simply go through all the possible addresses in a subnet, trying to find hosts bound to them.

Of these, blind scans are potentially more problematic, both because they are simpler to undertake, and hence may easily be automated to run from "bots" (previously compromised hosts); and because they may uncover hosts of whose presence the local administrator may not even be aware. It is an unfortunate fact that unsecured hosts may be temporarily or "accidentally" attached to external networks without the local administrator's knowledge. Such rogue hosts often then become vectors of further attack into the local network.

Blind scans are possible in IPv4 because of the small subnet sizes - for example, a /24 provides only 254 usable addresses. On the other hand, IPv6's typical subnet size of 2^64 has the potential to render blind scans essentially infeasible for it.

1.1 Example: Stateless address autoconfiguration

Unfortunately, though, IPv6 addresses can often be fairly predictable. For example, addresses produced by IPv6 stateless address autoconfiguration generally consist simply of some fixed portions and the interface MAC address. While MAC addresses are 48 bits long, the amount of "entropy" (so to speak) they offer can be quite limited.

To explain this, let us look at MAC addresses in more detail. The first 24 bits are the Organizationally Unique Identifier (OUI), identifying the manufacturer or vendor of the interface. Currently, fewer than 15,000 OUIs have been assigned; at any one time, only a very few hundred (or even less) are in active use in manufacturing. Typically, organizations only buy systems from a limited number of vendors, so the number of OUIs seen in the MAC addresses of systems within an organization's networks is likely smaller still. For example, locally, even though we have a fairly diverse set of equipment, there are currently only 24 different OUIs visible on all our local networks combined.

The network interface controller (NIC)-specific portion (lower 24 bits) of the MAC address is of course more variable, but even here, in organizations which do bulk system purchases, consecutive or closely-bunched NIC addresses are quite likely. Again, looking at our local networks, there are many instances of addresses which match up to the last octet. The net result is the amount of variation in stateless autoconfigured addresses may differ little from that in IPv4 addresses, making blind scanning nearly as easy for IPv6 as it is for IPv4.

1.2 DHCPv6 pool address assignment

The addresses returned by stateless autoconfiguration are fixed by protocol definition (RFC 2464), but those returned by other methods need not be so constrained. In practice, however, they often are. In the case of the DHCP server from ISC, when allocating IPv6 addresses from a pool, it takes the client identifier, hashes it with MD5 (RFC 1321), and extracts the appropriate bits from the result to fill in the host part of the address. All the variability in the result, then, comes from the client identifier.

Client identifiers vary, but are typically either the MAC address alone (DUID-LL), or the MAC address combined with a timestamp (DUID-LLT). The former offers no more entropy than in the stateless autoconfiguration case. The latter adds some, but since the timestamp must be chosen before the system has been assigned an address, and hence before it can contact time servers and the like, it may amount to little but another fixed value.

1.3 Hashing and salting

As mentioned above, the ISC DHCPv6 server uses MD5 to hash the client identifier when generating addresses. While MD5 has known cryptographic weaknesses, this is not so important in the ISC implementation, since it uses MD5 simply as a way to get good spread on the address values it generates, and not with any attempt at concealment. In any case, the use of rainbow tables would render ineffective any hash as a concealment method in this application, no matter what its strength.

The notion of rainbow tables, however, does suggest an approach to improved concealment. Simple rainbow tables can be defeated by the addition of "salts" (randomly-generated, but fixed strings of bits) to the value being hashed. When the value being concealed has high entropy, the salt need not be secret. In this case, though, given the relatively low entropy of the client identifiers used as input, it is better to keep the salt secret as well, a technique referred to as key strengthening. That is the approach taken here. For each address pool, a salt string, either user-supplied or randomly generated, is hashed in with the client identifier; the result is then used to form addresses to be allocated from the pool.

With this effort toward concealment, though, the issue of MD5's relative cryptographic weakness comes back into play. While not "reversible" in any strong sense, it could well be that with enough data (returned addresses), especially in the case where the client identifiers are known or determinable, that some bits of the salt could be discerned. For now, this is addressed simply by having a relatively long salt (320 bits by default); ultimately, switching to another hashing method may be preferable.

2. Downloads and installation

The salted address pool code is provided as a patch to the current DHCP server. It is available in the following versions: The patch is to be applied from the top level source directory of the corresponding version in the usual way, e.g.:
$ cd dhcp-4.2.0-P2
$ patch -p0 < dhcp-4.2.0-P2-salt.patch
The patch adds a new configuration option, --enable-ipv6salt. To propagate this option to the configuration files and makefiles, do the following after applying the patch:
$ autoconf
$ automake
Depending on your version of the GNU autotools, you may need to run autoreconf before the above. All of this only need be done the first time after applying the patch. The tar.gz files above have already had this reconfiguration done.

Then, to enable the option, do the following:

$ ./configure --enable-ipv6salt
and build and install as usual.

The spec file provided with the RPM version handles all these configuration details. After installing the source RPM, build binaries the usual way:

$ cd SPECS
$ rpmbuild -bb dhcpsalt.spec
The binary RPMs will be in the RPMS/ directory (e.g., RPMS/i686 or RPMS/x86_64). They can be installed in the usual way (rpm -Uvh or yum localinstall).

3. Usage

The patched server supports the salt option for range declarations in the DHCPv6 server configuration file (typically /etc/dhcpd6.conf or /etc/dhcp/dhcpd6.conf). Here are some sample declarations:

subnet6 3ffe:501:c14:1100::/64 {
	# Use the whole /64 prefix for salted addresses;
	# let the server create a random salt.
	range6 3ffe:501:c14:1100::/64 salt;

subnet6 3ffe:501:c14:1101::/64 {
	# Like the above, but with a fixed salt.
	range6 3ffe:501:c14:1101::/64 salt cc1618ef669e086b8e1f4398aa28374fd1b8070b953393360a61fd02bbbb3efd601d8c22047088b2;
As the examples show, you can either let the server create a random salt at startup, or manually add one to the configuration file. In the latter case, as noted above, it is best to protect the contents of the dhcpd6.conf file in order to keep the salt value concealed.

With the salt option added, the server will then include the salt with the client identifier in creating the address it returns. All other aspects of the DHCPv6 server are identical to the unmodified version.

To return to the ANTD IPv6 software distribution main page:

Point Of Contact:

Last update: Mon Apr 18 2011.