I’ve covered DHCPv6 quite a bit in the past, e.g. in these two ‘A Deep Dive into DHCPv6’ blogposts, this one on RFC 6939, a few other contributions discussing it in some way (1, 2, 3) and a talk on ‘Secure & Reliable DHCPv6’ at the Troopers #TR15 IPv6 Security Summit (slides & video).
I also had a number of Twitter exchanges on DHCPv6, and one of the communication partners recently reached out to me with an interesting question. That person asked: “we consider avoiding DHCPv6 in our campus networks, but the security team insists on using it to be able to properly identify systems which act in a malicious way. what’s your opinion?” – In this post I’ll try to give a response.
Before I start with a technical discussion myself let me further add that several IPv6 deployment case studies mention all types of issues with DHCPv6, like this one from CERN, this one from Microsoft and this one from Deutsche Telekom. You might think about this for a second… (if this wasn’t clear, let me rephrase: in general DHCPv6 might be a piece of crap whose use should be carefully considered from a production [-readiness] perspective).
In ancient IPv4 times, in enterprise networks usually DHCP served one or several of the following functions:
- 1a) provisioning of dynamic addresses (in a more or less centralized manner).
- 1b) provisioning of other IP-related parameters/properties needed by clients (default gateway, DNS resolvers, NTP servers, others e.g. place to find firmware/boot image etc.)
- 2) simple access control (like ‘only MAC addresses registered in CMDB get an IP address from DHCP’, which is supposed to prevent unauthorized network access. I’ve once seen this in a large automotive ICS environment).
- 3) contribute to DFIR activities by providing mapping of MAC addresses to IP addresses found in log files, PCAPs etc.
Now let’s look at those from an IPv6 perspective.
- 1) For address provisioning DHCPv6 is no longer needed (hosts can do that on their own, via SLAAC), for the default gateway it can’t be used, and the vast majority of systems can get their DNS resolvers via RAs (option 25/RDNSS as of RFC 8106; see also Chris‘ post when Windows 10 eventually had it). That leaves distributing NTP servers which in turn some operating systems take into their own hands anyway (e.g. Windows).
- 2) That ‘simple access control’ approach could be considered a curiosity for specific environments, and some of you might be reminded of those times when a printer’s test page (containing a MAC address) was sufficient to get access to enterprise networks running complex & expensive ‘NAC’ solutions…
That leaves us with the ‘we need DHCP(v6) for DFIR contributions’ thing, which was at the core of the initial question. To evaluate (the need for) this we should keep in mind that during a host’s lifecycle on a network a lot of properties can potentially be observed at various points. These include
- the MAC address(es)
- IPv6 address(es)
- IPv4 address(es)
- mDNS-related information or similar (NetBIOS names)
- username, e.g. in authentication context
- X.509 certs (machine-/user-based) and namely the wealth of data they contain
- RADIUS-related information
The correlation of the first two ones (MAC address to IPv6 addresses) or, maybe even better, to a username might hence be easily inferable from other information which is observable/can-be-logged at some point of a host’s lifecycle, e.g. X.509 cert based info in the context of Wireless EAP protocol (EAP-TLS or PEAP in most enterprise networks).
Read: you might not need DHCPv6 logs for that but just have a look at other sources available anyway (Bryan ‘The Packet Master’ Fite once coined the term ‘latent capabilities’ for this approach). In the following I’ll provide some examples.
Probably the best known of such capabilities is the ‘ipv6 neighbor binding logging’ command from Cisco’s IP Snooping framework which is available on most of their (physical) enterprise level switches (please note that I’ve never been a big fan of most features of that tool set, due to it’s complexity and immaturity in [test] deployments I’ve seen, but that logging capability is definitely helpful).
tl;dr: instead of using DHCPv6 (bringing its own complexities and troubles) to solve that security requirement it might be a much better idea to analyze which data bits one might have available in an environment anyway and how to correlate them.
Assuming that some of you readers are still in the early stages of the IPv6 deployment in your organization you might even be able to file respective feature requests (e.g. ‘logging of IPv6 address(es) and MAC address of a client directly after its association in a wireless network’) to the vendor of your network gear.