The autumn of 2020 saw the WLAN world in a little bit of a frenzy due to the implementation of MAC Randomization as a default setting in Apple’s iOS 14. Five months on, that frenzy probably reminds you a little bit of the panic around Y2K, right? It’s OK to admit it, I won’t take it personally.

It’s easy to understand why many of you think that. The release of iOS 14 has come and gone and, as of this writing, it’s even up to version 14.4 and not a whole lot of heartache has been seen around it. There might have been a small hiccup here and there, but most of the problems are gone and we are free to move on to the next panic in the technology world. In what might be bad news to some of you, I don’t think we have seen the last of the problems with MAC Randomization.

This belief stems from a couple of facts that can’t be ignored, so I want to take the time to lay these out for you.

Natural Progression

The use of random MAC addresses wasn’t a sudden implementation in September of 2020; it had been coming for a while. First introduced as devices probed for networks by Apple in 2014 and Android in 2017, this default behaviour only affected networks whose operators were looking to understand how many devices were in their facility but never connecting to the network.

Next came Android 10 and Windows 10 where devices used random MAC addresses when connecting to the network; it wasn’t enabled by default and it was an optional setting. Finally, we saw Android 11 and Apple’s iOS 14. Where Google had taken a phased approach to this feature, Apple jumped straight to it. These latest mobile operating systems enabled MAC Randomization as default and users had to opt-out rather than opt-in.

The next progression in the MAC address is one where it should really change every 24 hours. Windows 10 has that as an optional setting today; Android 11 has that as a developer option (super-secret advanced screen); Apple teased us with it during their beta testing of iOS 14. That’s when the networking people went crazy and Apple removed that option completely before iOS 14 was released.

What was originally a probing feature evolved into an optional feature (to be enabled) which then became a standard feature enabled by default. It might not be in the next couple of months, but the 24-hour feature is coming back, and more than likely, enabled by default. The writing is really on the wall.

Randomizing MACs Really isn’t MAC Randomization

I know this sounds crazy but hear me out. MAC randomization is what the device does, but when looking at the actual IEEE 802.1 standard, it’s not called MAC Randomization. What the device uses, and what we see, is a random MAC address, but the standard actually uses the term “Locally administered MAC Address.” OS developers are the ones who introduced the term “Private Address” as seen here on iOS 14.4 (enabled by default) and I don’t think using that term was an accident on their part.

Historically, the Global Unique MAC Address, or the “burned-in MAC,” was not a great indicator of the individual owner of a device. What it was good for was to determine if that device was an Apple device, or Samsung, or even a RUCKUS device by looking at the first half of the MAC (known as the OUI). OUI’s are assigned to organizations that make networking devices. My laptop’s MAC starts with “10:40:f3”, which will tell you that my laptop is an Apple device. What it doesn’t tell you is that it’s Jim’s MacBook Air. At least not initially.

If you have ever watched any spy movie, there is always a part in the movie where the hero will sit and watch someone, try to learn their routine, so that later in the movie they can exploit that routine. That’s what network operators have been doing. They don’t know at first who owns the device with my MAC address, but over time they can start to see a pattern. Piece by piece, bit by bit, I am exposing parts of my private life to the network. The pattern is based on when and where the network sees that one MAC address used by my device. If that key piece of information never changes, the patterns continue to get refined.

185 records for my iPhone in 1 week on my home network:

Even though today my iPhone is using the “private” MAC address seen above, the network really doesn’t care, as long as it’s the same MAC address that is used every day for that network. Networks might not know it’s an Apple iPhone at first, but with just a couple of times of connecting and my device pinging out to Apple services to check for a captive portal, the network will flag my device as being an Apple iPhone. Plus, when my device does a DHCP request and uses the name “Jims iPhone” as the device hostname, the game is up.

Developers know that a static MAC address, whether it’s globally unique or locally administered, doesn’t help protect anyone’s privacy. That is why the 24-hour feature was in use in beta #3 of iOS 14. After a bunch of folks had panic attacks, it was removed in beta #4, but knowing the progression of this particular feature, do you really think it’s never coming back? Even though the MAC address used by devices today are randomized, their ability to protect your privacy is really limited if they never change. Both Apple and Android are trying to protect the privacy of their users and the 24-hour feature is currently the best way to do it.

The Next Step

While a difficult thing to do today, try to imagine devices changing their MAC address every 24 hours. Know and understand how a MAC address can be identified and just get used to the fact that it might only be seen once on a network. Examine your network and how it functions; picture every mobile device carried by a person changing its MAC address every 24 hours. What does that do to your network? What does it do to how an IT engineer troubleshoots connectivity issues?

CommScope RUCKUS engineers are still feverishly working on the details of how the 24-hour feature might present itself to the network and network operators. There are still plenty of questions to be answered, assumptions being made, and notes to be taken; all in preparation for when we first get a glimpse of the next mobile OS major updates. There won’t be a whole lot of time to adjust solutions when the 24-hour feature is enabled by default and we can’t count on OS developers taking pity on us and postponing that setting once again.

Keep checking out the CommScope website for updates as we learn them. If you missed the first two parts of this blog post series, you can find Part 1 here and Part 2 here.