A Field Guide to Wireless LANs for Administrators and Power Users

WLANs are being rapidly adopted in corporate settings, perhaps even more so than the Internet was, primarily because there is now an existing network infrastructure to which the APs can be attached. This parallels the Internet's rapid growth, because the catalyst there was a killer app (i.e., the World Wide Web) and the enabler was an abundance of PCs that had already been attached to a LAN. Adding IP to such a PC was easy. In a similar way, the deployment of WLAN infrastructures is enabled by the existing networks that have, by now, become ubiquitous.

Anyone who has a network can easily add wireless to it, simply by purchasing APs. The user-based access control that is integrated into products based on IEEE 802.11i will also leverage other existing network services; for example, RADIUS servers that are already used to store user credentials in support of network authentication. These university deployments probably don't qualify as hotspots, per se, since they are typically limited to use by students and faculty, and are not available to the general public.

The biggest difference between a home-based (or SOHO-based) WLAN deployment and a medium-to-large enterprise deployment is simply one of scale. Due to the fact that radio frequency energy does not propagate equally well at all frequencies, designs must allow for the fact that if a corporation decides to deploy WLANs that use the 5 GHz frequency band, they will need to place their APs closer together.

The typical deployment of IEEE 802.11b or IEEE 802.11g may require APs to be located approximately every 120 feet apart, to cover a floor. In a corporate setting, the APs will typically be located in the ceiling. Because of the geometry of the situation, the coverage is maximized when the APs are arranged in a two-dimensional crystal shape known as "hexagonal close packing." The arrangement is comprised of equilateral triangles with sides that are 60 feet (18 meters) long. For IEEE 802.11b deployments, it is only necessary to populate every other "node" in the diagram with an AP, since a spacing of 120 feet (37 meters) between APs is sufficient for this application. Many current WLAN rollout design plans are based on 60-foot cells, with the initial deployment only using every other cell position (e.g.., effectively, creating 120-foot cells). Such designs are "future-proof" in that it is possible to put power outlets, wired connections, and so forth in the center of every cell when the network is being installed, and then add APs as necessary (it is trivial to add more in the future).

Figure 8-6 illustrates the arrangement of APs. Note that the empty circles correspond to places where APs could be added to make the spacing tighter (to cells based on 60-foot separation of APs). Note that it takes considerably more APs to cover the space when there are APs at the 60-foot spacing than at the 120-foot spacing. The reason one might want to have the denser distribution of APs is that certain WLAN technology (i.e., IEEE 802.11a) operates at a higher frequency, and its signals do not propagate as well as the lower-frequency signals of IEEE 802.11b or IEEE 802.11g.

To maximize the usage of the spectrum, the three non-overlapping channels in IEEE 802.11b can be situated so as to ensure that no two channels are ever adjacent. For example, in Figure 8-7, we see that channel 1 always borders channels 6 and 11, but never needs to border another cell using channel 1. This arrangement will work whether the 60- or 120-foot cell spacing is used. The coverage circles around each AP extend beyond the radius of the inter-location distance, which reflects the reality that the signals do not stop at exactly 60 feet, they gradually decrease in power.

Outside of any of these circles, a STA is more likely to find a better signal from another AP. However, there may be locations in which a STA is approximately equally served by more than one AP, and local events, such as someone walking between the user and one AP will make the other AP appear stronger. Thus, an apparently stationary node will be "roaming" from the perspective of the APs.

It is important to note that the coverage circles are not monolithic. When a STA is closer to an AP, it will be able to achieve the highest performance, whereas at progressively greater separations, the optimal transmission speed will gradually decrease, since the modulations used to achieve lower speeds have better range due to the fact that they can tolerate a lower signal-to-noise ratio.

When a STA is experiencing transmission difficulty, which it can detect by the need to fragment or retransmit frames, it may decide that another strategy for optimizing its successful transmission would be to lower the speed at which it is transmitting, to employ a more robust modulation technique. While this choice may seem counter-intuitive, the result may be superior to using a "faster" speed, since at the faster speed the STA may be spending more time waiting for frames to be successfully transmitted than actually transmitting frames.

^[30] An AP that supported no more than 2 Mbps could easily have cost $2000 or more.

