Scenario-Based Identity Based Networking Services Deployments [Identity Based Networking Services]

Last updated: April 2009

Introduction

Cisco Identity Based Networking Services (IBNS) is an integrated solution comprised of several Cisco products that offer authentication and identity-based access control to secure network connectivity and resources. With Cisco IBNS, you can facilitate greater security and enjoy cost-effective management of changes throughout your organization. Having a secure IBNS framework in place helps enterprises better manage employee mobility, reduce network access expenses, and boost overall productivity, while lowering operating costs.

To simplify the process of deploying IBNS, this document provides a high-level description of a phased, scenario-based deployment strategy that can be used to roll out IBNS with minimal impact to end users. The scenarios described in this document include Monitor Mode, Low Impact Mode and High Security Mode. Each scenario leverages specific combinations of features and configurations to satisfy a particular set of use cases. By starting with these scenarios, you can follow a well-defined and well-understood blueprint for implementing IBNS. Instead of starting "from scratch," you can follow the guidelines for a particular deployment scenario and then, if necessary, customize it to suit your network requirements.

Before describing the scenarios themselves, this document will discuss important steps in the planning process and describe implementation details that will form the basis of the scenarios that follow. Once you've reviewed these sections, you will be able to understand how and why each of the deployment scenarios operates the way that it does.

Planning a Deployment

In its simplest formulation, IBNS enables you to grant customized access to the network based on a person's (or device's) identity. Therefore, when planning an IBNS deployment, the first and most fundamental question that you must answer is this: Who gets what access?

To answer this question, start with your corporate security policy. A well-defined security policy should provide broad guidelines for who can access which corporate resources under what conditions. Next, determine the categories of users and devices that connect to your network.

TIP: Keep It Simple

For initial deployments, use broad categories for users and devices (ie: employee, managed asset, unknown asset). The simpler your policy, the smoother and more successful your initial deployment will be. Once basic access control has been successfully deployed, you can easily add more granular groups and policies if you want to evolve to a more highly differentiated model of access control.

Once you have determined the high-level categories of users and devices on your network, use the guidelines from your security policy to map each category to a network access level. The example in the following table, while very simple, has been used as the basis for many successful deployments:

Category	Network Access Level
Employee	Full Access (Intranet & Internet)
Managed Asset	Full Access (Intranet & Internet)
Unknown Device	Connectivity services (DHCP, DNS) only
Pre-Authentication	Connectivity services only
Failed Authentication	Connectivity services only

The last two categories, Pre-Authentication and Failed Authentication, deserve a little more explanation. "Pre-Authentication" refers to the level of access that a user or device will get before its identity has been determined. Under a very strict security policy, this level could be "no access." Alternatively, it could be limited to a small set of services (such as DHCP, DNS, TFTP) that would allow devices that depend on immediate network access (ie: a device that needs to download its operating system or a device that needs enough connectivity to perform a web-authentication) to function normally even before its identity has been established.

"Failed Authentication" refers to the level of access that a user or device will get if it fails to provide valid credentials. Again, under a very strict security policy, this could be "no access" (this is the default). Be aware, that if your policy is "no access", you must provide a manual process by which legitimate users can remediate their credentials (ie: renew an expired password). An example of a manual process might be to have employees take their laptops to a physically secure location where an IT administrator can update the credential. Such a process can be resource-intensive, both in terms of end-user education and IT support. Therefore, if your security policy permits, you might want to consider modifying the default "Failed Authentication" access to permit a small set of services that would allow a device to automatically update or request credentials.

Once you have identified the categories of users and devices on the network and determined the appropriate level of network access for each category, it is time to move on to some lower-level questions and issues that will determine how you will implement the policy you've defined.

Implementation Details

To implement your network access policy, it is necessary to define the following:

• Who is connecting to the network? What methods will be used to identify them as they come onto the network? What kinds of credentials will I accept as valid forms of identification?

• How will network access be controlled? Will VLANs be used to isolate traffic? Will ACLs be used to isolate traffic?

• How are users connected to the network? Are they connected directly to the access switchport? Via an IP Telephone? Are they connecting via a host operating system (ie: from a virtual machine)?

The following sections discuss these questions in more detail and identify configuration elements that are required to implement the solution that suits your network.

Who is Connecting?

