wdiff rfc9797.original rfc9797.txt

Internet Engineering Task Force (IETF) J. Henry
Internet-Draft
Request for Comments: 9797 Cisco Systems
Intended status:
Category: Informational Y. Lee
Expires: 23
ISSN: 2070-1721 Comcast
June 2025 Comcast
20 December 2024

Randomized and Changing MAC Address: Media Access Control (MAC) Addresses: Context,
Network Impacts, and Use Cases
draft-ietf-madinas-use-cases-19

Abstract

To limit the privacy issues created by the association between a
device, its traffic, its location, and its user in [IEEE_802] IEEE 802 networks,
client and client Operating System vendors have started implementing MAC
Media Access Control (MAC) address randomization. This technology is
particularly important in Wi-Fi [IEEE_802.11] networks (defined in IEEE 802.11) due
to the over-the-air medium and device mobility. 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
purpose of MAC address
randomization purposes. randomization.

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 two some existing frameworks to that maintain user privacy while
preserving user quality of experience and network operation
efficiency.

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents valid
approved by the IESG are candidates for a maximum any level of Internet
Standard; see Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 23 June 2025.
https://www.rfc-editor.org/info/rfc9797.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. MAC Address as Identity: User vs. Device . . . . . . . . . . 4
2.1. Privacy of MAC Address . . . . . . . . . . . . . . . . . 6 Addresses
3. The Actors: Network Functional Entities and Human Entities . 6
3.1. Network Functional Entities . . . . . . . . . . . . . . . 7
3.2. Human-related Human-Related Entities . . . . . . . . . . . . . . . . . 8
4. Degrees of Trust . . . . . . . . . . . . . . . . . . . . . . 9
5. Environment . . . . . . . . . . . . . . . . . . . . . . . . . 10 Environments
6. Network Services . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Device Identification and Associated Problems . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Existing Frameworks . . . . . . . . . . . . . . . . 18
A.1. IEEE 802.1X with WPA2 / WPA3 . . . . . . . . . . . . . . . . . 18
A.2. OpenRoaming . . . . . . . . . . . . . . . . . . . . . . . 19
A.3. Proprietary RCM schemes . . . . . . . . . . . . . . . . . 20 Schemes
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20

1. Introduction

When MAC-Address the MAC address was first introduced in [IEEE_802] Standard, [IEEE_802], it was used
in wired Ethernet network networks [IEEE_802.3]. Due to the nature of
the wired network,
networks, devices were relatively stationary stationary, and the physical
connection imposed a boundary to restrict that restricted attackers to from easily access
accessing the network data. But However, [IEEE_802.11] (Wi-Fi) brought
new challenges when it was introduced.

The flexibility of Wi-Fi technology has revolutionized communications
and become the preferred, and sometimes the only only, technology used by
devices such as laptops, tablets, and Internet of Things (IoT)
devices. Wi-Fi is an over-the-air medium that allows attackers with
surveillance equipment to 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 identifying a device only by the MAC address,
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 changes 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, IEEE 802 technologies
[IEEE_802], would be represented by a unique network MAC address that
would not change over time. When this assumption is broken, network
communication may be disrupted. For example, sessions established
between the end-device end device and the network services may break break, and
packets in transit may suddenly be lost. If multiple clients
implement aggressive (e.g., once an hour or shorter) MAC address
randomization without coordination with network services, some
network services services, such as MAC address cache caching in the AP and the
upstream layer-2 switch Layer 2 switch, may not be able to handle the load that load, which
may result in an unexpected network interruption.

