With complex networks, IoT devices, and everything imaginable now able to connect to WiFi, the days of mapping an SSID to a single VLAN are going by the wayside. Traditionally on a WiFi network, you would have an SSID for your corporate traffic, a guest SSID, and sometimes another one for something unique in the environment. Mapping these to a VLAN was not that big of a task, you would set the switch port to handle the VLANs needed on the AP, and make sure the VLAN was on any upstream switches. You would then decide if you wanted to tunnel everything back to the controller and let the controller handle the routing of the traffic or you could set routing up on your switches. This could be on your access, distribution, or core depending on your network’s size. You would then set up any ACLs (access control lists) to block traffic or VLANs from talking to each other.
This all started to change a few years ago with more and more smart devices hitting the network. If we held to the old way of an SSID to VLAN mapping, we would have so many SSIDs broadcasting that the beacon frames would start taking up much of the airtime available preventing clients from communicating.
A brief explanation of Beacon frames, for anyone that isn’t aware; a beacon frame is supposed to be sent out every 102.4ms per SSID. These are frames that broadcast the SSID, the security parameters supported on that SSID, the basic and supported rates. These are always transmitted at the lowest supported rate so any client that could be supported can hear the beacons. That means if you are planning to support legacy clients such as 802.11b or 802.11 prime devices the beacon frames will be broadcasted at 1 MBPS. This means about every 100 milliseconds (10 times a second) the clients must stop and listen for the beacon frames for every SSID.
This can easily bog down even the most well-designed network. If you have one AP broadcasting many SSIDs that may not be a huge deal, but when you start having multiple APs broadcasting the same number of SSIDs the airtime can be used up rather quickly. In a small environment, you may be able to deploy APs where you do not have to repeat any channel on 5 GHz, which is awesome when you can.
The big issue starts to come up when APs on the same channel or sometimes even adjacent channels (if not planned correctly) can hear the other AP’s transmissions, causing the AP to wait to transmit because it detected a signal before broadcasting. If the AP detects any WiFi signal above a certain level with carrier sense it must wait for the medium to clear. Also, if the AP detects any noise above a certain threshold using energy detect it will likewise not broadcast. While some interference is unavoidable, as clients move around and have yet to roam to a new AP and that AP’s channel, a good design tries to avoid adjacent channels on neighboring APs.
Here is a great chart provided by Revolution WiFI. https://revolutionwifi.blogspot.com/p/ssid-overhead-calculator.html
So, what is the solution to this problem? We use something called NAC (Network access and control). This device will profile the client device or user using the device by the permissions they have in their role. Before you say this is too complicated for my network, let me point out we have been doing something similar with Active Directory, Novell Netware (I miss Novell), and others for years!
Simply what a NAC does is take the permissions for the device or user and check them against a known list. This known list can be generated manually, tied to Active Directory roles, or generated in some other way, which is beyond this article. This concept is generally known as role-based access control (RBAC).
Let’s put all this together with an example. This company has two SSIDs broadcasting, the first a corporate using 802.1x authentication, and the second a guest that has a splash page. When the corporate user puts their credentials in, ultimately it will check it off a RADIUS server, usually tied to Active Directory. If a NAC is configured correctly, it can properly profile the device and place it in the proper VLAN automatically. If proper ACLs (access control lists) are set up to block unnecessary communications between VLANs, this can help minimize security risks. This is especially important with IoT devices.
By now most of us have heard in great detail that the 2014 Target breach was started by hackers gaining access to an HVAC IoT device[1]. While it is not clear whether this was a wired or wireless device, it can be implied that either way the network needed to be more segmented, among other security recommendations.[2] Let me bring this full circle back to the main point around WiFi. Making an SSID per VLAN will take too much airtime away from the client we are aiming to serve. If we limit the number of SSIDs to less than 5, ideally 2 or 3; we still should be able to serve the clients on the network. Ultimately, in today’s world, we all understand the need for security, but we sometimes get so caught up securing everything the way we used to years ago, that we overlook another potential issue, in this case, airtime.
[1] https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/
[2] https://www.zdnet.com/article/anatomy-of-the-target-data-breach-missed-opportunities-and-lessons-learned/
Bibliography
9, Tom Fiorillo February, JJ February 9, Rex March 2, TheHumanDefense February 9, T.B. Fitzgerald February 10, Brent February 10, Serena February 11, et al. “Target Hackers Broke in Via HVAC Company.” Krebs on Security, February 5, 2014. https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/.
Kassner, Michael. “Anatomy of the Target Data Breach: Missed Opportunities and Lessons Learned.” ZDNet. ZDNet, February 2, 2015. https://www.zdnet.com/article/anatomy-of-the-target-data-breach-missed-opportunities-and-lessons-learned/.
“SSID Overhead Calculator.” Fi. Accessed August 2, 2021. https://revolutionwifi.blogspot.com/p/ssid-overhead-calculator.html.