Authentication is the process by which the network establishes the identity of devices and users that are attempting to connect. To be able to authenticate users and devices, you must first decide what kind of credentials you will accept as valid identification. Ideally, you would use strong forms of identification such as digital certificates or properly encrypted usernames and passwords. A much weaker form of identification would be the MAC address of the connecting device.

The type of credentials that you will accept will determine what method you will use to validate those credentials. The authentication method determines how a device submits its credentials to the network. 802.1X is an IEEE standard that defines a process by which a device can submit strong credentials like digital certificates and passwords using a client (called a "supplicant"). 802.1X is a strong authentication method and is preferred in all cases where the device can support the required client. The specific details of which credentials are accepted and how they are submitted are determined by what is known as the EAP method. Common EAP methods include PEAP-MSCHAPv2 (for username/password credentials) and EAP-TLS (for certificate-based credentials).

For devices that cannot support the required 802.1X client, a supplementary form of authentication must be used. Mac-Authentication Bypass (MAB) is a secondary authentication method in which the access switch detects the device's MAC address and submits it as a form of identification.

Whatever kind of credential you choose to accept, you must be able to validate it. This means that you must have a database of allowed devices and their credentials and (for certificate-based authentication) a certificate chain of trust. If you are going to do authentication based on MAC address, you need to have a database of valid MAC addresses to validate against.

TIP: Leverage existing identity databases

In most cases, there is no need to build a credential database from scratch. For example, many organizations already possess a database of valid users and computers in the form of Microsoft Active Directory. Some organizations also maintain databases with the MAC addresses of corporate assets. Very often, these databases can be re-used for 802.1X and MAB. Using these databases will greatly simplify your 802.1X deployment.

Once you've determined the credential types, authentication methods and credential databases that you will use, you will be able to fill out a simple table such as the following example:

Authentication Method	Credential Type	Credential Database
802.1X	Username/Password*	Active Directory
MAB	MAC Address	LDAP database

* The credential type will depend on what EAP method you choose to implement. Username/password can be used for PEAP-MSCHAPv2 and others.

What Level of Authorization?

Authorization is the process by which an endpoint is granted a certain level of access to the network. In an identity-enabled network, network access should correspond to the authenticated identity of the endpoint. But an endpoint's network access can also depend on where the endpoint is in the authentication process. When planning a deployment, consider what access the endpoint should have at each of these stages:

1. Pre-authentication

2. Successful authentication

3. Failed authentication

The authorization options available in each stage are discussed in detail below.

Pre-Authentication

By default, endpoints are not authorized for network access prior to authentication. Before a device has successfully authenticated via 802.1X or MAB, the port allows no traffic other than that required for authentication. Access to the port is effectively "Closed." While very secure, this method of access control can cause problems for devices that need network access before they authenticate (ie: PXE devices that boot on an OS from the network) or devices that are sensitive to delays in network access that may result from the authentication process.

As an alternative, it is possible to configure Cisco switches for two other levels of Pre-Authentication authorization: Open Access and Selectively Open Access.

Open Access is the opposite of the default Pre-Authentication authorization. With Open Access, all traffic is allowed through the port before authentication. While Open Access is obviously not an effective way to enforce network access control, it does have an important role in initial stages of deploying 802.1X. This will be discussed later in the section on the Monitor Mode deployment scenario.

Selectively Open Access represents a middle-ground between the default Closed access and Open access. With Selectively Open Access, you can use a default port Access-Lists (ACLs) to permit or deny specific traffic (ie: permit TFTP and DHCP traffic to allow PXE devices to boot before they authenticate).

Pre-Authentication Access Level	Implementation
No Access	Default - "Closed"
Open Access	"Open"
Selectively Open Access	"Open" with port ACL

Be aware the choices that you make regarding Pre-Authentication access will influence your choices for post-authentication and failed-authentication access. This will be discussed more in the following sections.

Successful Authentication

After a successful authentication, the port is, by default, opened up completely and all traffic is allowed in the configured native VLAN of the port. This is a simple, binary decision: anyone who successfully authenticates by any method is granted full access. To achieve differentiated access based on the identity of the authenticated user or device, it is necessary to use dynamic access control with VLANs and/or ACLs.