At the same time, some network services rely on the end station (as
defined by the [IEEE_802] Standard, [IEEE_802], 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 there may be 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 to evaluate
possible
framework frameworks to maintain both the quality of user experience
and network efficiency while RCM happens, happens and user privacy is
strengthened. This document presents these assessments and
recommendations.

Although this document mainly discusses MAC-Address MAC address randomization in
Wi-Fi [IEEE_802.11] networks, networks [IEEE_802.11], the same principles can be easily
extended to any [IEEE_802.3] networks. IEEE 802.3 networks [IEEE_802.3].

This document is organized as follows. 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 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 frameworks that
are being worked on. existing frameworks.

2. MAC Address as Identity: User vs. Device

The

In IEEE 802.3 technologies [IEEE_802.3], the Media Access Control
(MAC) layer of IEEE 802.3 [IEEE_802.3]
technologies define 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 either 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) (6-octet) value in the first versions
of the [IEEE_802.3] Standard, [IEEE_802.3], other Standards standards under the [IEEE_802.3] IEEE 802.3 umbrella allow
this address to take an extended format of 64 bits (8
octets) octets), which enable
enabled a larger number of MAC addresses to coexist as
the IEEE 802.3
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 Universal/Local
(U/L) Address Bit, 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 to be locally administered (clause (see Clause
8.4 of [IEEE_802]). Note that universally administered MAC addresses
are required to register to IEEE IEEE, while locally administered MAC
addresses are not.

The intent of this provision is important for the present document.
The
[IEEE_802] Standard recognized recognizes 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 address is intended to be locally unique (not
globally unique). [IEEE_802] did not initially define the MAC Address
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 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] IEEE 802 radio technologies [IEEE_802] 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 refers to as ‘nodes "nodes in a
network’. Their definition is found in the [IEEE_802E] Recommended
Practice stated in network" (see
Section 6.2 of [IEEE_802].

1. [IEEE_802E] for definitions of these devices):

Shared Service Device, whose functions are Device: A device used by enough people that the
device itself, its functions, or its traffic cannot be associated
with a single or small group of people. Examples of such devices
include switches in a dense network, [IEEE_802.11] (WLAN) access points
[IEEE_802.11] in a crowded airport, and task-specific device devices
(e.g., barcode scanners).

Personal Device, which is a Device: A machine or node primarily used by a single person
or small group of people, and so that any identification of the device
or its traffic can also be associated with the identification of
the primary user or their online activity.

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 (i.e.,
Personally Identifiable Information, or PII) Information (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 (i.e., Personally Correlated Information, or PCI). Information (PCI)).

2.1. Privacy of MAC Address

This Addresses

The possible identification or association presents a privacy issue,
especially with wireless technologies. For most of them, and them
([IEEE_802.11] in
particular for [IEEE_802.11], particular), the source and destination MAC
addresses are not encrypted encrypted, even in networks that implement
encryption (so that
encryption. Thus, 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). effect.

This identification of the user associated with a node was clearly
not the intent of the IEEE 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. This type of MAC addresses
address is referred to as 'persistent' MAC address in this document.
This assumption sometimes adds to the PII confusion, for example 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]), [RFC2131]) but
still expect each device to use a persistent MAC address, for example
example, to re-assign reassign the same IP address to a returning device.
Changing the MAC address may disrupt these services.

3. The Actors: Network Functional Entities and Human Entities

The risk of service disruption is weighed against the privacy
benefits. However, the plurality of actors involved in the exchanges
tends to blur the boundaries of what which privacy violations should be
protected against. It Therefore, it is therefore useful to list the actors
associated with the network exchanges, either exchanges because they either actively
participate in these exchanges, exchanges or because they can observe them. Some actors are
functional entities, while some others are human (or related) entities.

3.1. Network Functional 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.

1. Wireless access network infrastructure devices (e.g., WLAN access
points or controllers): these These devices participate in IEEE 802 LAN
operations. As such, they need to identify each machine as a
source or destination to successfully continue exchanging frames.
As a device changes its network attachment (roams) from one
access point to another, the access points can exchange
contextual information, information (e.g., device MAC, MAC and keying material),
allowing the device session to continue seamlessly. These access
points can also inform devices further in the wired network about
the roam to ensure that layer-2 Layer 2 frames are redirected to the new
device access point.

