DHCPv6 Fingerprinting, BYOD, and the 2013 RMv6TF Summit
Fun fact: Did you know that staple of classic crime show ("Book 'em, Danno!") evidence, the humble fingerprint is perhaps not reliably unique? Fortunately, the fingerprints I talk about below are unlikely to let any real killers go free. More on that in a moment.
In a little more than a month I'll be speaking at the Rocky Mountain IPv6 Task Force Summit in Denver Colorado. For my presentation this year, I wanted to talk about something IPv6-related that was both relevant to enterprise networks as well as perhaps more technically substantial: As part of the Infoblox IPv6 CoE, I've tended to talk a lot more about general strategy and trends related to IPv6 adoption but drilling down to examine a specific technical aspect of IPv6 certainly tweaks my interest based on my background as a network architect and engineer -- heck, it even makes me a bit wistful for running live networks (not that I miss getting paged at 3AM when a production router gives up the ghost!).
Infoblox delivers products that are designed to increase network control and solve business problems by, among other things, leveraging the DDI (DNS, DHCP, and IP Address Management) technology it has been key in innovating. IT network requirements around scale, performance, and security are perennial while other challenges crop up based on often unpredictable market and cultural trends. The "BYOD" (i.e., "bring your own device") phenomenon and associated challenges are a perfect example of the latter. The enormous success of smartphones and tablets and the demand for integration of such personal devices into the corporate network have led to a recognition by those tasked with managing those networks that new tools and solutions are needed to securely and effectively accomplish such integration. DHCP/DHCPv6 fingerprinting offers one component of potential BYOD solutions.
The basic idea of DHCP/DHCPv6 fingerprinting is simple: any client wishing to connect to a corporate network must in nearly all cases request addresses via DHCP/DHCPv6.The basic DHCP/DHCPv6 transaction for a given client device includes a number of uniquely ordered DHCP "option" fields. These options can be "read" by the server as a way to reliably characterize the device. Such characterization includes attributes like device type (e.g., iPhone4, Dell Laptop, iPad2, Samsung Note II, etc.), device OS (iOS6, Fedora 18, Windows 7 SP1, Android 4, Mac OS X 10.7.4, etc.).
Once devices are characterized, actions can be taken to allow, disallow, or conditionally allow network access (typically accomplished using captive portal-type functionality). Further, reports can be generated to learn what devices are connecting, or attempting to connect, to the network allowing BYOD policy to be refined and improved leading to better security practice and closer adherence to security policy.
Perhaps best of all, the DHCP fingerprinting process introduces no additional transactional overhead or burden on the client (unlike, say, nmap OS detection). Any additional load on the server would be due to onboard captive portal or reporting functionality. But here's the rub. DHCP (IPv4) fingerprinting works well because of the relative abundance of client fingerprints from freely available sources like Fingerbank (maintained by the open-source captive portal provider Packet Fence). Unfortunately, no thorough database yet exists exclusively for DHCPv6 fingerprints. This is probably okay for now but corporate networks are likely to evolve first via migration to a dual-stack address architecture followed eventually by the deprecation of IPv4 altogether. Thus the ability to characterize clients via DHCPv6 fingerprinting will soon be essential. The effort to build and consistently maintain a publicly available database of DHCPv6 fingerprints should begin now.
That's all for now. Future blog posts will explore these topics in more detail. Hope to see you in Denver at the summit and remember: Never leave any fingerprints at the scene (but if you do make sure your lawyer reads that first linked article!).