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:
Physical layer problems or device failure
Host TCP/IP stack errors or misconfiguration
Router / switch failure or misconfiguration
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:
Host 802.1x Supplicant Problems
Host / server certificate issues (for TLS based EAP types)
Congestion / availability of RADIUS server
Congestion / availability of posture server
Misconfiguration of posture policy rules on server or endpoint
MAC address or other device ID not in database
Username / password expiry
EAP-type / crypto protocol mismatch
VLAN assignment / DCHP release â€“ renew problem
Port ACL misconfiguration
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.