End-to-end NAC remains difficult

The InteropLabs NAC team built three demonstration areas, each devoted to a single architectural model: Trusted Computing Group's Trusted Network Connect (TCG-TNC), Microsoft's Network Access Protection (NAP) and Cisco's Network Admission Control (C-NAC). Our goal was to bring together interoperable products in each NAC silo and build a complete, end-to-end deployment. Overall, we did find interoperable products within each silo, but no NAC architecture is completely filled out with products at this time.

TNC, the simplest of our demonstration areas, came up in just a few hours, but NAP and C-NAC took several engineers and a very long weekend to get to a stable state. In both these tough cases, we would not have been as successful as we were without substantial onsite advice from vendor engineers who had been through the exercise in their own interoperability labs.

The world of NAC is full of all-in-one solutions from vendors that offer to solve some of a company's NAC problems most of the time. The whole point of InteropLabs is interoperability, and we looked for products from multiple vendors that plug into open architectures.

Unfortunately for the enterprise buyer, InteropLabs' focus throws a blinding spotlight on the lack of interoperable solutions in the NAC marketplace.

For example, Lockdown Networks came in to integrate its product into the NAP demonstration area. Lockdown offers a "complete," end-to-end NAC system, but it's complete only if you use its product and its strategy for everything from the server to the client and every enforcement technology in between.

