Recommendations for BYOD Internet-only Access

In Chapter 5 it was noted that planning for Internet-only BYOD is fairly straightforward. The one request that makes it more complicated than standard guest portals is that many organizations want their employees to be able to use the Internet-only connection without the friction and frustration of a daily captive portal experience.

This is a completely legitimate desire—however, to meet this objective, decision-makers will often instruct wireless architects to allow personal devices on the secured network—either by allowing users to join 802.1X-secured networks with their domain usernames and passwords, or by having personal devices on an internal passphrase-secured network (WPA2- or WPA3-Personal). Neither of these are advised because they introduce several security risks.

Instead, for personal devices requiring Internet-only access, with the goal of not repeating a daily captive portal, one of these methods should be used. These are presented in order of most to least secure, but all are valid options.

• Registration-based BYOD Captive Portal This would allow employees to register their personal devices under their domain account using a portal page; the account can be authorized for a period of time or indefinitely.

  With some products, the users can manage their list of approved personal devices, and a maximum number of devices per user can be specified. These features are most often available with a NAC product, but some Wi-Fi products are adding built-in support for this as well.

  Notably, this option links the otherwise unknown personal device to a known user, but it does so safely, without exposing the user credential on the unmanaged device.

• Basic BYOD Captive Portal with an Extended Cache Timer A basic portal would look just like a guest portal, but the timer would be set for a much longer duration; for example, instead of a 1-day guest account, the employee can join with their device and not have to revisit the portal for 3–6 months, or even a year. The portal can be a subfunction of an existing guest portal and of course should offer Internet-only access.
• Passphrase-Secured BYOD Network Passphrase-secured networks for BYOD access is perfectly acceptable, as long as the access is Internet-only, but it's preferred to separate personal devices from any other corporate endpoints such as IoT devices.

  This can be accomplished with separate SSIDs, or through dynamic VLANs (or roles, policies, etc.). If at all possible, use WPA3-Personal for this purpose—remember that WPA3-Personal networks are far superior in security to legacy WPA2-Personal networks.

Recommendations for BYOD with Internal Access

Circling back to the opening paragraph—the one hard-and-fast rule for secure BYOD is that access to any secured or sensitive resources should only be allowed from a device the organization has some level of visibility into or control over.

From a technical perspective, I'd encourage you to advocate for this model and/or to start with this access until better direction is offered by the organization.

Organizations should not allow personal devices on secure production Wi-Fi networks unless all of the following criteria are met:

• There's a business case outlining the requirements and there is no other way to meet the business objective
• There's a policy in place (approved by executive leadership) stating that personal devices are allowed, along with the conditions and access; and in the absence of a policy, request approval for personal devices in writing (email is fine) from your manager or other leader in the organization
• Each user participating in BYOD has read, acknowledged, and signed the BYOD end user policy
• The organization has some visibility into the security posture of the personal device such as through an MDM tool or NAC agent
• There is a mechanism to securely onboard the personal device to the network, such as through an MDM and certificates, or through a NAC product
• There's no onboarding mechanism that puts the user's domain credentials at risk; specifically, the users should not join an 802.1X-secured network from a personal device using domain credentials

In addition to the preceding requirements, there are a few additional recommended items that would offer additional security:

• Use granular access policies to allow access only to the required resources
• Preferably, do not co-mingle unmanaged personal devices with managed devices on the same SSID or VLAN
• Have a way to determine which devices on the network are personally owned, and also to identify the user/owner of the device
• If possible, use an MDM or agent for security posture scanning to ensure the personal devices are not infected, and meet minimum security requirements such as passwords and patching

The reasons for the recommendations here are covered throughout the book, and especially in Chapter 3, “Understanding Authentication and Authorization,” and Chapter 6.

Cloud-Routed and Cloud Native Products

Cloud-routed and cloud native products are primarily focused on securing access to and from users that are not co-located with the resource because the data path involves the Internet. For example, if a user is working from home and accessing a resource on-prem or in the cloud, a cloud-routed product is well suited for the model.

Conversely, if the user is co-located on-prem with the resources, routing traffic out to and back from the Internet is not ideal. Depending on the network, data, and implementation, this hairpin routing out and back in from the Internet may be acceptable, but it's not how these products were envisioned.

These classifications of products, their features, and vendors change almost daily. These are all highly volatile markets, but for context, today's most common cloud-routed products include the following solutions:

• Zero Trust Network Access (ZTNA)
• Secure Access Service Edge (SASE)
• Cloud Access Security Broker (CASB)
• Secure Web Gateway (SWG)
• Software-defined WAN (SD-WAN)
• Workload and microsegmentation
• Software-Defined Perimeter (SDP)

ZTNA is an actual product and is not to be confused with zero trust as a strategy or architecture. Someone out there just wanted to further complicate and confuse us all with that name. SASE offerings are most often a ZTNA solution with additional services. The lines between the products listed here are blurry, at best.

Direct-Routed and On-Prem Products

The types of products designed to support zero trust strategies within a campus environment include:

• Network-based microsegmentation (next-gen NAC, SDN, VXLAN)
• Agent-based microsegmentation
• Network access control (NAC)
• Software-defined WAN (SD-WAN)
• On-prem components of Secure Access Service Edge (SASE)
• Zero trust enabled firewalls and gateways
• Purpose-built appliances

There are some crossover products and features between cloud-routed and on-prem products. There's also some re-use of language such as “microsegmentation,” however that word means two different things. Originally a datacenter concept for controlling authorization between servers, services, and microservices—the term microsegmentation was then borrowed by the network security vendors to describe more granular access controls from their products.

