Network VirtualizationAccess Control Design Guide

The first functional area of an end-to-end network virtualization solution is access control, which defines the ways for various categories of users to access the enterprise network. This task is achieved by leveraging a shared physical network infrastructure. This implies that switch ports (for wired clients) and access points (for wireless clients) become common network resources for the various categories of users. This document provides an analysis of the various methods of enabling user connectivity to the enterprise network, and distinguishes between wired and wireless scenarios. For related information, see the following documents:

Network VirtualizationGuest Internet Access Deployment Guide Network VirtualizationPath Isolation Design Guide Network VirtualizationServices Edge Design Guide

Contents
Introduction
2 2

Access to the Enterprise CampusWired Clients Static VLAN Configuration 4 Dynamic VLAN Configuration 4 802.1x Guest VLAN 5

Access to the Enterprise CampusWireless Clients 15 Access Point Only Deployment (Cisco Aironet) 16 Access Point Deployment (Cisco Aironet) with WLSM 18 Lightweight Access Point Deployment with the Cisco WLAN Controller Access to the Enterprise Branches 25 Wired Access to the Network 25 Wireless Access to the Network 26 Access Point Only Deployment (Cisco Aironet)

21

26

Corporate Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Copyright 2006 Cisco Systems, Inc. All rights reserved.

Introduction

Lightweight Access Point Deployment with Cisco WLAN Controller Remote Edge Access Points 26

26

Introduction
The access control functional area aims to identify the users or devices logging into the network so they can be successfully assigned to the corresponding groups. This process of identifying the users or devices is known as authentication. When identified, the endpoints must be authorized onto the network. To achieve this, the port on which an endpoint connects is activated and configured with certain characteristics and policies. This process is known as authorization. Examples of authorization include the configuration of the VLAN membership of a port based on the results of an authentication process, and the dynamic configuration of port ACLs based on the authentication.

Note

For wireless access, the concept of a port is replaced by an association between client and access point. When authorizing a wireless device, the association is customized to reflect the policy for the user or device. This customization can take the form of the selection of a different wireless LAN (WLAN), VLAN, or mobility group, depending on the wireless technology employed. When an endpoint is authorized on the network, it can be associated to a specific user group that usually corresponds to a separate virtual network in a segmented network architecture. Thus, it is the authorization method that ultimately determines the mapping of the endpoint to a virtual network. For example, when a VLAN is part of a virtual network, a user authorized onto that VLAN is therefore authorized onto the virtual network. The main authentication scenarios for the enterprise are as follows:

Client-based authentication for endpoints with client software Clientless authentication for endpoints with no client software

The current state of the technology provides broad support for VLAN assignment as an authorization alternative. In the cases where policy changes based on authentication are required and only VLAN assignment authorization is available, a static assignment of a policy to a VLAN provides the required linkage between the user authorization and the necessary policy. In effect, the policy is applied to the VLAN because users are subject to the policy when authorized onto the VLAN.

Access to the Enterprise CampusWired Clients

The traditional solution for differentiating categories of users that are connected to the enterprise network in a wired environment consists of placing the users in distinct VLANs. VLANs have been used for a long time and represent the most common way of virtualizing a network in the Layer 2 domain. Cisco recommends the use of three layers in campus network design: access, distribution, and core. As shown in Figure 1, Cisco recommends the use of Layer 3 devices in the distribution and core layers, and Layer 2 switches in the access layer. Layer 2 trunks connect the access layer switches to the distribution devices that represent the demarcation point between the Layer 2 domain and the routed portion of the network.

Network VirtualizationAccess Control Design Guide

OL-10417-01

Access to the Enterprise CampusWired Clients

Figure 1

Multilayer Campus Design

Campus Core Layer 3

Core Layer

Distribution Layer

Layer 2 Access Layer VLAN 20 Yellow 10.1.20.0/24 VLAN 120 Green 10.1.120.0/24 VLAN 220 Red 172.16.1.0/24 VLAN 40 Yellow 10.1.40.0/24 VLAN 140 Green 10.1.140.0/24 VLAN 240 Red 172.16.2.0/24

Each VLAN that is defined on the access layer switches must also be defined on the distribution layer devices. Cisco recommends, when possible, the use of different VLAN values on different access layer switches that are part of the same campus building block. This allows a Layer 3 link to connect the distribution layer peers, which avoids spanning tree loops and reduces the convergence time in case of a link failure. For more information on the Cisco multilayer campus design, see the following design guides:

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/cdccont _0900aecd801a8a2d.pdf http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/cdccont _0900aecd801a89fc.pdf

Routed access is an alternative network design that implies moving the demarcation line between Layer 2 and Layer 3 domains from the distribution layer devices to the access layer switches. In this case, Layer 3 links connect the switches across the entire campus network. A consequence of this approach is that each VLAN is defined only on the access layer switch, as shown in Figure 2.

Network VirtualizationAccess Control Design Guide OL-10417-01

153545

Access to the Enterprise CampusWired Clients

Figure 2

Routed Access Campus Design

Campus Core Layer 3

Core Layer

Distribution Layer

Layer 3 Access Layer VLAN 20 Yellow 10.1.20.0/24 VLAN 120 Green 10.1.120.0/24 VLAN 220 Red 172.16.1.0/24 VLAN 40 Yellow 10.1.40.0/24 VLAN 140 Green 10.1.140.0/24 VLAN 240 Red 172.16.2.0/24

A detailed analysis of the routed access design is not within the scope of this document. For more information, see the following URL: http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a00805fccbf.p df In either design, wired end users connect to the access layer switches and are assigned to different VLANs, depending on the specific group to which they belong (indicated in Figure 1 and Figure 2 by the yellow, green, and red areas). This VLAN assignment can be achieved in the following two ways:

Statically deploying each access layer port to a specific VLAN. Leveraging a dynamic mechanism to assign users to a VLAN based on unique identification information such as a MAC address, identity credential, or machine posture.

Static VLAN Configuration

In this approach, each switch port on the access layer switches in the campus needs to be manually assigned to a VLAN. There are multiple drawbacks to this approach, including the lack of mobility capabilities across the enterprise network and the lack of any mechanism to identify the user before allowing connectivity to the network. In a design supporting multiple user groups that need to remain isolated from each other, there is also the drawback of increased costs because each switch port is reserved for a specific user group, even when not used to capacity.

