The Challenges Of Wi-Fi Guest Access
August 21, 2009
Earlier today, I was passing by a conference room in the building where I work on the Syracuse University campus. One of our business partners from a local technology incubator was sitting in the conference room working on his laptop computer, trying to make productive use of his time before a meeting. I stopped in to say hello and it didn't take long before he related his frustration about the performance of our campus wireless network. This network is well engineered for performance, but I knew immediately that he was trying to use the guest access system. Performance was indeed abysmal, reminiscent of the days of dial-up networking. Needless to say, it didn't leave our visitor, someone we very much want to spend time on campus, feeling very good about our campus information services.
It's been over 10 years since I left my position as Director of Network and System Services to work as a faculty member in the School of Information Studies. During that time, I've been pretty heavily involved in wireless networking as a technology editor and analyst and I've also worked pretty closely with our central IT Services organization as they've rolled out Wi-Fi services across campus. During the early development of this network, I lobbied hard for guest access services. We have lots of campus visitors, including vendors, guest speakers, and family of students and prospective students. Many of these visitors come to campus with Wi-Fi equipped laptops and PDA's and they relish the opportunity to connect to the Internet while visiting. I thought the business case for providing guest access was pretty compelling and I was disappointed that my initial lobbying was met with considerable resistance from the network staff.
Once we got past the visceral reaction to open guest wireless access, we were able to hammer out a plan that seemed acceptable to all parties. By using wireless VLANs, some virtual network segmentation, and port restrictions, we were able to offer guest access to the Internet to our visitors without the need to authenticate. This was totally acceptable to campus visitors, and even though the lack of security left them somewhat vulnerable to eavesdropping, it was no different than what they would experience at Starbucks or hundreds of other open access Wi-Fi hotspots. Our more sophisticated visitors protected themselves using a VPN connection. The rest took their chances, relying on internal firewalls and application-layer security for modest protection.
Working out these arrangements required a little bit of compromise by all parties involved. In exchange for getting my way with guest access, I reluctantly agreed that it would be acceptable to throttle performance for these users, both to insure that they didn't impact wireless performance of authorized campus users (given the small numbers of guests, I didn't think this argument had much merit) and more importantly, to discourage campus users from bypassing the secure wireless network. Given the configuration complexities of the 802.11i-based security system, that concern seemed more reasonable. We also investigated our legal liabilities (e.g., an unauthenticated guest user sending out kiddie porn, there's that mini-maxing again) and a reputable attorney advised us that it wasn't a problem.