Beyond WEP
So what other options exist for securing your data while in transit?
Most vendors offer 128-bit encryption modes, but these are not standardized and therefore are not guaranteed to interoperate. In addition, only some vendors provide hardware-based encryption. Without hardware-based encryption, the user employing WEP will experience some performance degradation, because the device's CPU must do extensive numeric calculations on each packet sent and received. Modern equipment might see a performance degradation of 15 percent to 20 percent, with 128-bit encryption taking a higher toll; older laptops may suffer intolerable slowdowns. Some cards perform better than others; the National Laboratory for Applied Network Research has done some simple throughput testing, the results of which can be seen at www.scd.ucar.edu/nets/projects/wireless/performance.tests.html.
Several major vendors offer proprietary solutions to the authentication-scalability problem. These solutions resemble prestandard implementations of the pending IEEE 802.1x standard, which will ultimately solve this problem in a vendor-interoperable manner (see "The Future Solution: 802.1x").
In these schemes, the wireless client requests authorization from the access point, which then forwards the request to a RADIUS (Remote Authentication Dial-In User Service) server. Upon authorization, the RADIUS server sends a unique encryption key for the current session to the access point, which transmits it to the client.
However, while such products offer solutions to the authentication and encryption security problems, these solutions work only if you buy all your access points and wireless cards from the same vendor.
For medium- to large-scale deployments, all of the above security options present difficulties: Too many people know a shared secret in the form of network name or WEP key, or there are too many MAC addresses to use for filtering, or you're tied to a particular vendor for wireless cards.
VPN to the Rescue
While we wait for 802.1x to save the day, two approaches warrant your consideration. Both involve creating special subnets for your wireless traffic. Instead of using normal routers, these subnets have gateways that require authentication before packets can be routed.
Such subnets can be created via VLAN (virtual LAN) technology using switches that support the IEEE 802.1Q standard, in which 4 bytes are added to an Ethernet frame. Under this protocol, an IT manager can combine selected ports from different switches into a single subnet. In a campus environment, this is possible even if the switches are separated geographically as long as VLAN trunking is supported on the intervening switches. Nodes that use VLAN ports cannot access addresses on other subnets without going through a router or gateway, even if those other subnets are located on the same physical switch as the VLAN ports.
Once the VLAN is established, you need to create a gateway that will pass traffic from authorized users only. A VPN server can be used to establish such a gateway, since the function of a VPN server is to require authentication, then provide the client with an IP number and encryption key. Typically, packets using the VPN-provided IP number are encrypted and placed inside another IP packet. Simply grabbing an available IP number from the wireless subnet won't fool a VPN server into passing your traffic, as the correct encryption key for each session is required. Using a VPN server as the gateway not only requires authentication of the user, but offers a huge side benefit: The wireless stream is encrypted with a key unique to the user, eliminating the need for using the shared key of WEP.
In the absence of a router, all users of the wireless subnet must create connections with the VPN server to reach other subnets, and only authorized users can do so.
There are a number of valid reasons beyond wireless security for establishing a VPN -- for example, to provide secure, encrypted access to sensitive data from a remote location via the Internet, or to make remote users appear to be local so they can access services restricted by IP number.
But the VPN approach is hardly a free ride. Ramping up your understanding of VPN technology, choosing a vendor, configuring the server and supporting a VPN client are complex propositions. Troubleshooting VPN problems is no picnic either.
Custom Firewall
A different gateway avenue is worthy of mention. Although it requires a bit of custom programming, it also uses the VLAN approach to aggregate wireless traffic to a subnet without a conventional router. In this case, the gateway off the wireless subnet is a dual-homed Unix server running specialized code. IT professionals at the Atlanta-based Georgia Institute of Technology have implemented such a solution both for wireless use and for the walk-up laptop labs on campus. Their solution is elegant and straightforward to implement.
The Georgia Tech design uses the IP Tables firewall functions in the latest Linux kernel to provide the packet-filtering operation. When a client joins the wireless/walk-up network, the firewall/router hands out a DHCP address. To authorize access, the client must open a Web browser. The HTTP or HTTPS (HTTP Secure) request from the client triggers an automatic redirect to an authentication page from the gateway, and the authentication request is passed to a Kerberos server. If authentication is successful, a PERL script adds the IP address to the rules file, making it a "known" address to the IP Tables firewall process.
From the user's perspective, the wireless network doesn't seem to work until the user launches a browser and enters a user name and password. No client installation or configuration is required. Of course, this method provides only authentication, not encryption, and will scale to just a few hundred simultaneous users. While other institutions have implemented gateways that filter based on MAC address and that require a one-time registration of a user's address prior to use of the wireless network, the Georgia Tech solution allows on-the-fly use of wireless and provides a more timely association between user and MAC address.
Tom Zeller is the telecommunications technical adviser to Indiana University. Send your comments on this article to him at zeller@indiana.edu.