Dynamic VLAN Configuration

The first line of defense in the enterprise network is to determine who is accessing the network, to which resources these users should have access, and the current state of the device. This trust and identity model comprises two fundamental components:

Network VirtualizationAccess Control Design Guide

153546

OL-10417-01

Access to the Enterprise CampusWired Clients

Identity-based networking services (IBNS)Identifies and validates the network user or device credentials before granting physical access to the network. IBNS can be used to ensure access to the appropriate network resources. The first implementation of IBNS is the IEEE 802.1x protocol, which leverages Extensible Authentication Protocol (EAP) for authentication of end users with a centralized RADIUS server. Network Admission ControlIdentifies the posture (or compliance) of the device to ensure that the specific device can connect to the network without problems.

In both cases, the authorization mechanism to implement network policies consists of dynamically assigning users to a specific VLAN at the end of the authentication process. This is a key factor in identifying and isolating various categories of users in the Layer 2 domain.

802.1x Guest VLAN

For enterprises that are starting to deploy 802.1x in their networks, leveraging guest VLAN functionality is a key element in providing network access to clients that are not equipped with an 802.1x supplicant. The 802.1x guest VLAN functionality was initially deployed as a migration tool to allow enterprises to easily migrate client devices to support 802.1x, while still providing network connectivity. Any VLAN can be configured as the guest VLAN, except private VLANs (PVLANs), voice VLANs (VVID), and the VLAN used for Remote SPAN (RSPAN). The guest VLAN feature is currently supported across all Cisco Catalyst platforms (4500, 3750, 3560, 2950 running Cisco IOS, and 6500 running CatOS).

802.1x Guest VLAN Functionality

Figure 3 shows the functionality of the 802.1x guest VLAN feature.
Figure 3 802.1x Guest VLAN Feature

Client

EAP-Failure D = 01.80.c2.00.00.03 EAP-Identity-Request D = 01.80.c2.00.00.03 EAP-Identity-Request D = 01.80.c2.00.00.03 EAP-Identity-Request D = 01.80.c2.00.00.03 EAP-Success D = 01.80.c2.00.00.03

802.1x Process

1 Upon link up 2 Upon link up 3 30-seconds 4 30-seconds 5 30-seconds

153547

Note: the timer values displayed above are the default and can be tuned

Currently, when a switch port initially receives a link, an EAP-Failure message is transmitted. An EAP-Identity-Request frame from the authenticator (switch) immediately follows this failure message, actively looking for an 802.1x supplicant. This happens regardless of whether the device that connected to the port is actually equipped with the supplicant.

Network VirtualizationAccess Control Design Guide OL-10417-01

Access to the Enterprise CampusWired Clients

Assuming that the user does not have the 802.1x capability on their machine, the request from the switch goes unanswered. After the expiration of a timer (tx-period), the switch sends a new EAP-Identity-Request frame. This behavior is dictated by the 802.1x specification. This process continues until the third request from the switch goes unanswered. The number of retries is driven by the value of the max-reauth-req parameter. After the maximum number of retries is exceeded, and if the switch port has been configured with the 802.1x guest VLAN functionality, the port is moved to the guest VLAN and the switch sends an EAP-Success message to the client. This message is ignored and discarded by the client. From the point of view of the 802.1x process, the port has become authorized and the 802.1x state machine has entered the Authenticated state; no further security or authentication mechanisms are applied (the 802.1x state machine stops running). It is basically as if the administrator has disabled 802.1x and hard-set the port into that specific VLAN.

Configuring 802.1x Guest VLAN

The behavior illustrated in Figure 3 is valid when using default values for the 802.1x parameters that affect guest VLAN functionality: max-reauth-req and tx-period. The max-reauth-req parameter sets the maximum number of times that the switch retransmits an EAP-Identity-Request frame on the wire before receiving a response from the connected client. This value is set to two by default. This is why Figure 3 shows two retries (at Steps 3 and 4) after the initial EAP-Identity-Request frame sent at link-up. The commands used to change this parameter (in CatOS and Cisco IOS) are as follows:
CatOS
cat6500> (enable) set dot1x max-reauth-req ? <max-reauth-req> maximum number of retries to supplicant (1..10)

Cisco IOS
cat3750(config-if)#dot1x max-reauth-req ? <1-10> Enter a value between 1 and 10

The tx-period parameter sets the number of seconds that the switch waits for a response to an EAP-Identity-Request frame from the client before retransmitting the request. The default value is 30 seconds and is configurable as follows:
CatOS
cat6503> (enable) set dot1x tx-period ? <tx-period> tx period (1..65535 seconds)

Cisco IOS
cat3750(config-if)#dot1x timeout tx-period ? <1-65535> Enter value between 1 and 65535

The max-req parameter is part of the configurable 802.1x parameter in Cisco IOS. The max-req parameter is different from the max-reauth-req parameter and represents the maximum number of retries a switch performs for EAP-Request frames of types other than EAP-Identity-Request. Basically, this parameter refers to EAP-Data frames, which are the EAP frames exchanged after the supplicant has replied to the initial EAP-Identity-Request frame. For this reason, the max-req parameter is effective only when there is a valid 802.1x supplicant connected, and it does not apply to guest VLAN services.

Network VirtualizationAccess Control Design Guide

OL-10417-01

Access to the Enterprise CampusWired Clients

The configurable values for the parameters shown in the preceding configuration example are consistent between the various Catalyst switch platforms, when running the following minimum Cisco IOS software releases (previous releases are characterized by platform-specific configurable values):

Catalyst 356012.2(25)SEE Catalyst 375012.2(25)SEE Catalyst 450012.2.(31)SG

For a Catalyst 6500 running CatOS software, the situation is different; the main distinction is the fact that in CatOS releases earlier than 8.5 there is no max-reauth-req parameter. This implies that the same parameter described above (max-req) is used to tune both the number of retries for the EAP-Identity-Request and EAP-Data frames. Note also that the configurable values are consistent with the one detailed for Cisco IOS: max-reauth-req (and max-req) can vary from 1 to 10 and tx-period from 1 to 65535. The overall configuration of the 802.1x guest VLAN is relatively simple but differs on switches running IOS and CatOS software releases, as follows:
Cisco IOS
interface FastEthernet0/1 switchport access vlan 2 switchport mode access dot1x port-control auto dot1x guest-vlan 10 dot1x max-reauth-req 2 dot1x timeout tx-period 30 spanning-tree portfast