When post-authentication access is implemented with VLANs, the switch dynamically assigns a VLAN to a port based on the identity of the device that authenticated. Engineers could be assigned the ENG VLAN while accountants could be assigned the FINANCE VLAN. While this form of dynamic authorization is a powerful tool for differentiating access for different user groups, it comes at a cost. Supporting multiple VLANs on every switch may require changes to the network architecture and addressing scheme. In addition, VLANs isolate traffic at Layer 2 in the OSI stack, so dynamic VLAN assignment by itself cannot restrict access to specific subnets (at Layer 3) or applications (Layer 4 and above). However, dynamic VLAN assignment does provide the foundation for virtualizing IT resources using Network Virtualization Solutions.

When Successful Authentication authorization is implemented with ACLs, the switch dynamically assigns an ACL to a port based on the identity of the device that authenticated. Engineers could be assigned an ACL that permits access to engineering subnets and applications while accountants get a different ACL. While ACLs do not achieve the same level of logical isolation that VLANs provide, dynamic ACLs can be deployed without changing the existing network architecture and addressing schemes. On the other hand, care must be taken to ensure that the dynamic ACLs do not overwhelm the TCAM capacity of the access switch. Well-summarized networks and good network design are essential to the creation of short but effective ACLs.

When deciding between dynamic VLANs and dynamic ACLs, another factor to consider is the form of Pre-Authentication authorization that you have chosen to implement. Dynamic ACLs work well with any kind of Pre-Authentication authorization. Dynamic VLAN assignment, on the other hand, does not typically work well with Open or Selectively Open Pre-Authentication authorization.¹

The different kinds of authorization available after successful Authentication and the deployment considerations for each method are summarized below:

Post-Authentication Authorization Method	Impact to Network Architecture	TCAM impact	Compatible Pre-Authentication Methods	Notes
Default "Open"	Minimal	None	Closed	May be sufficient for simple deployments or as a first step for more complex deployments.
Dynamic VLAN	Significant	None	Closed	Required for network virtualization. Provides logical isolation of traffic at L2.
Dynamic ACL	Minimal	Significant	All	Does not support network virtualization. Provides access control at L3 & L4.

Failed Authentication

After a failed authentication, the port is, by default, left in the same state as it was before authentication was attempted. If the port was in the default Closed state before authentication, it will remain closed after a failed authentication. If the port was in a Selectively Open state before authentication, it will remain that way: open in the statically configured VLAN and subject to the default port ACL.

Since failed authentications revert to the pre-authentication authorization, it is necessary to decide whether your chosen pre-authentication network access is adequate for endpoints that fail authentication. If not, it may be necessary to modify your pre-authentication network authorization policy or to utilize some of the mechanisms available for modifying the default Failed Authentication network access levels. Specific mechanisms are discussed in the deployment scenarios below.

How Connected?

Hosts connect to the access layer in all sorts of ways. The simplest connection is a direct point-to-point connection of one host to one switch port. In IBNS deployments, this is sometimes referred to as "single host mode." Single host mode is the most secure form of connection and the default mode on Cisco switches enabled for 802.1X and MAB. A switch running 802.1X in single host mode will only allow one device at a time on that port. If another device appears on the port, the switch shuts down the port as a security precaution. Because only one device is allowed to connect to the port, there is no possibility of another device snooping the traffic from the authenticated device. A port in single-host mode effectively prevents casual port-piggybacking.

Although it is the most secure mode, single host mode is not always sufficient. One common exception to the point-to-point connection assumption is IP Telephony. In IP Telephony deployments, two devices are often connected to the same switch port: the phone itself and a PC behind the phone. In this case, a new host mode, "multi-domain," is required. With multi-domain host mode, the switch allows two devices to authenticate and gain access to the network: one voice device in the voice VLAN and one data device in the data VLAN.

Some deployments include devices that include multiple virtual machines even though there is physically only one connected device. Cisco switches support a third host mode, "multi-auth," that allows each virtual machine to access the port after being authenticated. The multi-auth host mode is a superset of multi-domain host mode, meaning that the multi-auth host mode allows one voice device in the voice VLAN and any number of data devices in the data VLAN.

When planning your access control strategy, examine your network and determine how your hosts are connecting to the network. This will help you determine the most appropriate host mode to configure on the switch.

TIP: Use the most restrictive host mode that suits your network

802.1X is most effective when it is most restrictive. If you don't have IP Telephony, don't configure multi-domain host mode. If you don't have virtual machines with unique MAC addresses on the same physical host, don't configure multi-auth host mode. If possible, use the same host-mode throughout your network. Using a standardized configuration will minimize operational costs.

The host modes are summarized in the table below:

With this Endpoint...	...Use this Host Mode
Point-to-point only (PC, printer, etc.)	Single-host
IP Telephony	Multi-domain
Virtual Machines (with or without IP Telephony)	Multi-auth

Deployment Scenarios

Once you've determined how you will authenticate users and devices, what network access they will be granted before and after authentication, and how devices will be allowed to connect to the network, the final step is putting all the answers together in a deployment scenario. The rest of this document will look at three generic deployment scenarios that can be rolled out as a three-phase deployment (or two-phase, depending on your ultimate design goals). IBNS deployments are often most successful when they are implemented in phases, gradually adding in network access restrictions to minimize impact to end users.

The three scenarios to be discussed are: Monitor Mode, Low Impact Mode, and High Security Mode.

Monitor Mode

Have you ever left the house and forgotten to lock the front door? It can ruin your day, especially if you realize it as you're pulling up to the office after a grueling commute. But suppose you've installed a security web-cam over the front door. You can bring up a browser and monitor the house for intruders. You may not be able to lock the door remotely, but you can at least see if anyone tries to break in.

Authenticating someone's identity without enforcing some form of authorization is like having an unlocked door with a web-cam: you don't physically prevent anyone from gaining access, but you can see who goes in and out. This kind of visibility is a non-trivial asset. Having visibility onto the network gives you insight into who is getting access, who has an operational 802.1X client, who is already known to existing identity stores, who has credentials, etc. As a side benefit, some intruders may be deterred by the simple knowledge that someone is watching. These, in essence, are the goals of Monitor Mode.

When you deploy IBNS in Monitor Mode, you enable authentication (802.1X and MAB) without enforcing any kind of authorization. There is no impact to users or endpoints of any kind: they continue to get exactly the same kind of network access that they did before you deployed IBNS. The authorization level Pre-Authentication is the same as after Successful Authentications and Failed Authentications: completely open. In the background, however, the network is querying each endpoint as it connects and validating its credentials. By examining the authentication and accounting records (at the ACS server), it is possible to determine the following information:

Endpoints on Your Network	How Determined
All endpoints/users with 802.1X clients and valid credentials	Passed 802.1X Authentication Records
All endpoints/users with 802.1X clients and invalid credentials	Failed 802.1X Authentication Records
All endpoints without 802.1X clients and known MAC addresses	Passed MAB Authentication Records
All endpoints without 802.1X clients and known MAC addresses	Failed MAB Authentication Records
Ports with multiple connected devices	Multiple Authentications Records for the same port on same switch.

Combining the information in authentication and accounting records results in very detailed knowledge of each endpoint that connects to your network: username, IP address, MAC address, port and switch where connected, time of connection, etc. Even more information about endpoint type (ie: IP Phone vs. Windows PC) can be gleaned in Monitor Mode by using active or passive profiling tools such as Cisco NAC Profiler.

Implementing Monitor Mode

Monitor Mode requires configuration on all components in the network: the ACS server, 802.1X-capable endpoints, and the Cisco switch.

The ACS server should be fully configured for 802.1X and MAB authentication. The following checklist offers a summary of the tasks that will be required to configure the AAA server:

1. Configure the ACS server to accept RADIUS authentication requests from all switches that are part of the IBNS deployment. Make a note of the RADIUS shared secret (also called the "secret key") configured for each switch.

2. Configure the ACS server to communicate with all available identity credential stores that will be used to validate identities (ie: Active Directory, asset databases with known MAC addresses, etc.).

3. Configure the ACS server to process 802.1X and MAB authentications using the identity credential stores. For 802.1X, configure all the EAP types you want to support. For each EAP type, ensure that you have the proper pre-requisites for that EAP type on the server (ie: PEAP and TLS both require a root CA certificate and a server certificate on the ACS).

4. Ensure that all dynamic authorization (dynamic VLAN assignment, dynamic ACL assignment) is DISABLED on the ACS server. Any form of dynamic authorization will impact end users and undermine the Monitor Mode's goal of end user transparency.

All endpoints that are capable of 802.1X should be supplied with a pre-configured supplicant (such as the Cisco Secure Service Client (SSC) or the native operating system supplicant) as well as any additional credentials or certificates that may be required by the EAP types you support (ie: PEAP and TLS both require a root CA certificate on the client; TLS requires a client certificate as well).