The result is that a microsegmentation product for datacenter and cloud applications is not the same as a microsegmentation product for network security on-prem. They're completely different technologies, operate with different enforcement mechanisms (covered next), and therefore have no overlap nor any relationship to one another.

Software-based PEPs

Software-based PEPs use agents on the requestor (subject) and/or the resource being accessed (target), and will most often use one or more of the following enforcement mechanisms to enforce an access policy:

• DNS
• Local host firewall
• Local routing control
• External routing control

The level of enforcement granularity may include one or more of the following, and the access policy may be unidirectional or bidirectional, meaning it may be initiated from the requestor (aka the subject), the resource (aka the target), or either. Some cloud-routed solutions offer limited granularity and may only be built to establish connections unidirectionally.

• Application signatures
• URL/URI
• TCP (any port)
• TCP (specific list of ports)
• UDP (any port)
• Microservices

Although software-based PEPs are viable on campus infrastructures with on-prem resources, they're more often used for access enforcement to and from Internet-based resources.

For this reason, most current products that are controlling access with campus environments are using on-prem products and the appliance-based PEPs described next.

Appliance-based PEPs

Appliance-based PEPs may be physical hardware or virtual appliances and include many of our traditional networking technologies such as firewalls, switches, routers, SD-WAN gateway, Wi-Fi controller or AP, or a purpose-built vendor device.

Just as with other access control technologies, the enforcement mechanisms in appliances most often include:

• Firewall policies or zones
• VLANs
• SDN or SD-WAN policies
• ACLs (static or dynamic)
• Routes (static or dynamic)
• VXLAN

The granularity of appliance-based PEP enforcement varies slightly from software PEPs, and includes the following:

• Application signatures
• Any TCP or UDP port or protocol
• TCP (specific list of ports)
• IP addresses or networks

Most of the appliance enforcement mechanisms will look familiar—they were covered as filtering and segmentation methods in Chapter 2, “Understanding Technical Elements.”

Device Identification

Most often, we have three ways to identify an endpoint on the LAN: it was manually provisioned, and the MAC address and other identifiers were documented; it has a logged-on user that identifies the device; or it has a device certificate that identifies the device.

In the absence of one of those three more deterministic methods, processes for identifying a device is more of a guess. Profiling methods (common in NAC, UEBA, and Wi-Fi products) gain some context by looking at the NIC OUI to determine the manufacturer and by watching aspects of traffic passing through such as DHCP requests. Other profiling methods may layer additional criteria such as mapping open ports or parsing an HTTP header. In total there are about twenty common active profiling mechanisms.

Newer profiling methods incorporate data from watching mirrored traffic on the network to get even more context about the endpoint and what it's doing on the network. Each of these methods offers an increasing level of confidence about the identity of the device, but none guarantee 100 percent accuracy.

When it comes to device identify with non-traditional endpoints, this is by far the most time-consuming task in any project (including and especially NAC projects).

Device Authentication