CatOS
set set set set set set vlan 2 2/1 port dot1x 2/1 port-control auto port dot1x 2/1 guest-vlan 10 spantree portfast 2/1 enable dot1x max-req 2 dot1x tx-period 30

Note

In CatOS systems, the values for max-req and tx-period are set at a global level, and not per port, as they are in Cisco IOS software.

Determining Which Values to Use for the 802.1x Parameters

The following formula calculates the time interval before a port can be successfully deployed into the guest VLAN: Guest VLAN deployment is based on (max-reauth-req + 1) multiplied by the tx-period. Based on the default values (max-reauth-req=2, tx-period=30sec), it takes up to 90 seconds to deploy a user into the guest VLAN (see Figure 3). Depending on the specific application, this can be an excessive amount of time. For example, when providing network services to visitors, you should minimize the guest VLAN deployment interval. By setting max-reauth-req to 0 and tx-period to 5 seconds, a machine can be deployed into the guest VLAN in just five seconds, as illustrated in Figure 4.

Network VirtualizationAccess Control Design Guide OL-10417-01

Access to the Enterprise CampusWired Clients

Figure 4

Tuning the Guest VLAN Deployments

Client

EAP-Failure D = 01.80.c2.00.00.03 EAP-Identity-Request D = 01.80.c2.00.00.03 EAP-Success D = 01.80.c2.00.00.03

802.1x Process

1 Upon link up 2 Upon link up 3 5-seconds

153548

This configuration should be attempted only after considering the consequences that this can have on the regular functionality of 802.1x. Analyzing the integration issues between 802.1x and DHCP at startup time helps in understanding this. If a user starts up a machine equipped with an 802.1x supplicant, two possible scenarios can occur in relation to the use of 802.1x machine authentication after connecting to a switch port configured for guest VLAN. A complete description of machine authentication is not within the scope of this document.

The 802.1x supplicant is enabled for machine authentication and the switch port is configured with a max-reauth-req setting of 0 and tx-period setting of 5. At system startup, the switch immediately sends an EAP-Identity-Request frame in an attempt to find a supplicant online. As a consequence of the 802.1x parameter settings defined here, the switch port is deployed into the guest VLAN after 5 seconds and the 802.1x state machine stops before the supplicant can authenticate. At a certain point during the startup process, the supplicant on the clients initializes and, because machine authentication is enabled, it can send an EAPOL-Start frame to restart the authentication process. This message is sent by default in Meetinghouse AEGIS, but not with the native Windows XP 802.1x supplicant, which requires a specific setting of the Windows registry. This is described at the following URL: http://www.microsoft.com/WindowsServer2003/techinfo/overview/wififaq.mspx#EAAAA However, assuming that EAPOL-Starts are sent, because the DHCP and the 802.1x processes are completely asynchronous, the machine can acquire an IP address from the DHCP pool associated to the guest VLAN even before sending the EAPOL-Start frame. In this case, the IP address must be released and renewed after the machine authentication process completes successfully, because the port can now be deployed in a different VLAN from the guest VLAN. In this case, things can break if the supplicant running on the machine is not able to trigger this DHCP renewal. The machine would not be able to get an IP address in the correct subnet. Tests run with various supplicants showed that all of them are able to renew the IP address after the machine authentication process completes. However, this happens by default with Funk Odyssey and Meetinghouse AEGIS but not with the Microsoft client. Windows XP requires the registry settings described previously or the machine does not send the EAPOL-Start and therefore is stuck in the guest VLAN. The same situation occurs when the user logs in through the Graphical Identification and Authentication (GINA) interface (which serves as the gateway for interactive logons).

The 802.1x supplicant is not enabled for machine authentication. In this case, during the startup process the switch port could be deployed into the guest VLAN and the machine could get an IP address from the guest VLAN pool. This happens not only when setting the max-auth-req and tx-period parameters at the minimum possible values, but also every time the startup process is longer than (max-reauth-req + 1) * tx-period seconds. A typical guest VLAN security policy limits communications to internal resources; this can break the startup process in all the scenarios where

Network VirtualizationAccess Control Design Guide

OL-10417-01

Access to the Enterprise CampusWired Clients

Windows clients need to participate in a Windows Active Directory (AD) networking environment. Even assuming the connectivity with an AD domain controller is not required, after the user logs in and successfully authenticates, there is the same need to renew the IP address as described previously. Validation tests run with various supplicants show that, by default, the Meetinghouse AEGIS clients are able to renew their IP address, whereas the Microsoft supplicant requires the registry setting to be modified to initiate the EAP authentication process after the user logs in. In conclusion, it is possible to set the tx-period and max-reauth-req parameters to the minimum configurable values to reduce the time interval required for the deployment of a switch port in the guest VLAN. To avoid breaking the 802.1x functionality when using the Microsoft XP supplicant, Cisco recommends that you modify the default Windows registry values to allow the Microsoft supplicant to send EAPOL-Start frames. This is the default behavior for Meetinghouse AEGIS clients.

Interaction with VoIP Deployments

The integration of 802.1x and IP phones is based on the switch configuration of multi-VLAN access ports. Multi-VLAN ports belong to two VLANs: native VLAN (PVID) and auxiliary VLAN (VVID). This allows the separation of voice and data traffic and enables 802.1x authentication only on the PVID. The type of communication that occurs on these two VLANs is shown in Figure 5.
Figure 5 Multi-VLAN Port
153549

Tagged (802.1q) IP Untagged (802.3)

When 802.1x is enabled on a multi-VLAN access port, a supplicant must complete the authentication process before getting access to the data (native/PVID) VLAN. The IP phone can get access to the voice (auxiliary/VVID) VLAN after sending the appropriate Cisco Discovery Protocol (CDP) packets, regardless of the dot1x state of the port. The use of CDP with Cisco IP phones is required, given the lack of support for an embedded 802.1x supplicant. The configuration commands for Cisco IOS and CatOS that are required to enable multi-VLAN functionality, in conjunction with 802.1x and guest VLAN functions, are as follows:
Cisco IOS
interface FastEthernet0/1 switchport access vlan 2 switchport mode access switchport voice vlan 2 dot1x port-control auto dot1x timeout tx-period 30 dot1x max-reauth-req 2 dot1x guest-vlan 10 spanning-tree portfast