The switches should be fully configured for 802.1X and MAB authentication. The following checklist summarizes configuration tasks on the switch:

1. First validate that your switch is in normal operating mode. All endpoints, including phones, should have full connectivity.

2. Globally enable AAA and configure the switch to send 802.1X authentication requests to your AAA server. Be sure the RADIUS secret key that you configure on the switch matches what you configured in the AAA server.

3. Globally enable 802.1X.

4. On each access port, enable open access authentication and multi-auth host-mode. Without multi-auth, the switch will run in single host mode and disable any ports with multiple devices (including phones). Monitor Mode requires multi-auth host-mode in order to be transparent to end users.

5. On each access port, enable 802.1X and MAB.

6. Verify that all endpoints have exactly the same access as before authentication was enabled on the switch.

Monitor Mode: Next Steps

After completing the configuration steps, your network will immediately begin authenticating users and devices and you will have visibility into who and what is connecting to your network. You will know which endpoints (PC, Printer, Camera, etc.) are connecting to your network, where they connected, and whether they are 802.1X capable or not, as well as whether they have valid credentials. Additionally, you will know if the endpoints are known valid MAC addresses via the failed MAB attempts.

One primary benefit of Monitor Mode is that it enables you to pro-actively address any issues that would impact end users once access control is enabled. Here is a list of things you should do before moving to the next phase of deployment:

To Do	Key Issue	Remediation
Analyze 802.1X failures	Are these valid devices or users that should be allowed access but are failing 802.1X?	Update credentials for valid devices and users so they will pass 802.1X.
Analyze MAB success	Are there any devices doing MAB that should be capable of 802.1X?	Update those devices with supplicants and credentials, so they can authenticate using 802.1X.
Analyze MAB failures	Are there managed assets that should be allowed access to the network but are failing MAB?	Update your asset database with these MAC addresses.
Analyze ports that have multiple devices on them	Are these rogue hubs or valid virtual machines?	Remove rogue devices. Note ports that may legitimately require support for multiple hosts per port.

Once you've addressed all the issues uncovered by deploying IBNS in Monitor Mode, it's time to move on to deploying identity-based access control. The next two scenarios describe common ways to deploy access control. Many customers will chose to implement Low Impact Mode only. Others may start with Low Impact Mode to help assess the impact of access control to end users and then later move on to High Security Mode. Other customers may move straight from Monitor Mode to High Security Mode. The rest of this paper will help you understand the access-control deployment scenario(s) and sequence that's right for your network.

Low Impact Mode

Low Impact Mode allows you to incrementally increase the level of port-based access control without impacting the existing network infrastructure. Low Impact Mode does not require the addition of any new VLANs nor does it impact your existing network addressing scheme. With Low Impact Mode, you can add as little or as much access control as you want.

Low Impact Mode builds on top of Monitor Mode. In Monitor Mode, the Pre-Authentication authorization level was completely open. In Low Impact Mode, the Pre-Authentication level is selectively open. The difference is that Low Impact Mode adds an ingress port ACL that specifies exactly what traffic will be allowed before authentication. This ACL can be as restrictive or permissive as your network requires.

TIP: Use the ingress ACL to permit traffic that might be sensitive to authentication-related delays

If your goal is to enable PXE machines to boot before authentication completes, you could permit DHCP, DNS, and TFTP in your ingress ACL.

In Low Impact Mode, a successful authentication causes the switch to download a dynamic ACL (dACL) that is applied on top of the ingress port ACL. The contents of the dACL will be determined by the identity of the user or device that authenticated. In a simple deployment, an employee or managed asset that authenticates successfully could receive a "permit ip any any" dACL that fully opens up the port. More complex deployments could assign different ACLs based on different classes of employee. For example, engineers might be assigned a dACL that permitted all engineering related subnets, whereas accountants could be assigned a different dACL that denied access to engineering subnets, but permitted all other access.

TIP: Both ingress ACLs and dACLs can be Layer 3 or Layer 4

Using ACLs allows you to permit or deny access to particular hosts, entire subnets and/or specific applications.

Whatever the contents of the dACL, the switch will substitute the source address of each access-list element with the source address of the authenticated host, ensuring that only that host is allowed by the dACL.

Devices that fail authentication (via 802.1X or MAB) will continue to have their access limited by the ingress port ACL.

Low Impact Mode: Deployment Considerations

