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.
The second type of equipment required the ACL to actually be generated on the policy server and pushed to the switch at the moment the user wants to get on the network. In our interoperability testing, HP's wired and wireless equipment fell into this camp. Although this is a less popular approach, it offers a different way to manage security in a more dynamic fashion.
While our policy server vendors also could all interoperate with the HP equipment, we didn't find any policy server that actually dynamically generated the ACL. Juniper's UAC, which can dynamically generate ACLs for Juniper's own firewalls, won't do so for non-Juniper equipment. None of the other policy servers had any dynamic generation capability. So while the HP approach is theoretically more dynamic, it's a moot point until more NAC products support that feature.
The Force10 switch on the network work couldn't support ACLs which restricted us to VLAN assignment when testing NAC with it. We took advantage of this difference to show how alternative NAC technologies can be used to provide posture checking and authentication by integrating Cisco's NAC Appliance (formerly Cisco Clean Access) into our network to handle guest users on all switches, and posture checking for the Force10 users. This alternative approach may be important, as new Gigabit-capable wiring closet switches are being selected with only very basic management and no support for ACLs.
< Return to main NAC story: Interop Labs test results: Microsoft gets it NAC act together) >