Device authentication becomes another challenge with many LAN-based IoT devices. Even though connected with familiar Wi-Fi technology, the endpoint may not support authentication (remembering that passphrases aren't considered true authentication).

Most of the more standard network devices including printers and VoIP phones do support 802.1X, and therefore can be authenticated with either a device certificate or device domain credentials. Other endpoints support no authentication but could use MAC Authentication Bypass (MAB, which again isn't really authentication in the infosec sense.)

Software Updates and Patching

Maintaining basic security hygiene with software updates and security patches is also challenging with many IoT devices (LAN-based and otherwise). It seems in many environments even printers and other readily accessible devices don't receive regular patches.

IoT endpoints without standard interfaces are even more cumbersome to update, often requiring additional management platforms.

Creation and Maintenance of Segmentation Policies

In a perfect world, each grouping of IoT devices would have granular access policies restricting traffic to and from only the requisite resources. In practice, many organizations have a single IoT-designated passphrase-secured network and throw everything there together, with little to no additional segmentation.

Wi-Fi, NAC, and authentication server products all support varying approaches to label and further segment IoT devices. Some offer integrations with external devices such as firewalls (which model traffic and apply labels to the endpoints); others rely on authentication policies with basic dynamic VLAN assignments.

Limited Options for Secure Wi-Fi Connections

Even when properly segmented, many IoT devices don't have robust support for secure Wi-Fi connectivity, making them vulnerable to over-the-air attacks. For example, Figure 8.7 shows a table from current product documentation for a vendor's industrial environmental monitoring systems. The wireless products referenced include sensors for temperature, pressure, humidity, sound, and cryogenic systems, among others, and are marketed to customers in healthcare, pharmaceutical, and food safety.

In the network requirements, the table shows only WPA2-Personal is supported, and communication is by default HTTP over port 80. The port is not editable by the customer. This vendor also claims their system can “effectively reduce the potential for any type of network attack to zero” which is, of course, misleading.

Bluetooth and BLE in the Enterprise

Classic Bluetooth and Bluetooth Low Energy (BLE) have been fixtures within most enterprise environments for some time. Classic Bluetooth has been well-suited for wireless accessories that require constant data transmission, such as wireless headsets and speakers.

But all that constant connection puts a drain on batteries, and battery life is of particular concern when it comes to IoT devices. The low energy (LE) specification of Bluetooth came along to help alleviate issues related to battery life and offer an alternate model with less power consumption (as well as some additional features).

Whereas Classic Bluetooth is still primarily used for connecting wireless peripherals, BLE expands on that connectivity and supports additional use cases including indoor location services. Just a few of the BLE applications include:

• Connectivity for power-sensitive IoT devices such as medical monitoring devices and industrial sensors
• Connectivity of personal wearables
• Mobile applications with BLE location points of interest
• Mobile applications with BLE door entry systems in hospitality

Bluetooth up through version 5.3 also supports a mechanism to switch to Wi-Fi-based connections. A museum with BLE-enabled points of interest and a mobile app may make use of this; the museum visitors can move throughout the museum and receive exhibit-specific information based on their location. The app might then push a document or video down to the app and could use Wi-Fi for that transfer to make use of higher bandwidths than what's available through Bluetooth (a feature referred to as alternative MAC/PHY, or AMP).

Bluetooth vs. BLE

Devices may support both classic Bluetooth and BLE operations simultaneously. Due to the differing battery requirements and use cases, whereas Bluetooth is always connection-based, BLE can be connection-less, meaning devices can interact with one another through listening to beacons instead of formally connecting through pairing.

From a layer 1 perspective, both Bluetooth and BLE use the industrial, scientific, and medical (ISM) portion of the 2.4 GHz spectrum (also used by 802.11 Wi-Fi), but Bluetooth and BLE both use different spectrum hopping methods and channel selection algorithms to avoid interference with other devices in the same airspace, including Wi-Fi.

Network Connectivity and Addressing

Considering network topology and connectivity, Bluetooth does not use IP addressing. Instead, it relies on 48-bit addresses (like a MAC address), the first half of which specify the organizationally unique identifier (OUI), just as in Wi-Fi devices.

Bluetooth creates small piconets (up to 8 devices due to 3-bit addressing) and multiple piconets can then connect to form what's called a scatternet. On the other hand, BLE uses 24-bit device addressing and could (theoretically) support piconets with millions of devices—although in practice they're much smaller—but this speaks to the expanded use cases of mesh IoT devices such as many sensors.

Provisioning and BLE Secure Connections

Bluetooth and BLE both use similar provisioning processes, which include:

• Numeric comparison, where one device displays a short code that can be matched to the other.
• Passkey entry, which is available for devices capable of input. The central device can generate a PIN that can be entered on a joining device, or the PIN is set during manufacturing and manually entered on both devices.
• Just Works™, which is a very lightweight pairing that uses a null value during the key exchange, effectively offering only connectivity and no security during the pairing process.
• Out of band (OOB) pairing, which allows Bluetooth devices to use a different wireless protocol to exchange keys and sensitive data not appropriate for Bluetooth (such as medical or payment card data). OOB could be used to connect capable devices over Wi-Fi or NFC, for example.

By far, the least secure mechanism is Just Works, yet it's the default mode of operation in Bluetooth devices. Other modes can be susceptible to eavesdropping and man-in-the-middle attacks, depending on the version and implementation. For more on why Just Works doesn't work, read the IEEE whitepaper on BLE Just Works security vulnerabilities, “Bluetooth Low Energy Makes ‘Just Works' Not Work,” at https://ieeexplore.ieee.org/document/9108931.

BLE got a major bump in provisioning security with the BLE Secure Connections, introduced in version 4.2. With that, the devices use Elliptic Curve Diffie-Hellman (ECDH) key exchange, similar to many Wi-Fi operations. This addressed the problem of possible eavesdropping and man-in-the-middle attacks during the pairing process. The idea in legacy implementations was that the connection was only vulnerable during the pairing process, but the reality was that it introduced too great a risk for many of today's commercial and medical BLE applications.

An important note is that BLE 4.2 devices are compatible with older 4.0 and 4.1 versions, however the BLE Secure Connections operation is not—meaning if a more capable BLE 4.2 device is paired with a legacy device, it will not benefit from the increased security.

Speaking of encryption, the following modes are supported and in all cases AES-CCM mode is used after the devices are paired (through the secure ECDH or other mechanisms):

• Encryption disabled for all data
• Encryption enabled for unicast only
• Encryption enabled for all data

Bluetooth Exploits in the Wild

An Internet search will yield countless results for Bluetooth vulnerabilities. Here are a few that made recent headlines.

• BrakTooth and SweynTooth Throughout 2020 and 2021, researchers released numerous new findings exploiting even the more secure BLE 4.2 modules. In fact, the BrakTooth suite of attacks in late 2021 resulted in disclosure of 16 new security vulnerabilities on top of exploiting 15 already known.

  The result? Everything from nagging denial-of-service attacks to full code execution on the Bluetooth-connected endpoints. Many of the devices tested included boards used in commercial products and industrial automation and monitoring, in addition to LED light controls and gaming systems.

  Other devices impacted by the vulnerabilities include smartphones, tablets, and laptops, as Intel, Qualcomm, and others used affected chips. The attacks were executed with equipment totaling less than $20 USD.

  The same researchers also released SweynTooth in 2020, discovering 17 new vulnerabilities. In those attacks, researchers were able to trigger crashes, buffer overflows, device locks, and even completely bypass security on BLE devices. These attacks, like BrakTooth, were tested on several chips including those used in smart locks, Fitbits, TSA-compliant luggage locks, smart plugs, and other smart home products. They were also found to be successful against other wearables and medical devices including a blood glucose meter and a Bluetooth-enabled pacemaker shown in Figure 8.8.

  The group's research including BrakTooth and SweynTooth can be found at https://asset-group.github.io/.

  

• Bluetooth Impersonation Attack Tested on more than 28 unique chips, the Bluetooth Impersonation Attack (BIAS) was successful on every device, including chips from Apple, Qualcomm, Intel, and Samsung. The vulnerability allows an attacker to impersonate any device that has been paired in the presence of the attacker.
• Hacked e-Scooter In one incident researchers were able to abuse a misconfiguration in Xiaomi brand electric scooters' Bluetooth authentication, and control scooters from 100 meters away—sending unauthenticated commands to lock (stop) scooters, brake, accelerate, and even deploy malware.

  You can read a recap of the research and accompanying video “Xiaomi Electric Scooters Vulnerable to Life-Threatening Remote Hacks” at https://thehackernews.com/2019/02/xiaomi-electric-scooter-hack.html.

Bluetooth and BLE attacks could go on for pages. My only reason for including these few examples is to demonstrate three points. First, even the newer versions of the BLE products are susceptible to attacks, and those attacks are non-trivial and can be life threatening in certain products. Second, the vulnerabilities are being disclosed almost daily. This proves the point that any specific guidance for Bluetooth and BLE specifically will be out of date quickly. Last, but not least, these attacks have been successful on popular wearables and smartphones (including Apple and Android), which further calls into question the use of peer-enabled protocols in a secure enterprise environment (a soapbox topic in Chapter 6).

I'm not suggesting organizations impose a moratorium on consumer devices, but they should be carefully considered, and the enterprise environment should be secured from these devices as best they can.

Zigbee

Zigbee is the outlier here, being a non-IP-based protocol. Although a step up from Bluetooth, Zigbee has not gained the traction in large-scale deployments due to limitations of its mesh architecture and lack of IP stack. Because Zigbee (along with Bluetooth) doesn't use edge IP addressing, a translator is required to convert Zigbee protocol into IP protocol for forwarding or routing to and from IP-based networks.

Despite a few alliance agreements here and there, Zigbee has been fizzling out in recent years, replaced by newer, faster, and more scalable stacks like those based on 6loWPAN. Zigbee has been rebranded as part of the Connectivity Standards Alliance (www.csa-iot.org), along with Matter and other technologies.

Thread and 6loWPAN

Thread is one such communication stack based on 6loWPAN and therefore IPv6. All of these (Thread, 6loWPAN, and Zigbee) work on top of the 802.15.4 physical layer, which specifies tiny packet sizes of 127 bytes. The challenge is, IPv6 frames are about ten times that size at 1280 bytes. I'm about to switch from bytes to bits; one byte is eight bits. Also contributing to the length crisis, IPv6 addresses are long at 128-bits (for context, an IPv4 address is 32-bits).

6loWPAN is simply an adaptation layer that allows sending IPv6 over 802.15.4; it does this by compressing the IPv6 address and headers and handling fragmentation. Figure 8.9 offers a visual of the difference in ratios of IPv4 to IPv6 addressing and of the frame sizes of 802.15.4 versus IPv6. Effectively, 6loWPAN's task is to shrink IPv6 to about one-tenth its original size, in order to transfer it over 802.15.4.

Figure 8.10 shows the Thread communication stack and the placement of 6loWPAN as the adaptation between layers 2 and 3 of the traditional OSI stack. Layers 1 and 2 of Thread (and 6loWPAN) use 802.15.4. Unlike Zigbee, Thread stops short of the application layer, allowing for extensible uses

The result of this stack and the IPv6 compression is that Thread (like many of its IoT cousins) requires a Thread-capable router to convert the local (compressed IPv6) addresses to something routable with full addressing.

I mention this because the language on the Thread Group site and documentation can be a little misleading and confusing, as it repeatedly notes there's “no need for a proprietary hub, gateway, or translator.” That's true but it (and any 6loWPAN communication) does require a border router to convert the addressing and shortened headers.

The best way I've heard it described is like network address translation (NAT). If you contrast the private IP address space with publicly routable IP address spaces, the private address (such as 192.168.1.12) wouldn't be able to communicate directly with 4.2.2.2. Instead, it would go through a router or firewall that would convert the source and destination addresses so the publicly routed data can find its way back to the private IP address.

There is a major difference between 6loWPAN and non-IP technologies like Bluetooth and Zigbee. The border router is just that—it's routing the packets to and from the local (compressed) IPv6 addressed endpoints. Bluetooth and Zigbee aren't speaking IP at all, and their traffic must fully be translated to IP to interact with IP networks.

Current State of Private Cellular by Country

If you haven't heard of private cellular networks yet, it's probably because spectrum for this use case is just now being opened up around the globe.

The following is the current state as of early 2022, with the expectation that by the time you're reading this, the status for some countries will have changed.

In the U.S., the designated RF for private cellular is the Citizens Broadband Radio Service (CBRS) spectrum—in the 3.5 GHz band nestled neatly between 2.4 GHz and 5 GHz without interfering. On that spectrum, we can use both 4G and 5G technology.

Outside of the U.S.—Japan, Norway, Germany, the Netherlands, Poland, and Sweden—have all identified spectrum for private cellular use. Following a slightly different model, Australia, China, France, the Czech Republic, along with Hungary, Portugal, South Africa, and Spain offer leased spectrum for private cellular use. As of writing, spectrum allocations in Canada, Mexico, Brazil, and Turkey are to be determined.

Throughout Europe, many EU member countries have specified or are considering use of frequency bands n77 and n78 for 5G private networks. These operate in the 3.4-3.8GHz and 3.8-4.2GHz spectrums for n78 and n77, respectively. The UK has settled on n77 as well as band 40 and is exploring additional spectrum.

Deployment Models and Architectures

Cellular technologies have their own vernacular and architecture that doesn't correlate directly to Wi-Fi, aside from the concepts of radios in a cellular Radio Access Network providing connectivity conceptually as a Wi-Fi AP would. Behind the radios are a packet core in cellular, which offers a breadth of authentication and coordination functions. The packet core could be likened to a Wi-Fi controller but that's a grossly overly simplified correlation.

The two areas I want to cover are the deployment architectures and models that describe how private cellular is used, and how it may be integrated into the existing enterprise LAN:

• Deployment Architectures
• Deployment Models

• Deployment Architectures Deployment architectures describe how, when, and where private cellular networks are used within an enterprise.
  • Private Cellular LAN for Endpoint Connectivity Private cellular can be deployed as a cellular LAN, offering endpoint connectivity both indoor and outdoor. This most closely mimics an 802.11 WLAN, with the notable exception that the RF technology used is not based on 802.11 standards.

    Endpoints connecting directly to a cellular LAN require either a physical SIM card, a software-based eSIM, or an adapter/dongle.

    The upcoming section “Comparison of Cellular to Wi-Fi” will offer more details about how cellular LAN compares to Wi-Fi.

    • Private Cellular Backhaul and Fixed Wireless Private cellular can be deployed in fixed wireless and backhaul architectures as well. In these deployments the goal is to offer point-to-point or point-to-multipoint connectivity acting as a wireless bridge, versus servicing endpoints directly.

      One deployment option is to use private cellular over a distance to connect to remote gateways that can convert cellular to Wi-Fi. The use case of this architecture would be a municipality or school that may want to extend Internet access to employees or students in rural areas without reliable broadband access. Municipalities and various commercial organizations also use remote gateways to service endpoints in hard-to-reach locations where wired cabling is not possible or is cost prohibitive. Endpoints in this use case include video cameras, IoT sensors, and remote payment kiosks such as parking meters.

      • Deployment Models Deployment models describe the level of integration into the enterprise LAN, and the option to extend services between the cellular and traditional LANs.

        Private cellular LAN integration is vendor-dependent, as some offer only overlay solutions that are fully managed, others offer enterprise-managed LAN-integrated solutions, as well as everything in between.

        The architecture and management model will also influence cost. For fully managed services there's obviously an ongoing subscription fee. With consumption-based models (like Amazon Web Services), customers pay based on the level of capacity and throughput.

        Regardless of the pricing models, current solutions can be loosely categorized into parallel, overlay or integrated LAN solutions.

        • Parallel to LAN Many MNO-managed solutions are installed as a dedicated second network, parallel to the existing LAN. In this model, the cellular LAN infrastructure is deployed with a dedicated network infrastructure, cabling, and connectivity.

          In this deployment model, there is no direct connection or integration between the private cellular network and the existing enterprise LAN. Traffic between the two networks would have to be routed externally. In this model, the cellular packet core is hosted and managed by the provider and is not located within the enterprise environment.

          Within the realm of parallel solutions, the features and requirements may vary greatly. Some offerings are designed only for vendor-specific traffic (such as one offering from Motorola currently that prioritizes its voice and push-to-talk traffic only).

          Considerations and variations in requirements for solutions deployed in parallel to the LAN include:

          • Offerings may require dedicated cabling for cellular APs
          • Some offerings require a full parallel infrastructure including switching, routing, and a separate broadband connection
          • Offerings may be limited to specifying QoS for certain devices and applications
          • Offerings with a remote packet core and no local handoff will introduce undesired hairpin routing and potential latency
          • The provider will own and manage the packet core, meaning the enterprise does not have full control over the data or data paths for privacy
        • Overlay to LAN Private cellular deployments that rely in part on the existing enterprise infrastructure may be deployed as an overlay to the LAN. From an architecture perspective, the overlay model falls between the parallel and integrated deployment models.

          Depending on the solution, the packet core may be located within the enterprise environment, or it may be offsite and managed by the provider. Most overlay solutions will provide the RAN but rely on the enterprise's existing switching, routing, and Internet connections.

          Considerations for overlay solutions include many of those covered previously in “Parallel to LAN,” and some items from the upcoming section on “Integrated to LAN” also apply.

        • Integrated to LAN Solutions that can be fully integrated to the enterprise LAN bring several benefits, and I'm partial to these solutions personally, whether delivered as fully managed solution or not.

          In broad terms, with a cellular LAN solution, it may be integrated to the LAN in a few ways. And, more specifically, a fully featured solution will offer use of all integration options on a per-use case basis—similar in concept to how we're able to tunnel or bridge Wi-Fi traffic, except we're talking about the handoff between the cellular packet core and the LAN.

          Currently available options to integrate the cellular LAN to the enterprise LAN include core handoffs that can:

          • Bridge cellular traffic to the LAN
          • Route cellular traffic to the LAN
          • NAT cellular traffic to the LAN

          One or more of these handoff techniques can be used based on the needs. Aside from the data paths, other integrations to the LAN and network services may include the following:

          • DNS
          • DHCP
          • Specifying authorization from enterprise RADIUS/AAA
          • Mapping endpoints to enterprise VLANs
          • Applying ACLs to cellular LAN traffic to and from the enterprise LAN

          For solutions that are integrated, the level of integration will vary by vendor. Some may offer basic local handoffs, while others offer deeper integrations with network and domain services including RADIUS.

          Figure 8.13 shows how cellular LANs can be integrated into the enterprise LAN including support for routing to/from the LAN, bridging to VLANs, and NAT.

• The deployment model (overlay or integrated) will dictate how tightly the services of the enterprise LAN and cellular LAN can be integrated. Obviously, in a pure overlay model with all traffic routed out to the Internet (and back into the enterprise if needed), the options for integrating services such as VLANs and RADIUS are limited.

Service Delivery Options

As with all topics in this chapter, the status of private cellular is in flux almost daily and varies by region. The statements about service delivery models are generalizations based on what's in the market today:

• Managed Service by a Mobile Network Operator
• Managed Service by a Third Party
• Enterprise-managed

• Managed Service by a Mobile Network Operator Private cellular solutions may be offered by MNOs, and in some regions that may be the only option. A main consideration for MNO-provided private cellular is the privacy of the enterprise data. Just as with public cellular data, if an MNO is in control of, or has visibility into the enterprise data or metadata, there is opportunity for them to share or monetize that. It's also possible the contract may include clauses affording the MNO additional liberties. Reviewing the contract and privacy statements is always advised with any managed service, whether from an MNO or any third party. Most MNO-provided solutions follow the parallel to LAN deployment model.
• Managed Service by a Third Party Private cellular solutions can also be provided as a fully managed service by non-MNOs and other third parties. In these instances, the infrastructure is managed by a third party, but the third party is not an MNO. This can assuage some of the data privacy and performance concerns of MNO-provided offerings, but as always, check the contracts carefully.

  Managed deployments may be fixed-fee models or based on consumption. Check the billing structure carefully, as some services include billing for data that stays within the enterprise.

  Fully managed deployments are vendor-specific, and some may impact the options for integration into the enterprise LAN, offering only an overlay option. At least today, backhaul and fixed wireless solutions are most often provided as managed services.

  Managed solutions range in level of touch and control. Some providers may not allow enterprise IT teams to manage or co-manage the cellular LAN or endpoints at all, while others offer more flexibility.

• Enterprise-managed In many regions, a private cellular solution can be deployed and/or managed by the enterprise IT team. This is especially easy with cellular LAN deployments where the solution can be managed very similarly to Wi-Fi.

  For enterprises that wish to manage their own infrastructure, the requirements vary by region. Some require license and certification for specific use cases. For example, deploying CBRS in the U.S. requires involvement from a CBRS Certified Professional Installer (CPI). The level of touch depends on whether the solution is deployed indoor or outdoor.

Licensing and Spectrum Utilization

Private cellular technologies can run in licensed spectrum, unlicensed spectrum, and shared spectrum with different models:

• Leased licensed spectrum
• Shared/coordinated spectrum
• Other dedicated spectrum
• Unlicensed spectrum (supported but not widely used)

As a comparison, public cellular (like your mobile phone) operates in licensed RF spectrums. Depending on the geographic region, private cellular may operate in licensed, unlicensed, or lightly licensed (shared) spectrum.

• Leased Licensed Spectrum Today's cellular connectivity uses allocated spectrum that's licensed to various carriers. RF spectrum is managed per region or country. MNOs can lease portions of their licensed spectrum to an enterprise or entity for private cellular.
• Shared/Coordinated Spectrum Private cellular in many regions including the U.S. uses a “shared” or lightly licensed spectrum that relies on coordination services, which are always subscription-based. In the U.S. the dedicated spectrum is CBRS, or LTE band 48. As you'll see in “Comparison of Cellular to Wi-Fi” this sits around the 3.5 GHz spectrum.

  Specifically for CBRS, there are three tiers of access prioritization: incumbents, priority, and general. Incumbents are afforded the highest priority and include fixed satellite services, radar, and defense. Priority access licenses (PALs) are available for a portion of the dedicated spectrum. PALs are bid on regionally and those entities are given higher priority than general access (for that spectrum). General access is the level most used for localized cellular LANs and is everything else that isn't formally registered as incumbent or priority.

  Since it's coordinated spectrum, to enforce the three access tiers CBRS includes a central coordination system called Spectrum Access System (SAS).

• Other Dedicated Spectrum In some regions, private cellular uses dedicated spectrum that's not necessarily shared or coordinated but is also not a slice of an existing MNO spectrum. This varies by country and is in flux. For example, in the UK, spectrum may be applied for and granted for a small fee. The model is similar to coordinated spectrum but is static in nature through the manual application and allocation process.
• Unlicensed Spectrum (Supported but Not Widely Used) It is also possible to deploy private cellular in unlicensed spectrums (as Wi-Fi does). This is supported by technology such as MulteFire but is not widely used. Using cellular technology on unlicensed spectrum forces it to behave more like Wi-Fi, which negates many of the RF benefits of cellular.

Comparison of Cellular to Wi-Fi

In many cases, cellular technology can offer specific advantages over other wireless. If you reflect for a minute on the different experiences you've had with mobile phones versus Wi-Fi, you'll begin to understand some of the advantages cellular connectivity might bring.

From an RF perspective, private cellular can offer more resilience and coverage than Wi-Fi. It can also operate at higher density, longer distances, and in harsher (RF) noise environments, making it ideal for certain applications. Plus, cellular has guaranteed QoS and SLA due to scheduling versus Wi-Fi's contention-based operation. This feature alone has a significant impact on the reliability of the connection and support for latency-sensitive applications.

Table 8.5 touches on a few technology comparisons of private cellular to 802.11 Wi-Fi technology. As always, there are many other factors to consider when deciding what wireless connectivity is best for a given use case. This information is selected to demonstrate the drivers behind moving some enterprise applications from Wi-Fi to private cellular or cellular LAN connectivity.

The details following Table 8.5 focus on comparisons of:

• Distance/Coverage
• RF Resiliency, Spectral Efficiency, and Interference
• Device Identity and Authentication
• Transmission Scheduling, QoS, and Roaming
• Access Hardware
• Supporting Clients
• Traffic/Data Path

There's a lot to unravel here, so let's look at a few of these comparisons and offer additional context. For readability, some topics in Table 8.5 will be consolidated and detailed together, and others are omitted from further explanation. The highlights are as follows:

• Distance/Coverage Layers 1 and 2 of cellular are substantially different than Wi-Fi. The different modulation and encoding techniques mean cellular signals are viable well beyond the threshold of Wi-Fi.

  We describe how well a wireless signal can be heard over the ambient noise floor in terms of decibels (dB), as a relative signal strength. The absolute power is defined in units of dBm (decibels relative to a milliwatt), which is a logarithmic (not linear) scale. Without boring you to death with RF math, in Wi-Fi we usually design for something in the neighborhood of –65 to –75 dBm, which gives us a net positive of around 15 dB signal above the noise floor.

  Cellular technologies use small subcarriers, which means the endpoint can still receive and decode data with much weaker signals. By comparison, 4G/LTE coverage may be designed in the –95 to –110 dBm range. Both Wi-Fi 6 and LTE are using orthogonal frequency-division multiple access (OFDMA) modulation but applied differently. In addition, cellular clients can transmit at a higher power than Wi-Fi, meaning they can communicate farther distances from the radio.

  The result is that a single 4G/LTE eNodeB (cellular AP) can cover three to four times the area as Wi-Fi indoors, and ten times the area outdoors. That's significant.

  As an example, Figure 8.14 shows a vendor's budgetary network planner for a 500,000 sq ft convention center. This tool offers a rough estimate and doesn't take the place of a proper design, but the output estimates just 22 cellular APs, versus what would easily require over 125 Wi-Fi APs (and that's being very generous to Wi-Fi).

• RF Resiliency, Spectral Efficiency, and Interference Proper Wi-Fi design can get complicated quickly. The 2.4 and 5 GHz RF spectrums used by Wi-Fi are crowded, and the transmission is contention-based (something covered in “Transmission Scheduling, QoS, and Roaming” shortly). In addition, in Wi-Fi, it's the endpoints that make decisions about roaming and connectivity. There are numerous roaming protocols, and not all endpoints support all protocols, further adding complexity.

  The combination of the spectrum interference, contention mechanisms (endpoints having to fight for airtime), and the often unpredictable behavior of endpoints render the resilience of Wi-Fi over the air quite volatile.

  

  Conversely, private cellular technologies work in a less cluttered (at least for now) and a more strictly managed spectrum, include guaranteed scheduling of transmissions, enforce system-coordinated roaming, and (as described in the prior section) can operate effectively with much weaker signal strength. The system coordination extends to spectral efficiency as well; in cellular, the coordination by the cellular APs allows for spectrum re-use and very granular scheduling. This brings the added benefit of allowing for much denser endpoint populations in the same airspace and even on the same radio.

• Device Identity and Authentication As someone who's worked with network access control (NAC) technologies for many years, device identity and authentication is always a pain point. Earlier in this chapter, challenges with endpoint identity and authentication were captured in “LAN-Based IoT.”

  In Wi-Fi, if an endpoint doesn't have a user attached, we don't always know what it is—an especially daunting task with the insurgence of IoT in the enterprise. Simply identifying a device becomes a complex dance of profiling mechanisms and parsing network traffic from DHCP requests and/or mirrored ports. The level of assurance varies, and at best the IoT endpoints have an assertion of identity (most often based on MAC address), and rarely, if ever, true authentication. IoT endpoints that support device certificates are the rare exception.

  Cellular technologies, public and private, use unique identifiers coded into the hardware and linked to a physical SIM or software-based eSIM. The identity is immutable, and private cellular endpoints are known and provisioned, meaning the enterprise knows exactly what something is without guessing. In addition, the unique device IDs along with cryptographic keys are used for mutual authentication between the cellular endpoint and the network.

• Transmission Scheduling, QoS, and Roaming As hinted earlier, in Wi-Fi, the endpoints are in control of their wireless experience. They make decisions about which APs to connect to, when and how to roam between APs, and they're active participants in the contention-based processes for securing airtime to transmit.

  Cellular technologies operate the other way around; the infrastructure is in control of when and how the endpoint connects, when it transmits, as well as when, how, and to where it roams.

  That coordination is made possible by the mandatory RF feedback loop in cellular technology using channel quality indicator (CQI). These metrics let the cellular infrastructure know the RF conditions as experienced by the endpoint. That data allows the infrastructure to direct the endpoint to use the best client modulation through adaptive modulation and coding (AMC). The process can be compared conceptually to 802.11k and 802.11v in Wi-Fi with the understanding that client support of Wi-Fi protocols is optional and the experience inconsistent.

• Because of that one fundamental differentiator, cellular is able to guarantee time slots and create an environment of predictable performance. It's a good fit for applications that are latency-sensitive or require strict service level agreements (SLAs) and QoS. In fact, not only does cellular have an absolute command of the scheduling, but 5G technologies introduce network slicing and support QoS over the air to a great degree.

  As you've probably learned through your journey with this book, Wi-Fi can get pretty dang complicated. Even on its best days, Wi-Fi networks will have collisions, congestion, and large variations in performance due to 802.11 contention mechanisms. Clients do what they want and often operate off-standard. Toss in the occasional monkey wrench of poor RF design, hidden node, and misbehaving clients, and it's a mess.

  When it comes to roaming, the variability with Wi-Fi endpoints is just as troublesome. There are numerous standards and variations in endpoint support for Wi-Fi. Certifying devices (infrastructure and endpoints) with the Wi-Fi Alliance is purely optional, and even for vendors that pursue it, they may opt for the lowest requirements and not test and certify critical features such as Fast BSS Transition for secure roaming and WPA-Enterprise operation to support 802.1X.

  In Chapter 4, in “Understanding Wi-Fi Design Impacts on Security,” we took a deep look at the roaming technologies in Wi-Fi and the supplemental protocols required to facilitate fast and secure roaming between APs on encrypted networks. That same section discussed at length the challenges with supporting both security and speed and the resulting common use of less secure networks to support low-latency applications.

  Cellular has been designed to support voice and has inherent mechanisms for ensuring both QoS and seamless, low-latency roaming.

• Figure 8.15 demonstrates the roaming decisions in Wi-Fi (by the endpoint) versus roaming in cellular where the packet core makes the decision about endpoint roaming.

• Access Hardware Where Wi-Fi has APs, cellular access radios are referred to as NodeBs, specifically eNodeBs in 4G, and gNodeB in 5G (for Evolved NodeB and Next Generation NodeB, respectively).

  You'll also see references in cellular terminology to a packet core or mobile core. In private cellular LANs, this is a virtual or physical appliance that acts much like a Wi-Fi controller. It handles many functions like managing the cellular APs, authentication, routing, and applying QoS policies and access control policies.

  Figure 8.16 offers a view of both an indoor and outdoor cellular AP. Very similar to Wi-Fi APs, most cellular nodes (or cellular APs) run on PoE and standard cabling. Unlike Wi-Fi the reach of private cellular is much greater, especially outdoors.

  

• Supporting Clients One area Wi-Fi has a huge leg up on cellular is with the breadth of endpoints that support Wi-Fi, but that's been changing since 2020. It's obvious that mobile phones and many tablets have cellular support, but what's less obvious is that many of today's laptops support it as well.

  Endpoint adoption of the CBRS (band 48) in the U.S. has jumped significantly, and other regions of the world are following suit. To date, just some of the devices that support CBRS include Apple iPads; Dell, HP, and Lenovo laptops; Microsoft Surface devices; Panasonic rugged laptops; Zebra and other handheld scanners, and chipsets from Qualcomm.

  For devices that don't natively support SIM, eSIM, or have private cellular radios, there are adapters that can be used with most IP devices to convert them to cellular endpoints.

• Traffic/Data Path With cellular LANs, the data path can be identical to an enterprise Wi-Fi data path. And, depending on the vendor, it can be far more flexible than that of traditional controller-based APs. Cellular's use of NFV and microservices means the core duties could be distributed and virtualized on-prem or in a public or private cloud.

Security and Privacy in Private Cellular

Cellular brings several advantages in terms of security. Its inherent device identity offers the foundation required for data confidentiality and integrity. Looking back to the IAC (integrity, availability, and confidentiality) triad of infosec, cellular can help in all three aspects, and can do it natively, without requiring external products or services.

In the prior topics I've shared several bullets and explanations of the possible security benefits of cellular technologies. There are a few additional points and overarching themes to call out for private cellular LANs specifically.

• Identity, Authentication, and Encryption Cellular has inherent strong device identification and authentication using SIM/eSIMs, eliminating the need to “guess” what mystery endpoints are for specifying access control. This is also used for strong encryption over the air and extended through to the packet core and beyond.

  Cellular LAN products can come pre-hardened, and most can offer added integrity through authentication of the system components to one another, natively—meaning the endpoints authenticate to the cellular APs (or NodeBs), which in turn authenticate to the core, which authenticates to a central management platform, if applicable.

  Most private cellular deployments support the same AES-128 bit encryption comparable to WPA3-secured networks, with AES-256 on the near horizon—encryption comparable to the WPA3-Enterprise 192-bit, CNSA suite. In the Wi-Fi ecosystem, to get the same level of integrity and confidentiality requires the addition of NAC-type products, and/or a PKI infrastructure with device certificates.

• Segmentation Also, cellular (especially 5G) has intrinsic segmentation over the air and private cellular systems can extend this end-to-end throughout the LAN infrastructure. Some products can slice and encrypt over the air at the granularity of a single flow.

  Segmentation can be extended to or through the enterprise LAN, depending on the product and implementation. With integrated solutions, the cellular slice or segment can be carried through to the wired side and handed off to the LAN just like any other wired or Wi-Fi traffic, and segmentation can be preserved, changed, or modified at that point, based on policy.

• Data Privacy Integrated cellular LANs have the potential to keep enterprise data in control of the organization and eliminates privacy concerns related to passing data through carriers/MNOs or other managed service providers.

  The privacy statements are vendor- and deployment-dependent. Solutions offered by MNOs and/or as a fully managed service by a third party may have visibility into certain aspects of the data or metadata.

  As with all hosted services, read and vet the provider's privacy statement that details how your organization's data privacy will be maintained, and whether the provider may be giving or selling data to third parties.

• Centralized Security and Risk Management Cellular LANs that can be integrated to the enterprise LAN aid in centralizing visibility and control, allowing organizations to maintain security compliance and incorporate IoT connectivity into existing risk management models and zero trust strategies.