Because Low Impact Mode can be deployed with little or no change to the existing campus network design, it is attractive to customers looking to deploy access control without altering the existing VLAN infrastructure or IP addressing scheme. Some customers may not want the additional IT overhead needed to add and support additional VLANs; other customers may not control the VLAN infrastructure at all (ie: at a branch office where the service provider owns the routers and has implemented Multiprotocol Label Switching (MPLS)). In the latter case, ACL-based enforcement is the only choice for port-based access control. There are, however, deployment considerations that should be understood prior to deploying this model of access control.

First, the current implementation of dACLs requires a pre-configured static port ACL on every access port that may download an ACL. If the switch attempts to apply a dACL to a port without a pre-existing port ACL, the authorization will fail and users will not be able to gain access (even if they presented valid credentials and passed authentication).

Second, since the static port ACL is a port-based ACL, it applies to both the data VLAN and, if present, the voice VLAN. Since the switch performs source address substitution on the dACL, traffic from the phone will not be permitted by a dACL downloaded by a data device authenticating behind the phone. This means that both the phone and any devices behind the phone must authenticate individually and download their own dACL. This means that the host mode on the port must be multi-domain.

Third, Cisco switches use Ternary Content Addressable Memory (TCAM) to support wire-rate ACL enforcement. TCAM is a limited resource which varies by platform. If the TCAM is exhausted, switching performance can be degraded. Therefore, it is important to verify that your access switches have sufficient TCAM to support the number and length of ACLs (static and dynamic) that your deployment will require.

Fourth, dynamic (or "downloadable") ACLs extend the standard RADIUS protocol in order to optimize the downloading process and support ACLs of arbitrary size. Use the Cisco ACS server as your AAA server to support downloadable ACLs.

Fifth, because the switch performs source substitution on the source address of the dynamic ACL, the switch does not enforce the dACL until it learns the source address of the authenticated host. IP address learning is enabled by the IP Device Tracking feature on the switch.

Sixth, when designing your ingress port ACL, be aware that this ACL will restrict access before authentication and after failed authentications. You should design the ingress port ACL with this in mind. For example, if you want employees that fail 802.1X because of an expired certificate to be able to download a new certificate, you should consider allowing access to the CA server in the ingress ACL. Or, if you want a contractor that fails 802.1X or MAB to be able to access the Internet or VPN to a home network, you should also allow that traffic in the ingress port ACL.

Implementing Low Impact Mode

Before transitioning to Low Impact Mode from Monitor Mode, you should ensure that all endpoints that should authenticate can authenticate. All identity store databases should be up to date and online.

To enable a smooth transition from Monitor Mode, configure the switch first. To ensure that devices continue to get access during the transition, follow these steps:

1. Configure an ACL on the switch, called "DEFAULT-ACCESS" in the rest of this document, that is completely open ("permit ip any any").²

2. Configure the switch to accept authorization instructions from the AAA server

3. Apply the PERMIT-ANY ACL to all access ports on the switch.

4. Enable IP Device Tracking

At this point, network access levels should not have changed from Monitor Mode (since the port ACL "PERMIT-ANY" permits all traffic).

On the ACS server, follow these steps:

1. Configure downloadable ACLs to match your policy. This could be as simple as a single dACL ("permit ip any any" for all users and devices that authenticate) or it could be multiple dACLs if you want to differentiate between different classes of users or devices.

2. Configure your ACS to apply the appropriate dACL to each class of users and devices (including phones)

3. For phones, also ensure that the ACS is configured to send down the appropriate permission to allow the phone to access the voice VLAN.³

At this point, endpoints that connect to the network should start downloading the appropriate dACL based on their authenticated identity. Verify that the switch is successfully downloading and applying the dACLs.

The final step is to replace the PERMIT-ANY port ACL on the switch with a port ACL that restricts traffic before authentication.

1. Modify the DEFAULT-ACCESS ACL on the switch's access ports so that it limits access before authentication in accordance with your policy.

2. Unless you have a specific need to support multiple data devices on a single port, configure all access ports for single host-mode (for non-IP-Telephony deployments) or multi-domain host-mode (for IP Telephony deployments).

When the endpoints re-authenticate, the dACL will be applied on top of the DEFAULT-ACCESS ACL. Ensure that the combined ACL gives the endpoints the level of access you intended.

TIP: The default port ACL can always be modified

