Introduction

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?

Requirements

• Wired network -- how big, how designed. Is the middle of the campus network Layer 2 or 3?
  
• Scale -- number of users.
• Wired replacement? Or small community of mobile users? Volume of traffic?
  
• Mobility -- how many, what type of roaming time, how sensitive to drops in coverage. Will WLAN phones be in use? (What about the coming hybrid cell / 802.1x phones?)
  
• Authentication -- how secure does authentication need to be? How confidential do transmissions need to be?
  
• Security -- other risks? Is someone associating with your WAP going to be in the headlines? Are you concerned enough about liability to warrant the high cost of a separate WLAN infrastructure? (Probably not needed with good crypto/authentication).
  
• Security -- need to accomodate guests and contractors for Internet and external access. Do they need to log in first before getting even that level of access?
  
• Drivers -- how flexible can you be concerning drivers? Especially for guests? This interacts with authentication and security. Note that 802.1x or NAC for guests might be a problem. And what about for a PDA or cell phone?
• Security -- is there desire for pre-admission patch or virus scan of all devices, including guest devices. This opens a whole can of worms concerning pre-admission scanners, clients versus clientless, potential bottlenecks, etc.  External scans are now defeated by software firewalls, but can you require guests to install client-side scanners? Apple and Linux support?
  
• Network and Security Management -- what tools, capabilities needed? Rogue detection? Firewall, IDS, other?
  

Designs

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.
The less-costly alternative for those who like this sort of approach is to use wired isolation VLAN(s) to connect up the WAP's. See the following figure. Doing this allows you to connect the WLAN VLAN's to the Internet for guests, and do IPSec for employees. This works fine for small to medium shops, i.e. as long as you have L2 up to a collapsed core/distribution switch or switches (which will probably be L3).  This saves the cost of the separate infrastructure, but is subject to some of the same concerns as above.

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.

Here's what that looks like with multiple floor WLAN VLAN's and IPSec layered into the diagram. (Apologies for flipping left and right on you, but I don't want to take the time to redo this drawing). The main reason for many WLAN VLAN's is to avoid increased size of Spanning Tree (STP) domains. Those of you who have been reading me for a while know of my strong allergy to STP and to extended VLAN's.

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.

Summary

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.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has ten CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, IPSec VPN, wireless LAN and bridging,  network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw <at> netcraftsmen <dot> net (formatted this way to fool email harvesting software).

2/1/2005
Copyright (C)  2005  Peter J. Welcher