Internet Engineering Task Force J. Henry
Internet-Draft Cisco Systems
Intended status: Informational Y. Lee
Expires: 17 May 2025 Comcast
13 November 2024
Randomized and Changing MAC Address: Context, Network Impacts and Use
Cases
draft-ietf-madinas-use-cases-11
Abstract
To limit the privacy issues created by the association between a
device, its traffic, its location, and its user, client and client
Operation 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 set 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 solutions
to maintain user privacy while preserving user quality of experience
and network operation efficiency.
Status of This Memo
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 17 May 2025.
Henry & Lee Expires 17 May 2025 [Page 1]
Internet-Draft RCM Use Cases November 2024
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. MAC Address as Identity: User vs. Device . . . . . . . . . . 4
2.1. Privacy of MAC Address . . . . . . . . . . . . . . . . . 5
3. The Actors: Network Functional Entities and Human Entities . 6
3.1. Network Functional Entities . . . . . . . . . . . . . . . 6
3.2. Human-related Entities . . . . . . . . . . . . . . . . . 8
4. Trust Degrees . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Environments . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Network Services . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Device Identification and Associated Problems . . . . . . 12
6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Existing Solutions . . . . . . . . . . . . . . . . . 18
A.1. 802.1X with WPA2 / WPA3 . . . . . . . . . . . . . . . . . 18
A.2. OpenRoaming . . . . . . . . . . . . . . . . . . . . . . . 19
A.3. Proprietary RCM schemes . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
IEEE 802.11 (or 'Wi-Fi') [IEEE_802.11] technology has revolutionized
communications and become the preferred, and sometimes the only
technology used by devices such as laptops, tablets and Internet-of-
Thing (IoT) devices. Wi-Fi is an over-the-air technology, 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 packers 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,
Henry & Lee Expires 17 May 2025 [Page 2]
Internet-Draft RCM Use Cases November 2024
without the user consent.
To reduce the risks of correlation between a device activity and its
owner's, multiple client and client OS vendors have started to
implement Randomized and Changing MAC addresses (RCM). By
randomizing the MAC address, it becomes harder to use the MAC address
to construct 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 packets with a particular individual using one particular
device.
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 the user privacy
has more value than any continuity of network service state.
It could be useful to enumerate services that may be affected by RCM,
and evaluate possible solutions to maintain both the quality of user
experience and network efficiency while RCM happens and user privacy
is reinforced. This document presents such assessment 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 Trust degrees.
Section 5 discusses various network environments that will be
Henry & Lee Expires 17 May 2025 [Page 3]
Internet-Draft RCM Use Cases November 2024
impacted. Section 6 analyzes some existing network services that
will be impacted. Finally, Appendix A includes some solutions that
are being worked on.
2. MAC Address as Identity: User vs. Device
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 thus 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
then allowed this address to take an extended format of 64 bits (8
octets), thus 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 either 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 local or administrator. Universally
administered addresses have this bit set to 0. If this bit is set to
1, the entire address is considered as 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
thermostat) may never change their attachment network and thus would
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 didn't
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
Henry & Lee Expires 17 May 2025 [Page 4]
Internet-Draft RCM Use Cases November 2024
the network without confusion on which machine is the source or
destination or any message). The advantage of a ly 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].
1. Shared Service Device, which functions are used by a number of
people large enough 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 in a crowded airport,
task-specific (e.g., barcode scanners) devices, etc.
2. Personal Device, which is a machine, a 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 to the identification of the primary user or their
traffic.
The identification of the device is trivial if the device expresses a
ly unique MAC address. Then, the detection of elements directly or
indirectly identifying the user of the device (Personally
Identifiable Information, or PII) is sufficient to tie the MAC
address to a user. Then, any detection of traffic that can be
associated to the device becomes also associated with the known user
of that device (Personally Correlated Information, or PCI).
2.1. Privacy of MAC Address
This possible identification or association presents a privacy issue,
especially with wireless technologies. For most of them, and in
particular for 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, so as to use the right decryption key when multiple
unicast keys are in effect).
Henry & Lee Expires 17 May 2025 [Page 5]
Internet-Draft RCM Use Cases November 2024
This identification of the user associated to 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 to 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, multiple layers implemented at
upper OSI layers have been designed with the assumption that each
node on the LAN, using these services, would have a MAC address that
would stay the same over time, and that this document calls a
'persistent' MAC address. 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.
3. The Actors: Network Functional Entities and Human Entities
The risk of service disruption is thus weighted against the privacy
benefits. However, the plurality of actors involved in the exchanges
tends to blur the boundaries of what privacy should be protected
against. It might therefore be useful to list the actors associated
to the network exchanges, either because they actively participate to
these exchanges, or because they can observe them. Some actors are
functional entities, some others are humans (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 (entities,
like 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 devices participate in IEEE 802 LAN
operations. As such, they need to identify each machine as a
source or destination so as to successfully continue exchanging
frames. Part of the identification includes recording, and
adapting to, devices communication capabilities (e.g., support
for specific protocols). As a device changes its network
attachment (roams) from one access point to another, the access
Henry & Lee Expires 17 May 2025 [Page 6]
Internet-Draft RCM Use Cases November 2024
points can exchange contextual information (e.g., device MAC,
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
frames are redirected to the new device access point.
2. Other network devices operating at the MAC layer: many wireless
network access devices (e.g., IEEE 802.11 access points) are
conceived as layer-2 devices, and as such they bridge a frame
from one medium (e.g., IEEE 802.11 or Wi-Fi) to another (e.g.,
IEEE 802.3 or Ethernet). This means that 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
technologies, and as such operate on the expectation that each
device is associated to 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 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 MAC address as a first pointer to the
device identity (before operating further verification).
Similarly, some networking devices offer layer-2 filtering
policies that may rely on the connected MAC addresses. 802.1X-
enabled [IEEE_802.1X] devices may also selectively put the
interface in blocking state until a connecting device is
authenticated. These services then use the MAC address as a
first pointer to the device identity to allow or block data
traffic. This list is not exhaustive. Multiple services are
defined for 802.3 networks, and multiple services defined by the
IEEE 802.1 working group are also applicable to 802.3 networks.
Wireless access points may also connect to other mediums than
802.3, which also implements mechanism under the umbrella of the
general 802 Standard, and therefore expect the unique and
persistent association of a MAC address to a device.
Henry & Lee Expires 17 May 2025 [Page 7]
Internet-Draft RCM Use Cases November 2024
3. Network devices operating at upper layers: some network devices
provide functions and services above the MAC layer. Some of them
also operate a MAC layer 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 802
principle of unique MAC-to- device mapping. For example, Address
Resolution Protocol (ARP) [RFC826] and Neighbor Discovery
Protocol (NDP) [RFC4861] use 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 switch it is connected to or the provider of a service
that expects a stable MAC-to-device mapping, the provider of the
service and traffic fowarding may be disrupted.
3.2. Human-related Entities
Humans may actively participate to the network structure and
operations, or be observers at any point of network lifecycle.
Humans could be wireless device users or people operating the
wireless networks.
1. Over the air (OTA) observers: as the transmitting or receiving
MAC address is usually not encrypted in wireless 802-technologies
exchanges, and as any protocol-compatible device in range of the
signal can read the frame header, OTA observers are able to read
individual transmissions MAC addresses. Some wireless
technologies also support techniques to establish distances or
positions, allowing the observer, in some cases, to uniquely
associate the MAC address to a physical device and it associated
location. It can happen that an OTA observer has a legitimate
reason to monitor a particular device, for example for IT support
operations. However, it is difficult to control if another actor
also monitors the same station with the goal of obtaining PII or
PCI.
2. Wireless access network operators: some wireless access networks
are only provided devices matching specific requirements, such as
device type (e.g., IoT-only networks, factory operational
networks). Therefore, operators can attempt to identify the
devices (or the users) connecting to the networks under their
care. They can use the MAC address to represent an identified
device.
3. Network access providers: wireless access networks are often
considered beyond the first 2 layers of the OSI model. For
example, several regulatory or legislative bodies can group all
OSI layers into their functional effect of allowing network
Henry & Lee Expires 17 May 2025 [Page 8]
Internet-Draft RCM Use Cases November 2024
communication between machines. In this context, entities
operating access networks can see their liability associated to
the activity of devices communicating through the networks that
these entities operate. In other contexts, operators assign
network resources based on contractual conditions (e.g., fee,
bandwidth fair share). In these scenarios, these operators may
attempt to identify the devices and the users of their networks.
They can use the MAC address to represent an identified device.
4. Over the wire internal (OTWi) observers: 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 bridge, observers may be positioned over the wire
and 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 division of a network where a device in the
division can send, receive and monitor data frames from all
devices in the same division. In most networks, such capability
requires physical access to an infrastructure wired device in the
broadcast domain (e.g., switch closet), and is therefore not
accessible to all.
5. Over the wired external (OTWe) observers: beyond the broadcast
domain, frames headers are removed by a routing device, and a new
layer-2 header is added before the frame is transmitted to the
next segment. The personal 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 the next segment
(e.g., pre- [RFC4941] and pre-[RFC7217] IPv6 addresses built from
the MAC address). Therefore, unless this last condition exists,
OTWe observers are not able to see the device MAC address.
4. Trust Degrees
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. Therefore, a
device can express 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. Trust is not a
binary currency. Thus 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:
Henry & Lee Expires 17 May 2025 [Page 9]
Internet-Draft RCM Use Cases November 2024
1. Full trust: there are environments where a personal device
establishes a trust relationship and can share a persistent
device identity with the access network devices (e.g., access
point and WLAN Controller), the services beyond the access point
in the layer-2 broadcast domain (e.g., DHCPv4, AAA), without fear
that observers or network actors may access PII that would not be
shared willingly. The personal device (or its user) also has
confidence that its identity is not shared beyond the layer-2
broadcast domain boundary.
2. Selective trust: in other environments, a device may not be
willing to share a persistent identity with some elements of the
layer-2 broadcast domain, but may be willing to share a
persistent identity with other elements. That persistent
identity may or may not be the same for different services.
3. Zero trust: in other environments, a device may not be willing to
share any persistent identity with any local entity reachable
through the AP, and may express a temporal identity to each of
them. That temporal identity may or not be the same for
different services.
5. 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. Thus, it is useful to observe the typical
trust structure of common environments:
A. Residential settings under the control of the user: this is
typical of a home network with Wi-Fi in the LAN and Internet
connection. In this environment, traffic over the Internet does
not expose the MAC address of 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
therefore usually not at risk of hosting an eavesdropper. Full
trust is typically established at this level among users and with
the network elements. The device trusts the access point and all
layer-2 domain entities beyond the access point. However, unless
the user has full access control over the physical space where
the Wi-Fi transmissions can be detected, there is no guarantee
that an eavesdropper would not be observing the communications.
As such, it is common to assume that, even in this environment,
full trust cannot be achieved.
B. Managed residential settings: examples of this type of
environment include shared living facilities and other collective
environments where an operator manages the network for the
Henry & Lee Expires 17 May 2025 [Page 10]
Internet-Draft RCM Use Cases November 2024
residents. The OTA exposure is similar to that of a home. A
number of devices larger than in a standard home may be present,
and the operator may be requested to provide IT support to the
residents. Therefore, the operator may need to identify a device
activity in real time, but may also need to analyze logs so as to
understand a past reported issue. For both activities, a device
identification associated to the session is needed. Full trust
is often established in this environment, at the scale of a
series of a few sessions, not because it is assumed that no
eavesdropper would observe the network activity, but because it
is a common condition for the managed operations.
C. Public guest networks: public hotspots, such as in shopping
malls, hotels, stores, train-stations, and airports are typical
of this environment. The guest network operator may be legally
mandated to identify devices or users or may have the option to
leave all devices and users untracked. In this environment,
trust is commonly not established with any element of the layer-2
broadcast domain (Zero trust model by default).
D. Enterprises with Bring-Your-Own-Device (BYOD): users may be
provided with corporate devices or may bring their own devices.
The devices are not directly under the control of a corporate IT
team. Trust may be established as the device joins the network.
Some enterprise models will mandate full trust, others,
considering the BYOD nature of the device, will allow selective
trust.
E. Managed enterprises: in this environment, users are typically
provided with corporate devices, and all connected devices are
managed, for example through a Mobile Device Management (MDM)
profile installed on the device. Full trust is created as the
MDM profile is installed.
6. Network Services
Different network environments provide different levels of network
services, from simple to complex. At its simplest level, a network
can provide to 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 a
multiplicity of more advanced services, from AAA, to Quality of
Experience monitoring and management. These services are often
accompanied with network performance management services. Different
levels of services may call for different relationships with the
Henry & Lee Expires 17 May 2025 [Page 11]
Internet-Draft RCM Use Cases November 2024
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). The
same type of network may have a need to limit the effect of IP
address spoofing and invalid reuse through mechanisms like SAVI
[RFC6620].
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
of Service or security profiles, encryption key material. Some
advanced access points and controllers also include upper layer
functions which 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 these parameters. 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 decrypting the device traffic, and fail
selecting the right key to send encrypted traffic 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 802.11i Standard
[IEEE_802.11i] 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.
Layer-2 switches rely on ARP [RFC826] and NDP [RFC4861], and use the
MAC address to forward frames. 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 which
port location can no longer be found. As these infrastructure
devices also implement a cache (to remember the port position of each
known device), too frequent randomized MAC address changes can cause
resources exhaustion and the flush of older MAC addresses, including
for devices that did not change their MAC to a new randomized value.
For the RCM device, these effects translate into session
discontinuity and return traffic losses.
Henry & Lee Expires 17 May 2025 [Page 12]
Internet-Draft RCM Use Cases November 2024
In wireless contexts, 802.1X [IEEE_802.1X] authenticators rely on the
device and user identity validation provided by a AAA server to
change the interface from blocking state to forwarding state. The
MAC address is used to verify that the device is in the authorized
list, and 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. Therefore, MAC address randomization can interrupt the
device traffic, and cause a strain on 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 would return. As the DHCPv4 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 through a 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 ARP and inverse ARP exchanges.
In residential settings (environments type A in section 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 MAC address. MAC address randomization
removes the possibility for such control.
Henry & Lee Expires 17 May 2025 [Page 13]
Internet-Draft RCM Use Cases November 2024
In residential settings (environments type A) and in enterprises
(environments 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 wireless MAC address. MAC address
randomization breaks the services based on such model.
In managed residential settings (environments types B) and in
enterprises (environments 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 is able
to 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 environments, policies are associated to each group of
objects, including IoT. MAC address randomization may prevent an IoT
device from being identified properly, thus leading to network
quarantine and disruption of operations.
6.2. Use Cases
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.
Henry & Lee Expires 17 May 2025 [Page 14]
Internet-Draft RCM Use Cases November 2024
+=======================+======+=========+==========+=============+
| Use Cases |Trust | Network | Network | Network |
| |Degree| Admin | Services | Support |
| | | | | Expectation |
+=======================+======+=========+==========+=============+
| Residential settings |Medium| User | Medium | Low |
| under the control of | | | | |
| the user | | | | |
+-----------------------+------+---------+----------+-------------+
| Managed residential |Medium| IT | Medium | Medium |
| settings | | | | |
+-----------------------+------+---------+----------+-------------+
| Public guest networks | Low | ISP | Simple | Low |
+-----------------------+------+---------+----------+-------------+
| Enterprises with |Medium| IT | Complex | Medium |
| Bring-Your-Own-Device | | | | |
| (BYOD) | | | | |
+-----------------------+------+---------+----------+-------------+
| Managed enterprises | High | IT | Complex | High |
+-----------------------+------+---------+----------+-------------+
Table 1: Use Cases
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. The
home user commonly expects the network operator to protect the home
network from external threats (i.e., attacks from the Internet). The
home user also commonly expects simple policy features (e.g.,
Parental Control). Most home users do not expect to need networking
skills to manage their home network. Such environments may lead to
full-trust conditions. However, if the trust commonly exists between
allowed actors, there is no guarantee that an eavesdropper would not
be observing the Wi-Fi traffic from outside, thus practically
limiting the applicability of the trust in most home scenarios.
On the other end of the spectrum, Public Wi-Fi is often considered to
be completely untrusted, where a user has no expectation of being
able to trust other users or any actor inside or outside of 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 service, and expect only limited to no technical
support.
Henry & Lee Expires 17 May 2025 [Page 15]
Internet-Draft RCM Use Cases November 2024
There are existing technical solutions that address some of the
requirements from several of the use cases listed above. Appendix A
provides a list of some of these existing solutions.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
Privacy considerations are discussed throughout this document.
9. Informative References
[draft-tomas-openroaming]
Tomas, B., "WBA OpenRoaming Wireless Federation", IETF ,
2024.
[I-D.ietf-radext-deprecating-radius]
DeKok, A., "Deprecating Insecure Practices in RADIUS",
Work in Progress, Internet-Draft, draft-ietf-radext-
deprecating-radius-04, 11 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
deprecating-radius-04>.
[IEEE_802] IEEE 802, "IEEE Std 802 - IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture",
IEEE 802 , 2014.
[IEEE_802.11]
"IEEE 802.11-2020 - Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
802.11 , 2020.
[IEEE_802.11bh]
"IEEE 802.11bh-2024 - Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 1:
Operation with Randomized and Changing MAC Addresses",
IEEE 802.11bh , 2024.
[IEEE_802.11i]
"IEEE 802.11i-2004 - Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) specifications: Amendment
6: Medium Access Control (MAC) Security Enhancements",
IEEE 802.11i , 2004.
Henry & Lee Expires 17 May 2025 [Page 16]
Internet-Draft RCM Use Cases November 2024
[IEEE_802.1X]
"IEEE 802.1X-2020 - IEEE Standard for Local and
Metropolitan Area Networks--Port-Based Network Access
Control", IEEE 802.1X , 2020.
[IEEE_802E]
"IEEE 802E-2020 - IEEE Recommended Practice for Privacy
Considerations for IEEE 802 Technologies", IEEE 802E ,
2020.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[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>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<https://www.rfc-editor.org/info/rfc6620>.
Henry & Lee Expires 17 May 2025 [Page 17]
Internet-Draft RCM Use Cases November 2024
[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>.
Appendix A. Existing Solutions
A.1. 802.1X with WPA2 / WPA3
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 allows for the mutual identification of the client
device or of 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 obfuscated from unauthorized
observers. However, the authentication authority is in most cases
under the control of the same entity as the network access provider,
thus making the user or device identity visible to the network owner.
This scheme is therefore well-adapted to enterprise environments,
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
however limited outside of the enterprise environment by the
requirement to install an authentication profile on the end device,
that would be recognized and accepted by a local authentication
authority and its authentication server. Such server is uncommon in
a home environment, and the procedure to install a profile cumbersome
for most untrained users. Remembering that unofficial estimations
count approximatively 500 million Wi-Fi hotspots on the planet, the
likelihood that a user or device profile would match a profile
recognized by a public Wi-Fi authentication authority is also fairly
limited, thus restricting the adoption of this scheme for public Wi-
Fi as well. Similar limitations are found in hospitality
environments.
Henry & Lee Expires 17 May 2025 [Page 18]
Internet-Draft RCM Use Cases November 2024
A.2. OpenRoaming
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
[draft-tomas-openroaming]. The federation structure also 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 also facilitates the establishment of trust between a local
network and an identity provider. Such 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, thus offering 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 therefore seems well-adapted to public Wi-Fi
and hospitality environments, allowing for the obfuscation of the
identity from unauthorized entities, while also permitting 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 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, thus obfuscating the traffic
from observers.
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 in home environments.
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.
Henry & Lee Expires 17 May 2025 [Page 19]
Internet-Draft RCM Use Cases November 2024
A.3. Proprietary RCM schemes
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 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 thus 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
Henry & Lee Expires 17 May 2025 [Page 20]