CatOS
set set set set set vlan 2 2/1 port dot1x 2/1 port-control auto port dot1x 2/1 guest-vlan 10 spantree portfast 2/1 enable port auxiliaryvlan 2/1 2 set dot1x max-req 2 set dot1x tx-period 30

Network VirtualizationAccess Control Design Guide OL-10417-01

Access to the Enterprise CampusWired Clients

The multi-VLAN and the guest VLAN features are not currently supported on Catalyst 6500 platforms running native Cisco IOS images. The Catalyst 6500 requires CatOS or Hybrid (CatOS and Cisco IOS). These features are supported on all other Catalyst platforms, beginning with the following minimum software releases:

Catalyst 295012.1(12c)EA1 Catalyst 356012.1(19)EA1 Catalyst 375012.1(14)EA1 Catalyst 450012.2(20)EWA Catalyst 65007.6(1)

This section describes the circumstances in which the Ethernet port on the IP phone can be shared between users equipped with 802.1x supplicants and users that do not have supplicants. When accessing the network by connecting to the port on an IP phone, no link-down event occurs on the switch port when the PC is later removed. Therefore, the switch is unaware of this event, which poses security vulnerabilities.

Note

The same considerations are valid in cases where hubs are deployed between the end users and the access layer switch. Cisco does not officially support the deployment of hubs in conjunction with 802.1x, so the topic here is limited to the use of IP phones. To determine the conditions under which the same IP phone PC port can be sequentially used by various categories of users (users equipped with an 802.1x supplicant and those who are not), two main aspects must be considered:

The capability of the IP phone to send an EAPOL-Logoff message on behalf of the client after it detects a link-down event on the PC port (this functionality is called proxy EAPOL-Logoff).

Note

Proxy EAPOL-Logoff was introduced in the Cisco 7940 and 7960 phones in firmware 7.2(2) and the Cisco 7911, 7941, 7961, 7970, and 7971 phones in firmware 7.0(1). Both images were released in June 2005. More information can be found at the following URL: http://www.cisco.com/en/US/partner/products/hw/phones/ps379/prod_release_note09186a008 0461f84.html The mode of operation of the 802.1x process on Catalyst switch ports after receiving the EAPOL-Logoff message. This differs depending on the switch platform and on the specific software image. Based on this, it is possible to distinguish the following two scenarios.

Scenario 1
The considerations in this scenario are valid for Cisco Catalyst switch platforms running Cisco IOS software versions previous to the ones listed here:

Catalyst 2950 (IOS)12.1(22)EA2 Catalyst 3560 (IOS)12.2(25)SE Catalyst 3750 (IOS)12.2(25)SE Catalyst 4500 (IOS)12.2(25)EWA Catalyst 6500 (CatOS)8.4(4)

The same considerations are valid for the Catalyst 6500 running the following CatOS release:

Network VirtualizationAccess Control Design Guide

10

OL-10417-01

Access to the Enterprise CampusWired Clients

As previously mentioned, when a user connects to the Ethernet port on a Cisco IP Phone, the switch port is unable to detect when the user later disconnects. The proxy EAPOL-Logoff capability is provided on Cisco IP phones to communicate to the 802.1x process that the user (who might have been previously authenticated) has left the port, so that the switch port can be moved from the Authenticated to the Unauthorized state. In describing the interaction of the guest VLAN with an IP phone, it is essential to distinguish between the two cases where the Cisco IP Phone supports EAPOL-Logoff.

IP Phone That Supports EAPOL-Logoff

When an IP Phone is plugged into a switch port configured as shown in the preceding configuration example, the sequence of events shown in Figure 6 occur and, after Step 5, the port is assigned to the guest VLAN (note that the Cisco IP phone is not able to reply to the EAP messages originated from the switch given the lack of 802.1x supplicant).
Figure 6 IP Phone and Guest VLAN

IP Phone IP

802.1x Process

1 Phone plugged in 2 EAP-Failure 3 EAP-Identity-Request 4 EAP-Identity-Request 5 EAP-Identity-Request 6 EAPOL-Success

153550

Now the 802.1x state machine running on the switch port has entered into the Authenticated state. At this point, what happens depends on who is connecting to the Ethernet port on the IP phone. The port remains configured in the guest VLAN if one of the following two situations occurs:

A guest connects using a machine that does not have an 802.1x supplicant. An internal employee (or even a guest) connects using a machine that is equipped with an 802.1x supplicant that is not able to send EAPOL-Start (remember that by default Microsoft Windows XP supplicant does not send an EAPOL-Start). In this specific case, the user might wonder why the 802.1x authentication completes successfully when connecting to a switch port, but does not when plugging into the Ethernet port on the IP phone.

In either of these two situations, the 802.1x state machine remains in the Authenticated state (it basically stops running); this is true even when the user disconnects from the IP phone. A different situation occurs if an employee connects to a machine that is equipped with a supplicant that is able to send EAPOL-Start. The reception of this packet restarts the 802.1x state machine on the switch port, and assuming that the authentication is successful, the port is deployed in the proper data VLAN. When the employee disconnects, the IP phone sends an EAPOL-Logoff message to the switch to inform the 802.1x process of this event. As a consequence, the 802.1x state machine on the switch port enters

Network VirtualizationAccess Control Design Guide OL-10417-01

11

Access to the Enterprise CampusWired Clients

the Unauthorized state and 802.1x stays active. After sending a few EAPOL-Identity-Request frames (this number is dictated by the value of the max-reauth-req parameter) looking for a supplicant, the switch port is finally deployed into the guest VLAN. This sequence of events is shown in Figure 7.
Figure 7 EAPOL-Logoff Capability with Older Software Releases

802.1x Supplicant
IP Phone IP

802.1x Process

PC plugged in

2 EAPOL-Start
EAP Auth process

