Remote users can feel marginalized if they don't have the same technology amenities that employees at headquarters enjoy, and they won't take design complexity, management overhead, or security risk as an excuse. A prime example is a branch office that deems itself underserved because "everyone else has wireless." Employees might just pitch in to buy a $50 access point and believe they're doing the corporate IT folks a favor by solving the "problem" themselves.

Of course, security is only as strong as its weakest link, so that $50 rogue access point could neutralize thousands of dollars' worth of sophisticated, layered access controls. Put simply, an open AP connected to the corporate network is tantamount to placing an Ethernet jack in the parking lot. Even when the device is configured with Wired Equivalent Privacy, it's vulnerable. Armed with a high-gain antenna and a proximate location to the target, an attacker can inject and/or collect 802.11 data frames and recover static WEP keys and passphrases used by the "helpful" employee who's attempting to secure his unauthorized device.

To make matters worse, once someone gains access to the remote office's network and obtains a valid IP address, the intruder could appear, at least from a network perspective, to be an authorized corporate user. Unless you have network access control or core firewalling in place, the attacker may well gain access to all local and WAN-connected corporate assets via the branch-office connection.

With the advent of enterprise-class 802.11n systems, the remote WLAN equation becomes even more complex. The upside is that 802.11n will greatly increase the throughput rates of each AP radio while enhancing IT's ability to identify rogue devices. The downside--besides the enormous cost premium that 11n gear commands--is that it will be even easier for wireless users to saturate available WAN bandwidth.

DIG DEEPER

THE N FACTOR

Don't give in to irrational exuberance over the latest Wi-Fi standard. Cold, hard calculations are called for.

Download this
InformationWeek Report

>> See all our Reports <<

The best answer for geographically diverse organizations may be to provide enterprise-class 802.11 WLAN coverage at branch offices. While you could just stick lightweight access points at remote sites, link them to the controller at your main office, and call it a day, problems with subpar connectivity and bandwidth hogging make this a poor choice. Better are scaled-down WLAN controller appliances from companies such as Aruba Networks, Cisco Systems, and Motorola-Symbol that can support as many as six access points while providing many of the sophisticated capabilities available in controllers that scale to well over 1,000 APs.

Alternately, manufacturers such as Aruba and Cisco offer enhanced systems designed to extend corporate WLAN standards to branch offices while addressing the bandwidth constraints inherent in WAN connectivity. Aruba's Remote Access Points and Cisco's Hybrid Remote Edge Access Points use standard lightweight APs loaded with specialized firmware that integrates seamlessly with centralized WLAN controllers, letting branch offices enjoy the functionality and security provided to headquarters without the need to deploy local WLAN controllers--or have advanced IT resources on site to maintain them.

DESIGN TIME
The dominant WLAN architecture secures wireless access using a strong controller and lightweight managed APs. This centralized approach makes it easy to create WLAN profiles to provide tailored wireless access to diverse groups. For companies using multiple controllers, the addition of a wireless network management system can bring all WLAN infrastructure components into a single management interface.

There are a few major design requirements to keep in mind when rolling out any 802.11 wireless service to remote sites:

• Security implementations must be consistent and interoperable with the setup at headquarters, and user authentication should be uniform. If your main site uses EAP-TTLS authentication, remote offices should do the same. Encryption should be consistent as well.

• Wireless intrusion-prevention systems should be used to enforce a "no rogue access point" policy. This security control prevents purposeful--and clueless--attachment of unsanctioned APs. A well-designed system can disable rogue APs by shutting down their copper LAN switch ports, temporarily tar-pitting their radio frequency resources, and helping IT locate the device.

• Web-portal-based guest access should be made available for visitors. Captive portal functions like this should always use secure authentication protocols, such as HTTPS.

• Apply role-based access control bandwidth throttling (on a per-group or per-user basis) when available.

So why not deploy the same lightweight access points at branch offices that are used in headquarters and manage them with central controllers? Short answer: because of how the centralized WLAN model works, in particular traffic and data flows. When a lightweight access point powers up, it obtains an IP address and information about the controller with which it needs to communicate. Once the remote AP has this information, it creates a tunnel--using GRE (Aruba), LWAPP (Cisco), or another format--over the WAN back to the controller to obtain updated WLAN configuration information, firmware, and settings.

It's a feasible setup, but because the hardware has not been optimized to communicate over a WAN link, inefficiencies and failure points greatly diminish the appeal of this option. For example, if connectivity to the controller is lost, as from a WAN failure, the access point can't by itself process WLAN traffic and will begin searching for a backup controller. When this occurs, wireless clients are dropped and can access neither remote nor local resources. Note that some WLAN vendors, including Colubris and Trapeze Networks, do build resiliency into their basic APs by leveraging a design model called "distributed forwarding" to push more switching intelligence back out to the AP. This approach has its own pros and cons, however.

In addition, most basic lightweight access points are configured to tunnel all traffic back to their target controllers. Thus, traffic destined for any device on the network--even those at the same site as the AP--must first traverse the WAN to get to its destination. For traffic originating and terminating at the remote site there is no local switching option, so the data frame must cross the WAN twice just to exchange one data frame. Stated simply, basic lightweight APs aren't smart enough to selectively forward traffic based on source and destination information.

Clearly, while the basic AP architecture model can be made to work, it's not an elegant solution to the remote office WLAN problem. Better choices: a scaled-down controller appliance at the branch site or a product, like Aruba's Remote Access Points (RAP) or Cisco's Hybrid Remote Edge Access Points (H-REAP), that extends central WLAN management to remote sites. Both the controller appliance and remote AP options provide WLAN deployment consistency, direct remote troubleshooting capabilities, wireless intrusion-prevention system capabilities to enhance RF visibility, and the knowledge that corporate WLAN security standards are being extended to all locations within the organization.

