| Internet-Draft | RCM Use Cases | December 2024 |
| Henry & Lee | Expires 6 June 2025 | [Page] |
To limit the privacy issues created by the association between a device, its traffic, its location, and its user, client and client Operating System vendors have started implementing MAC address randomization. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the MAC address randomization purposes.¶
This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines schemas to maintain user privacy while preserving user quality of experience and network operation efficiency.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 June 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[IEEE_802.11] (or 'Wi-Fi') technology has revolutionized communications and become the preferred, and sometimes the only technology used by devices such as laptops, tablets, and Internet of Things (IoT) devices. Wi-Fi is an over-the-air that allows attackers with surveillance equipment can "monitor" WLAN packets and track the activity of WLAN devices. It is also sometimes possible for attackers to monitor the WLAN packets behind the Wi-Fi Access Point (AP) over the wired Ethernet. Once the association between a device and its user is made, identifying the device and its activity is sufficient to deduce information about what the user is doing, without the user's consent.¶
To reduce the risks of correlation between a device activity and its owner multiple clients, client OS vendors have started implementing Randomized and Changing MAC addresses (RCM). By randomizing the MAC address, it becomes harder to use the MAC address to construct a persistent association between a flow of data packets and a device, assuming no other visible unique identifiers or stable patterns are in use. When individual devices are no longer easily identifiable, it also becomes difficult to associate a series of network packet flows in a prolonged period with a particular individual using one specific device if the device randomizes the MAC address governed by the OS privacy policies.¶
However, such address change may affect the user experience and the efficiency of legitimate network operations. For a long time, network designers and implementers relied on the assumption that a given machine, in a network implementing [IEEE_802] technologies, would be represented by a unique network MAC address that would not change over time, despite the existence of tools to flush out the MAC address to bypass some network policies. When this assumption is broken, network communication may be disrupted. For example, sessions established between the end-device and network services may break and packets in transit may suddenly be lost. If multiple clients implement fast-paced MAC address randomization without coordination with network services, these network services may become over-solicited.¶
At the same time, some network services rely on the end station (as defined by the [IEEE_802] Standard, also called in this document device, or machine) providing an identifier, which can be the MAC address or another value. If the client implements MAC address randomization but continues sending the same static identifier, then the association between a stable identifier and the station continues despite the RCM scheme. There may be environments where such continued association is desirable, but others where user privacy has more value than any continuity of network service state.¶
It is useful for implementations of client and network devices to enumerate services that may be affected by RCM and evaluate possible schemas to maintain both the quality of user experience and network efficiency while RCM happens, and user privacy is strengthened. This document presents these assessments and recommendations.¶
This document is organized as follows. Section 2 discusses the current status of using MAC address as Identity. Section 3 discusses various actors in the network that will be impacted by the MAC address randomization. Section 4 examines the degrees of trust between personal devices and the entities at play in a network domain. Section 5 discusses various network environments that will be impacted. Section 6 analyzes some existing network services that will be impacted. Finally, Appendix A includes some schemas that are being worked on.¶
The Media Access Control (MAC) layer of IEEE 802 technologies defines rules to control how a device accesses the shared medium. In a network where a machine can communicate with one or more other machines, one such rule is that each machine needs to be identified either as the target destination of a message or as the source of a message (and the target destination of the answer). Initially intended as a 48-bit (6 octets) value in the first versions of the [IEEE_802] Standard, other Standards under the [IEEE_802] umbrella allowed this address to take an extended format of 64 bits (8 octets), of which enabling a larger number of MAC addresses to coexist as the 802 technologies became widely adopted.¶
Regardless of the address length, different networks have different needs, and several bits of the first octet are reserved for specific purposes. In particular, the first bit is used to identify the destination address as an individual (bit set to 0) or a group address (bit set to 1). The second bit, called the Universally or Locally Administered (U/L) Address Bit, indicates whether the address has been assigned by a universal or local administrator. Universally administered addresses have this bit set to 0. If this bit is set to 1, the entire address is considered locally administered (clause 8.4 of [IEEE_802]).¶
The intent of this provision is important for the present document. The [IEEE_802] Standard recognized that some devices (e.g., smart thermostats) may never change their attachment network and will not need a globally unique MAC address to prevent address collision against any other device in any other network. The U/L bit can be set to signal to the network that the MAC Address is intended to be locally unique (not globally unique). The 802 Standard [IEEE_802] did not initially define the MAC Address allocation schema when the U/L bit is set to 1. It states the address must be unique in a given broadcast domain (i.e., the space where the MAC addresses of devices are visible to one another).¶
It is also important to note that the purpose of the Universal version of the address was to avoid collisions and confusion, as any machine could connect to any network, and each machine needs to determine if it is the intended destination of a message or its response. Clause 8.4 of [IEEE_802] reminds network designers and operators that all potential members of a network need to have a unique identifier in that network (if they are going to coexist in the network without confusion on which machine is the source or destination or any message). The advantage of an administrated address is that a node with such an address can be attached to any Local Area Network (LAN) in the world with an assurance that its address is unique in that network.¶
With the rapid development of wireless technologies and mobile devices, this scenario became very common. With a vast majority of networks implementing [IEEE_802] radio technologies at the access, the MAC address of a wireless device can appear anywhere on the planet and collisions should still be avoided. However, the same evolution brought the distinction between two types of devices that the [IEEE_802] Standard generally referred to as ‘nodes in a network’. Their definition is found in the [IEEE_802E] Recommended Practice stated in Section 6.2 of [IEEE_802].¶
Identifying the device is trivial if it has a unique MAC address. Once this unique MAC address is established, detecting any elements that directly or indirectly identify the user of the device (Personally Identifiable Information, or PII) is enough to link the MAC address to that user. Then, any detection of traffic that can be associated with the device will also be linked to the known user of that device (Personally Correlated Information, or PCI).¶
This possible identification or association presents a privacy issue, especially with wireless technologies. For most of them, and in particular for [IEEE_802.11], the source and destination MAC addresses are not encrypted even in networks that implement encryption (so that each machine can easily detect if it is the intended target of the message before attempting to decrypt its content, and also identify the transmitter, to use the right decryption key when multiple unicast keys are in effect).¶
This identification of the user associated with a node was clearly not the intent of the 802 MAC address. A logical solution to remove this association is to use a locally administered address instead and change the address in a fashion that prevents a continuous association between one MAC address and some PII. However, other network devices on the same LAN implementing a MAC layer also expect each device to be associated with a MAC address that would persist over time. When a device changes its MAC address, other devices on the same LAN may fail to recognize that the same machine is attempting to communicate with them. Additionally, upper protocol layers (e.g., application layer) have been designed with the assumption that each node on the LAN using these services will have a MAC address that would remain consistent over time. This type of MAC address is referred to as 'persistent' MAC address in this document. This assumption sometimes adds to the PII confusion, for example in the case of Authentication, Authorization, and Accounting (AAA) services [RFC3539] authenticating the user of a machine and associating the authenticated user to the device MAC address. Other services solely focus on the machine (e.g., DHCPv4 [RFC2131]), but still expect each device to use a persistent MAC address, for example to re-assign the same IP address to a returning device. Changing the MAC address may disrupt these services.¶
The risk of service disruption is weighted against the privacy benefits. However, the plurality of actors involved in the exchanges tends to blur the boundaries of what privacy violations should be protected against. It might therefore be useful to list the actors associated with the network exchanges, either because they actively participate in these exchanges, or because they can observe them. Some actors are functional entities, some others are human (or related) entities.¶
Network communications based on IEEE 802 technologies commonly rely on station identifiers based on a MAC address. This MAC address is utilized by several types of network functional entities such as applications or devices that provide a service related to network operations.¶
Humans may actively participate in the network structure and operations, or be observers at any point of the network lifecycle. Humans could be wireless device users or people operating wireless networks.¶
The surface of PII exposures that can drive MAC address randomization depends on (1) the environment where the device operates, (2) the presence and nature of other devices in the environment, and (3) the type of network the device is communicating through. Consequently, a device can use an identifier (such as a MAC address) that can persist over time if trust with the environment is established, or that can be temporal if an identifier is required for a service in an environment where trust has not been established. Note that trust is not binary. It is useful to distinguish what trust a personal device may establish with the different entities at play in a network domain where a MAC address may be visible:¶
The trust relationship depends on the relationship between the user of a personal device and the operator of a network service that the personal device may use. It is useful to observe the typical trust structure of common environments:¶
Different network environments provide different levels of network services, from simple to complex. At its simplest level, a network can provide a wireless connecting device basic IP communication service (e.g., DHCPv4 [RFC2131] or SLAAC [RFC4862]) and an ability to connect to the Internet (e.g., DNS service or relay, and routing in and out through a local gateway). The network can also offer more advanced services, such as file storage, printing, or local web service. Larger and more complex networks can also incorporate more advanced services, from AAA to Quality of Experience monitoring and management. These services are often accompanied by network performance management services. Different levels of services may call for different relationships with the device, its user, and the identity. For example, there is usually no need to identify the device or its user in a public network. However, there may be a need, in an enterprise private network, to associate a device to an identity in order to provide adapted quality of services (e.g., to prioritize identified voice traffic coming from a smartphone over keepalive data coming from an IoT endpoint). Applications may use ECN [RFC3168] for congestion and/or DSCP [RFC8837] for classification to signal the network for prioritization. The same type of network may need to limit the effect of IP address spoofing and invalid reuse through mechanisms like SAVI [RFC6620].¶
Wireless access points and controllers use the MAC address to validate the device connection context, including protocol capabilities, confirmation that authentication was completed, Quality of Service or security profiles, and encryption keying material. Some advanced access points and controllers also include upper layer functions whose purpose is covered below. A device changing its MAC address, without another recorded device identity, would cause the access point and the controller to lose the relation between a connection context and the corresponding device. As such, the layer-2 infrastructure does not know that the device (with its new MAC address) is authorized to communicate through the network. The encryption keying material is not identified anymore (causing the access point to fail to decrypt the device packets and fail to select the right key to send encrypted packets to the device). In short, the entire context needs to be rebuilt, and a new session restarted. The time consumed by this procedure breaks any flow that needs continuity or short delay between packets on the device (e.g., real-time audio, video, AR/VR, etc.) The [IEEE_802.11i] Standard recognizes that a device may leave the network and come back after a short time window. As such, the standard suggests that the infrastructure should keep the context for a device for a while after the device was last seen. MAC address randomization in this context can cause resource exhaustion on the wireless infrastructure and the flush of contexts, including for devices that are simply in temporal sleep mode.¶
Some network equipment such as Multi-Layer routers and Wi-Fi Access Points which serve both layer-2 and layer-3 in the same device rely on ARP [RFC826], and NDP [RFC4861], to build the MAC-to-IP table for packet forwarding. Aggressive MAC randomization from many devices in a short time interval may cause the layer-2 switch to exhaust its resources, holding in memory traffic for a device whose port location can no longer be found. As these infrastructure devices also implement a cache (to remember the port position of each known device), to frequent randomized MAC address changes can cause resource exhaustion and the flush of older MAC addresses, including for devices that did not change their MAC to a new randomized one. For the RCM device, these effects translate into session discontinuity and return traffic losses.¶
In wireless contexts, 802.1X [IEEE_802.1X] authenticators rely on the device and user identity validation provided by an AAA server to change the interface from a blocking state to a forwarding state. The MAC address is used to verify that the device is in the authorized list, and to retrieve the associated key used to decrypt the device traffic. A change in MAC address causes the port to be closed to the device data traffic until the AAA server confirms the validity of the new MAC address. Consequently, MAC address randomization can disrupt the device traffic and strain the AAA server.¶
DHCPv4 servers, without a unique identification of the device, lose track of which IP address is validly assigned. Unless the RCM device releases the IP address before changing its MAC address, DHCPv4 servers are at risk of scope exhaustion, causing new devices (and RCM devices) to fail to obtain a new IP address. Even if the RCM device releases the IP address before changing the MAC address, the DHCPv4 server typically holds the released IP address for a certain duration, in case the leaving MAC returns. As the DHCPv4 [RFC2131] server cannot know if the release is due to a temporal disconnection or a MAC randomization, the risk of scope address exhaustion exists even in cases where the IP address is released.¶
Network devices with self-assigned IPv6 addresses (e.g., with SLAAC defined in [RFC6620]) and devices using static IP addresses rely on mechanisms like Optimistic Duplicate Address Detection (DAD) [RFC4429] and NDP [RFC4861] for peer devices to establish the association between the target IP address and a MAC address, and these peers may cache this association in memory. Changing the MAC address, even at disconnection-reconnection phase, without changing the IP address, may disrupt the stability of these mappings for these peers, if the change occurs within the caching period.¶
Routers keep track of which MAC address is on which interface, so they can form the proper Data Link header when forwarding a packet to a segment where MAC addresses are used. MAC address randomization can cause MAC address cache exhaustion, but also the need for frequent Address Resolution Protocol (ARP), Reverse Address Resolution Protocol (RARP) [RFC826], Neighbor Solicitation and, Neighbor Advertisement [RFC4861] exchanges.¶
In residential settings (environment type A in Section 5), policies can be in place to control the traffic of some devices (e.g., parental control or block-list filters). These policies are often based on the device's MAC address. MAC address randomization removes the possibility for such control.¶
In residential settings (environment type A) and in enterprises (environment types D and E), device recognition and ranging may be used for IoT-related functionalities (door unlock, preferred light and temperature configuration, etc.) These functions often rely on the detection of the device's wireless MAC address. MAC address randomization breaks the services based on such model.¶
In managed residential settings (environment types B) and in enterprises (environment types D and E), the network operator is often requested to provide IT support. With MAC address randomization, real-time support is only possible if the user can provide the current MAC address. Service improvement support is not possible if the MAC address that the device had at the (past) time of the reported issue is not known at the time the issue is reported.¶
In industrial environment, policies are associated with each group of objects, including IoT devices. MAC address randomization may prevent an IoT device from being identified properly, thus leading to network quarantine and disruption of operations.¶
Section 6.1 discusses different environments, different settings, and the expectations of users and network operators. Table 1 summarizes the expected degree of trust, network admin responsibility, complexity of supported network services, and network support expectation from the user for the different use cases defined in Section 5.¶
| Use Cases | Trust Degree | Network Admin | Network Services | Network Support Expectation |
|---|---|---|---|---|
| (A) Residential settings under the control of the user | Full trust | User | Medium | Low |
| (B) Managed residential settings | Selective trust | IT | Medium | Medium |
| (C) Public guest networks | Zero trust | ISP | Simple | Low |
| (D) Enterprises with Bring-Your-Own-Device (BYOD) | Selective trust | IT | Complex | Medium |
| (E) Managed enterprises | Full trust | IT | Complex | High |
For example, a Home network is sometimes considered to be trusted and safe, where users are not worried about other users (or the home network admin) seeing their MAC address. Users expect a simple procedure to connect to their home network. All devices in the home network often trust each other. The Home network can also include many IoT devices, which need to be simple to onboard and manage. Home users typically expect the network operator to protect the home network from external threats (i.e., attacks from the Internet). Home users also typically expect certain policy features (e.g., Parental Control). Most home users do not expect to need networking skills to manage their home network. Such environment may lead to full-trust conditions. Although trust may typically exist between allowed actors, there is no guarantee that an eavesdropper isn't monitoring the Wi-Fi traffic from outside or a rogue IoT device isn't monitoring local traffic from within. The reality often limits the effectiveness of trust in most home scenarios.¶
On the other end of the spectrum, Public Wi-Fi is often viewed as completely untrusted, with users not expecting to trust other users or actors inside or outside the layer-2 domain. Privacy is the number one concern for the user. Most users connecting to Public Wi-Fi only require simple Internet connectivity services and expect limited to no technical support.¶
Existing technical schemas that address some of the requirements of the use cases listed above in Appendix A.¶
This memo includes no request to IANA.¶
Privacy considerations are discussed throughout this document.¶
At the time of association to a Wi-Fi access point, 802.1X [IEEE_802.1X] authentication coupled with WPA2 or WPA3 [IEEE_802.11i] encryption schemes allow for the mutual identification of the client device or the user of the device and an authentication authority. The authentication exchange does not occur in clear text, and the user or the device identity can be concealed from unauthorized observers. However, the authentication authority is in most cases under the control of the same entity as the network access provider. This may lead to expose the user or device identity to the network owner.¶
This scheme is well-adapted to enterprise environment, where a level of trust is established between the user and the enterprise network operator. In this scheme, MAC address randomization can occur through brief disconnections and reconnections (under the rules of [IEEE_802.11bh]). Authentication may then need to reoccur, with an associated cost of service disruption and additional load on the enterprise infrastructure, and an associated benefit of limiting the exposure of a continuous MAC address to external observers. The adoption of this scheme is limited outside of the enterprise environment by the requirement to install an authentication profile on the end device, which would be recognized and accepted by a local authentication authority and its authentication server. Such a server is uncommon in a home environment, and the procedure to install a profile is cumbersome for most untrained users. The likelihood that a user or device profile would match a profile recognized by a public Wi-Fi authentication authority is also fairly limited. This may restrict the adoption of this scheme for public Wi-Fi as well. Similar limitations are found in hospitality environment.¶
In order to alleviate some of the limitations listed above, the Wireless Broadband Alliance (WBA) OpenRoaming Standard introduces an intermediate trusted relay between local venues (places where some public Wi-Fi is available) and sources of identity [I-D.tomas-openroaming]. The federation structure extends the type of authorities that can be used as identity sources (compared to traditional enterprise-based 802.1X [IEEE_802.1X] scheme for Wi-Fi), and facilitates the establishment of trust between local networks and an identity provider. Such a procedure increases the likelihood that one or more identity profiles for the user or the device will be recognized by a local network. At the same time, authentication does not occur to the local network. This may offer the possibility for the user or the device to keep their identity obfuscated from the local network operator, unless that operator specifically expresses the requirement to disclose such identity (in which case the user has the option to accept or decline the connection and associated identity exposure).¶
The OpenRoaming scheme seems well-adapted to public Wi-Fi and hospitality environment. It defines a framework to protect the identity from unauthorized entities while to permit mutual authentication between the device or the user and a trusted identity provider. Just like with standard 802.1X [IEEE_802.1X] scheme for Wi-Fi, authentication allows for the establishment of WPA2 or WPA3 keys [IEEE_802.11i] that can then be used to encrypt the communication between the device and the access point. The encryption adds extra protection to prevent the network traffic from being eavesdropped.¶
MAC address randomization can occur through brief disconnections and reconnections (under the rules of [IEEE_802.11bh]). Authentication may then need to reoccur, with an associated cost of service disruption and additional load on the venue and identity provider infrastructure, and an associated benefit of limiting the exposure of a continuous MAC address to external observers. Limitations of this scheme include the requirement to first install one or more profiles on the client device. This scheme also requires the local network to support RADSEC [RFC6614] and the relay function, which may not be common in small hotspot networks and home environment.¶
It is worth noting that, as part of collaborations between IETF MADINAS and WBA around OpenRoaming, some RADIUS privacy enhancements have been proposed in the IETF RADEXT group. For instance, [I-D.ietf-radext-deprecating-radius] describes good practices in the use of Chargeable-User-Identity (CUI) between different visited networks, making it better suited for Public Wi-Fi and Hospitality use cases.¶
Most client device operating system vendors offer RCM schemes, enabled by default (or easy to enable) on client devices. With these schemes, the device changes its MAC address, when not associated, after having used a given MAC address for a semi-random duration window. These schemes also allow for the device to manifest a different MAC address in different SSIDs.¶
Such a randomization scheme enables the device to limit the duration of exposure of a single MAC address to observers. In [IEEE_802.11bh], MAC address randomization is not allowed during a given association session, and MAC address randomization can only occur through disconnection and reconnection. Authentication may then need to reoccur, with an associated cost of service disruption and additional load on the venue and identity provider infrastructure, directly proportional to the frequency of the randomization. The scheme is also not intended to protect from the exposure of other identifiers to the venue network (e.g., DHCP option 012 [host name] visible to the network between the AP and the DHCPv4 server).¶