3 EAPOL-Success 4 PC leaves 5 EAP-Logoff 6 EAP-Identity-Request 7 EAP-Identity-Request 8 EAP-Identity-Request 9 EAPOL-Success

153551

This means that the situation is back to the condition shown in Figure 6. In summary, this case represents the best scenario because it allows deploying a user into the guest VLAN or into a data VLAN, depending on the capability of the user client to initiate an 802.1x conversation with the switch after connecting to the IP phone. Also, because of the EAPOL-Logoff capability of the IP phone, the switch port is always deployed into the guest VLAN when a previously connected employee disconnects from the IP phone, making the port reusable by a guest.

IP Phone That Does Not Support EAPOL-Logoff

This situation is identical to what was previously described until Step 4 of Figure 7. After this point, because the IP phone is not capable of sending an EAPOL-Logoff frame to the switch, the port remains in the 802.1x Authenticated state. This clearly opens a security hole, because an illegitimate user can now gain access to the port by spoofing the authenticated MAC address, and completely bypassing the 802.1x authentication phase. The situation grows worse because the process breaks even if a legitimate user connects to the IP phone when the switch port is in the Authenticated state. In fact, assuming that the MAC address of the new user is different from the one of the user previously authenticated, the switch could treat the event as a security violation. As a consequence, the switch port can be placed in an error disable state, in which case not only is the new user prevented from connecting, but the IP phone

Network VirtualizationAccess Control Design Guide

12

OL-10417-01

Access to the Enterprise CampusWired Clients

is disconnected. The only scenario where the switch port might still be deployed into the guest VLAN is when 802.1x re-authentication is enabled on that port, and it initializes before a user connects to the IP phone.

Scenario 2
The considerations in this scenario are valid for Catalyst switch platforms running the following Cisco IOS software versions:

Catalyst 2950 (IOS)12.1(22)EA2 Catalyst 3560 (IOS)12.2(25)SE Catalyst 3750 (IOS)12.2(25)SE Catalyst 4500 (IOS)12.2(25)EWA

Once again, the situation is different for Catalyst 6500 platforms that require the CatOS release listed here (and previous):

Catalyst 6500 (CatOS)8.4(3)

As described in Scenario 1, you need to make a distinction between the cases where IP phones have the capability to send EAPOL-Logoff frames.

IP Phone That Supports EAPOL-Logoff

When an IP phone is connected to a switch port and configured as shown in the previous configuration example, the sequence of events shown in Figure 8 occurs, and after Step 5, the port is deployed into the guest VLAN.
Figure 8 Cisco IP Phone and Guest VLAN

IP Phone IP

802.1x Process

1 Phone plugged in 2 EAP-Failure 3 EAP-Identity-Request 4 EAP-Identity-Request 5 EAP-Identity-Request 6 EAPOL-Success

153550

This situation is identical to that previously described at the first step of Scenario 1, page 10. However, a different situation occurs if, starting from the initial situation shown in Figure 8, an employee connects to a machine that is equipped with a supplicant that is able to send EAPOL-Start.

Network VirtualizationAccess Control Design Guide OL-10417-01

13

Access to the Enterprise CampusWired Clients

The reception of this packet restarts the 802.1x state machine on the switch port, and assuming that the authentication is successful, the port is deployed into the appropriate data VLAN. If the employee disconnects, the IP phone sends an EAPOL-Logoff message to the switch to inform the 802.1x process of this event. As a consequence, the 802.1x state machine on the switch port enters the Unauthorized state and stops running. This sequence of events is shown in Figure 9.
Figure 9 EAPOL-Logoff Capability

802.1x Supplicant
IP Phone IP

802.1x Process

1 PC plugged in 2 EAPOL-Start
EAP Auth process

3 EAPOL-Success 4 PC leaves 5 EAP-Logoff

Guests that attempt to connect a cable to the IP phone who are not equipped with a supplicant are not deployed into the guest VLAN because the state machine is stopped in the Unauthorized state. The only event that unblocks this situation is when a machine with a supplicant that is able to send an EAPOL-Start message connects to the IP phone. In summary, the IP phone capability of sending EAPOL-Logoff closes the security hole described in the following section, but at the same time jeopardizes the deployment of the switch port into the guest VLAN.

IP Phone That Does Not Support EAPOL-Logoff

This situation is identical to that shown in Steps 1 through 4 of Figure 9. After this point, because the IP phone described here is not capable of sending an EAPOL-Logoff frame to the switch, the port remains in the 802.1x Authenticated state. This clearly opens a security hole, because an illegitimate user can now gain access to the port by spoofing the authenticated MAC address, and completely bypassing the 802.1x authentication phase. Even worse, the process breaks even if a legitimate user connects to the IP phone when the switch port is in the Authenticated state. In fact, assuming that the MAC address of the new user is different from the one of the user previously authenticated, the switch can treat the event as a security violation. As a consequence, the switch port can be placed in an error disable state, which not only prevents the new user from connecting, but also causes the IP phone to be disconnected. This differs from Scenario 1 in that, in this case, the switch port cannot be deployed into the guest VLAN even if re-authentication is enabled on that port and it initializes before a user connects to the IP phone.

Network VirtualizationAccess Control Design Guide

14

OL-10417-01

153552

Access to the Enterprise CampusWireless Clients

Note

As previously mentioned, the description of events in Scenario 2 is valid for Catalyst switches running newer versions of Cisco IOS code. To maintain backward compatibility, a new global command, dot1x guest-vlan supplicant, has been added in Cisco IOS software releases that allows you to manually configure the switches to behave as described in Scenario 1, page 10. This global command is available on Cisco IOS for all the Catalyst platforms, but it is not available on CatOS for Catalyst 6500, so these devices can only perform as described in this scenario when running software releases earlier than 8.4(4). In conclusion, when describing the integration of the 802.1x guest VLAN with IP telephony, these are the recommended design choices:

Use IP phones running a firmware version that enables them to send the EAPOL-Logoff frame when an authenticated user disconnects from the Ethernet port on the IP phone. Implement the guest VLAN functionality on Catalyst switches running either older IOS software versions or ones configured with the dot1x guest-vlan supplicant command. An improvement is to provide this command on a switch port level rather than globally. This allows individual ports to be configured for the operation and enhances operational flexibility by enabling this feature only on switch ports that are accessible from enterprise public areas (where guest access must be provided). It is not used in the other enterprise locations (a guest should not be able to achieve network connectivity when connecting, for example, to an IP phone that is located in an employee office). When using Catalyst 6500 platforms, Cisco recommends using the minimum software release 8.4(4).