The default port ACL (DEFAULT-ACCESS in the example above) is not set in stone. You can start with a "permit any" statement (as we did above to transition from monitor mode) and then selectively add "deny" statements to prevent access to sensitive assets before authentication. Over time, you may transition from a default port ACL that denies access to a few resources and permits everything else to a default port ACL that permits access to a few resources (ie:. DHCP, DNS, TFTP for PXE, etc.) and denies everything else. Evolving your ACL in this way allows you to incrementally add access control without inadvertently blocking important traffic.

Figure 1. Two Models for Default Port ACL

Low Impact Mode: Next Steps

For many customers, Low Impact Mode will be the final step in the IBNS deployment. If this mode provides you with the access control that you need, then the only "next step" will be monitoring your network and fine-tuning ACLs as required by your policy.

However, if your network security requirements evolve and you no longer want to offer any form of pre-authentication access, you can move to the next phase: High Security Mode.

If Low Impact mode does not meet your network and design security requirements in the first place, you may skip Low Impact Mode altogether and go straight from Monitor Mode to High Security Mode.

High Security Mode

High Security Mode returns to a more traditional deployment model of 802.1X. In a properly prepared network, High Security Mode gives you total control over network access at Layer 2.

In High Security Mode, the port is kept completely closed until a successful authentication takes place. There is no concept of Pre-Authentication access. For users and devices that successfully complete 802.1X, this is not typically an issue since 802.1X authentication is usually very quick.⁴ For devices that cannot perform 802.1X, however, there may be a significant delay in network access. Since the switch always attempts the strongest secure authentication method first, non-802.1X-capable devices must wait until the switch times out the 802.1X authentication and falls back to MAB as a secondary authentication method.

One solution to the delays associated with MAB in High Security Mode is to configure the switch to perform MAB first, before 802.1X. This way, non-802.1X devices will get immediate access after successful MAB.

After a successful authentication, network access will, by default, change from completely closed to completely open. To add more granular access control, High Security Mode uses dynamic VLAN assignment to isolate different classes of users into different broadcast domains.⁵ By isolating traffic from different classes of users into separate VLANs, High Security Mode provides the foundation for virtualized network services.⁶

Devices that can't authenticate or fail to authenticate retain the same level of access that they had before authentication-in other words, no access at all.

High Security Mode: Deployment Considerations

Deploying High Security Mode with VLAN assignment can have a significant impact on network architecture. Understanding these potential impacts is essential to a successful deployment of this mode.

First, dynamic VLAN assignment requires that every dynamic VLAN be supported on every access switch to which a user might connect and authenticate. This requirement has several repercussions: If you have three user groups to which you wish to assign unique VLANs - Engineering, Finance, HR - then every access switch must have those three VLANs defined by name (the number of the VLAN does not have to be the same). If the switch attempts to apply a non-existent VLAN to a port, the authorization will fail and users will not be able to gain access (even if they presented valid credentials and passed authentication).

Second, supporting multiple VLANs per access switch is non-trivial from an IP addressing perspective. Good campus design principles dictate a single subnet per VLAN with no VLAN spanning more than one switch. Your IP addressing scheme should support multiple subnets per switch in such a way that does not over-burden the control and data planes of the campus distribution block.

TIP: Use the minimum number of VLANs necessary

The fewer VLANs you assign, the more manageable and scalable your solution will be. Some customers have found that, upon analysis, their security policy requirements could be met with very few VLANs (ie: Employee, Guest/Fail, and Voice).

Third, if you choose to change the order of authentication to perform MAB before 802.1X, be aware that this will mean that every device (even those capable of 802.1X) will be subject to MAB. This could significantly increase the amount of control plane traffic in your network.⁷

Fourth, if some level of access is needed for devices that fail 802.1X (for example, to allow employees with expired certificates to download a new certificate), it is possible to configure the solution to grant limited access based on the type of authentication method that failed. If 802.1X fails, the switch can be configured to open the port into a special VLAN-the Auth-Fail VLAN-for this purpose.⁸

Fifth, there may be devices on your network that cannot perform 802.1X and cannot pass MAB (for example, contractors with no supplicants that need to VPN to their home network). For unknown MAC addresses that fail MAB, it is possible to configure the Cisco ACS server with an unknown MAC address policy. Such a policy allows ACS to instruct the switch to allow devices with unknown MACs into a dynamically assigned VLAN. In essence, an unknown MAC policy enables a dynamic version of the Auth-Fail VLAN for failed MAB attempts.

