Most network equipment vendors are ready to up the ante in terms of how their gear can control access in a NAC deployment.

In previous Interop Labs testing, we used virtual LAN assignment as the method for access control: putting specific types of users on different VLANs to control access. For example, one VLAN might be for employees, one for guests, one for VoIP phones, and, of course, one for quarantined users in need of remediation.

While VLAN assignment works fine in small networks, the collective experience of the Interop Labs team is that many networks can't use VLAN assignment. Sometimes the networks are too large or too distributed. Other times VLANs are already being used for a different purpose and can't be reused to set security boundaries. And, of course, some enterprise networks want finer-grained access control than VLANs can provide.

This year we pushed the NAC envelope with the decision that access control would be handled with a combination of access control lists (ACL) and VLANs. We used VLAN separation for guests and VoIP phones, areas where we had a clear, never-changing security policy. All internal users -- employees, whether they needed remediation or not -- were put on the same subnet and had their access controlled with ACLs : keeping quarantined users to their own part of the network and away from normal users, yet all on the same subnet and using the same address space.

Using the same VLAN and subnet for users in and out of remediation avoids one of the tricky parts of NAC -- telling an end system that it has moved from one subnet to another and needs to get another IP address. We found that most of the wireless and wired network equipment in the Interop Labs was able to use ACLs to control end-user policy.

The majority of the equipment, including LAN switches from Cisco and Enterasys, and wireless equipment from Aruba, Cisco, Trapeze and Xirrus, all work by having ACLs preloaded into the equipment by the network manager. Then, the NAC policy server simply pointed to an ACL when responding to the RADIUS authentication request and this ACL is then applied to the end user trying to gain access. For example, on our Aruba wireless equipment, we defined four access control lists to differentiate between employee, quarantined, and administrative users and devices such as printers and VoIP phones. When an employee connected, the NAC policy servers would send a specific RADIUS attribute with a predetermined value (such as 1, 2, 3, 4) for the ACL that should be applied to that user.

Our policy server vendors, including Avenda Systems, Cisco, Juniper, Microsoft, and Open System Consultants, all were able to configure their policy servers to work this way. We found that it wasn't necessarily simple, because there is no commonly accepted way to do this. For example, on Cisco switches, one type of RADIUS attribute (Filter-ID) was needed, while on Cisco's wireless equipment, a different RADIUS attribute (Airespace-ACL-Name) is needed.

We were able to configure the various policy servers so that they could work with all of the different pre-loaded ACL systems simultaneously. That was a welcome result, because it means that network managers with multiple types of network equipment -- or even different types from the same vendor -- will not have problems using this approach.