2. Other network devices operating at the MAC layer: many Many wireless
network access devices (e.g., [IEEE_802.11] access points) points [IEEE_802.11]) are
conceived as layer-2 Layer 2 devices, and as such, they bridge a frame
from one medium (e.g., [IEEE_802.11] or Wi-Fi) Wi-Fi [IEEE_802.11]) to another (e.g.,
[IEEE_802.3] or Ethernet).
Ethernet [IEEE_802.3]). This means that the MAC address of a
wireless device MAC
address often exists on the wire beyond the wireless
access device. Devices connected to this wire also implement
[IEEE_802.3]
IEEE 802.3 technologies and, [IEEE_802.3], and as such, they operate
on the expectation that each device is associated with a MAC
address that persists for the duration of continuous exchanges.
For example, switches and bridges associate MAC addresses to
individual ports (so as to know to which port to send a frame
intended for a particular MAC address). Similarly, AAA services
can validate the identity of a device and use the device's MAC
address as a the first pointer to the device identity (before
operating further verification). Similarly, some networking
devices offer layer-2 Layer 2 filtering policies that may rely on the
connected MAC addresses. IEEE 802.1X-enabled [IEEE_802.1X] devices
[IEEE_802.1X] may also selectively put the interface in a
blocking state until a connecting device is authenticated. These
services then use the MAC address as a the first pointer to the
device identity to allow or block data traffic. This list is not
exhaustive. Multiple services are defined for [IEEE_802.3] networks, IEEE 802.3
networks [IEEE_802.3], and multiple services defined by the IEEE
802.1 working group Working Group are also applicable to [IEEE_802.3] networks. IEEE 802.3 networks
[IEEE_802.3]. Wireless access points may also connect to other mediums
other than [IEEE_802.3] (e.g., DOCSIS the Data-Over-Cable Service
Interface Specification (DOCSIS) [DOCSIS]), which also implements
mechanisms under the umbrella of the general IEEE 802 Standard, standard
and therefore expect the unique and persistent association of a
MAC address to a device.

3. Network devices operating at upper layers: some Some network devices
provide functions and services above the MAC layer. Some of them
also operate a MAC layer function: for function. For example, routers provide
IP forwarding services but rely on the device MAC address to
create the appropriate frame structure. Other devices and
services operate at upper layers but also rely upon the IEEE 802
principles of unique MAC-to-device mapping. For example, the
Address Resolution Protocol (ARP) [RFC826] and Neighbor Discovery
Protocol (NDP) [RFC4861] use a MAC address to create the mapping
of an IP address to a MAC address for packet forwarding. If a
device changes its MAC address without a mechanism to notify the
layer-2
Layer 2 switch it is connected to or is the provider of a service
that expects a stable MAC-to-device mapping, the provider of the
service and traffic forwarding may be disrupted.

3.2. Human-related Human-Related Entities

Humans may actively participate in the network structure and
operations,
operations or be observers at any point of the network lifecycle.
Humans could be wireless device users of wireless devices or people operating
wireless networks.

1. Over-The-Air Over-the-Air (OTA) observers: as the The transmitting or receiving MAC
address is usually not encrypted in wireless 802-technologies
exchanges, exchanges in IEEE
802 technologies, and as any protocol-compatible device in range of
the signal can read the frame header. As such such, OTA observers are
able to read the MAC addresses of individual transmissions. Some
wireless technologies also support techniques to establish
distances or positions, allowing the observer, in some cases, to
uniquely associate the MAC address with a physical device and its
associated location. An OTA observer may have a legitimate
reason to monitor a particular device, for example, for IT
support operations. However, another actor might also monitor
the same device to obtain PII or PCI.

2. Wireless access network operators: some Some wireless access networks
host devices that meet specific requirements, such as device type
(e.g., IoT-only networks, networks and factory operational networks).
Therefore, operators can attempt to identify the devices (or the
users) connecting to the networks under their care. They often
use the MAC address to represent an identified device.

3. Network access providers: wireless Wireless access networks are often
considered beyond the first 2 two layers of the OSI model. For
example, a law enforcement agency (e.g., the FBI in the United
States) may legally require the network access provider to
identify communications from a subject. In this context, the
operating access networks need to identify the devices used by
the subjects and cross-reference the data generated by the
devices in the network. In other contexts, the operating access
networks assign resources based on contractual conditions (e.g., fee,
fee and bandwidth fair share). In these scenarios, the operators
may use the MAC address to identify the devices and the users of
their networks.

4. Over-The-Wired Over-the-Wired internal (OTWi) observers: because Because the device
wireless MAC address continues to be present over the wire if the
infrastructure connection device (e.g., access point) functions
as a layer-2 Layer 2 bridge, observers may be positioned over the wire
and may read transmission MAC addresses. Such capability
supposes that the observer has access to the wired segment of the
broadcast domain where the frames are exchanged. A broadcast
domain is a logical segment of a network in which devices can
send, receive, and monitor data frames from all other devices
within the same segment. In most networks, such capability
requires physical access to an infrastructure wired device in the
broadcast domain (e.g., switch closet), closet) and is therefore not
accessible to all.

