Internet DRAFT - draft-ietf-madinas-use-cases
draft-ietf-madinas-use-cases
Internet Engineering Task Force J. Henry
Internet-Draft Cisco Systems
Intended status: Informational Y. Lee
Expires: 1 September 2024 Comcast
29 February 2024
Randomized and Changing MAC Address Use Cases
draft-ietf-madinas-use-cases-09
Abstract
To limit the privacy issues created by the association between a
device, its traffic, its location and its user, client and client OS
vendors have started implementing MAC address rotation. When such a
rotation 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
rotation purposes. This document lists various network environments
and a set of network services that may be affected by such rotation.
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 1 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Henry & Lee Expires 1 September 2024 [Page 1]
Internet-Draft RCM Use Cases February 2024
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 . . . . . . . . . . 3
3. The Actors: Network Functional Entities and Human Entities . 6
3.1. Network Functional Entities . . . . . . . . . . . . . . . 6
3.2. Human-related Entities . . . . . . . . . . . . . . . . . 7
4. Trust Degrees . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Environments . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Network Services . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Device Identification and Associated Problems . . . . . . 11
6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Considerations . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. IANA Considerations . . . . . . . . . . . . . . . . . . . 15
7.2. Security Considerations . . . . . . . . . . . . . . . . . 15
8. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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. 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 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, the persistent association between a
given traffic flow and a single device is made more difficult,
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 flows with
a particular individual using one particular device.
Henry & Lee Expires 1 September 2024 [Page 2]
Internet-Draft RCM Use Cases February 2024
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 RCM rotations 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) providing an identifier, which
can be the MAC address or another value. If the client implements
MAC rotation 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.
There is a need 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.
2. MAC Address as Identity: User vs. Device
Any device member of a network implementing IEEE 802 technologies
includes several operating layers. Among them, the Media Access
Control (MAC) layer defines rules to control how the 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
Henry & Lee Expires 1 September 2024 [Page 3]
Internet-Draft RCM Use Cases February 2024
Locally Administered (U/L) Address Bit, indicates whether the address
has been assigned by a local or universal administrator. Universally
administered addresses have this bit set to 0. If this bit is set to
1, the entire address (i.e., 48 bits) has been 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 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. To accommodate for this requirement, the second
bit of the MAC address first octet was designed to express whether
the address was intended to be globally unique, or locally unique.
The address allocation method was not defined in the Standard in this
later case, but the same clause defined that an address should be
unique so as to avoid collision with any other device attached to the
same network.
It is also important to note that the purpose of the Universal
version of the address was to avoid collisions and confusion, as any
machine could connect to any network, and each machine needs to
determine if it is the intended destination of a message or its
response. Clause 8.4 of [IEEE_802] reminds network designers and
operators that all potential members of a network need to have a
unique identifier in that network (if they are going to coexist in
the network without confusion on which machine is the source or
destination or any message). The advantage of a universal 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]. One type is a 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. Another type is a 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
Henry & Lee Expires 1 September 2024 [Page 4]
Internet-Draft RCM Use Cases February 2024
traffic can also be associated to the identification of the primary
user or their traffic. Quite naturally, the identification of the
device is trivial if the device expresses a universally 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 universal 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).
This possible identification or association presents a serious
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).
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, Association and
Accounting (AAA) services 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., DHCP), 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.
Henry & Lee Expires 1 September 2024 [Page 5]
Internet-Draft RCM Use Cases February 2024
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 entitities (entities,
like applications or devices, that provide a service related to
network operations).
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 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 OSI model Layer 2 frames are redirected to the new device
access point.
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 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, authentication,
authorization and accounting (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
Henry & Lee Expires 1 September 2024 [Page 6]
Internet-Draft RCM Use Cases February 2024
rely on the connected MAC addresses. 802.1X-enabled devices may also
selectively block the data portion of a port 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.
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, DHCP services with IPv4 commonly
provide a single IP address per MAC address (they do not assign more
than one IP address per MAC address, and assign a new IP address to
each new requesting MAC address). ARP and reverse-ARP services
commonly expect that, once an IP-to-MAC mapping has been established,
this mapping is valid and unlikely to change for the cache lifetime.
DHCP services with IPv6 commonly do not assign the same IP address to
two different requesting MAC addresses. Hybrid services, such as
EoIP, also assume stability of the device-to-MAC-and-IP mapping for
the duration of a given session.
3.2. Human-related Entities
Networks do no operate without humans actively involved at one or
more points of the network lifecycle. Humans may actively
participate to the network structure and operations, or be observers.
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.
Henry & Lee Expires 1 September 2024 [Page 7]
Internet-Draft RCM Use Cases February 2024
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.
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 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.
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. 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.
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.
Henry & Lee Expires 1 September 2024 [Page 8]
Internet-Draft RCM Use Cases February 2024
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:
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 L2 broadcast domain (e.g., DHCP, 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 L2
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 adddress of internal devices if it is not
copied to another field before routing happens. The wire segment
Henry & Lee Expires 1 September 2024 [Page 9]
Internet-Draft RCM Use Cases February 2024
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 L2 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
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, trains 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 L2
broadcast domain (Zero trust model by default).
D. Enterprises (with 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.
Henry & Lee Expires 1 September 2024 [Page 10]
Internet-Draft RCM Use Cases February 2024
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 address allocation
service (DHCP) 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 authentication (AAA), to quality of experience (QoE)
monitoring and management. These services are often accompanied with
network performance management services. Different levels of
services may call for different relationships with the device, or its
user, identity. For example, there is usually no need to identify
the device or its user for a public network to provide a DHCP-sourced
IP address to a connecting station, or accept a station using its
self-generated IP address (e.g., using SLAAC [RFC4862] ). However,
there may be a need, in an enterprise private network, to identify
devices 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
Many network functional devices offering a service to a personal
device use the device MAC address to maintain service continuity.
Wireless access points and controllers use the MAC address to
validate the device connection context, including protocol
capabilities, confirmation that authentication was completed, QoS 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 recognizes
that a device may leave the network and come back after a short time
Henry & Lee Expires 1 September 2024 [Page 11]
Internet-Draft RCM Use Cases February 2024
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 rotation 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.
Other devices in the Layer 2 broadcast domain also use the MAC
address to know whether and where to forward frames. MAC rotation
can cause these devices to exhaust their 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 MAC rotation can
cause resources exhaustion and the flush of older MAC addresses,
including for devices that did not rotate their MAC. For the RCM
device, these effects translate into session discontinuity and return
traffic losses.
In wireless contexts, 802.1X authenticators rely on the device and
user identity validation provided by a AAA server to open their port
to data transmission. 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 rotation can
interrupt the device traffic, and cause a strain on the AAA server.
DHCP 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 the rotation occurs, DHCP 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 the rotation occurs, the DHCP server typically
holds the released IP address for a certain duration, in case the
leaving MAC would return. As the DHCP server cannot know if the
release is due to a temporal disconnection or a MAC rotation, the
risk of scope address exhaustion exists even in cases where the IP
address is released.
Network devices using self-assigned IPv6 addresses (e.g., with SLAAC
defined in [RFC6620] ) use mechanisms like DAD to and ND to establish
the association between a target IP address and a MAC address, and
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, if the change
occurs within the caching period.
Henry & Lee Expires 1 September 2024 [Page 12]
Internet-Draft RCM Use Cases February 2024
Routers keep track of which MAC address is on which interface. MAC
rotation 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. Rotation of the MAC address
removes the possibility for such control.
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
rotation 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 rotation,
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 rotation 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 1 September 2024 [Page 13]
Internet-Draft RCM Use Cases February 2024
+=============+==============+=========+==========+=================+
| Use Cases | Trust | Network | Network | Network Support |
| | Degree | Admin | Services | Expectation |
+=============+==============+=========+==========+=================+
| Home | Medium | User | Medium | Low |
+-------------+--------------+---------+----------+-----------------+
| Managed | Medium | IT | Medium | Medium |
| Residential | | | | |
+-------------+--------------+---------+----------+-----------------+
| Campus | Medium | IT | Complex | Medium |
| (BYOD) | | | | |
+-------------+--------------+---------+----------+-----------------+
| Enterprise | High | IT | Complex | High |
| (MDM) | | | | |
+-------------+--------------+---------+----------+-----------------+
| Hospitality | Low | IT | Simple | Medium |
+-------------+--------------+---------+----------+-----------------+
| Public WiFi | Low | ISP | Simple | Low |
+-------------+--------------+---------+----------+-----------------+
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 (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.
7. Considerations
Henry & Lee Expires 1 September 2024 [Page 14]
Internet-Draft RCM Use Cases February 2024
7.1. IANA Considerations
This memo includes no request to IANA.
7.2. Security Considerations
Privacy considerations are discussed throughout this document.
8. Informative References
[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 WG - 802 LAN/MAN Standards Committee, "IEEE
802.11-2020 - Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE 802.11 , 2020.
[IEEE_802E]
IEEE 802.1 WG - 802 LAN/MAN architecture, "IEEE 802E-2020
- IEEE Recommended Practice for Privacy Considerations for
IEEE 802 Technologies", IEEE 802E , 2020.
[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>.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
DOI 10.17487/RFC5176, January 2008,
<https://www.rfc-editor.org/info/rfc5176>.
[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 1 September 2024 [Page 15]
Internet-Draft RCM Use Cases February 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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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 1 September 2024 [Page 16]