There is a significant advantage in IEEE 802.11a, in that even though the APs must be spaced closer together, there are many more non-overlapping channels (at least 8, and frequently as many as 12). The larger number of channels means that the channels can be laid out on successive floors such that the "no two adjacent APs use the same channel" rule is extended into the third dimension. If you think about it, there is no way to do this with three channels. Any channel that is put above or below any of the channels in Figure 8-7 will have to overlap with one of the others. There are only three channels from which to choose. In the plane (i.e., on a floor of a building), it is just sufficient that there are three non-overlapping channels. If only two non-overlapping channels existed, there would be no way to arrange the layout of the channels such that no two channels were ever adjacent. Therefore, with IEEE 802.11b, it is virtually guaranteed that signals from a floor above or below may interfere with signals on the floor in between, although the signal's ability to cause interference may be limited by the attenuation caused by the materials in the floor or ceiling.

For the optimal arrangement of the WLAN cells in a three-dimensional deployment (i.e., a multi-floor deployment), try to visualize stacking cannonballs or oranges or other approximately spherical items. To extend Figure 8-6 into the third dimension, you need more channels to ensure that the "no two adjacent cells use the same channel" rule is observed. We can safely assume that the AP's coverage does not extend up and down two to three floors…the floors are far more substantial than the walls, and so are much more effective at attenuating the signal, and the antennae in commercial APs tend to be designed such that they radiate most of their energy in a horizontal plane, not uniformly in all directions. Thus, it is fair to assume that a given AP will only be able to "interfere" with those on the floors immediately above and below it.^[31]

^[31] Caution: non-linear propagation effects (i.e., through elevator shafts or heating and ventilation ductwork) can create situations where this is not the case, wherein signals reach well beyond one floor above or below the device emitting the signal. Such cases will probably be discovered by a process of trial and error.

There are two ways to stack the cells. In the easiest way, the APs on a given floor are directly above or below those on another floor. In the slightly less easy way, the APs are arranged in a three-dimensional hexagonal close-packing arrangement^[32] in both dimensions, so that the number of APs is minimized. In the latter case, one can get away with a smaller number of channels and still meet the rule that no two adjacent cells will use the same channel. However, the tetrahedron need not be an equilateral tetrahedron, because the signals do not propagate as well in the vertical dimension. In the three-dimensional hexagonal close-packing arrangement, I believe that at most six^[33] channels would be required to cover an arbitrary number of floors such that no two adjacent cells would interfere with each other. Whether five or six non-overlapping channels are required is irrelevant, since IEEE 802.11a has a minimum of eight non-overlapping channels, which is more than enough to do the job.

^[32] Imagine a stack of billiard balls, oranges, or any roughly spherical shape. Each layer, as in Figure 8-6, is a two-dimensional hexagonal close-packing arrangement, and a similar arrangement of each higher layer will nest into the gaps in the layer below. As multiple layers are built up, the resulting stack is known as a three-dimensional hexagonal close-packed structure.

^[33] It's possible that only five channels are required, but I can't prove that to myself at the moment. As far as I can tell, six will work for sure.

To help visualize the stacking of the cells, Figure 8-8 attempts to show how the floor above (APs indicated in gray, which cover the intersections of the coverage circles) nestles among the coverage circles of the middle floor (in black), and how on the floor below (in gray, but which are drawn under the intersections of the coverage circles), the APs nestle in the opposite intersections of the coverage circles. On either floor, the gray (below) or gray (above) circles are arranged exactly as the black circles on the middle floor are arranged, in a hexagonal array with 60-foot spacing.

The author, using his limited drawing capabilities, has tried to indicate the main floor as the one with the black central APs, and the concentric circles indicating the APs' coverage areas on the main floor. The APs below are indicated by gray circles which are visible under the intersection of the coverage circles, and the APs on the floor above are indicated by gray circles that block the intersection of the coverage circles on the main floor.

Incremental RSN Deployment Using Channel Overlays