5. Over-The-Wired Over-the-Wired external (OTWe) observers: beyond Beyond the broadcast
domain, frame headers are removed by a routing device, and a new
layer-2
Layer 2 header is added before the frame is transmitted to the
next segment. The device MAC address is not visible anymore
unless a mechanism copies the MAC address into a field that can
be read while the packet travels onto to the next segment (e.g.,
pre- [RFC4941] and pre-[RFC7217] IPv6
addresses built from the MAC address). address prior to the use of the
methods defined in [RFC4941] and [RFC7217]). Therefore, unless
this last condition exists, OTWe observers are not able to see
the device's MAC address.

4. Degrees of Trust

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 it can
be use
an identifier that is temporary 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:

1. Full trust: there There is an environment where a device establishes a
trust relationship, and the device can share its persistent MAC
address with the access network devices (e.g., access point and
WLAN Controller). In this environment, the controller). The network provides necessary security
measures to prevent observers or network actors from accessing
PII. The device (or its user) also has confidence that its MAC
address is not shared beyond the layer-2 Layer 2 broadcast domain
boundary.

2. Selective trust: in In another environment, depending on the pre-
defined
predefined privacy policies, a device may decide to use one pseudo-
persistent
pseudo-persistent MAC address for a set of network elements and
another pseudo-persistent MAC address for another set of network
elements. Examples of privacy policies can be SSID a combination of
Service Set Identifier (SSID) and BSSID
combination, Basic Service Set Identifier
(BSSID), a particular time-of-day, time of day, or a pre-set preset time duration.

3. Zero trust: in In another environment, a device may randomize its
MAC address with any local entity reachable through the AP. It
may generate a temporary MAC address to each of them. That
temporary MAC address may or may not be the same for different
services.

5. Environment Environments

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:

(A) Residential settings under the control of the user: this This is a
typical home network with Wi-Fi in the LAN and Internet in the
WAN. In this environment, traffic over the Internet does not
expose the MAC address of the internal device if it is not
copied to another field before routing happens. The wire
segment within the broadcast domain is under the control of the
user and is usually not at risk of hosting an eavesdropper.
Full trust is typically established at this level among users
and with the network elements. Note that Full trust "Full trust" in this
context is referring to the MAC address persistency. It does
not extend to full trust between applications or devices. The
device trusts the access point and all layer-2 Layer 2 domain entities
beyond the access point, where the Wi-Fi transmissions can be
detected, but there is no guarantee that an eavesdropper will
not observe the communications. As such, even in this
environment, it is common to assume that, even in
this environment, that attackers may still be
able to monitor the unencrypted information such as MAC addresses.
If a device
decided decides to not fully trust the network, it might
apply any necessary policy to protect its identity. Most
devices in the network only require simple connectivity so that
the network services are simple. For network support, it is
also simple. It is usually related to Internet connectivity.

(B) Managed residential settings: examples Examples of this type of
environments
environment include shared living facilities and other
collective environments where an operator manages the network
for the residents. The OTA exposure is similar to (A). The
operator may be requested to provide IT support to the residents
and may need to identify a device activity in real-time. It may also
need to real time or analyze
logs. The infrastructure is shared and covers a larger area
than (A), in (A); residents may connect to the network from different
locations. For example, they may regularly connect to the
network from their own apartments. They may apartments and occasionally connect to the network from
common areas. The device may decide to use different pseudo-persistent pseudo-
persistent MAC address addresses as we described in Section 4. As such,
the trust degree of trust is Selective trust. "Selective trust". In this environment,
the network services will be slightly more complex than in (A). Network
The network may be segmented by locations and multiple SSID. User's SSIDs.
Users' devices should be able to join the network without pre-certification and pre-
certification or pre-approval. In most cases, users only need
simple connectivity; thus, network support will be slightly but (but
not significantly significantly) more complicated than in (A).

