Why Small and Medium Enterprises don’t use 802.1x

April 16, 2008 – 5:00 AM

With JJ blogging about 802.1x, I thought it would be timely to talk about why I think small and medium sized enterprises (SMEs) do not and probably never will deploy 802.1x for wired networks.

I make a point of meeting with customers whenever I can. Amongst the small and medium enterprise customers I’ve met, none have shown an interest in deploying 802.1x. The reason is simple – the problems solved by 802.1x do not justify the time and pain involved to setup and maintain it. Many of these customers would love to require everyone to identify themselves prior to joining the network, and want to keep risky machines off their network. They know this makes their networks healthier and easier to maintain. But I’ve yet to meet the customer willing to endure the complexity of 802.1x to get there.

There are two security functions that 802.1x brings to the table: authentication and access control. Authentication is pretty straightforward. Prior to a device gaining access to the network a user must authenticate. (There is also an option to do device authentication, but I’ll disregard that for this post). Access control is more involved. Generally, when people talk about using 802.1x to do access control they mean assigning a device to a particular VLAN depending on the “health” of the device connecting. In the case of Microsoft NAP, this health information is sent via the 802.1x protocol.

Multiple characteristics of 802.1x make it undesirable for most SME networks. First, setting up all the components for 802.1x is an exercise only for those with time, patience and MacGyver-like IT skills. The second and more significant obstacle to 802.1x is the unfriendly end user experience that results when problems occur.

The pain of 802.1x configuration

In typical 802.1x deployments, three separate components need to be configured properly: the client, the switch and the Radius server. Each of these components is usually supplied by a different vendor, and 802.1x introduces plenty of new terminology. 802.1x clients are called supplicants, switches are called authenticators, and 802.1x requires admins to take a crash course in protocols such as PEAP and EAP-TTLS with a helping of PKI.

With so many moving parts, when something goes awry it can be difficult to figure out why. Many hours are wasted reading logs from the switch and the Radius server trying to decipher which is configured improperly. Each switch vendor has its own unique way of setting up 802.1x, so this adventure often reoccurs with each new switch purchase. I have fount that the typical SME has at least three brands of switches in their wiring closet.

Once the switch is talking with the Radius server, there is the challenge of configuring a desktop client on hundreds of computers. Until an 802.1x client can properly authenticate, it can be difficult to determine which component in the chain is causing the problem. This problem repeats with each new 802.1x client. For example, switching between Mac OS X 10.4 and 10.5 involves a completely new 802.1x client configuration.

Keeping the bad guys out (and the good guys too)

Using 802.1x to quarantine user devices that fail health checks usually involves configuring VLANs. In turn, this means setting up redundant network resources such as DHCP servers for each VLAN. I have met very few SMEs that use VLANs for anything other than VoIP. VLANs are not rocket science and are well within the expertise of most IT teams, but a complex VLAN deployment is rare in the SME.

Another difficulty arises when guests and non-guests need to share the same port such as a conference room. As guests are unlikely to have an 802.1x supplicant configured properly, the optimal configuration would allow guests to connect without 802.1x while requiring 802.1x for employee access. With most switches this is not supported, especially if you are using VLANs for quarantine access.

Leaving users in the cold

As I mentioned above, the most significant issue for 802.1x deployments is the user experience when the supplicant cannot successfully communicate with the Radius server. If there are problems, the end result is often a lack of network access. Any chance of automated support over the network is lost. The frustrated user typically picks up the phone and calls the help desk (assuming the 802.1x outage didn’t take out their VoIP phone too). A great example is a user who simply forgets their password. With no IP address, there is no opportunity for an automated password reminder or support call via a web page.

Is there an alternative?

If you are wondering why any SME IT administrator with limited time and budget would deploy 802.1x for a wired network, you may appreciate Napera’s approach to building network products. Most SMEs demand a superior deployment and operating experience with their networking equipment. Until vendors can provide a simpler end-to-end 802.1x, don’t expect significant adoption in SME networks.

It is possible to accomplish the goals of securely controlling access to the network based on identity and health of a computer while delivering a great user experience for both the user and administrator. At Napera we chose to solve this problem by embedding more intelligence into the access switch. It was important to build a product that gave our SME customers tools that are easy to deploy and maintain while delivering the security features desired. We consider this core to ensuring a robust and healthy network. In a future post I will talk specifically about how we did this.

Source: Napera