(click image for larger view)

A BETTER WAY
Aruba's RAP and Cisco's H-REAP technologies, choosing two as examples, reintroduce intelligence to the formerly "dumb" lightweight AP model and are designed to reduce the required round trips to the controller by selectively switching packets locally if they're destined for local devices. Setting up a RAP or H-REAP access point requires only configuring the device to provide LAN awareness so local switching can be performed when possible.

Picture a situation where Mary and Bob are in the same office, and Mary's PC needs to connect to Bob's PC. If the local access point is joined to the headquarters controller via the WAN in a conventional manner (that is, with no local switching intelligence) the volume of WAN transactions is enormous, as illustrated by the diagram on p. 38. By using RAP or H-REAP functionality and adding some intelligence into our switching decisions, data flows can be optimized.

As with the other design options, there are a few considerations to keep in mind. First, RAP/H-REAP APs are not designed to support wireless VoIP or other latency-sensitive applications. In addition, while RAP and H-REAP do allow for some local authentication robustness, typically, if access to the controller is lost, new users won't be able to authenticate using common 802.1X/EAP mechanisms. Depending on your authentication approach, some configuration can be done on the APs themselves to provide some local authentication of users to help bridge outages where WAN resources might not be available. Vendor support for local authentication and EAP types varies, so ensure compatibility before deployment.

One big win is flexible remote offices: When an AP is in RAP/H-REAP mode, it can provide remote users with secure access to corporate resources. This approach can be extended to road warriors, who could plug a preconfigured access point directly into a customer network. In this regard, Aruba RAP devices have an advantage because they use standard IPsec VPN protocols to secure the connection between the AP and controller and to allow either wireless or wired access directly to the AP for tunneling back to the controller. The Aruba system has other benefits as well, such as the ability to traverse remote captive portals like those commonly found in hotels. In contrast, Cisco's H-REAP uses LWAPP, which authenticates WLAN components with public certificates and encrypts communications with the Advanced Encryption Standard.

Overall, the RAP/H-REAP architecture is ideal for extending enterprise WLANs to remote sites requiring up to three APs. IT gains features and design options that facilitate consistency, extend centralized management, and provide WLAN visibility into remote offices. But even with these advantages, there are uses for which there's no substitute for a local, dedicated controller.

(click image for larger view)

LOCAL CONTROL
Whereas RAP and H-REAP are tailored for sites needing three or fewer APs, a controller-based system is more viable for larger locations and those in need of high performance for applications such as voice over Wi-Fi. One design option, depending on the size of the office being served, is the placement of a suitably sized WLAN controller at each site. When deciding whether or not to place a controller at a remote office, consider the following issues:

• Centralized management: As the number of controllers grows, so does the overhead required to maintain consistency and properly monitor the various systems. Vendors typically offer customized wireless network management systems that provide a unified way to create WLAN profile templates, manage multiple controller settings, and centralize alerts across a geographically diverse enterprise. There's a cost associated with purchasing and configuring such software, so this should be factored into the overall equation.

• Scalability: Controller capacity typically starts at five or six access points and can grow into supporting many hundreds or thousands of devices. The cost per access point decreases precipitously with larger controllers as economies of scale begin to kick in. Consider such factors as WAN latency, quality of service, and local traffic filtering to make an informed decision.

• Quality of service: RAP/H-REAP systems aren't designed to support the fast roaming required to optimize secure voice communications. If a remote location requires a high level of performance, along with multi-AP roaming, a local controller may be required.

• WAN latency: A slow WAN connection, or high congestion on the remote office LAN, can cause high-millisecond latency. If RAP/H-REAP devices have slow communication (more than 100 milliseconds) back to their controllers, they can become temporarily "disconnected" and cut over to local-switching mode. As network issues are resolved, the devices re-establish connections with the controllers and switch their states again. This scenario may lead to user connectivity problems and impact the accessibility of the WLAN.

• Local resiliency: A local controller makes network operations less dependent on the WAN connection. RAP/H-REAP devices are designed to be flexible, offer direct authentication options, and perform local switching to help compensate for a lost WAN connection; however, they're not as flexible as a controller located just off a local high-speed LAN. A local controller can facilitate direct firewalling, fast and secure roaming, EAP off-load, VPN termination, and a host of other features directly at the remote location.

For most sites, the correct architecture decision can be made by simply determining the number of required access points. Generally speaking, if the remote location is very small, requiring one or two APs, then the RAP/H-REAP approach is almost always the best way to go. If the office is a bit larger and requires five or more access points, then placing a controller on site is probably the right solution.

For those offices falling into the gray area of three or four access points, review the site's requirements and capabilities to select the best approach. Cost considerations may also play a significant role in the decision-making process. Cost will vary based on the number of sites, the presence of existing infrastructure, the availability of technical support teams, and business factors. When calculating costs, remember that RAP/H-REAP access points still count toward the total number of APs that a controller can manage. So in addition to the cost of the access points, you'll need enough available AP capacity on your central controllers to manage all the remote access points. Fortunately, the cost per AP decreases as the size of the controller increases.

Richard S. Dreger Jr. (CISSP, CWNE) and Grant P. Moerschel (CISSP, CWSP, CCSP) are co-founders of WaveGard, a vendor-neutral technology consulting company. Contact the authors at [email protected].

Illustration by Nick Rotondo

Continue to the story:
802.11n Is Here. Get Ready For A Wire-Free Enterprise