(C) Public guest networks: public Public hotspots in shopping malls,
hotels, stores, train stations, and airports are typical
examples of this environment. In this environment, trust is
commonly not established with any element of the layer-2 Layer 2
broadcast domain. Users do not anticipate a public guest
network using the MAC address information to identify their
location and network activity. They do not trust the network
and do not want the network to memorize them permanently. The trust
degree of trust is Zero. "Zero trust". Devices in this network should
avoid using a long-lived MAC address to prevent fingerprinting.
For example, the device may use a different MAC address every
time it attaches to a new Wi-Fi access point. Some guest
network operators may legally abide to identify devices. They
should not use the MAC address for such a function. Most users
connecting to a public guest network only expect simple Internet
connectivity services, so the network services are simple. If
users have issue to connect issues connecting to the network or to access accessing the
Internet, they expect limited to no technical support. Thus,
the network support level is low.

(D) Enterprises with Bring-Your-Own-Device (BYOD): this This type of
networks are
network is similar to (B) except that the onboarding devices are
subjected to pre-approval and pre-certification. The devices
are usually personal devices and are not under the control of
the corporate IT team. Compared to residential network, networks,
enterprise
network networks usually provides provide more sophisticated network
services
including including, but not limited to to, application-based network policies and
identity-based network policies. Change of Changing the MAC address may
interrupt network services if the services are based on that MAC
address. Thus, network operations will be more complex, so the
network support level is high.

(E) Managed enterprises: in this environment: this This type of networks
are network is similar to (C).
The main difference is that the devices are owned and managed by
the enterprise. Given Because both the network and the devices are
owned and managed by the enterprise, the trust degree of trust is Full
trust.
"Full trust". Network services and the network support level
are the same as
(D) in (D).

Table 1 summarizes the environment in a table format. environments described above.

Table 1: Use Cases

Existing technical frameworks that address some of the requirements
of the use cases listed above are discussed in Appendix A.

6. Network Services

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 with basic IP communication
service (e.g., DHCPv4 [RFC2131] or SLAAC Stateless Address
Autoconfiguration (SLAAC) [RFC4862]) and an ability to connect to the
Internet (e.g., DNS service or relay, relay and routing in and out through a
local gateway). The network can also offer more advanced services,
such as managed instant messaging service, file storage, printing,
and/or local web service. Larger and more complex networks can also
incorporate more advanced services, from AAA to AR/
VR AR/VR applications.
To the network, its top priority is to provide the best Quality quality of Experience
experience to its users. Often the network contains policies which that
help to make a forwarding decision based on the network conditions,
the device, and the user identity associated to the device. For
example, in a hospital private network, the network may contain a
policy to give highest priority to doctors' Voice-Over-IP packets.
In another example, an enterprise network may contain a policy to
allow applications from a group of authenticated devices to use ECN
Explicit Congestion Notification (ECN) [RFC3168] for congestion and/or DSCP and/
or Differentiated Services Code Point (DSCP) [RFC8837] for
classification to signal the network for a specific network policy.
In this configuration, the network is required to associate the data
packets to an identity to validate the legitimacy of the marking.
Before RCM, many network systems use used a MAC address as a persistent
identity to create an association between user and device. After RCM
being implemented,
implementing RCM, the association is broken.

6.1. Device Identification and Associated Problems

Wireless access points and controllers use the MAC address to
validate the device connection context, including protocol
capabilities, confirmation that authentication was completed, Quality quality
of Service 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 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.). For example: example, [IEEE_802.11i]
recognizes that a device may leave and re-join rejoin the network 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. The device should maintain the same MAC
address in such a scenario.

Some network equipment such as Multi-Layer multi-layer routers and Wi-Fi Access
Points access
points, which serve both layer-2 Layer 2 and layer-3 Layer 3 in the same device device, rely
on ARP [RFC826], [RFC826] and NDP [RFC4861], [RFC4861] to build the MAC-to-IP table for
packet forwarding. The size of the MAC address cache in the layer-2 Layer 2
switch is finite. If new entries are created faster than the old
entries are flushed by the idle timer, it is possible to cause an
unintentional deny-of-service denial-of-service attack. For example, the default
timeout of the MAC address cache in Linux is set to 300s. 300 seconds.
Aggressive MAC randomization from many devices in a short time
interval (e.g., less than 300s) 300 seconds) may cause the layer-2 Layer 2 switch
to exhaust its resources, holding in memory traffic for a device
whose entry can no longer be found. For the RCM device, these
effects translate into session discontinuity and disrupt the active
sessions. The discontinuity impact may vary. Real-time applications
such as video conference may experience short interruption while non-real-time non-
real-time applications such as video streaming may experience minimal
or no impact. The device should carefully balance when to change the
MAC address after analyzing the nature of the running applications
and its privacy policy.