An optional capability for devices (in particular, APs) that support RSN is that of the TSN. TSN allows a mix of RSN and pre-RSN STAs to associate with a given AP. When TSN is enabled, traffic to or from the AP is encrypted using WEP, TKIP, or CCMP (whereas WEP is not allowed in a pure RSN situation). In a WLAN that is configured for encryption, all data frames (MPDUs) will be encrypted, once the key derivation is complete. It is illegal to send unprotected traffic in such a WLAN. However, even without allowing for unencrypted traffic, it should be obvious that this situation is ridiculously insecure. Because it supports WEP, TSN is as insecure as WEP was (which is just about as secure as sending data in the clear).

TSN is more appropriately discussed in this chapter, which is concerned with deployment-related issues, versus Chapter 7, Security Mechanisms for Wireless LANs, for two reasons. First, TSN is not secure, and second, TSN is purported to exist solely to aid deployment of RSN (the author finds this to be a highly dubious assertion). The TSN approach does not enhance security unless it is used very rapidly as it was intended as a transition mechanism. Then, it will have improved security by aiding the elimination of the old technology that was insecure.

There is no performance or other benefit to running a WLAN in TSN mode. In fact, due to the complexity of TSN, the AP may have software implementation errors that create their own security vulnerabilities. The author has seen "transitional" technologies or designs implemented too many times in the past, after which people got used to them and the transitional schemes became "operational" (i.e., part of the expected mode of operation). Thus the author is pre-disposed to advise against starting down that path, if it can be avoided, since it is likely to make it more difficult to step off that path, human nature being what it is.

For security reasons, most corporate WLANs are maintained outside of the corporate firewall, and users must use VPN software to access the "inside" of the corporate network (even if they are physically inside the corporate office space). Even when proprietary techniques such as cisco's Lightweight EAP (LEAP) are used, which offer much better authentication than WEP's Shared Key authentication, but which do nothing to improve key management, operating a WLAN still represents a sufficient risk such that it makes sense to take a security stance that distrusts all WLAN STAs.

However, there is a way to avoid the complexity and insecurity of TSN and still maintain the goal of mixing RSN-capable and pre-RSN STAs. Imagine that all of the APs in Figure 8-7 are pre-RSN APs. As an alternative, consider a deployment that effectively creates a "secure parallel universe" overlaid on the existing floor plan. In order to deploy RSN technology, new RSN-capable APs could be rolled out and mounted near the existing APs. Rather than replacing the old with the new, it would be better to run both together for a short time. The configuration of the original APs need not change at all. The new APs would be configured to run on different channels (e.g., if a new AP were mounted next to an AP that was on channel 1, the new AP could be on channel 6, or similarly, a new AP next to an existing AP on channel 6 could be configured to use channel 11, and finally, a new AP on channel 1 would be situated next to an existing AP that was on channel 11).