Access to the Enterprise CampusWireless Clients

Wireless users access the network differently depending on the specific wireless deployment adopted in the enterprise; the Cisco Integrated Wireless Network includes two secure, enterprise-class wireless LAN (WLAN) solutions: the Cisco Distributed WLAN Solution and the Cisco Centralized WLAN Solution. Both solutions address the WLAN security, deployment, management, and control issues facing companies and organizations considering WLANs. The Cisco Distributed WLAN Solution is currently deployable in the following two configuration options:

Access point only deployment for secure WLAN access using Cisco Aironet access points (1200, 1230 AG, 1100, 1130 AG, 1300). This is also known as the Cisco traditional AP-based wireless deployment. Access point (using Cisco Aironet devices) for network access, and control through the use of the Cisco Catalyst 6500 Series Wireless LAN Services Module (WLSM), integrated with the Cisco Catalyst 6500 Series switch with Supervisor Engine 720.

The Cisco Centralized WLAN solution includes Cisco Aironet Series lightweight access points with a Cisco Wireless LAN Controller, managed via the Cisco Wireless Control System (WCS), which supports advanced location services using the optional Cisco Wireless Location Appliance. Cisco Aironet lightweight access points support the Lightweight Access Point Protocol (LWAPP) and operate in conjunction with a Cisco Wireless LAN Controller. A detailed description and comparison of the various wireless deployment options is not within the scope of this document; a brief, high-level description of each scenario is provided in the following sections but only in the context of network access control. See the following URL for more information on Cisco Integrated Wireless Networks: http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/ns337/networking_solutions_package.html

Network VirtualizationAccess Control Design Guide OL-10417-01

15

Access to the Enterprise CampusWireless Clients

A typical company security policy most likely requires the implementation of various types of authentication and encryption for various types of users. For example, open authentication and no encryption are the typical choices when providing guest access, whereas 802.1x authentication and strong encryption are usually adopted for internal employees. This is achieved by defining multiple service set identifiers (SSIDs) on each access point, with each SSID characterized by its own security policies. End users associate with the closest access point by selecting a specific SSID to access the enterprise network. After this point, various mechanisms are adopted to logically separate the traffic from users belonging to different groups, depending on the specific wireless deployment adopted by the enterprise. This is described in more detail in the following sections.

Access Point Only Deployment (Cisco Aironet)

In the traditional Cisco wireless deployment, Cisco Aironet access points are deployed at the edge of the network and connected via Layer 2 trunks to Catalyst switches in the wiring closet. These trunks are normally used to carry the VLANs that are associated to each defined SSID on the access point (AP), as shown in Figure 10.
Figure 10 Traditional AP-based Wireless Deployment

Campus Core Layer 3 Layer 2

= L2 trunk Guest Emp Wireless VLANs Guest Emp = SSID = VLAN

Guest Emp

Guest Emp

In this example, two SSIDs are defined on each access point: the employee (Emp) SSID to be used for internal employees (usually associated to some form of authentication, such as LEAP or EAP-Fast); and the guest SSID (with open authentication), which is broadcast into the air to allow visitors to easily associate with, and gain access to, the network. The following is a sample configuration for an access point that highlights the definition of the SSIDs:
dot11 vlan-name Emp vlan 10 dot11 vlan-name Guest vlan 20 ! dot11 ssid Emp vlan 10 authentication open eap eap_methods authentication network-eap eap_methods authentication key-management wpa

Network VirtualizationAccess Control Design Guide

16

153553

OL-10417-01

Access to the Enterprise CampusWireless Clients

! dot11 ssid Guest vlan 20 authentication open guest-mode ! interface Dot11Radio0 no ip address no ip route-cache ! encryption vlan 10 mode ciphers tkip ! ssid Emp ! ssid Guest

As you can see from the preceding configuration sample, each SSID is associated to a different VLAN. This means that wireless traffic coming from an internal employee machine is bridged to the employee (Emp) VLAN, and guest traffic is bridged to the guest VLAN. These VLANs need to be defined on both the access and distribution layer switches, and to be enabled on the Layer 2 trunk connections between these devices (and between the APs and the access layer switches). With the traditional AP-based deployment, Fast Secure Roaming (FSR) is available only if the client roams between two APs that are configured with the same VLAN on the wired side. This is Layer 2 roaming; the clients are able to maintain their original IP addresses because they are always kept in the same VLAN. As a consequence of such an implementation and to provide a campus-wide roaming solution, the VLAN to which the client belongs must be configured on every access switch where the APs are attached. This mobility capability is not usually a requirement for guest users; this implies that the guest VLAN defined on each access layer switch (and access point) can have a unique value (as pointed out in Figure 10 by using two different colors). In summary, from the point of view of network access control, this scenario is very similar to the wired previously described case because VLANs are the mechanism adopted in the Layer 2 portion of the enterprise network to isolate the traffic for various categories of users. Traffic isolation achieved in this way is valid up to the point of access into the routed (Layer 3) portion of the network. As previously described, this can be on the distribution layer switch (for traditional campus network designs) or on the access switch itself (for routed access designs).

Access Point Deployment (Cisco Aironet) with WLSM

The first alternative to the traditional AP-based design involves the use of the Cisco Catalyst 6500 Series WLSM (integrated into the Cisco Catalyst 6500 Series switch with Supervisor Engine 720). The introduction of WLSM removes the design and management limitations described in the previous scenario and provides a highly-scalable solution for Layer 3 mobility in the campus. One of the most important concepts introduced with the use of the WLSM is the mobility group. A wireless client experiences seamless roaming (maintaining all its IP sessions) when moving between two APs configured to be part of the same mobility group. A mobility group is defined on the AP by a unique mapping between the SSID for the radio side and the network ID for the wired side. The network ID represents the overlaid logical network built on top of the existing infrastructure using GRE tunnels, and its mapping to the SSID replaces that between the SSID and the VLAN ID. Figure 11 shows how a GRE tunnel is associated to each SSID defined on the AP.

