It’s time to stamp out rogue wireless LANs by deploying a real one. But should you choose a switch or a gateway?
Nothing makes network administrators cringe like the prospect of deploying a large wireless LAN.
Security is only the most obvious stumbling block. True, immature WLAN security standards have led many administrators to deploy slow, awkward VPNs to “secure the air”. But perhaps more intimidating is that in wide-scale deployments, configuring APs (access points) for optimum coverage can demand a rocket scientist’s understanding of RF (radio frequency) management. These obstacles have led IT to drag its feet on wireless — even as rogue users take matters into their own hands and set up dangerously unsecured APs.
Thanks to a recent flood of new WLAN gateways and switches, however, conventional excuses are wearing thin. Today, IT managers are stalling for another reason: There are too many choices for solving WLAN security and RF management problems.
The first volley of solutions came from the gateway developers — such as ReefEdge, Bluesocket, and Vernier Networks — and mainly addressed security. More recently, WLAN switches have added automated RF management. This enables IT workers to handle APs as a group from a central point, easing setup and reconfiguration dramatically. And native Wi-Fi security protocols are actually reaching the point where they can be used effectively in the real world.
IT teams now face the challenge of choosing among a host of new devices — the most advanced of which are manufactured by unfamiliar companies — even as further technology evolution seems certain and a shakeout among hardware vendors looms. Moreover, each vendor is adamant that their way is the only way.
“People get into this religious-war business, but one size doesn’t fit all,” says Mike Disabato, senior analyst at Burton Group. Ultimately, he says, the layout of the existing LAN, the desired WLAN coverage, the authentication mechanisms, and the integration options all weigh heavily on the choice of technology for a given wireless network.
Gateways vs switches
One of the first decisions IT must make is to choose between a gateway solution and a WLAN switch.
Companies that have already deployed a slew of APs and are loath to replace them may want to consider gateways because they can operate with APs from any vendor. In addition, gateways stray the least from standards-based technology. But they also focus mainly on managing security and user profiles, not on managing the WLAN itself. Services such as rogue AP detection or AP layout planning must be added piecemeal, usually by opting for third-party solutions.
“We think it’s important to get this technology from someone who has all the parts so you don’t have to be a system integrator,” says Dan Simone, vice president of product management at Trapeze Networks, a WLAN switch developer. Burton’s Disabato has polled the WLAN switch vendors and found that each bundles similar features, including rogue AP detection and AP deployment tools. The downside is that — because the 802.11 standard fails to address such issues — these features are implemented differently from vendor to vendor, leading to classic lock-in.
One key RF management feature common to many WLAN switch providers allows enterprises to eliminate time-consuming site surveys for determining the best places to station APs. Customers can port existing drawings of floor plans into an application that maps out where APs should be located. Once the APs are in place, the WLAN switch automatically configures channel settings and power levels so the APs don’t interfere with each other.
To do that, however, the WLAN switch makers must alter the way APs work. The 802.11 standard defines how a radio pulls data packets out of the radio waves and sends them upstream into the network, explains Doug Klein, CTO of Vernier Networks, a gateway provider. But the standard makes no mention of sending control data upstream, which makes automatic configuration of generic 802.11 APs, such as QoS and RF power adjustments, impossible. “That’s why the switch guys always have proprietary APs,” he says. “They have to modify the firmware to send more stuff, like control data, upstream.”
A number of wireless switch vendors have come together to develop a draft standard called LWAPP (Lightweight Access Point Protocol), under the auspices of the Internet Engineering Task Force. LWAPP would define the protocol for a WLAN switch to AP communications channel. Such a standard would allow enterprises to mix and match WLAN switches and APs from different vendors. The biggest obstacle to LWAPP is Cisco Systems, which has its own proprietary scheme for RF management called the Structured Wireless-Aware Network Framework.
For those unafraid of proprietary solutions, RF management features make WLAN switches compelling, particularly for wide-scale deployments. The basic choice in switches is between layer 2 and layer 3 switch functionality.
Layer 2 solutions require that an AP be physically connected to the WLAN switch responsible for WLAN management. This means a WLAN switch must be deployed on every floor in every wiring closet. Layer 3 solutions don’t require that physical connection. Instead, they exploit frame tagging to “find” the management unit at the centre of the network.
Aruba Wireless Networks makes WLAN switches that operate at layer 3 and enable administrators to hang APs anywhere. “The AP will automatically bootstrap itself over the IP network and connect to the WLAN switch,” says Keerti Melkote, vice president of project management and founder of Aruba. The AP will appear in the IP subnet already provisioned for that floor or office, so the IT manager doesn’t need to manage the LAN-level VLAN assignments of APs deployed across the network.
Chantry Networks has developed its own layer 3 solution. Cornell University, which is testing Chantry’s gear, plans to deploy its WLAN in buildings across the campus, each of which has several wiring closets. But each floor may require as few as four APs. Many layer 2 WLAN switches have 12, 24, or even 72 ports. “That’s stranded capital,” says Bob Meyers, co-founder and CTO of Chantry. By contrast, Chantry’s layer 3 switch sits in the control centre and manages all the scattered APs remotely.
Layer 3 switches may sound like the obvious choice for big deployments, but they come with their own set of caveats. Layer 3 WLANs may be less secure because the APs must include an IP stack and SNMP capability in order to route data along an IP network and manage the AP, says Harry Bims, CTO and founder of WLAN switch developer AirFlow Networks. “By not having a TCP/IP stack at the radio, it’s hard to hack into (layer 2 switches),” Bims says.
Another potential layer 3 downside is performance. “It will add more latency,” says Philip Kwan, product manager for enterprise applications at Foundry Networks. That’s because all the traffic travelling to and from APs in remote locations must tunnel back to the appliance at headquarters, which could be across the country.
Trapeze says that the next version of its switch will enable centralised remote management of APs via TCP/IP at layer 3, but pass normal traffic at layer 2. And Extreme Networks introduced a new switch in September that supports wired Ethernet or WLAN on every port on the box. Last but not least, Foundry will introduce software this month that will allow administrators to make its switches wireless-aware on a port-by-port basis.
Foundry’s first-generation solution, a fat AP that is centrally controlled by software and was expected to be available this month, claims a management protocol that travels over routed networks. So even though the APs operate at layer 2, the management protocol allows an IT manager to centrally control certain functions of the AP. Regular traffic is routed locally through a local layer 2 switch that is none the wiser.
Cisco Systems advocates allowing the user to determine where intelligence resides in the network in order to customise products for specific uses. For now, Cisco’s wireless domain manager, which handles authentication, resides in the AP. That means that in remote offices, user authentication happens locally rather than travelling back to headquarters to be centrally authenticated.
Ultimately, each solution will find a home. “The layer 2 thing makes sense when trying to wire up an airport and do RF management in a signal-rich environment where a central controller deals with all the hot spots,” Disabato says. But a system that supports fat APs or can route over a wide-area routed network is best for an implementation that requires remote AP deployments, he says.
Securing the network
No matter what hardware an enterprise chooses, it will immediately land in the middle of today’s hot security debate: whether or not to use a VPN to secure the wireless network.
Right now, the prevailing sentiment is pro-VPN. But some suggest that enterprises are stuck on VPN technology for the wrong reasons. “Our take is IPSec is a buzz phrase that makes senior managers feel comfortable,” Trapeze’s Simone says. Meanwhile, new security extensions to the 802.11 standard promise security more in tune with the demands of WLANs.
Now is the time to begin exploring security based on the new protocols, says Paul deBeasi, vice president of marketing at Legra Systems, a WLAN switch maker. “VPNs are a stopgap. Over the next six to 12 months, WPA (Wi-Fi Protected Access) will be dominant,” deBeasi says. A subset of the forthcoming 802.11i standard due to be finalised late this year, WPA includes TKIP (Temporal Key Integrity Protocol) encryption — a vast improvement on WEP (Wired Equivalent Privacy). It also includes 802.1x authentication, which employs EAP (Extensible Authentication Protocol) to validate user certificates against RADIUS, Kerberos, and other authentication servers.
Simone and deBeasi believe that WPA will actually deliver stronger wireless security then VPNs — and be easier to deploy and manage. For one thing, TKIP is lighter weight than IPSec. For another, VPNs encapsulate packet headers, so there’s no way for the VPN to discern between low- and high-priority packets, notes Ron Seide, product line manager of Cisco’s wireless networking business unit. That could pose problems for enterprises that want to deploy voice or other streaming media over WLANs.
Nonetheless, VPNs prevail today, and the network hardware vendors have several approaches to implementing them. Vernier’s solution terminates the VPN at its box, rather than an enterprise’s existing VPN concentrator. “With a concentrator, you have to create a single VLAN across the entire network to transport unauthenticated traffic across the network to the VPN concentrator where it’s terminated and then back to the network,” Vernier’s Klein says. “It’s incredibly inefficient.”
Colubris Networks pushes VPN termination even further out, all the way to its intelligent APs. Most VPN appliances were built to handle occasional usage by travelling employees, not by a slew of internal WLAN users, says Pierre Trudeau, CTO and founder of Colubris. Terminating the VPN in the AP lightens the traffic running through the concentrator and eliminates a potential bottleneck.
Without question, enterprises looking to deploy a robust WLAN today will have to make some compromises. One vendor’s central management tools could be just right, for example, but security options may be limited. On the other hand, a restrictive list of approved hardware vendors could force IT management to consider solutions that lack effective RF management. But one thing is clear: The time for procrastination is running out. If you don’t deploy a WLAN, rogue users will.