If an RSN-capable STA arrived in any of the cells, it would perform an active or passive scan and discover that one of the APs was sending out RSN IEs in its Beacons or Probe Responses, which would cause the RSN-preferring STA to associate with that AP (and use the RSN AP's channel) rather than the other AP that it hears, which is advertising that it supports WEP (the legacy APs could even be configured with no encryption, a capability that is impossible in the context of TSN). When the RSN and pre-RSN APs are mixed in this way, the transition to RSN is straightforward. Simply watch the old network and once very few STAs are using it, work out how to migrate these stragglers to RSN capability.

When is TSN useful? There are two cases of "WLAN upgrades" that could enable TSN. Remember, to be able to use TSN, users must upgrade their APs to support it. Such an upgraded AP will (at a minimum) probably support TKIP, IEEE 802.1X, and WEP.

• A firmware/software upgrade for existing deployed APs. This will provide basic RSN capability (i.e., TKIP).

• A newly purchased AP device. This will support both TKIP and CCMP, and perhaps optionally WEP (either in the context of TKIP, or alone).

The latter type of device is the one that could be rolled out in parallel with an existing WLAN infrastructure. The former, as it is a software upgrade, is not really going to provide an opportunity to co-locate two APs in the same vicinity. An upgraded AP that supports RSN (i.e., TKIP) may or may not support TSN, but it will certainly support WEP (since TKIP is built on WEP). Even a newly purchased RSN-capable AP will support WEP if it supports TKIP, but the hope is that customers will be eager to migrate to the most secure configuration as soon as it is available.

Just because an AP supports WEP does not mean it can use it keys are required for a device to successfully participate in WEP. If the network manager does not configure WEP keys into the device, then the device will not be able to perform Shared Key authentication, nor will it be able to perform WEP encryption. For the case of devices that receive firmware and/or software upgrades, the customer who performs such an upgrade is probably interested in investment protection at least as much as in security, and for this type of customer, the TSN capability will probably be quite valuable, especially since both new and old STAs will be able to access the newly upgraded AP. However, the customer who purchases new APs would be well advised to configure them in pure RSN mode. Besides the fact that they are much more secure, the usability is much better on the part of the end users, since they only need to enter the necessary credentials to enable their chosen EAP method to successfully authenticate the user to the network.

In the event that the EAP method consists of per-STA pre-shared keys,^[34] each user only needs to enter his or her pass phrase, from which the PSK is derived. Given that we have assumed that there is an existing WLAN, there is reason to expect that the TSN capability is not that useful, since there is a presumed infrastructure that is already in place that supports WEP. The new RSN-capable APs can support the new RSN-capable STAs without needing to enable TSN mode. There is already a network in place that allows the pre-RSN STAs to attach to the WLAN. The usefulness of TSN is maximized when an AP is upgraded from pre-RSN to TKIP capability, since the "new" APs are just upgraded old APs, which can support RSN-capable STAs without needing the pre-RSN STAs or APs to be changed at all. Any new RSN-capable APs can implicitly support all forms of encryption, authentication, and key management.

^[34] Remember that the PSKs in use at any given time should all be unique on a per-STA basis. A shared PSK, across multiple STAs, is more vulnerable to attack and is not recommended.

Is this overlay technique superior? For one thing, the availability of strong security for WLANs is likely to unleash a torrent of purchasing by corporate IT departments who have not yet invested in WLANs because of the lack of security. These fence-sitters will start purchasing APs rapidly once they are comfortable that the security issues have been resolved. The author has reason to believe that the installed base, which TSN is designed to protect (in the sense of investment protection, not security protection), will soon be dwarfed by RSN-capable (or WPA-capable) devices. In a market where the legacy devices are outnumbered by the next generation, the motivation to produce patches to the old generation is greatly reduced, and the larger market for RSN-capable (or WPA-logo-ed) devices will drive down the prices for the new technology, making a "forklift upgrade" economically feasible for early adopters of WLAN technology. It's very likely that many existing corporate WLAN deployments have stalled pending the resolution of the well-publicized security issues, so any new RSN-capable equipment that will be purchased starting later in 2003 could simply be used to build out the parts of the wireless network that were on hold, and eventually the original APs could be swapped out in favor of the RSN-capable APs as they either fail or are replaced due to the network manager wanting a common RSN-capable hardware platform throughout his or her WLAN implementation.

In general, TSN seems like a solution in search of a problem (in some ways, it's a problem in search of a solution!). TSN is only useful in a limited set of circumstances, and it is unfortunately perpetuating a security model that is known to be broken. The IEEE 802.11i TG has emphatically stated that TSN is only meant to be a short-lived approach, and that any organizations that use TSN should migrate to RSN as quickly as they can. It is also in the economic interest of hardware vendors to enable this transition to new RSN-capable hardware, since the profit margins on selling a new RSN-capable AP should exceed the profit derived from selling software/firmware upgrades to the installed base. Not only is this not terribly profitable, it is also likely to be a support nightmare, since the number of things that can go wrong in a TSN is significant. It is likely that there are many corner cases lurking that are not obvious, and so are not easily tested. The result is that the end users become the beta testers.

The inclusion of TSN was done with the best of intentions, but it will probably not be widely used (at worst, it risks giving IEEE 802.11i technology a bad name by association, if poor implementations of TSN get bad press), but if an overlay design is chosen, there is no need for the complexity of TSN. The other reason why the overlay technique is superior is that the STA side of the equation will rapidly evolve toward RSN, as new equipment (e.g., laptops with embedded Wi-Fi support, newer model PC Cards, etc.) is likely to support RSN (or the Wi-Fi Alliance's WPA) in its "out-of-the-box" configuration. The market for legacy pre-RSN devices should quickly drop to near zero.