NAC players prove Interop on experimental show net

Cisco, Juniper, Microsoft all jibe over access control in InteropLabs demos

You don’t often see Cisco, Juniper, and Microsoft working together. But that’s what happened last month as the superstars of NAC gathered in an industrial warehouse in Belmont, Calif., to prepare for InteropLabs (iLabs), the experimental portion of the Interop show network which is up and running in Las Vegas this weekNOTE: May 21st/cb.

Overall, the iLabs NAC testing showed three things:

• Cisco CNAC, Microsoft NAP and TCG/TNC all are mature enough to make interoperable NAC a candidate for any network.

• Levels of enforcement, ranging from go/no-go passage through VLANs, ACLs, filters and even firewalls, are easily available and — at least to some extent — interoperable across different vendors.

• There are a wide range of special client issues -- such as MAC authentication for VoIP phones and multiple systems trying to establish a secure connection through a single switch port—that IT managers will need to understand in order cleanly and securely integrate them into a NAC deployment.

The focus of this year’s iLabs NAC testing was -based authentication, with a captive portal for guest users. Although Cisco CNAC and Microsoft NAP both support many other types of authentication and access-control scenarios, the question of interoperability shows up mainly when using 802.1X for authentication and access control.

At the core of the network were NAC policy engines, including Cisco’s ACS, ID Engines’ Ignition, Juniper’s UAC, Microsoft's NPS and OSC’s Radiator. These systems connected to a single authentication database, a shared Active Directory server with user authentication information. To make it all work together, an additional server (OSC’s Radiator) was placed between all of the NAC policy-enforcement points (switches and wireless access points). This combination served as a RADIUS switch, routing the NAC authentication information between enforcement and policy engine based on the username.

Although no enterprise would actually plan a NAC deployment with multiple competing architectures in place, the RADIUS switch allowed the testing team to concentrate on working through common problems that network managers would have in rolling out NAC, without having to replicate everything three times.

With the RADIUS switch in place, the NAC framework demonstrated was a function of the username used to log on. For example, you could take a laptop loaded with the Cisco NAC client and attach it to any of the switches or wireless access points from Cisco, Enterasys, Extreme, HP or Trapeze in the iLabs network that were pointed at the RADIUS switch in the center.

By using a Cisco-specific username, the RADIUS switch routed the request to the Cisco ACS policy server. Likewise, you could take a different laptop loaded with the Juniper TNC NAC client and using a Juniper-specific username, connect to the same switch and participate in the TNC framework. As a third option, you could try a laptop with Vista running on it, and with the right username, you’d be using the Microsoft NAP framework.

The team’s “Introduction to NAC” testing – which quickly was nicknamed “Barbie NAC” – serves up a scenario showing perfect NAC conditions: Windows running on laptops, endpoint-security posture assessment and VLAN assignment for enforcement of policy.

This testing showed that most RADIUS servers can talk to most switches and send VLAN access-control information to the switches. The team did, however, run into problems that echoed the issues from last year’s testing, including that varying interpretations of the RADIUS standard caused some switches – namely, those from Extreme – not to work with the Radiator server.

Barbie NAC included a layer of endpoint-posture checking tools. In this case, not every posture checker claimed compatibility with every framework: Trend Micro was an exception, claiming its product works with both Microsoft NAP and Cisco CNAC. Where posture checkers claimed to work, the team had no interoperability issues.

LANDesk, Trend Micro and two Cisco agents all worked in the in the case of CNAC. Q1 Labs, Wave, Juniper and Patchlink all worked in the case of TCG/TNC. And Trend Micro and Microsoft agents worked as advertised in the case of Microsoft NAP.

The final test of the Barbie NAC scenarios assessed how guest users were shunted to the proper VLAN. Since no one expects guest users to have 802.1X NAC clients pre-configured on their laptops, the common assumption is that NAC deployments will need to detect guest users and send them to a captive portal for any required authentication or posture assessment.

The iLabs team set up three captive portal scenarios, including Cisco’s Cisco Clean Access, Juniper’s ScreenOS-based firewall, and Lockdown Networks’ Enforcer. Then, the testing showed that the devices in the “Introduction to NAC” part of the test, including switches from Cisco, Enterasys, Extreme, HP, and Trapeze, could detect non-802.1X users and properly route them to a guest VLAN.

The team also assessed in its Infrastructure NAC testing area how NAC components would interact with existing network infrastructure elements, such as switches, routers and firewalls, and would provide a spectrum of enforcement. For example, enterprise-class LAN switches usually have the ability to accept an access-control list or filter, which in turn would give finer granularity than VLAN assignment. The iLabs team built a stack of switches of a variety of makes and models to show that the NAC policy engines could send down ACLs and filter information to them.

The successful results here help put to rest widespread claims by several industry-analyst firms of incompatibility between different infrastructure elements and different NAC frameworks. Right now, clients and servers are firmly tied to one framework or another, but the infrastructure elements were all widely interoperable when using VLANs for enforcement. Yes, Cisco CNAC works just fine on someone else’s switches, if that’s what you want. And TCG/TNC works just as well on Cisco’s switches as well as most other vendors’ gear.

What didn’t work quite so well was pushing advanced enforcement controls into each device. The team discovered that every device it tested had support for fine-grained enforcement features within NAC, but every vendor had chosen a slightly different way to communicate those measures from the policy server to the switch.

The different interpretations meant the team wasn’t able to come up with a single configuration of the NAC policy servers that worked for all devices, but had to craft individual rules for each different switch or wireless access point. Defining the more granular controls was like making cheese: the same raw ingredients each time, but taking very different paths to what could be very different — or very similar — results.

In its endpoint NAC testing, the team focused on variant client scenarios. In this case, the team didn’t work as hard to prove interoperability, but spent most of its time showing different kinds of unusual client situations. For example, a real-world NAC deployment might have to deal with VoIP phones, rogue devices, printers and cameras. The team installed a Beacon appliance from Great Bay Software and linked it to Cisco ACS as an example of how MAC-based authentication for such devices as VoIP phones would work.

The team also assessed the issue of multiple devices showing up on a single 802.1X-controlled switch port. For example, in a conference room with only one switch port, multiple users might want to connect using a hub in the room that uplinks using that one switch port — a parameter not allowed by the 802.1X standard. Switch vendors have come up with a feature, often called multi-auth, which stretches the 802.1X standard to allow multiple devices to share a single port. The team demonstrated using hubs how switches from Cisco, Extreme, Enterasys and HP can support multi-auth and can be part of all three NAC frameworks.

NW Lab Alliance

Snyder is also a member of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry, each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to

< Return to iLabs testing introduction

Copyright © 2007 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022