Network VirtualizationAccess Control Design Guide OL-10417-01

17

Access to the Enterprise CampusWireless Clients

Figure 11

WLSM-based Deployment

WLSM/WDS

Emp GRE Guest GRE

Campus Core

Emp GRE Guest GRE

Layer 3

Wireless VLANs

Guest Emp

= L2 trunk = SSID

Guest Emp

Following the same example adopted in the previous section, the network diagram in Figure 11 highlights the use of two distinct SSIDs associated to two categories of users: internal employees and guests. In this scenario, the access point configuration becomes the following:
dot11 vlan-name Emp vlan 10 dot11 vlan-name Guest vlan 20 ! dot11 ssid Emp vlan 10 authentication open eap eap_methods authentication network-eap eap_methods authentication key-management wpa mobility network-id 10 ! dot11 ssid Guest vlan 20 authentication open guest-mode mobility network-id 20 ! interface Dot11Radio0 no ip address no ip route-cache ! encryption vlan 10 mode ciphers tkip ! ssid Emp ! ssid Guest

Network VirtualizationAccess Control Design Guide

18

153554

OL-10417-01

Access to the Enterprise CampusWireless Clients

The configuration of the SSIDs is basically identical to the one described for a traditional AP-based deployment, with the only addition being the mobility network-id command to map the mobility group to the SSID. Note that a VLAN is still associated to each SSID; these VLANs are now defined only on the access point and do not need to be configured on the access layer or distribution layer switches. The only purpose of the VLAN portion of the configuration is to provide a binding between the encryption associated with the VLAN to a specific SSID.

Note

Trunking VLANs between the AP and the access layer switch is still required to support multicast. For more information, see the WLSM Deployment Guide at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/wireless/wlsmdig.htm In other words, VLANs are no longer used for traffic isolation on the wired side of the AP. In this case, with the definition of the mobility group, the traffic from different SSIDs is carried on the wired side over different GRE tunnels to the central switch. Even if this network virtualization is achieved across a Layer 3 network, it can be compared to the case described in the previous paragraph. The only difference is that now the entry point to the Layer 3 routed part of the enterprise network is not the first Layer 3 hop device, but the Catalyst 6500 equipped with the WLSM blade (which can be placed many hops away). The mobility group is also identified on the Supervisor 720 by the configuration of a multipoint GRE (mGRE) tunnel interface. This interface is assigned to the mobility group by configuring the corresponding network ID. The tunnel interface acts as the default gateway for all the wireless traffic belonging to the wireless logical network, and represents the single point of ingress and egress for IP unicast traffic to and from the wired network. The configuration required for the creation of the mGRE interfaces is as follows:
interface Loopback0 description src mGRE for employees ip address 10.100.100.100 255.255.255.255 ! interface Loopback1 description src mGRE for guests ip address 10.100.100.101 255.255.255.255 ! interface Tunnel0 description mGRE for employees ip address 172.16.1.1 255.255.255.0 no ip redirects ip mtu 1476 ip dhcp snooping packets tunnel source Loopback0 tunnel mode gre multipoint mobility network-id 10 ! interface Tunnel1 description mGRE for guests ip address 172.16.2.1 255.255.255.0 no ip redirects ip mtu 1476 ip dhcp snooping packets tunnel source Loopback0 tunnel mode gre multipoint mobility network-id 20

Note that the mobility network-id command under each mGRE interface is matching the value previously configured on the access point for the corresponding SSID.

Network VirtualizationAccess Control Design Guide OL-10417-01

19

Access to the Enterprise CampusWireless Clients

The GRE tunnels are used only for the data traffic. Data traffic is never going through the WLSM but is switched in hardware, leveraging the capabilities of Supervisor Engine 720. All the control traffic exchanged between the distributed access points and the WLSM is instead carried over the native infrastructure, leveraging the management IP address configured on the Bridge Group Virtual Interface (BVI) of the access points. The position of the WLSM blade in the context of a campus network often depends on the particular requirements and needs of a customer. Whenever possible, Cisco recommends placing the WLSM blades in one of the distribution layer switch pairs. Given the critical role that the WLSM has in the wireless network, Cisco suggests positioning a redundant pair of WLSMs in the aggregation layer devices in the data center, as illustrated in Figure 12.
Figure 12 WLSM Deployment in a Campus Network

Data Center Internet

Cisco recommends this so that the WLSMs can be physically placed in a location that is highly available and continuously monitored, which means also providing uninterruptible power supply and dedicated networking staff that control these services around the clock.

Lightweight Access Point Deployment with the Cisco WLAN Controller

A new trend in the WLAN space dictates the deployment of a new wireless architecture, where a WLAN controller system is used to create and enforce policies across many different lightweight access points. As briefly described before, traditional WLAN solutions distribute all traffic handling, RF control, security, and mobility functions to the access point itself.

Network VirtualizationAccess Control Design Guide

20

153555

OL-10417-01

Access to the Enterprise CampusWireless Clients

By centralizing intelligence within a controller system, security, mobility, quality of service (QoS), and other functions essential to WLAN operations can be efficiently managed across an entire wireless enterprise. Furthermore, by splitting functions between the access point and the controller, IT staff can simplify management, improve performance, and increase security of large wireless networks.

Note

The Cisco Centralized WLAN Solution is based on the recent Airespace acquisition.
Figure 13 Cisco Wireless LAN Controller

RF Domain Wireless LAN Controller LAN Domain

Lightweight Access Points

The key for this paradigm shift is the deployment of Lightweight Access Point Protocol (LWAPP). LWAPP revolutionizes the way WLAN deployments are managed with the concept of the split MAC; this means the ability to separate the real-time aspects of the 802.11 protocol from most of its management aspects. In particular, real-time frame exchange and certain real-time portions of MAC management are accomplished within the access point, while authentication, security management, and mobility are handled by WLAN controllers. The Cisco Centralized WLAN Solution, which uses LWAPP, was the first centralized WLAN system to use the split MAC. From a traffic handling point of view, a wireless deployment based on the use of LWAPP is similar to the WLSM scenario described in this document. All data traffic originated from wireless clients associated to the distributed lightweight access points is encapsulated on the access points themselves and carried to a centralized wireless LAN controller, which aggregates the traffic and represents the single point of ingress and egress for IP traffic to and from the wired network. In addition to this conceptual similarity, there are the following differences:

