Introduction to Cisco Network Admission Control

Introduction

Time flies, and so do I. I apologize to anyone who has been looking for an article -- things have been a bit busy. This article got started a couple of months ago, and finally the planets aligned and I could finish it!

I've been doing a fair amount of Cisco Network Admission Control (NAC) work lately, including time in the lab, and checking site equipment and needs against the Cisco documentation. As interest in and need for NAC seems to be increasing, it must be a good topic to write about!  I think I've picked up on a couple of areas where people are running into issues, and hope I can help.

I see certain similarities here to what I'm encountering with wireless. Namely, you really have to examine your requirements before you buy gear. Since there are several choices, you need to examine what you're trying to do, and adjust your technology choices to match your strongest requirements.  

In the case of wireless, the common mistake seems to be jumping into the site survey, without knowing what you're  really trying to do. Yet your objectives affect the places and density of access points (APs), which is a starting point for the site survey. The two biggest things to look out for, since they can dramatically change the AP location requirements: Voice Over Wireless, and Location Appliance.  Other factors: lots of metal, stone, bodies, or other RF-absorbing materials. 

The somewhat similar aspect of NAC seems to be that we get sold on one  technology, then try to bend it to fit what we're trying to do. Or we find the subject complex enough to get confused about which products work with which other products. 

In this article, we'll back off from the details, in order to try to gain more perspective on requirements and capabilities. My other objective is to clarify for you the "moving parts" that  make up the two solutions. Subsequent articles may then provide more details about how to design for and deploy each of the two solutions.

What is Cisco NAC?

Cisco has been talking up Network Admission Control for quite some time now. The idea is about taking control over whether computers can connect to the network, and what they can access once they're on the network. One big part of NAC is authentication, and the other is what Cisco calls "posture assessment". That term means verifying a PC complies with security policy, such as being current on patches, has the latest anti-virus signatures, has the virus scanner running, etc. 

Cisco either caught the wave early or created a market, since other vendors including Microsoft are all pushing their own NAC approaches. Lately, I refer to Cisco NAC as "CNAC", to distinguish it from the other vendors' variants. I see Cisco as offering  the true control point -- the Microsoft approach has the PC Operating System "pull the plug", which means connectivity enforcement is up to the very PC that is to be controlled. Both approaches requires some degree of trust in what PC software is telling the policy enforcement side of things. 

Cisco and Microsoft have announced an interoperability plan, in a joint whitepaper listed in the Conclusion section below. 

Both want third party products to plug into their framework. Well, Cisco does -- I don't think Cisco wants to be in the PC patch and virus signature business. Microsoft is very much in those lines of business, which begs the question of how much they really want to cooperate with third party vendors. It doesn't require a lot of paranoia to see an echo of this in the fact that Microsoft Vista kernel security enhancements heavily impact the third party security vendors.  

Cisco NAC comes in two variants, Framework and Appliance. 

The Cisco NAC Framework ("CNACF") has been around for a while. Some dislike it for complexity. I personally have always thought it looked very scalable, with manageable complexity. It still looks that way to me, and now the supporting code seems to be a lot more mature. CNACF (NAC Framework) also looks like it is far less costly at any scale. Factors that add complexity: the plethora of PC drivers, patches, and security products that  might affect behavior, and the need for Cisco switches or access control points that support what you're trying to do. 

The Cisco NAC Appliance ("CNACA") is a family of related products, derived from the Perfigo acquisition, then renamed "Cisco Clean Access (CCA)". (FLASH: the product family has just  been renamed, with names starting with "Network Access".) The appliance approach has the virtue of being simpler, especially for small organizations or sites, although the appliance is rather costly. 

As the scale of the deployment increases, CNACF appears to be far less costly than CNACA. On the other hand, CNACF requires edge Cisco devices that support it, whereas CNACA can be used "in-band" with almost any edge or access device, including those from other vendors. CNACF also requires extensive testing with your PC hardware and drivers, your switches and Cisco IOS or CatOS code, etc. From that perspective, CNACA offers a somewhat more controlled environment, where you possibly don't need as much lab time to get it doing what you need. CNACA also works in-band with most vendors' equipment, and so is more suitable for a heterogenous (mixed vendor) environment. 

Cisco is claiming the two NAC products or technologies will be merged, with CNACA supporting CNACF. The evolutionary path to this nirvana is not at all clear to me, however. I probably need to go to NAC roadmap re-education camp. One hopes the vision will become clearer as new CNACA code releases come out.  

Overview of Cisco NAC Framework

Cisco NAC Framework requires two things; Cisco edge device support, and Cisco Secure Access Control Server (ACS) 4.x or later. The set of code and features supporting CNACF are now known as "NAC Framework 2.1". 

The Cisco edge device (switch, router, VPN Concentrator, etc.) must detect a new user or user logoff / login sequence somehow. It must also control user access to the network, somehow. There are three methods by which this can take place within Cisco NAC Framework:

• L2 IP
• L3 IP
• 802.1x

The 802.1x support is NAC Framework 2.0 / 2.1, typically used with wired connections to switches. The other two methods are more router-based. 

The computer that is attempting to access the network then needs to authenticate and have its posture validated. If this is done with the Operating System (OS) native 802.1x driver on a wired network, one is doing what Cisco calls "IBNS (Identity Based Network Services)". For CNACF, it is intended to be done by the Cisco Trust Agent (CTA), which is also available bundled into Cisco Secure Access (CSA), or Cisco Secure Services Client CSSC. CTA extends the vendor's driver and passes the PC posture assessment information to the Cisco Secure ACS server. 

Of the above three methods, only 802.1x handles authentication, via EAP / 802.1x. All three methods listed above use EAP to communicate  posture information to the Cisco edge device. 

The Cisco edge device in turn uses RADIUS to relay the information to Cisco Secure ACS, which in turn can use one or more back-end servers to complete the authentication and posture validation. Once the user's access is approved, a RADIUS message is sent back to the edge device, telling it to admit the user (open the port for access). Optional RADIUS attributes can provide settings for  the edge device, including dynamic VLAN assignment based  on user or group matching in ACS. These are known as RADIUS Authorization Components, or RACs. 

Here is a brief summary of the characteristics of the three authentication / posture validation (admission) methods: 

All permit downloadable ACLs (802.1x, only for the 6500 model switches). 

The approach taken varies with the admission method. L2 and L3 IP are based on NAC 1.0, which was implemented in routers. Once access is granted by an in-line device, ongoing access is maintained based on MAC or IP address, depending on whether the method is L2 or L3-based. 

With 802.1x, CNACF is tied to a standard for port-based admission control. Thus once a user is admitted, the port permits their traffic until there is a status change.

Another detail to consider is how well the admission method handles guest access, either a guest without a supporting driver, or guest with a supporting driver but no credentials on the network. One challenge we are currently seeing in the lab is that once the port is put into the "auth-fail" state, it does not periodically offer the user another chance to log in for quite some time, apparently tied to the standard 3600 second re-authentication interval. One really wants a separate timer in case of say taking 3 tries to notice your Caps Lock is on. One way to trigger re-authentication is to disconnect the Ethernet cable -- but that is rather inelegant, and not necessarily obvious to the end-user.  

Overview of Cisco NAC Appliance

The Cisco NAC Appliance (CNACA) relies on catching user traffic transiting the Appliance, at least initially. That means placement in your network in such a fashion that the user's traffic, or some early traffic, does pass through the Appliance. This can be done in various ways, which I hope to discuss in a future article dedicated to designing for use of the Cisco NAC Appliance. 

The basic idea is rather simple:

• If the CNACA is in-band, the user's traffic must pass through the Appliance, no problem. 
• If the NAC appliance is out-of-band, the user obtains an address by DHCP in an initial VLAN. Traffic from this range of source addresses is then forced through the NAC Appliance. When the user is authenticated and passes posture assessment, the user switch port is shifted to another VLAN and re-DHCP-ed. The new source address means the validated user traffic no longer has to pass through the CNACA. 

Here are the components of CNACA:

• Cisco Clean Access Agent (now Network Access Agent, NAA)
• Clean Access Appliance or Server (CAS), now Network Access Server (NAS)
• Clean Access Manager (CAM), now Network Access Manager (NAM, not to be confused with the Network Analysis Module NAM)

The way CNACA works is that initial traffic traps the user in a Registration VLAN or address space. If they lack the NAA agent, they will need to obtain it via web login. The NAA client on the user PC communicates status to the upstream NAS. The NAS then either grants them access to the network (role-based or Healthy VLAN), or puts them into the Quarantine VLAN. The actual mechanism details differ somewhat for In-Band (per-user ACLs) versus Out-of-Band (dynamic change of VLAN on user port). 

The slideware and documents discussing CNACA design all involve several variants of this. For some reason, I personally find the way the alternatives are presented confusing. To me, it all comes down to:

• Where is the NAS in the network? Is it being used in-band or out-of-band?
• Why does initial traffic have to go through the NAS? 
• What does the user PC think is the default gateway? 
• Is the NAS bridging (both interfaces = same subnet, possibly different VLANs) or routing (interfaces in different subnets)?

Conclusion

Do you agree with me? Do you see things differently? Let me know by email!

I have put some good links concerning NAC into the following table:

Stay tuned: I may write in more detail about NAC Framework and NAC Appliance in the next articles, especially the design / deployment side of things.  We've finished heavily revising the ARCH course for Cisco, and there are lots of ideas from that course that I'd like to write about., network design being my main interest and all.  Since ARCH covers CNACA in some detail, I might even be able to do both things at once. 

Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher my email address.