Cellular Carrier Use of Unlicensed Spectrum

One of the questions I'm often asked is: “Will LAA interfere with Wi-Fi?” The short answer is: YES.

For years, mobile network operators (MNOs, aka cellular carriers) have been seeking ways to augment their connectivity and capacity for remote and high-density cellular areas. They do this by using portions of unlicensed spectrum (the same bands we use for Wi-Fi).

Licensed Assisted Access (LAA) is one technology designed for this need. LAA was introduced in 4G/LTE and approved by the FCC in the U.S. in 2016. It uses spectrum in the unlicensed 5 GHz band which does, in fact, overlap with Wi-Fi. LAA uses cellular (LTE) signaling (not Wi-Fi). Although in most markets (including the U.S., India, and South Korea) LAA uses a Listen Before Talk (LBT) mechanism to attempt to avoid interfering with Wi-Fi, if there is no free airtime, LAA will “share one of the occupied channels equally and fairly with Wi-Fi.”

Now, I don't know who gets to define what “equally and fairly” looks like, but in an already crowded Wi-Fi spectrum, LAA will absolutely impact Wi-Fi. The sensing threshold for LAA's LBT is –72 dBm, which is moderate but not necessarily adequate even in an undertaxed Wi-Fi environment. Most environments also suffer severe degradation on Wi-Fi with hidden node problems, which occur almost everywhere at some point.

In 2021, researchers at the University of Chicago in the U.S. studied the impact of LAA on Wi-Fi performance.

“Wi-Fi throughput can degrade as much as 97 percent when coexisting with LAA whereas LAA throughput only degrades 35 percent,” the researchers wrote. A summary of the findings and a link to the research can be found at https://www.cs.uchicago.edu/news/article/laa-Wi-Fi/. The full body of research can be accessed via https://arxiv.org/abs/2103.15591.

The other technology a carrier may propose (instead of LAA) is LTE-U (LTE over Unlicensed), which also uses Wi-Fi's precious 5 GHz spectrum. LTE-U was a precursor to LAA in terms of RF sharing technology and it doesn't employ the same LBT mechanism as LAA, meaning it introduces further opportunity for interference.

Because cellular uses scheduled and coordinated slots and Wi-Fi uses contention-based mechanisms, there's unlikely to be a “fair” and “equal” sharing. Even if there was, the overhead added by the LTE network (such as with LAA LBT) will query and reserve airtime for LTE and impact the performance of both the Wi-Fi and the unlicensed cellular transmissions.

In the LAA and LTE-U models, the MNO (carrier) deploys its equipment within your organization and manages the network, which will use cellular technology over the 5 GHz spectrum. One alternative to the MNO's augmentation of its networks is use of neutral host networks, covered next.

Cellular Neutral Host Networks

Neutral host networks (NHNs) also provide a method to supplement cellular carrier coverage, but they do so in a way that allows the enterprise to retain better control over the RF environment. NHNs are made possible by the recent advances in cellular technology and its use of NFV and SDN. With these two abstractions, cellular communications aren't tied to carrier hardware and software as in prior generations.

In NHNs, the carrier's networks are advertised through the enterprise's cellular infrastructure. That statement may not make sense if you haven't read the “Private Cellular and Cellular LANs” section of Chapter 8.

For organizations already taking advantage of private cellular or cellular LANs, adding NHN capabilities will only require a few knobs and settings to connect to carriers on the backend.

I imagine most technologists will have an immediate “heck, no!” response to the notion of the enterprise serving up carrier networks, but over time, the benefits will greatly outweigh the concerns. Security is not even a consideration in NHN because the authentication and IPSec are handled completely by the respective carrier—the enterprise is not involved in the device identity, authentication, encryption, or security at all. It's only serving as a conduit to pass the traffic to the carrier's network.

In fact, NHN operates on the same principle as single sign-on (SSO) or payment processing. Think of how many online sites you've ordered from and were allowed to pay with your Amazon, Google Pay, PayPal, or Apple Pay account. You've probably also had the option to create an account with a new service or website or simply log on using Google, Facebook, or other social site credentials. It's the same theory with NHN.

In addition, 5G networks will further protect public users including those on NHNs with privacy controls. Cellular devices have a permanent fixed identity—a Subscription Permanent Identifier (SUPI), which is protected through the use of a Subscription Concealed Identifier (SUCI). The closest network analogy is that of a MAC address on a device, and the use of MAC randomization for user privacy. However, in my opinion, the cellular implementation of SUPI/SUCI is a bit more elegant.

NHNs offer enterprises the opportunity to increase cellular connectivity in underserviced areas without handing over control of the RF to the carrier.