Traffic is tunneled from the access points to the centralized controller, leveraging LWAPP and not GRE. The LWAPP tunnel is a Layer 2 tunnel (the original Ethernet frame is LWAPP-encapsulated), whereas the GRE tunnel is a Layer 3 tunnel. Both control and data traffic is carried via LWAPP. Data traffic uses UDP port 12222, control traffic is encapsulated in UDP port 12223, and Radio Resource Manager uses ports 16666/16667. Also, the control traffic is AES-encrypted, and the data is in the clear. There is not a separate logical tunnel for each defined SSID; only a single logical tunnel is built between each access point and the centralized WLAN controller. This LWAPP tunnel is used to carry the data traffic for all the wireless clients associated to the access point, independently from the SSID they are using for this association.

Figure 14 shows the deployment of the lightweight architecture in an enterprise campus network where the usual two categories of users (employees and guests) are defined.

Network VirtualizationAccess Control Design Guide OL-10417-01

153556

21

Access to the Enterprise CampusWireless Clients

Figure 14

Lightweight Architecture Deployment

airespace

Airespace Controller

Guest Emp

Campus Core

LWAPP

Layer 3

LWAPP

Wireless VLANs
153557

Guest Emp

= L2 trunk = SSID

Guest Emp

From the traffic isolation point of view, this scenario is very similar to the wired deployment in a traditional campus design. The reason is that traffic from various categories of users associating with their own SSID, after being aggregated to the main WLAN controller, is bridged to a corresponding VLAN and carried up to the first Layer 3 hop device. Figure 15 shows how the use of VLANs allows maintaining separation between the guest traffic and the enterprise internal traffic in the Layer 2 domain, in a very similar way to the wired scenario for a traditional campus deployment (Layer 2 in the access).

Network VirtualizationAccess Control Design Guide

22

OL-10417-01

Access to the Enterprise CampusWireless Clients

Figure 15

Similarities Between Wired and Wireless Deployments

Campus Core

Core Layer

Campus Core

Distribution Layer Layer 2 trunks VLAN 10 Guest VLAN 20 Emp Access Layer Layer 2 trunks VLAN 10 Guest VLAN 20 Emp

Guest Emp

Several alternative designs can be deployed when positioning the WLAN controllers in the campus network. For consistency with the positioning of the WLSM described in the previous section, Cisco recommends placing the WLAN controllers in a centralized location (for example, a data center) to leverage the high availability and continuous monitoring characteristic of such an environment (see Figure 16).

Network VirtualizationAccess Control Design Guide OL-10417-01

23

153558

Access to the Enterprise Branches

Figure 16

Cisco Wireless LAN Controller Deployment in a Campus Network

Data Center Internet

Access to the Enterprise Branches

Wired Access to the Network
The way end users are able to connect to the network in a wired fashion at a branch location does not differ from what described in Access to the Enterprise CampusWired Clients, page 2 for campus deployments. Therefore, the users, after connecting, should be deployed into a corresponding VLAN. This happens in one of the two ways previously described: by statically configuring this VLAN or by leveraging a dynamic mechanism (802.1x). In the access layer (Layer 2 domain) of a typical branch, it is possible to deploy all the traditional Catalyst platforms (2950, 3560, 3750, and 4948) or the Cisco EtherSwitch Service Module (integrated switches modules for Cisco routers). The support for 802.1x guest VLAN functionality extends across all of the listed platforms.

Network VirtualizationAccess Control Design Guide

24

153559

OL-10417-01

Access to the Enterprise Branches

Wireless Access to the Network

The deployment of wireless networking at a branch office location can leverage all the design choices already described in Access to the Enterprise CampusWireless Clients, page 15, with the exception of the WLSM deployments that are mostly pervasive in campus environments and uncommon in branch deployments. The various network access options that have been considered for branch deployments in the context of this document are listed in the following sections. Independent from the specific design that is implemented, the traffic originated by wireless clients is eventually be bridged on a corresponding VLAN locally defined at the branch. This is because even in controller-based deployments, it often does not make sense to tunnel traffic to the main site to preserve the already scarce bandwidth resources usually available across the WAN cloud.

Access Point Only Deployment (Cisco Aironet)

When deploying standalone Aironet APs in a branch location, the required AP configuration is identical to the one described in Access Point Only Deployment (Cisco Aironet), page 16 for campus deployments. After associating to the remote AP, the traffic originated from the wireless clients is bridged to a locally defined VLAN; the same considerations made for wired clients in the previous paragraph can be repeated here.

Lightweight Access Point Deployment with Cisco WLAN Controller

The Cisco 2006 Wireless LAN Controller supports up to six lightweight access points, making it ideal for small-to-medium-sized enterprise facilities, such as branch offices. Similar consideration can be made for the integrated Cisco Wireless LAN Controller Module supported on Cisco 2800 and 3800 series Integrated Services Routers (ISRs) and Cisco 3700 Series routers. When deploying a controller locally in the branch location, all the traffic is carried from the access points to the controller leveraging LWAPP, and then bridged on a corresponding dedicated VLAN, similarly to what described in Lightweight Access Point Deployment with the Cisco WLAN Controller, page 20 for campus deployments.

Remote Edge Access Points

Remote edge access points (REAPs) are designed to be deployed in situations where the remote branch is not large enough to justify the use of a local controller. Using REAP devices (model 1030), the LWAPP control plane is separated from the wireless data plane. Cisco Wireless LAN Controllers are still used for centralized control and management in the same way as regular LWAPP-based APs, but all user data is bridged locally at the AP. The main issue of the REAP devices is that they cannot currently perform 802.1q VLAN tagging; as such, traffic on each SSID terminates on the same subnet on the wired network. The main consequence is the need to dedicate an access point to a specific category of users (for example, guests or employees). When deploying REAP, it is important to keep in mind that this type of access point can operate only in environments capable of supporting packets of 1500 bytes in length without fragmentation.

Network VirtualizationAccess Control Design Guide OL-10417-01

25

Access to the Enterprise Branches

Network VirtualizationAccess Control Design Guide

26

OL-10417-01