One of Windows XP's new features is enhanced support for 802.11b wireless networking. While Microsoft was advancing XP through its prerelease versions, the company took every opportunity to show off the features that would supposedly make XP an ideal platform for 802.11 wireless LANs (WLANs). With the release version of XP Professional in hand, I decided to test the OS's WLAN functionality.
But before I share my findings, I want to provide a little background about WLANs and discuss the challenges they present to organizations that deploy them.
A Little Background
Although wireless networking might seem to be a new development in corporate environments, the technology has been around for several years. The recent popularity of WLANs is partially due to the efforts of the IEEE, which published several standards that harnessed the industry's collective expertise and presented a unified model for WLAN technology. The result was a boom in the availability of 802.11 devices that provided high bandwidth and low prices.
When the IEEE published the 802.11 standard for WLANs in 1997, the maximum available wireless bandwidth was 2Mbps. The first wave of wireless NICs cost more than $500 each, and access points (APs)—devices that function as a combination hub for wireless clients and bridge to link wired and wireless networks—cost more than $1200. In 1999, the IEEE ratified the 802.11b standard and ushered in 11Mbps wireless throughput capability. The performance boost, combined with an average 80 percent drop in the cost of wireless hardware, made WLANs an attractive technology for businesses of all sizes—a development that Microsoft watched with interest.
Even though 802.11b wireless networking has great potential, this young technology remains a work in progress. The two areas in which the standard needs the most work are roaming and security. Not surprisingly, Microsoft has focused on these two areas in its efforts to integrate wireless capabilities into XP.
The Roaming Challenge
The ability to roam your corporate campus with an untethered portable device would seem to be a core allure of 802.11 wireless networking, but the 802.11 standard doesn't specify how roaming should work. The standard addresses functionality on only the Physical and Data Link layers (Layers 1 and 2) of the standard Open System Interconnection (OSI) model, whereas roaming functionality involves the Network layer (Layer 3). Therefore, vendors have developed proprietary methods to enable their devices to roam seamlessly, as end users expect. In an attempt to stem a proliferation of proprietary roaming solutions, the IEEE drafted 802.11f, a best-practices guideline for wireless roaming. Although this guideline has helped keep roaming solutions on similar paths, some vendors (e.g., NetMotion Wireless, NetSeal Technologies, ReefEdge, Ecutel) offer solutions that enhance wireless networking by providing especially robust roaming and security capabilities.
Every roaming scenario is unique, but Figure 1, page 50, shows a general representation. To join a network, a wireless device must associate with an AP on that network. The device then periodically scans the available range of wireless channels for other AP signals. If the device detects a stronger signal from another AP—a common event as a device moves out of the range of one AP and into the range of another—the device switches channels and reassociates to the new AP. Many vendors use Inter-Access Point Protocol (IAPP) to make this channel-switching process transparent. In a scenario such as the one in Figure 1, each AP contains an association table to track wireless devices that the AP is hosting, as well as active sessions with hosts on the network. As the wireless device moves from one AP to another, the APs share this information through IAPP and ensure that all data to and from the wireless device is properly routed. A common limitation to this seamless experience occurs when the wireless device crosses network boundaries where IP addresses must change. In XP, Microsoft offers a solution to this limitation.
When a wireless device roams across a network boundary, it must clear two hurdles. First, the end user typically must initiate an association with an AP on the new network. To do so, the user enters the new network's name (aka the Service Set Identifier—SSID) and possibly an encryption key. Second, because the wireless device's TCP/IP configuration isn't valid for the new network, the end user must manually change the TCP/IP settings or initiate a configuration renewal with a DHCP server. This process is a hassle for the power user, a potential showstopper for the average user, and a support headache for the administrator. Enter XP's Zero Configuration for Wireless.
Zero Configuration for Wireless automates the process of configuring and authenticating roaming wireless devices. In a nutshell, Zero Configuration for Wireless can detect available wireless networks, automatically configure network settings, and establish an association to an AP—in most cases, without any user intervention. You can configure profiles that contain any necessary encryption keys and other authentication to connect to WLANs automatically and by order of preference. XP can even detect the absence of an AP and initiate ad hoc or peer-to-peer networking with another 802.11b device. (Microsoft specifies that, to enjoy the functionality I just described, you need 802.11b NICs that are compatible with Zero Configuration for Windows. At the time of this writing, Agere Systems, Cisco Systems, and Symbol Technologies offer such NICs, and Intersil and 3Com plan to release compatible products by the time this article reaches you.)
To test Zero Configuration for Wireless, I used a Dell Latitude 600 portable laptop and APs that Intel, Intermec, and Dell supplied. I also tested the feature on a pair of Compaq DeskPro EN desktop systems, using Intel's LAN PCI Carrier—a PCI card containing a PC Card slot—to plug in an 802.11b wireless NIC.
My first XP experience was favorable: I installed the OS, which provided drivers for Dell's Integrated TrueMobile 1150 Mini PCI Wireless NIC and an Intel PRO/Wireless 2011 NIC, without a hassle. I logged on to the local computer and noticed that XP had immediately recognized the presence of the APs (which I'd set up in the Lab) and had associated with one of them. At a command prompt, I checked my IP settings and saw that the Dell portable laptop had received an IP address from the DHCP server on the network to which it was connected. The experience was no different than that of a wired setup.
Next, I explored my network connections: I right-clicked the icon that represented my wireless link and chose View Available Wireless Networks from the resulting menu. Figure 2 shows the Connect to Wireless Network dialog box, which lists the APs that XP detected in the Lab. To connect to an AP, I simply selected the AP's SSID and clicked Connect. Changing networks was fast, and the system automatically reconfigured TCP/IP settings each time through DHCP. After I enabled 802.11b Wired Equivalent Privacy (WEP) security for each network, establishing a connection required one more step—entering a network encryption key (I discuss WEP and security in more detail later). This key is a password containing 5 or 13 ASCII characters, corresponding to a 40-bit or 104-bit encryption key length, respectively. You enter this key in the wireless network's Network key field, which you see at the bottom of Figure 2. After you record the connection information for each network, you can set order of network preference and XP saves the information. Overall, XP's wireless-connection process was relatively smooth, particularly compared with Windows 2000's process. Under Win2K, I needed to rely on the 802.11b NIC vendor's wireless client to move between different networks, and I needed to perform much of the configuration manually.
To further test XP's Zero Configuration for Wireless feature, I roamed between the APs while adjusting security and network settings, manipulating reception and interference factors, and moving in and out of range. Impressively, XP automatically adjusted to the available network or ad hoc connections, following my preferred order of connections and choosing the AP with the strongest signal. Zero Configuration for Wireless took a lot of the work out of roaming between networks.
But although Microsoft has put a dent in 802.11b's roaming problem, Zero Configuration for Wireless is only a partial solution. The ability to automate the configuration of network settings reduces some roaming problems, but a truly seamless end-user experience would include the ability to retain your original session state across all network boundaries. In this ideal scenario, all the functionality that you enjoy in your wired office would be available to you on the road.
Currently, companies such as NetMotion Wireless and NetSeal Technologies offer innovative, seamless roaming solutions. However, a comprehensive, standards-based approach to mobile networking would provide the functionality that users want and the interoperability that administrators need.
The Security Challenge
From an IT perspective, the advent of WLANs adds a troubling new wrinkle to network security. Out of the box, most 802.11b APs transmit regular beacons announcing their presence. These beacons travel through walls to the limits of their range, which can be as wide as 300 feet. Plugging an AP into your network is like installing network jacks in your parking lot and posting a neon sign that flashes "Network Access Here!"
Even the architects of the 802.11 standard recognized the potential security risk of WLANs. As I mentioned earlier, the XP client supports WEP, the primary security mechanism of the 802.11b specification that outlines a scheme for encrypting data before transmission. Another component of WEP defines an authentication process that uses a shared 40-bit or 104-bit key. The consensus of security experts and hackers—who have mercilessly hammered the 802.11 standard's authentication and encryption components—is that WEP is worthless. (For a detailed analysis of WEP's limitations, see Shon Harris, "Security Shortcomings," December 2001.)
Because of WEP's flaws, many vendors have developed proprietary solutions, which offer varying levels of interoperability. The result is a confusing array of security choices, few of which are interoperable (because of proprietary algorithms) or highly scalable in an enterprise environment. One workable solution is to force WLAN clients to use VPN connections as if the clients are accessing the corporate network from the Internet. This scenario abandons WEP in favor of the more capable encryption and authentication schemes that VPN tunnels provide.
The Arrival of 802.1x
In XP, Microsoft has taken a relatively novel approach to security. In combination with Cisco and other members of the IEEE 802.11 group, Microsoft has helped promote 802.1x, a standard independent of 802.11b but capable of integration into 802.11 WLANs. You can use 802.1x to control access to any 802.11 LAN and as a transport for Extensible Authentication Protocol (EAP), which the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2284 describes.
The 802.1x standard promises a more secure method of authentication by incorporating encryption-key management. WEP's default behavior is to rely entirely on administrators and end users to create, distribute, and update encryption keys—which is a lot to ask. However, XP's 802.1x client relies on the use of public key infrastructure (PKI) and a Remote Authentication Dial-In User Service (RADIUS) server for authentication, then manages the key pairs that encrypt and decrypt data between the device and the AP. By default, XP changes encryption keys every 30 minutes, greatly reducing the system's vulnerability to brute-force attacks or key theft. Further integration of 802.1x in the XP wireless client lets you configure the details of the secure authentication process as part of a wireless network profile. As a result, Zero Configuration for Wireless can automatically handle reauthentication as you roam between 802.1x-enabled APs.
Unfortunately, I was able to look at XP's 802.1x functionality on only a theoretical level. While I was testing XP with the Lab's wireless devices, Microsoft was finalizing the configuration details of the components that 802.1x required on the wired network; these components include Microsoft Certificate Server, Active Directory (AD), and Microsoft Internet Authentication Service (IAS), which acts as the RADIUS server. Furthermore, very few vendors had begun shipping 802.1x-capable wireless equipment. Thus, I had to be satisfied with viewing the settings provided on the 802.1x client's Authentication tab, which Figure 3 shows. This tab provides the only visible configuration interface of the XP 802.1x client.
Overall, Microsoft's attempt to improve wireless security is laudable. However, you need to be aware that 802.1x security relies on 802.1x-compatible hardware—for example, Cisco's Aironet 350. If your mobile users attach to APs that don't support 802.1x at airports or other public places, they won't be able to use 802.1x when they communicate with the home network. As a result, if your users travel outside your controlled network, you might be vulnerable to intruders. Your safest bet is to use VPN access, which relies on more secure mechanisms and algorithms.
XP is a promising platform for mobile users who access wireless networks. Zero Configuration for Wireless will save administrators many support calls and end users many headaches. Although the 802.1x client presents some limitations—primarily because of its immaturity—it's a much more scalable solution than most hardware vendors' proprietary solutions. However, XP's 802.1x isn't likely to be a comprehensive solution to your wireless security needs.