Author
Jim Palmer
In part 1, I explained what is happening with MAC randomization.
As a quick refresher, MAC randomization is a privacy feature that has been an optional setting in many devices but with the introduction of Apple’s iOS 14 operating system, it is now enabled by default. I discussed why this is a big deal and now I’ll discuss - what do we do now?
Let’s break down some of the specific ways MAC randomization can break an existing network starting with security. Many times, network engineers rely on the MAC address to verify that the device attempting to associate is legitimate. This concept, MAC authentication, is rarely a good idea, but sometimes it’s all engineers think they have. There are options, such as RUCKUS Dynamic Pre-Shared Key (DPSK) that can provide a better alternative. RUCKUS DPSK is a unique key that identifies the device user, not the MAC address, to the network. This works for both mobile devices and for IoT devices. IoT devices aren’t randomizing their MAC address (yet) but being able to manage both IoT devices and mobile devices using random MAC addresses with the same security solution is a great first step. RUCKUS DPSK offers other advantages when securing the network - too much to cover here but I’ll try to explore in a future blog.
CLICK TO TWEET: CommScope’s Jim Palmer explains why MAC Randomization is a big deal and what we do now.
As previously discussed, devices are supposed to revert to the last known working MAC address/SSID combination if connection errors occur. This behavior will allow RUCKUS DPSK to still function in this “new normal” but until I see MAC randomization working in the wild and at scale, I’m using a lot of terms like “supposed to.” A downside of this behavior is the amount of extra management traffic incurred on the channel while a client tries a couple of times to associate before reverting to the previous MAC address. If extra management traffic on the channel is a concern, it comes up later as well. Good network engineers with solid troubleshooting skills are key here but unfortunately, it takes lots of time and learning to get to that level.
RUCKUS external DPSK (eDPSK) is similar to RUCKUS DPSK but instead of the RUCKUS SmartZone controller managing the DPSK verification, it’s handled by an external server like RUCKUS Cloudpath. RUCKUS Cloudpath is a software/SaaS designed to provide secure wired and wireless network access. By design, it can handle multiple MAC addresses associated with one DPSK and, as a dedicated server, it is much more capable of handling the many nuances this new development brings. To top it off, it can also perform myriad other tasks that help to securely onboard devices and users to your network.
MAC randomization can have an unintended impact in other areas, including security. Every once in a while, network administrators and engineers will observe a device they don’t want to connect to their network. A common tactic is to simply add this MAC address to a block list which tells the network to ignore this device. Hackers have had a way around this tactic for years by spoofing their MAC address, but it was something that the user needed to know to try.
With MAC randomization, the bar has been lowered for mischief-making which, while maybe not immediately obvious, is going to increase the workload for network administrators and engineers. Setting up event management and reporting to identify client issues will be more critical than ever and they will need to watch for the same APs to see repeated failed association attempts to identify MAC randomization (or malicious actors spoofing) in the wild. Rules that define when devices are allowed to access the network, like a rule on a home SSID that defines what kids can access on the internet when they are supposed to be doing schoolwork, will also be impacted.
In addition to impacts on security, there are other areas that will see an effect with randomization at Layer 2. The issue presents itself at Layer 3 however, where IP addresses live and more importantly, where IP addresses get assigned to clients. When a DHCP discovery packet is received by the DHCP server, the critical piece of information in this process is the MAC address of the requesting device. If that piece of information is randomized, the resulting IP assignment is going to be random as well. Any network policy that relies on the same IP address being assigned to the same MAC address will break. Relying on the MAC address going forward is going to create additional administrative work for both help desks and IT staff.
Enter RUCKUS Cloudpath (again) and secure onboarding using WPA2/WPA3-Enterprise or eDPSK. With RUCKUS Cloudpath, network administrators can define policies for any device that connects to the network. Since WPA2/WPA3-Enterprise and DPSK doesn’t rely on the MAC address of the client, this development isn’t as impactful as with other configurations like traditional Pre-Shared Key (WPA2-Personal) for network associations. When RUCKUS Cloudpath combines these secure onboarding techniques with the assignment of attributes to a client via RADIUS, not only do random MAC addresses no longer present problems, advanced network configurations are now available.
Lastly, I want to discuss DHCP lease times. In the past, the common wisdom was to use long DHCP lease times to reduce the amount of management overhead on a wireless network. Long lease times weren’t as big a problem if the same devices showed up every day with same MAC address since the lease would carry over from day to day. Now, with the same device showing up day in and day out, but possibly with a new MAC address, lease times become something to pay attention to in order to avoid IP address depletion. My recommended time for a DHCP lease on a wireless network is 4 hours, but no longer than 6 hours. Oddly enough, anything less than 2 hours isn’t recommended for Apple products.
Due to the many iterations of devices, networks, code versions and upgrade paths, there isn’t a reliable way to predict how this new development will impact every network. How will Network Access Control (NAC) solutions work? What about MDM solutions? How will portals be affected? Anything else you can think of or maybe something that you haven’t? I don’t know of any one person who can address every problem that might arise from this, at least not yet. This is a new development that every network administrator and engineer should look at and address now, before an optional setting becomes the default and has the potential to wreak havoc on unprepared networks everywhere. Understanding and addressing some of these issues now will free up network administrators and the help desk to tackle other problems. Remember, this isn’t a one-time speed bump, this is going to be an issue for months to come. Take the opportunity now to discuss the implications and find ways to address the challenges MAC randomization presents.
Stay tuned as we bring additional updates on this topic. For more information on RUCKUS DPSK, eDPSK using RUCKUS Cloudpath, or RUCKUS SmartZone visit http://www.commscope.com/ruckus and learn how CommScope can partner with you to advance your network into the future.
To "So Really, What is the Big Deal with MAC Randomization? - Part 3" >