We tried to bolt the Lockdown system into the NAP policy decision point (the place in the network where NAC policy decisions are made. But Lockdown quickly pulled back from full participation, but promised to come back at Interop for another grab at the NAP ring.

In other cases our implementation was stalled merely by the fact there were no vendors from which to choose. In the NAP silo, for example, not a single vendor came forward with client-posture data-collection and validation add-ins for the Microsoft client.

This may not be such a big surprise, seeing that we are a nine months out from the release of Vista/Longhorn - the version of Windows that will fully support NAP- but it is evidence of how new and untested this technology is. In the TNC test network, we had three integrity-measurement validators available - but only because engineers at Juniper Networks had written all three.

Trusted Computing Group's Trusted Network Connect

The TNC interoperability demonstration comprised Juniper's Odyssey client on the user's system and Juniper's Steel-Belted Radius (SBR) server as the policy decision point. This demo came up fast, but there's a caveat: Juniper has plans to move on from the products it brought to InteropLabs. Infranet, Juniper's original NAC architecture, is undergoing a radical restructuring as a result of the company's acquiring Funk Software last December.

In the InteropLabs testing, we heard about one of the main reasons Funk was so attractive to Juniper: a fully operable NAC product based on the TNC architecture. Juniper promised to bring Version 2.0 of its NAC product set to Interop, which will combine the client and server pieces from Funk with its own Infranet Controller policy management tools. This combination should help push Juniper's firewalls and SSL VPN devices as enforcement points inside the TNC realm.

In our InteropLabs silo, we built a network where the policy-enforcement point could be any of four -compliant switches from Cisco, Enterasys, Extreme and HP, or of two 802.1X-compliant wireless access points from Cisco and Enterasys.

To the network's policy decision point, we bolted in a Symantec integrity-measurement validator atop Juniper's SBR server. Juniper has built four TNC integrity-measurement validators for IBM/Tivoli, McAfee, PatchLink and Symantec. We were disconcerted to find that only Juniper is shipping a production TNC client. Of course, some of this scarcity is because of incomplete TNC specifications. Our hope is that by this time next year, we'll have more choice in clients.

Because all the switches and access points support RFC 3580 - assignment - we showed that clients moving in and out of compliance would be shunted off to production or quarantine VLANs. This was a fairly limited demonstration but showed one small aspect of NAC's promise. To extend our reach into more interesting areas to be addressed by NAC in the future, Mark Townsend, the Enterasys engineer on-site during HotStage, brought the Enterasys switch into the picture with finer-grained access controls - simple packet filters - in place.

This was an interesting experiment, because it illustrated the perils of mixing different switches in a NAC network. We discovered if we took advantage of the access-control list features of the Enterasys switch, several other switches quit working as NAC policy-enforcement points. We also saw disagreement between switches about the format of the attributes sent by the SBR server.

Fortunately, we had Juniper engineers Christian MacDonald and Jeff Reilly onsite to add the necessary magic to the SBR server to resolve this issue by creating separate RADIUS dictionaries for each device. Regardless of the happy ending, it is a harsh lesson on how brittle a NAC deployment can be and how much expertise is required to put all the pieces together in good working order.

In addition to the Juniper implementation, the TNC team had a parallel NAC-deployment effort going on that used open source tools. Chris Hessing from the University of Utah is one of the lead developers of Xsupplicant, the open source 802.1X supplicant for Linux systems. Hessing worked with Mike McCauley of Open Systems Consultants to add TNC support to Xsupplicant and Radiator, a commercial RADIUS server.

By the end of HotStage, Hessing had Xsupplicant on the access-requester, talking to Radiator on the policy-decision-point side using a Vernier EdgeWall gateway as the policy-enforcement point. The effort won't have much commercial impact (because enterprises rarely worry about the endpoint-security status of their Linux desktops), but it does represent an invaluable reference platform for software developers looking to test interoperability or just to see "how it all fits together."

Microsoft's Network Access Protection

Without a guided tour showing exactly what build to install and how to avoid the product's rough spots, no one but an experienced Microsoft engineer stands a chance at getting NAP running at this stage in the Vista/Longhorn beta cycle. Our team, led by Craig Watkins, one of Interop's most senior network engineers, spent the first four days of the HotStage downloading code from the Microsoft site, guessing which components to install and floundering over the Longhorn server and Vista client, to no avail. Then, thankfully, Microsoft sent down Chris Edson, one of NAP's test engineers, and things began to fall into place.

Although NAP is slated to integrate with many access methods, such as VPNs, our demonstration focused on using it in an 802.1X, wired and wireless LAN (WLAN) environment. We assembled switches from Cisco, Enterasys, Extreme, HP and Nortel, and access points from Aruba Wireless Networks, Cisco and HP as our policy-enforcement points. In the world of NAP, looking for integrity measurement collectors (software on the client that gather endpoint-security information) and integrity-measurement validators is not so easy.

Microsoft has an integrity-measurement collector-validator pair that evaluates Windows security settings, such as the state of its built-in firewall, and Windows Update. But no other collector and validator tools are ready to go at this early date in Vista/Longhorn's life cycle. The one closest to being ready is a tool from CA for eTrust Antivirus, because Microsoft uses the tool for its internal beta testing. We stuck with Microsoft's own collector and validator tools.

Our results were mixed, especially in the wireless arena, but this probably has more to do with the newness of Longhorn and Vista than with defects in the NAP software. For example, at one point the network policy server (NPS) on our Longhorn server (which is Microsoft's policy decision point) started recording errors in the log file rather than responding to NAP authentication requests, indicating that something had broken between the Longhorn TCP/IP stack and the NPS application.

A quick reboot solved the problem, but finding the suddenly errant server took time. Our experiences on the client side were also inconclusive. We had two identical laptops running Vista, and until the wee hours of the morning, one laptop worked very well, but the other wouldn't authenticate at all. The next day, mirabile dictu, everything was fine.

In another example of the newness of the platform raising warning flags about NAC, we can point to Vista not handling correctly when on a wireless network and flopping between quarantine and production networks, which required manual intervention. From the point of view of interoperability, however, NAP worked well with the wired and wireless devices we tested. We ran into the same RADIUS formatting-interoperability problem that we saw in TNC, but solved it using mechanisms built into Microsoft's NPS tool.

Cisco's Network Admission Control

Our C-NAC demonstration had mixed success: What we tried worked, but because of time constraints, we couldn't explore the breadth of the C-NAC architecture. With extensive onsite support from InfoExpress and LANDesk, the C-NAC team, led by Brett Thorson, a network scientist specializing in IPv6 security, built a C-NAC network with multiple integrity measurement collector and validator pairs. What Cisco's network lacks in openness at the network policy enforcement point layer - you can use only Cisco switches - it makes up for in the availability of third-party, interoperable tools to help in making the policy decision.

Cisco provided great hardware support but couldn't spare any staff to help with configuration. That left us fairly high and dry in getting things to work together properly in fairly short order. Cisco Trust Agent (CTA) client-side software uses strategies that depend on a network's topology to get information about endpoint-security assessment from the integrity-measurement collector to the validator.

We used its extensible authentication protocol ()-over-User Datagram Protocol () strategy with Cisco routers and switches as a first stab at the problem, with a plan to move to the EAP-over-802.1X option if time permitted. Because of time constraints, we couldn't attempt Cisco's clientless option, Cisco Clean Access (from the Perfigo acquisition) or its own host , Cisco Secure Access (from the Okena acquisition).

On the access-requester side, Cisco provides Cisco Trust Agent, talking to Cisco's Access Control Server (ACS) Version 4.0 Radius server on the policy-decision-point side.

We used a Cisco 3550 LAN switch as our policy enforcement point and brought InfoExpress' CyberGatekeeper and LANDesk's Management Suite in as integrity measurement collectors and validators, with a piece sitting on the clients and InfoExpress and LANDesk servers running within the policy decision point, talking to the Cisco ACS RADIUS server.

We observed that the integration between LANDesk and InfoExpress and Cisco's ACS wasn't going to work in all situations. In particular, we saw the client-side tools could use only the C-NAC path to get their integrity information to their servers. They had to have an unencumbered path on the network. This would cause issues if a company wanted to mix EAP-over-UDP and EAP-over-802.1X communication streams in its network. LANDesk was compatible only with the older versions of CTA (before Version 2.0), and the company's engineer onsite couldn't integrate his tools with the current version of the CTA client C-NAC tool.

Although the Cisco solution took longer to set up than we had expected, we found good interoperability between security-management tools sitting on top of CTA on the client side and on top of ACS on the server side. Making changes to the network was also easy.

For example, while it took a full day to get everything running with LANDesk, our first third-party vendor, adding InfoExpress's gear to the network once everything was stable took only a few hours work.

The bottom line on our overall NAC interoperability experience is that this is a market where there is not only the strong aroma but also the Limburger. We have three solid groups of vendors trying to solve a common problem and pushing forward as quickly as commercially possible.

While there is considerable chaos in the market, it's a safe bet to say that interoperable solutions are going to be available at year-end or the beginning of next year. It's too early to draw any conclusions about which strategy will work best for which types of networks, though, especially with powerhouse Cisco going head-to-head with TNC standards-based approach.

Snyder, a Network World Test Alliance partner, is a senior partner at Opus One in Tucson, Ariz. He can be reached at Joel.Snyder@opus1.com.