In wireless contexts, [IEEE_802.1X] IEEE 802.1X authenticators [IEEE_802.1X] rely
on the device and user identity validation provided by an a 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, 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 [RFC2131], without

Without a unique identification of the device, DHCPv4 servers
[RFC2131] 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 [RFC2131] cannot know if the release is due to a
temporary 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
[RFC4862]) 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 the
disconnection-reconnection phase, without changing the IP address, address may
disrupt the stability of these mappings for these
peers, peers if the change
occurs within the caching period. Note that this behavior is against
standard operation and existing privacy recommendations.
Implementations must avoid changing the MAC address while maintaining
the previously assigned IP address without consulting the network.

Routers keep track of which MAC address is on which interface, interface so that
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, exhaustion but also the need for frequent
Address Resolution Protocol (ARP), Reverse Address Resolution
Protocol (RARP) [RFC826], and Neighbor Solicitation and, 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 blocklist 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 (e.g., 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. models.

In managed residential settings (environment types type 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 (in the past) is not known at the time the issue is
reported.

In industrial environments, policies are associated with each group
of objects, including IoT devices. MAC address randomization may
prevent an IoT device from being identified properly, properly and thus leading lead to
network quarantine and disruption of operations.

7. IANA Considerations

This memo includes document has no request to IANA. IANA actions.

8. Security Considerations

Privacy considerations are discussed throughout this document.

9. Informative References

[DOCSIS] "DOCSIS 4.0 Physical Layer Specification CableLabs, "Cable Modem Operations Support System
Interface Specification", Data-Over-Cable Service
Interface Specifications, DOCSIS 4.0, Version I06, DOI
CM-SP-CM-OSSIv4.0", CableLabs DOCSIS , March
2022, <https://www.cablelabs.com/specifications/CM-SP-CM-
OSSIv4.0?v=I06>.

[I-D.ietf-radext-deprecating-radius]
DeKok, A., "Deprecating Insecure Practices in RADIUS",
Work in Progress, Internet-Draft, draft-ietf-radext-
deprecating-radius-05, 26 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
deprecating-radius-05>.

[I-D.tomas-openroaming]
Tomas, B., Grayson, M., Canpolat, N., Cockrell, B., and S.
Gundavelli, "WBA OpenRoaming Wireless Federation, Work in
Progress, Internet-Draft, draft-tomas-openroaming-03", 25
July 2024, <https://datatracker.ietf.org/doc/html/draft-
tomas-openroaming-03>.

[IEEE_802] IEEE, "IEEE Std 802 - IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture, DOI 10.1109/
IEEESTD.2014.6847097", Architecture", IEEE 802 , Std 802-2014,
DOI 10.1109/IEEESTD.2014.6847097, 30 June 2014,
<https://ieeexplore.ieee.org/document/6847097>.

[IEEE_802.11]
IEEE, "IEEE 802.11-2020 Standard for Information Technology--
Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks--Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
802.11 , 11
Std 802.11-2020, DOI 10.1109/IEEESTD.2021.9363693, 26
February 2021,
<https://standards.ieee.org/ieee/802.11/7028/>.
<https://ieeexplore.ieee.org/document/9363693>.

[IEEE_802.11bh]
IEEE, "IEEE 802.11bh-2023 Draft Standard for Information Technology--
Telecommunications and Information Exchange Between
Systems Local and Metropolitan Area Networks--Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 8
: Operation with Randomized and Changing MAC Addresses",
IEEE 802.11bh , P802.11bh/D1.0, 19 July 2023,
<https://ieeexplore.ieee.org/document/10214483>.

[IEEE_802.11i]
IEEE, "IEEE 802.11i-2004 - Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) specifications:
Amendment 6: Medium Access Control (MAC) Security Enhancements, DOI
10.1109/IEEESTD.2004.94585",
Enhancements", IEEE 802.11i , Std 802.11i-2004,
DOI 10.1109/10.1109/IEEESTD.2004.94585, 24 July 2004,
<https://ieeexplore.ieee.org/document/1318903>.

[IEEE_802.1X]
IEEE, "IEEE 802.1X-2020 - IEEE Standard for Local and Metropolitan Area
Networks--Port-Based Network Access
Control, DOI 10.1109/IEEESTD.2020.9018454", Control", IEEE 802.1X , Std
802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, 28 February
2020, <https://ieeexplore.ieee.org/document/9018454>.

[IEEE_802.3]
IEEE, "IEEE 802.3-2018 - IEEE Standard for Ethernet", IEEE
802.3 , 31 August 2018,
<https://standards.ieee.org/ieee/802.3/7071/>. Std 802.3-2022,
DOI 10.1109/IEEESTD.2022.9844436, 29 July 2022,
<https://ieeexplore.ieee.org/document/9844436>.

[IEEE_802E]
IEEE, "IEEE 802E-2020 - IEEE Recommended Practice for Privacy
Considerations for IEEE 802(R) Technologies", IEEE 802E , Std
802E-2020, DOI 10.1109/IEEESTD.2020.9018454, 13 November
2020,
<https://standards.ieee.org/ieee/802E/6242/>. <https://ieeexplore.ieee.org/document/9257130>.

[RADIUS] DeKok, A., "Deprecating Insecure Practices in RADIUS",
Work in Progress, Internet-Draft, draft-ietf-radext-
deprecating-radius-06, 25 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
deprecating-radius-06>.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.

[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539,
DOI 10.17487/RFC3539, June 2003,
<https://www.rfc-editor.org/info/rfc3539>.

[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.

[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/info/rfc6614>.

[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.

[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>.

[RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta,
"Differentiated Services Code Point (DSCP) Packet Markings
for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January
2021, <https://www.rfc-editor.org/info/rfc8837>.

[WBA-OPENROAMING]
Tomas, B., Grayson, M., Canpolat, N., Cockrell, B. A., and
S. Gundavelli, "WBA OpenRoaming Wireless Federation", Work
in Progress, Internet-Draft, draft-tomas-openroaming-05,
15 April 2025, <https://datatracker.ietf.org/doc/html/
draft-tomas-openroaming-05>.

Appendix A. Existing Frameworks

A.1. IEEE 802.1X with WPA2 / WPA3

In a typical enterprise Wi-Fi environment, IEEE 802.1X authentication
[IEEE_802.1X] coupled with WPA2 or WPA3 [IEEE_802.11i] encryption
schemes are commonly used for onboarding a Wi-Fi device. This allows
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, in most cases, the
authentication authority is in most cases under the control of the same entity as
the network access provider. This may lead to expose exposing the user or
device identity to the network owner.

This scheme is well-adapted to an 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 disruption, an 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 the hospitality
environment. Hospitality The hospitality environment refers to space provided by
the hospitality industry, which includes but is not limited to
hotels, stadiums, restaurants, concert halls halls, and hospitals.

A.2. OpenRoaming

In order to alleviate some of the limitations listed above, the
Wireless Broadband Alliance (WBA) OpenRoaming Standard 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]. [WBA-OPENROAMING].
The federation structure extends the type of authorities that can be
used as identity sources (compared to the traditional enterprise-based enterprise-
based IEEE 802.1X [IEEE_802.1X] scheme for Wi-Fi), Wi-Fi [IEEE_802.1X]) 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. environments. It defines a framework to protect the
identity from unauthorized entities while to permit permitting mutual
authentication between the device or the user and a trusted identity
provider. Just like with the standard IEEE 802.1X [IEEE_802.1X] scheme for
Wi-Fi, Wi-Fi
[IEEE_802.1X], 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
disruption, an 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. environments.

It is worth noting that, as part of collaborations between the IETF
MADINAS Working Group and WBA around OpenRoaming, some RADIUS privacy
enhancements have been proposed in the IETF RADEXT group. Working Group.
For instance,
[I-D.ietf-radext-deprecating-radius] [RADIUS] describes good practices in the use of
Chargeable-User-Identity (CUI) between different visited networks,
making it better suited for Public public Wi-Fi and Hospitality hospitality use cases.

A.3. Proprietary RCM schemes Schemes

Most client device operating system vendors offer RCM schemes, schemes that
are 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).

Authors' Addresses

Jerome Henry
Cisco Systems
United States of America
Email: jerhenry@cisco.com

Yiu L. Lee
Comcast
1800 Arch Street
Philadelphia, PA 19103
United States of America
Email: yiu_lee@comcast.com