Implementing High Security Mode

Before transitioning to High Security Mode, you should ensure that all endpoints that should authenticate can authenticate. All identity store databases should be up to date and online.

On the switch, perform the following steps (these steps assume you have previously configured the solution for Monitor Mode):

1. Verify that all VLANs that may be assigned are defined by name on the access switch and that each VLAN has the expected connectivity.

2. Verify that the switch has been configured to accept authorization instructions from the AAA server.

3. Remove any ingress port ACLs from the switch. This deployment scenario does not require ACLs.⁹

4. Disable open access authentication on all ports. If desired, configure the authentication order to perform MAB before 802.1X and modify the authentication priority so that 802.1X can pre-empt a successful MAB authentication.

5. Unless you have a specific need to support multiple data devices on a single port, configure all access ports for single host-mode (for non-IP-Telephony deployments) or multi-domain host-mode (for IP Telephony deployments).

On the ACS server, perform the following steps:

1. Remove any dACL assignments. This deployment scenario does not require ACLs.

2. Configure your ACS to apply the appropriate VLANs to each class of users and devices except phones. Phones will continue to use the statically configured voice VLAN on the port.¹⁰

3. For phones, ensure that the ACS is configured to send down the appropriate permission to allow that device to access the voice VLAN.¹¹

Deployment Scenarios: Summary

The following table provides a quick summary of the three deployment scenarios discussed in the previous sections:

Deployment Scenario	Best for...	Auth Types	Host Mode	Pre-Auth	Successful Auth	Failed Auth
Monitor Mode	All Customers (Initial Deployment)	802.1X & MAB	multi-auth	Open	Open	Open
Low Impact Mode	Customers seeking simple access control with minimal impact to end users and network infrastructure	802.1X & MAB	single-auth (non-IPT) multi-domain (IPT)	Selectively Open	Dynamic ACL	Selectively Open
High Security Mode	Customers seeking the security of traditional 802.1X with L2 traffic isolation and/or network virtualization	802.1X & MAB	single-auth (non-IPT) multi-domain (IPT)	Closed	Dynamic VLAN	Closed (or Auth-Fail VLAN)

Conclusion

Many customers have successfully deployed 802.1X using the deployment scenarios described in this paper. By starting your deployment in a "Monitor Mode" and adding in access control in a phased transition to a different scenario, you can deploy 802.1X with minimal impact to your end users.

For more information, please go to the Identity Based Networking Services website at: www.cisco.com/go/ibns

¹Why not use Dynamic VLAN assignment with Open pre-authentication? When Pre-Authentication authorization is Open, devices can receive IP addresses on the switchport VLAN subnet at link up. If a different VLAN is assigned as the result of an authentication, the old address will not be valid on the new VLAN. 802.1X-capable devices with modern supplicants can typically detect the VLAN change and request a new address on the new VLAN but clientless devices (such as a printer) will not be able to.

²This ACL will be used for the transition/troubleshooting only and will be modified in the final step.

³This is a Cisco VSA "device-traffic-class=voice"

⁴This assumes a "single signon" deployment where credentials are automatically gleaned from the device or user. In environments that require manual log-on (ie: with a pop-up window to enter username and password), there may be some delay.

⁵It is possible to use dynamic ACLs and dynamic VLAN assignment at the same time. For simplicity, this deployment mode focuses only on dynamic VLAN assignment.

⁶For more information on Network Virtualization solutions, see http://www.cisco.com/en/US/netsol/ns658/networking_solutions_package.html

⁷If there are devices in your network that might pass both 802.1X and MAB, be sure to either 1) ensure that no 802.1X-capable devices are in the MAB database; or 2) configure the switch to prioritize 802.1X over MAB so that the port will process an 802.1X authentication after a successful MAB authentication.

⁸The switch can also be configured to "fail back" to a MAB authentication if 802.1X fails. However, 802.1X with failover to MAB should typically not be deployed if the authentication order has been changed to do MAB first.

⁹Although ACLs are not required in this scenario, they are supported should you choose to customize this scenario with dACLs.

¹⁰Many Cisco switches also support dynamic voice VLAN assignment. For simplicity, this scenario utilizes the static voice VLAN.

¹¹This is a Cisco VSA "device-traffic-class=voice"

Hierarchical Navigation

Identity Based Networking Services

Scenario-Based Identity Based Networking Services Deployments

Downloads