This section details typical large-enterprise WLAN deployments. WLAN deployment in large enterprise networks can be considered to have three phases. The first phase is usually a pilot deployment with limited coverage (typically for executive users who require mobility throughout one or multiple floors). The security design and implementation issues are resolved in the initial phase. In the second phase of deployment, meeting rooms throughout multiple buildings typically are covered to provide WLAN connectivity. Management issues are resolved as the deployment starts to grow in terms of the number of WLAN infrastructure elements and WLAN users. The third and last phase of deployment is to expand coverage throughout the enterprise. In the last phase, scalability issues have to be addressed and any infrastructure/client-management issues revisited. The security deployment model determined in the first phase holds unless the customer runs into major management and scalability issues. In the main campus environment, WLAN connectivity is likely to be secondary connectivity (with wired connectivity being primary), whereas in a branch office environment, WLAN connectivity is likely to be considered the primary network connectivity mechanism.
The first example is taken from a large enterprise WLAN deployment in a high-tech company. This customer deployment covers all main areas of multiple campuses across the globe (in multiple cities) and several branch offices. The majority of the user community tends to be technology savvy and good at adopting new technologies. In this deployment, wired connectivity is considered the primary network connectivity, and wireless is provided as the secondary network connectivity throughout the campuses. In some remote offices, WLAN connectivity is considered the primary network connectivity.
The customer deployment criteria are as follows:
Mutual authentication and strong encryption for WLAN users.
Single sign-on required; desire to tie the Windows login to WLAN user authentication.
Authenticate WLAN users to Microsoft back-end Active Directory (AD) infrastructure.
No public-key infrastructure (PKI) (digital certificate) requirement for user authentication.
Desire to deploy WLAN ubiquitously across the globe.
Plan to deploy wireless voice over IP (VoIP).
Provide guest access service across main campus buildings.
The customer deployment environment includes the following:
WLAN users standardized on Windows 2000 and XP; however, a small subset of the users has Linux, Mac OS X laptops and Windows CE personal digital assistants (PDAs).
WLAN users standardized on Cisco Aironet adapters or embedded CCX laptops.
Microsoft AD infrastructure is deployed globally.
Central (corporate and regional headquarters [HQ]) to remote sites have redundant WAN links. Redundant WAN links can be relied on to provide reliable RADIUS service to authenticate remote WLAN users.
A subset of the user community (sales representatives and support personal) is mobile within a country and at times across the globe.
Guest users can bring in laptops with any OS and any WLAN vendor network interface card (NIC) adapter.
Given the preceding deployment criteria and deployment environment, EAP/802.1x with Temporal Key Integrity Protocol (TKIP) (WPA [Wi-Fi Protected Access] model) was selected as the deployment model to provide Layer 2?based user authentication and data confidentiality for employees. In this specific scenario, the customer selected Cisco LEAP for mutual authentication and dynamic Wired Equivalent Privacy (WEP) for strong encryption in the initial phase of the deployment. LEAP was selected due to the customer's desire for noncertificate-based user authentication (that is, non-PKI). Furthermore, LEAP deployment was facilitated with the use of Cisco Aironet client adapters and the CCX laptops where LEAP support is natively provided. Initially, WLAN connectivity was enabled only for Windows 2000 and XP users. In the second phase of deployment, WLAN access was expanded to Mac OS, Linux, and Windows CE (PDA) users.
For users with Cisco Aironet client adapters, single sign-on was facilitated using the Aironet Client Utility (ACU) configured to obtain LEAP authentication credentials via Windows user login. For users with CCX laptops, single sign-on was facilitated using securely stored user authentication credentials on the user's laptop. The deployment was expanded to allow wireless access for 25,000 employees worldwide.
In the initial phase, dynamic WEP was deployed to facilitate a quick deployment. Because of known WEP weaknesses (as discussed in Chapter 6, "Wireless Vulnerabilities"), the encryption key was rotated every 15 minutes using IETF parameter 27 (also known as session-timeout, which is a per-user or user-group IETF parameter) on the RADIUS server. To provide strong data confidentiality, users were slowly migrated to WPA. Along with migration to WPA, strong password policy was instituted for WLAN users to enable LEAP authentication. The IT administrator instituted a minimum of 10 characters with at least two nonalphanumeric characters in a user's password as the strong password policy. A long-term migration to EAP-FAST is planned for the Cisco Aironet client adapter and CCX users to minimize risk due to offline dictionary attacks.
In deploying WLAN throughout the campus environment, a single VLAN per building was deployed to accommodate WLAN devices and WLAN users. This provided the IT administrator with the flexibility to enforce specific wired security policies for the WLAN devices and users. This also enabled seamless Layer 2 mobility within a building. However, this meant spanning a single VLAN at the building distribution layer level and was against the overall wired deployment policy, which mandated limiting the size of wired VLANs. Limiting the size of wired VLANs usually means enforcing Layer 3 routed links between distribution and access layer level switches. In the initial deployment phase, the compromise was made for security purposes (isolating WLAN devices/users per building) and for enabling seamless Layer 2 roaming, however.
As the deployment grew to a large size (500+ access points and 10,000 WLAN users), the IT department had to automate WLAN infrastructure management and user management. The IT department has a "home-grown" network management system to facilitate infrastructure management. Wireless LAN Solution Engine (WLSE) was incorporated as part of this to enable automated software and firmware management for APs along with configuration management. WLSE version 2.5 (or above) and AP IOS release 12.2(13)JA (or above) are incorporated (as part of the SWAN architecture) to automate RF site survey (using the assisted site-survey feature). Furthermore, WLSE along with SWAN network elements (switches/routers, APs, and clients) were configured to scan and detect rogue APs. Specifically, distribution layer switches (Catalyst 6500 switches with Supervisor 720 module and the Wireless LAN Service Module [WLSM]) were configured to enable Wireless Domain Services (WDS) to facilitate SWAN-related features, such as RF monitoring, rogue AP detection, and fast secure roaming for VoIP devices.
To facilitate large-scale WLAN user deployment, automated IT tools (such as Altiris client management solution) were used to push out the Aironet Installation Wizard and Aironet Client Utility (ACU) configuration (generated using the Aironet Configuration Administration Tool [ACAT]) to all users with Aironet client adapters and CCX-certified laptops.
Figure 13-1 provides the overall deployment architecture and topology of this customer's network. As seen in the figure, WLAN was deployed for multiple buildings in a large campus environment. Standard campus design practices were implemented for the wired deployment in access, building distribution, core, data center, and Internet access modules.
Note that integration of WLSM into Catalyst 6500 switches at the distribution layer level (as shown in Figure 13-1) removes the need to span user VLANs across the distribution switch. Each wired VLAN per floor can be GRE tunneled into the supervisor using the Catalyst 6500 WLSM integration model. Preferably, WLSM integration can be performed starting in the first phase of deployment to minimize changes to the existing wired network when integrating wireless into a large campus-wired network.
In addition to management issues, AAA infrastructure scalability and availability issues had to be resolved. To facilitate large-scale EAP/802.1x authentication, AAA (RADIUS server) infrastructure had to be scaled for large campuses, and redundancy had to be provided for large campus and remote office deployment scenarios. Central network operation centers (NOCs) were used for large campuses (using the DATA center as the NOC), and RADIUS servers were deployed in regional NOCs to address remote office deployments.
Four Cisco Secure ACS RADIUS servers were deployed in the central NOC for the main campus HQ where 10,000+ WLAN users are facilitated. A minimum of two Cisco Secure ACS RADIUS servers were deployed per regional NOC. A load balancer (such as Cisco Catalyst 6500 server content switching module or the 6500 Supervisor IOS load balancing feature) was used to load balance among multiple RADIUS servers. In the remote office deployment, the APs were configured to use the regional RADIUS infrastructure as the primary RADIUS server, and the central NOC (that is, corporate NOC) was configured as the secondary RADIUS infrastructure (to be used under regional NOC failure conditions only).
RADIUS server scaling for EAP authentication is based on many factors. The number of WLAN users, the number of APs, authentication timeout, and the EAP protocol used are some of the factors that you should consider. For more details, visit the Cisco website and explore deployment guidelines for this. Specifically, refer to http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_white_paper09186a00801495a1.shtml.
In the initial deployment, one key issue for RADIUS server infrastructure scalability was session rekey timing. Initially, every user was configured for reauthentication every 15 minutes (while WEP was deployed for encryption); as a result, RADIUS server infrastructure was impacted (due to an increased number of user authentication requests per minute). However, in the long run, migration to WPA eliminated the rekey (that is, reauthentication) timing requirement, which significantly improved the RADIUS server's scalability and performance.
Along with RADIUS server scalability issues, Microsoft AD scalability and availability had to be increased for WLAN user authentication. To facilitate users who roamed from site to site (which was possible globally), RADIUS server infrastructure had to be integrated with the Microsoft AD domains deployed throughout the globe. As shown in Figure 13-2, data centers (both central and regional NOCs) were equipped with one domain controller per AD domain to facilitate users who roam globally (to minimize authentication delay) and to provide sufficient availability and scalability. As shown in Figure 13-2, WDS running in each branch office is configured to use the RADIUS infrastructure in the regional NOC as the primary RADIUS server. In the event of regional NOC failure, the central NOC RADIUS infrastructure would be used as the backup RADIUS server.
In a large enterprise WLAN network deployment, expansion to include multiple applications needs to be addressed. One of the initial nondata applications to be deployed is VoIP over WLAN. To facilitate unique security requirements for VoIP deployment, a separate WLAN/ wired VLAN was deployed per floor or per building (along with the existing VLAN[s] for data users). Using the multiple VLANs capability in Aironet APs, four VLANs were created. The initial VLAN was maintained for the data users, a second VLAN was created for VoIP WLAN users, a third VLAN was created for guest access (discussed later in this chapter), and a fourth VLAN was created as the management VLAN for the WLAN infrastructure. VoIP VLAN/SSID was configured to allow EAP authentication with WPA-TKIP along with Cisco Centralized Key Management (CCKM) for fast secure roaming (as part of the Cisco SWAN architecture). Cisco 7920 WLAN VoIP devices were deployed for WLAN VoIP access, where they were configured to use LEAP and WPA-TKIP along with CCKM to comply with WLAN VoIP security policy.
Apart from considering security policies for VoIP deployment, you should reconsider RF site-survey for the WLAN network. Specifically, the robustness of RF coverage affects the VoIP over WLAN quality. For more details on this, refer to the Cisco website.
Guest services deployment across the main campus building was facilitated by configuring the guest VLAN as open/no WEP and using a Layer 3-based service access control device (such as BBSM) to authenticate guest users via secure HTTP. Typically, guest user authentication is implemented to prevent unauthorized users from accessing an enterprise's guest network and using the network connectivity for malicious activities. As shown in Figure 13-1, guest traffic from each access switch was groomed at the building distribution layer switch, and a generic routing encapsulation (GRE) tunnel was used to transport the guest traffic to the Internet access module (typically, this would be the demilitarized zone [DMZ]) within the main campus network. A BBSM-like device was used at the Internet access module to authenticate guest users and allow Internet access. BBSM was configured to use HTTP redirect to authenticate guest users to the RADIUS infrastructure. Using a web-based online Intranet signup page, guest users were provisioned with temporary accounts on the RADIUS infrastructure.
The main challenges in this deployment were ongoing client management, RF management, rogue AP detection, and security. The requirement to continuously upgrade software/firmware is a significant challenge for the IT department, and efforts were undertaken to automate this process using readily available client management tools and home-grown applications. RF management and rogue AP detection required significant manpower during initial deployment.
However, the deployment of SWAN architecture (WLSE 2.5 or above along with 12.2 JA or above on APs) minimized the RF deployment burden and provided the capability to scan and detect rogue APs.
Finally, security is an ongoing challenge; the IT department must keep up with the latest developments in WLAN security and maintain an up-to-date security implementation to minimize risks due to commonly known WLAN vulnerabilities. The IT department uses the SWAN RF monitoring capability to continuously scan the enterprise WLAN deployment and detect any unauthorized WLAN activity. Along with RF monitoring, secure WLAN management policies were deployed to secure the WLAN infrastructure. These policies include enabling TACACS authentication on the WLAN infrastructure, enabling SSH (along with disabling Telnet access), and restricting access to the WLAN management VLAN (as discussed in Chapter 12, "WLAN Security Configuration Guidelines and Examples").
This deployment example is also taken from a large enterprise WLAN deployment in a high-tech company. Similar to Example I, this deployment covers multiple campuses across the globe, and WLAN is deployed as an overlay network. (That is, wired connectivity is considered primary and wireless secondary.) In some remote offices, WLAN connectivity is considered the primary network connectivity.
The following are the customer deployment criteria:
Mutual authentication and strong encryption exists for WLAN users.
Single sign-on is required; you do not want user intervention during WLAN authentication.
Authenticate WLAN users to back-end LDAP infrastructure.
A desire exists to deploy WLAN ubiquitously across the globe.
Minimize client management. Minimize the number of SW components to be managed on the WLAN client for user authentication and encryption.
The customer deployment environment includes the following:
WLAN users are standardized on Windows 2000 and XP.
The LDAP infrastructure is deployed globally.
The majority of the NIC cards are Cisco PCMCIA cards (80 percent of the users); however, the rest of the WLAN clients are non-Cisco and are from a mixed vendor base.
- Non-Cisco clients are supported on the Windows XP OS platform only.
Central (corporate and regional HQ) to remote sites have redundant WAN links.
- Redundant WAN links can be relied on to provide reliable RADIUS service to authenticate remote WLAN users.
A subset of the user community (sales representatives and support personal) is mobile within a country and at times across the globe.
Given the preceding deployment criteria and deployment environment, along with the customer's desire to implement IEEE 802.11i security recommendations, EAP/802.1x with TKIP (WPA model) was selected as the deployment model to provide Layer 2-based user authentication and data confidentiality. In this specific scenario, the customer selected EAP-FAST (EAP- Flexible Authentication via Secure Tunneling) and PEAP/MS-CHAPv2 (protected EAP with MS-CHAPv2) for mutual authentication along with WPA for strong encryption in the initial phase of the deployment. EAP-FAST was selected as the mutual authentication solution for Cisco Aironet clients, whereas PEAP/MS-CHAPv2 was selected as the authentication solution for non-Cisco/non-CCX clients.
EAP-FAST implementation on Cisco clients provides strong mutual authentication using user ID/password as the user authentication credential, along with the use of Protected Access Credential (PAC) as discussed in Chapter 7, "EAP Authentication Protocols for WLANs." In addition, both EAP-FAST and WPA are supported on Cisco clients for Windows 2000 and XP operating systems. Similar to EAP-FAST, PEAP/MS-CHAPv2 provides strong mutual authentication using user ID/password as the user authentication credential. PEAP/MS-CHAPv2 was selected for non-Cisco clients because EAP-FAST is not supported on them. However, non-Cisco clients standardized on Windows XP can take advantage of native OS support of PEAP/MS-CHAPv2 and WPA security features.
EAP-FAST deployment on Cisco Aironet clients was facilitated with the use of ACU, which was configured to locally store the user authentication credential (username/password). PEAP/ MS-CHAPv2 deployment on non-Cisco/non-CCX clients was facilitated using Windows native EAP supplicant, which was configured to allow PEAP/MS-CHAPv2 authentication. Cisco Secure ACS (Release 3.2.3 and above) was deployed to authenticate both EAP-FAST and PEAP/MS-CHAPv2 users. RADIUS server certificates were bought from a public PKI entity (for example, VeriSign) and installed on the RADIUS servers to enable PEAP authentication. Note that the choices here are either to use an enterprise (private) PKI entity to issue RADIUS server certificates or to use a public PKI entity to issue RADIUS server certificates to enable PEAP authentication. If you are using a private PKI entity, the trusted root CA certificate (and possibly sub-CA certificates) needs to be distributed to the WLAN clients configured to execute PEAP authentication. It is a deployment requirement to configure the trusted root CA (and any sub-CAs) on a PEAP-enabled WLAN client.
To minimize changes on the existing wired infrastructure to integrate WLAN, a pair of Catalyst 6500 switches at the data center level was integrated with the Wireless LAN Service Module (WLSM) (and Supervisor 720) to enable centralized WLAN traffic aggregation. As discussed in Chapter 9, "SWAN: End-to-End Security Deployment," this deployment model provides a single point of ingress for all WLAN user traffic and control traffic. WLSM provides a scalable WDS for radio management and fast secure roaming services. Furthermore, the 6500 WLSM integration model removes the need to span user VLANs across the distribution switch to enable seamless roaming across the enterprise network. Each wired VLAN per floor can be GRE-tunneled into the supervisor using this deployment model.
One of the major challenges in the initial deployment was that the EAP-FAST automatic provisioning for LDAP back-end user DB was not supported. Automatic provisioning enables the per-user PAC to be dynamically provisioned on the user's device. Manual PAC provisioning could be used for LDAP back-end user databases (supported in ACS 3.2.3 release and above) but was rejected due to ease of deployment concerns. Another challenge was that PEAP/MS-CHAPv2 authentication is not supported with the LDAP back-end database. To address these major deployment challenges, the customer was able to create an automated "out-of-band" (using wired connectivity) mechanism for enabling wireless users. A user who desired wireless access was directed to an internal company website and was required to authenticate to the back-end LDAP DB and specify a separate username/password for wireless access. After the user was provisioned on the RADIUS infrastructure (using an automated script), he was notified via e-mail. The user was instructed (via the confirmation e-mail) to configure his or her laptop with the username/password for WLAN authentication.
Lastly, users were provisioned on the root RADIUS server, and configuration of the root RADIUS server was distributed to the nonroot RADIUS servers worldwide (using the Cisco Secure ACS features). This facilitates users who roam between several regions to use the same authentication credential to gain network access.
As previously discussed in Example I, AAA infrastructure scalability and availability issues had to be resolved. To facilitate large-scale EAP/802.1x authentication, the AAA (RADIUS server) infrastructure had to be scaled for large campuses and redundancy had to be provided for large campus and remote office deployment scenarios. Central NOCs were used for large campuses (using the data center as the NOC), and RADIUS servers were deployed in regional NOCs to address remote office deployments. For more information, refer to the "AAA and External User Database Infrastructure Implementation Details" section earlier in this chapter.
Major deployment challenges in this example were related to chosen EAP protocols and back-end user DB compatibility. However, the customer was able to overcome these challenges using out-of-band (over the wired network) provisioning of user authentication accounts on the RADIUS infrastructure.
Finally, in addition to authentication and data confidentiality needs, the customer deployed the Cisco SWAN solution to enable RF management (including rogue AP detection) and to enable a central point of ingress for all WLAN traffic into the wired LAN network. WLSE, IOS-enabled Cisco Aironet APs, Catalyst 6500 switches equipped with the WLSM, and Cisco/non-Cisco clients were integrated to enable the SWAN solution.