If the LAA, LTE-U, and NHN are confusing, Table D.1 provides a comparison.

The Purpose of MAC Randomization

It's all about data privacy and consent. MAC randomization was designed to afford users on public networks a level of privacy by obscuring the device identity. The thought was that users could disable app-level location tracking of cellular phones via GPS, but there wasn't a way for a user to prevent a Wi-Fi network operator from tracking the device's movement by MAC address.

What it was not designed to do (necessarily) was modify behavior for enterprise-managed devices on enterprise networks, but MAC randomization is enabled by default, and the impact on enterprise networks is just considered massive collateral damage.

How MAC Randomization Works

Where's my “it depends” stamp? The creation of the random MAC addresses is specified by an IEEE standard and is covered in Chapter 7—see the subsection titled “Client with Invalid (Fake) MAC Address” under “Attacks WIPS Can Detect and Prevent.”

How it actually works is dependent on the vendor implementation and the default behavior has varied wildly since its inception, including:

• Unique MAC address on each connection
• Unique MAC address per SSID (unless/until the device is told to forget the network)
• Unique MAC address rotated after XX hours or days
• Randomized MAC addresses for active scanning (when not associated)
• Randomized MAC addresses for Access Network Query Protocol (ANQP) exchanges (when not associated)

Most platforms allow some level of customization and the option for users to enable or disable a randomized MAC address per network. Whether we like it or not, MAC addresses are used for unique device identification for countless (and critical) purposes, such as:

• Captive portal registration including pay-per-use networks
• Portals for device registration including BYOD
• Identifying and securing enterprise-owned headless devices
• MAC-based NAC functions for registration, authentication, and authorization
• Enterprise device authorization with MAC Authentication Bypass (MAB) for endpoints and infrastructure devices
• Security monitoring and event correlation including WIPS
• Network services such as DHCP leases
• Troubleshooting and end-user support
• Network analytics

The impact of randomized MAC addresses on enterprise networks manifests in many ways, including:

• Forcing guest users through captive portal and pay gates multiple times
• Forcing BYOD users through registration portals multiple times (and consuming “seats”)
• Driving up costs associated with per-device licensing, which is all based on unique MAC addresses in the system
• Inability to uniquely identify enterprise assets for inventory and security
• Inability to identify endpoints for troubleshooting and trending analysis that informs network configuration modifications
• Inability to properly correlate security events

In addition to impacting the enterprise, the user experience may be negatively impacted, as hinted in the preceding bullets The impact of MAC randomization on captive portals is further detailed in Chapter 3.

The Future of Networking with MAC Randomization

Despite numerous organizations pushing back, IEEE's response to the issue is that (I'm paraphrasing)—MAC addresses should not be used to uniquely identify devices on the network, and they should only be used for layer 2 communication.

Alternatively, IEEE suggests that users and devices should be identified by some other means. The only other option to identify a device is to force some form of authentication, which (in my opinion) only increases the user friction, further invades the user's privacy, and often is not possible for headless IoT devices.

My frustration with the application of MAC randomization is that the industry has tried to solve a political compliance problem with a technical control that's not appropriate for enterprise applications. If the issue is that network operators are using MAC addresses for marketing purposes and financial gain, then just as with all other PII, a governing body should implement a policy protecting the user's privacy and forbid use of that data in that way.

So far, the appeals from numerous organizations to IEEE for MAC randomization are falling on deaf ears. And not only is it unlikely the industry will roll back from MAC randomization, but some vendors are even pushing for further expansion of its use—advocating to require MAC randomization for each and every connected device. If that happens, the IT and infosec communities are going to have a serious problem.

Despite the dismissive rebuttal by IEEE that “MAC addresses shouldn't be used for device identity,” the truth is the great majority of current IoT-type endpoints don't support any other option. As I've mentioned several times throughout this book, using a MAC address is (at best) identity and not authentication. But, for now it's all we have to work with in some cases. It will be years before the endpoint industry makes use of unique hardware-based device certificates, and even then, that identity will be just as telling as a MAC address—even more so.

If MAC randomization drives the industry in a better direction for unique device IDs, that will be a positive side effect. My soapbox on the topic isn't that we should keep relying on MAC addresses, but that randomizing MAC addresses in the enterprise doesn't add value and has numerous negative consequences.

In the meantime, it's widely accepted for enterprises to disallow MAC randomization for endpoints connected to their networks. Just like a business can put up a “shirt and shoes required” sign or a facility can say “face coverings required,” so, too, can the enterprise stipulate the conditions for using its resources. This is especially true for managed endpoints and those in BYOD programs.