Large Enterprise Deployment Examples
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.
Large Enterprise WLAN Deployment Example I
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.
WLAN Security Deployment Details
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.
Wired/Wireless LAN Integration and WLAN Infrastructure and User Management Details
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.
Figure 13-1. Large Enterprise WLAN Deployment I Example
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.
AAA and External User Database Infrastructure Implementation Details
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).
Note
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.
