Those of you who’ve been in the IT industry for a long enough time have seen a remarkable evolution in connectivity. The evolution occurred so slowly that perhaps you missed it. Let’s back up to the early 1990s before IP really caught on in the enterprise space. Network engineers—myself included—were running around getting our Certified Netware Engineer (CNE) certifications and spending a lot of time building networks that ran IPX. IPX was a remarkably simple protocol that used a variation of the machine MAC address as the L3 IPX address. If this sounds a bit like IPv6, it should. Both derive the L3 address from the L2 address and make connectivity fairly easy, at least on a local level.
Skip forward to the mid 1990s and we were all enamored with the Internet and the possibilities of TCP/IP. Like me, perhaps you took part in the installation of your company’s first Internet firewall / bastion host. One thing you did, firewall or not, was configure static IP addresses. Lots of them…On every host that used TCP/IP. This is because DHCP didn’t materialize first as RFC 1531 until 1993 (It later became RFC 2131) and didn’t get deployed ubiquitously for a while after that. In that time between IPX and DHCP, configuring these static IP addresses was a pain. The chance of misconfiguration was high, and you tracked all your IP networks in an Excel spreadsheet. You knew that Bob’s IP address was 192.0.2.45 because you hard coded it as such just the other day. If you wanted to write a security policy for Bob, for all practical purposes 192.0.2.45 = Bob.
Static configuration was a particular pain for the network admins themselves who were constantly moving machines around the network for testing and troubleshooting. Since the Excel spreadsheet was invariably a bit out of date and your time on any IP network was limited, you tended to guess an address for the last octet of your machine’s IP address. Sometimes you guessed right, sometimes you guessed wrong and the gratuitous ARP caused your stack to shut down. Troubleshooting network connectivity had to do with making sure DNS was set right, the default gateway was set right, and you weren’t conflicting with another’s IP address. Of course the fact that TCP/IP stacks weren’t built into Windows until 1995 presented other problems that I won’t go into here.
The point of this trip down IT memory-lane is that since the deployment of DHCP we’ve been on a wave of more and more ubiquitous connectivity and less and less troubleshooting per connected station. You move your laptop to another segment, plug in, and get an address that works. IPsec VPNs gave us a small taste of problems as the filtering of ICMP Type 3 Code 4 (Fragmentation Needed and DF bit set) messages by overzealous firewall admins led to MTU issues from the IPsec headers. But for the most part, we’ve experienced a decade or so of fairly consistent connectivity. WLANs just extend the reach of the places you can connect and when combined with home broadband, hotel access, etc. we’ve been in IPv4 connectivity nirvana.
Now you may be wondering whom the villain is in this story and there isn’t one, save progress in general. This time it was progress in security. You see, this ubiquitous connectivity combined with nearly all IP connected stations being Internet connected created a breeding ground for network attacks of all sorts. There’s no need to rehash this except to say the last five years haven’t exactly been in the “Win†column for the good guys.
The latest wave of technology to combat the growth of Internet threats of all kinds is a technology type that I’ll call device posture assessment. Posture assessment products exist or are in development everywhere you look (Cisco, Juniper, Microsoft, TCG TNC, Symantec/Sygate, Consentry, etc.). The basic idea of these systems is to query the state of a connecting machine to see if it is an asset of the organization who runs the network, and if it is up to date with its anti-virus, patch levels, firewall policy, etc. These systems often make use of the RADIUS protocol and slightly less commonly the IEEE 802.1X port authentication standard. While these technologies offer great promise as they mature, they also have the unintended consequence of making troubleshooting basic network connectivity harder than I can ever remember it being. Let’s review the list of things that could be wrong in a normal vanilla DHCP enabled IP LAN:
I’m sure I’m missing a couple here but I think I’ve got the big ones. Now let’s look at the list of additional problems introduced in a RADIUS / 802.1X enabled posture checking system:
Companies who have been delivering these capabilities to the market have been focused on the basic functionality, which has left troubleshooting under developed. This reality has not escaped the notice of magazine reviews but the focus of these articles has been mostly evaluating the promise of the security capability and not taking a serious look at the realities of deploying this in production. Take another quick look at the list of potential problems above. Imagine a caller coming into your help desk complaining about something not working. Now imagine the steps you’d go through trying to figure out what might be wrong.
The moral of this story, if there indeed even is one, is that while these posture checking technologies offer great promise, we’re still in the land of the bleeding-edge with respect to production deployment. Organizations looking to deploy should first evaluate the robustness of their management infrastructure and the troubleshooting tools that the vendor will provide. Since most of these techniques make use of RADIUS and 802.1X perhaps trying to get those technologies deployed for simple user or device authentication provides a more tractable problem in the near term. As the posture offerings settle down and mature you’ll have set the stage by building out a robust AAA infrastructure to handle whatever standards (de facto or de jure) eventually emerge. The next couple years should prove quite interesting for network connectivity, I look forward to seeing how it all shakes out.
[...] I always had a sense that NAC–as narrowly defined under the endpoint health banner–might find the “trough of disillusionment” (as Gartner describes it) earlier than expected. With so much hype, so little standards, and so many vendors piling on with solutions it seems almost inevitable. Much of my talks with customers, at conferences, and in posts on this blog have encouraged caution in approaching this problem space so quickly–and so narrowly focused on endpoint health. [...]