|Designing Wireless LANs|
|Tuesday, 01 February 2005 21:00|
I've been participating in some wireless LAN designs lately. This has lead to writing a seminar which I'll present at "Cisco U" sessions in Herndon, VA and Columbia, MD, on February 3-4, 2005. This seemed like a useful topic to also cast as an article, or more likely, several articles. Which explains my choice of this month's topic!
I don't normally include dates in the body of articles, since that makes old material rather blatant, even where still applicable. In this case, however, WLAN design practices are rapidly changing and hence some indication of date is highly necessary. Let me also caution the reader that this is my own particular take on the subject, not Cisco's or anybody else's. Just some ideas that have been jelling over time, that I hope you'll find helpful!
In case you're thinking, "What about the Cisco Airespace acquisition?", yes, that's a good question. I'm waiting to see how Cisco positions the WLAN product sets. It seems like Airespace might be a good Small-Medium size business contender, for position in between Linksys (SOHO) and large Enterprise. Simplicity of installation and management are attractive. Either that, or Cisco bought them for customer base and technology, especially management software. Scalability while preserving simplicity seems to be the open question when comparing to the designs using the Wireless Services Module (WLSM). More below.
Why Wireless LAN (WLAN) Design?Several things alerted me. First, I've seen some non-Cisco materials equating WLAN design to doing a site survey and assigning WAP locations. That's the obvious thing you have to do, but certainly isn't everything. Second, there are a lot of capabilities in the Cisco WAP's, something I don't see the trade press catching onto. Yes, because of that, they can get complex to configure, too. In doing designs recently, I've seen that sites may not have thought past the "wireless for mobile users" stage, i.e. where they want to be in 1 or 2 years. That can affect the design. Third, we've seen some work or queries which sounded to me like resellers or in-house staff doing rather minimal installations. There seems to be a certain amount of attitude that "it's like putting a Linksys in your home". Unfortunately, it's not that simple.
RequirementsGood design takes into account present and near-term future customer requirements. A list of factors to consider when determining WLAN requirements follows.
DesignsOne good place to start is with current design approaches. That lets us understand their strengths and weaknesses, since we can compare different models. This also seems like a good starting point because I've got some diagrams we can discuss -- always better than pure prose (1:1000 ratio).
The first approach is simple but costly. Put WAP's and perhaps guest wired ports in conference rooms into a separate physical infrastructure . Dedicated wiring, separate switches on each floor, etc. This is not cheap, duplicates internal cabling and infrastructure, and increase overall management complexity. This is sometimes accompanied by having employees use IPSec to access the corporate network via the VPN concentrator and/or firewall. That creates a potential throughput bottleneck, since you pay solidly for each Mbps of IPSec throughput you want. This design was popular when WLAN authentication and encryption couldn't be trusted. It still may be used by law firms, financial organizations, and folks who worry significantly about liability, accidents allowing outsider access to internal network, etc. My personal take is that if you use this design, you should probably also really control physical access and wired ports, e.g. use 802.1x for wired network access.
Note that a multi-floor building can use different WAP VLAN's for each floor, although to do that it helps to have a firewall that does trunking. If you want core routing, you can use VRF-Lite (MPLS-style VRF interface-specific routing tables without the MPLS). The alternative is to run a L2 trunk from the core out to the firewall.
You can also substitute some sort of authentication and access control device for the firewall, sort of dedicated firewall with some other features. WLAN switches play to this space, although some apparently do some form of L2 or L3 tunneling back to central WLAN switches. (Questions to ask: how is that configured? Automatic? L2 or L3? What protocol? How do I scale it up if I need to?)
Note that a number of WLAN switch vendors do not seem to have central switch location/tunneling, in which case you scale around a L3 core by adding multiple WLAN switches as access control points. If you do that, there's cost. Also, can they be centrally managed, or does each have to be individually managed and configured?
Another good question: if the WAP is not authenticating and doing encryption, what protects the authentication? What preserves confidentiality of NIC to WAP traffic?
My last question for a vendor of such a device: is it a switch, a web authentication box, a firewall, a NAT point, an IDS, what is it? It's convenient having them in one box. Why should I think the vendor has any particular expertise at them? Why do I want to duplicate elements I probably already have elsewhere in my infrastructure (cost to buy, cost to manage)?
Vendors in this space include: BlueSocket, Vernier, Airespace, Enterasys WAP's, Cisco BBSM, Cisco IOS web auth-proxy, Cisco Perfigo, etc. This approach is still necessary for these in-line authentication, ACL, and/or pre-scanning boxes to be effective.
Of these, it appears Airespace has some simple way (DHCP attributes perhaps? Or initial manual setup?) for its "simple" WAP's to find a central WLAN switch and tunnel through a network, possibly at L3. The posted whitepapers do not provide sufficient technical detail. That's presumably something Cisco ownership will rectify, eventually.
I've always been puzzled as to why vendors don't want to tell me what they're doing, as in open access to good tech docs about their product. Let's see, they've finally got me where they want me, taking my scarce time to look for information on their product, and they instead turn me off?
Some of these vendors point to simple ACL's or other controls on user traffic. This reads like a template for the relevant group of users is applied to traffic to/from each user, substituting the user address as source or destination, as appropriate. Details probably vary by vendor, and online details seem to be mostly lacking, not that I've expended a whole lot of effort trying to find them. I've been dubious about this approach. It seems like it would work reasonably well for small to medium networks, so maybe I'm suffering from large network-itis. My concern about this form of access control is that it seems to lead to one huge ACL that controls everything each user might ever try to access. That's easy to do for guests (block internal network, allow Internet). It gets progressively harder in bigger networks. It's usually simpler to have local policy enforcement nearer destinations, e.g. an ACL for who is allowed to get to servers, applied to control access to just those servers. But to do that, you need source address to tell you about class of user. Something to consider when thinking about using such boxes in a design. It recently dawned on me that different users could be re-DHCP'd or NAT'ted into different address pools, which would give the kind of distinctive source addresses I'd prefer. Whether these authentication and access control boxes can do that is an open question.
That brings us to a more recent model, which I'm calling the infrastructure model. The key to this design is the perception that strong encryption to/from the WAP buys strong authentication, and that with the two of them, authentication controls and confidentiality are at least as good as for the wired network.
If your security risk level is not too high for this, and if you have simple roaming needs, this is a great model. All encryption is localized, so doing this can stand up to the heavy loads of wired replacement, in terms of throughput. This model scales with L3 in the core and distribution. What it doesn't do is fast L2 or L3 roaming. It also does not accomodate guests, contractors, consultants well, assuming you want to provide Internet access to such users, if you have L3 core and distribution switches. It also assumes reasonably current drivers and operating systems, which is an issue some colleges would rather not deal with.
SummaryI plan to continue this article next month, with a look at some other design approaches, some of the nifty things the Cisco WAP's can do. We'll also talk about the Cisco WLSM blade and what purposes might cause you to want to use it in your WLAN design. I also plan to mention Bradford Campus Manager briefly. If you can't wait, you'll find the PDF of my seminar slides at WLAN Design seminar slides.
Some of my previous WLAN postings:
Some useful WLAN-related links:
Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher my email address.