Get a head start on NAC

In the past two years a consensus architecture has emerged for providing policy-based control over access to networks. Led by the development of the Trusted Network Connect  (TNC) specifications, this architecture provides a framework for all standards-based NAC (network access control). It is also shared by the two major proprietary initiatives -- Cisco’s Network Admission Control and Microsoft’s Network Access Protection -- and many other third-party NAC solutions.

TNC, Cisco NAC, and Microsoft NAP apply different terms to the various components, but all three schemes employ a client on each end point that collects posture information (such as anti-virus and firewall configuration), a network enforcement point (typically an 802.1x-capable switch, VPN gateway, or firewall) that grants or denies access according to policy, and a server that validates authentication and posture information and passes policy information back to the enforcement point.

The network enforcement point performs the necessary adjustment to the end point’s access and, in some cases, alerts the end point to the decision as the end point is granted or denied access. Depending on policy, the end point could be granted access to everything on the network (similar to typical DHCP access today), or only to the Internet, or to some subset of available network resources.

Despite the common architecture, there are important differences among the three primary approaches. For example, whereas Microsoft’s end point-oriented NAP uses VLANs for enforcement, the more network-oriented approach of Cisco’s NAC allows for more granular access control through port-based ACLs (access control lists), but creates requirements for client-specific components such as an 802.1x supplicant. The TNC standards focus on providing the protocols to allow either approach to be interoperable, but do not have the installed-base strength of Microsoft Windows or Cisco networking equipment.

In implementing these three major approaches for Interop Las Vegas 2006, the InteropLab Network Access Control engineering team discovered that design of similar basic policies is straightforward in all three approaches. Although straightforward, however, the designs were not easily implemented in any of the approaches, requiring extensive expertise on our team plus the aid of the respective companies’ engineers. At this time, single-vendor solutions are the only real option for near-term deployment, and interoperability is still in the future. You’ll want to wait for standards to shake out before deploying enterprise-wide.

In the meantime, you can start preparing for NAC by defining your access control policies and creating a comprehensive authentication policy using 802.1x for both wired and wireless systems. To develop your access policies, consider the areas of your network to which NAC may grant access (such as general-purpose servers, specialty servers, Internet access, wireless network, and voice network) and the classifications of users who will receive each level of access (employees and guests, consultants and specialty staff, executives and human resources, and so on). You can also begin rolling out changes to the network (such as dividing server farms into multiple subnets) required to support your policy definitions.