Randomized and Changing MAC Address: Context, Network Impacts, and Use Cases
draft-ietf-madinas-use-cases-19

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-madinas-use-cases and RFC 9797, changed IESG state to RFC Published)

Closed request for Last Call review by OPSDIR with state 'Team Will not Review Version': The I-D was already approved by the IESG on 20th Dec

[Ballot comment]
Thanks for this interesting document, I enjoyed reading it.

One nit: “temporal” is not a synonym for “temporary”. It seems like you mean the latter in the four places you use the former.

[Ballot comment]
Thank you to Thomas Fossati for the GENART review.

** Section 2.1
  Additionally, upper protocol
  layers (e.g., application layer) have been designed with the
  assumption that each node on the LAN using these services will have a
  MAC address that would remain consistent over time.

I am confused by this statement.  What application layer protocols make assumptions about MAC addresses?  I’m thinking of application layer protocols to be SMTP and HTTP.

** Section 3.2
        For
      example, several regulatory or legislative bodies can group all
      OSI layers into their functional effect of allowing network
      communication between machines.
I don’t understand what this sentence is say.  Can it be clarified?  What are regulatory bodies doing?  Who are there bodies specifically?

** Section 3.2
      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

Why would it have to be a “personal device”?  The behavior described in this section is true of any device which passes traffic through a routing device.

** Section 4.
  1.  Full trust: there is environment 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.

Is an enterprise or industrial environment another example of this “full trust” environment?  Why is there a reference to a “personal device”?

** Section 4.
  2.  Selective trust: in another environment, a device may selectively
      share a persistent identity with some elements of the layer-2
      broadcast domain but not others.

What are examples if different “elements of the layer-2 broadcast domain”?  Since the context is address randomization, is the device sharing different MAC addresses?

** Section 5
      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.

Is this saying “full trust is forced because there are no other options”?

How is this scenario-B practically different from scenario-D?  The user’s device is forced to comply with whatever policies the network operator establishes as a condition of access.

** Section 6
  To the network, its top priority is to provide the
  best Quality of Experience to its users.

Is this statement universally true for the use cases identified in the previous section.  Couldn’t one argue that certain public guest networks are to collect revenue from a captive audience?

** Section 6.1
  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.)
…
As such, the standard suggests that the
  infrastructure should keep the context for a device for a while after
  the device was last seen.

Could more be said about the notional cost/resource impact of RCM “breaking flows”?  Doesn’t this presuppose some number of devices rapidly cycling MACs?  Let’s assume a coffee shop scenario – how many times is one expecting a device to change its MAC while having an active flow?  How long is the infrastructure keeping all of these MAC to cause resource exhaustion?

** Section 6.1
  Aggressive MAC randomization from many devices in
  a short time interval may cause the layer-2 switch to exhaust its
  resources, holding in memory traffic for a device whose port location
  can no longer be found.

What is “aggressive MAC randomization”?  Is that every day?  Hour?

** Section 6.1
  For the RCM device, these effects translate into session
  discontinuity and return traffic losses.

From the user perspective, how significant of a problem is this?  Isn’t there some tradeoff to be made about occasional traffic losses for gained privacy?

** Section 6.1
  In wireless contexts, 802.1X [IEEE_802.1X] authenticators rely on the
  device and user identity validation provided by an AAA server to
  change the interface from a blocking state to a forwarding state.
  The MAC address is used to verify that the device is in the
  authorized list, and to retrieve the associated key used to decrypt
  the device traffic.  A change in MAC address causes the port to be
  closed to the device data traffic until the AAA server confirms the
  validity of the new MAC address.  Consequently, MAC address
  randomization can disrupt the device traffic and strain the AAA
  server.

Is it common to deploy 802.1X in scenarios where heavy RCM is expected?  Revisiting the use cases from Section 5, isn’t 802.1X more commonly deployed in enterprise scenarios such as scenario-D (BYOD) and scenario-E (managed enterprises) where policy can control how much RCM is happening? 

** Section 6.2.  Why is the level of “network support expectation” medium for scenario-B.  This is a managed network.  Why isn’t it “high”?  What’s the difference?

** Section 6.2.  What is the difference between simple/medium/complex?  Why can’t scenario-A be “simple”?

** Section 6.2
  Home users typically expect the network operator to protect the home
  network from external threats (i.e., attacks from the Internet).

What is the basis of this assertion?  If it were the case, the personal “anti-virus”/end-point market would seemingly be much smaller than it is.

** Section 6.2
  On the other end of the spectrum, Public Wi-Fi is often viewed as
  completely untrusted, with users not expecting to trust other users
  or actors inside or outside the layer-2 domain.

  Privacy is one of
  the major concerns for users.

Could this be substantiated? Does the average user know to exercise caution on public Wi-Fi?

[Ballot comment]
# Internet AD comments for draft-ietf-madinas-use-cases-16
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S6.1

* "with SLAAC defined in [RFC6620]"

  SLAAC is defined in 4862.  6620 is a SAVI doc and doesn't define SLAAC
  per se.

## Nits

### Abstract

* "and its user in Wi-Fi [IEEE_802.11] network" ->
  "and its user in Wi-Fi [IEEE_802.11] networks"

### S3.2

* "They can use the MAC address to represent an identified device."

  Consider "They may use" or "They often use", to avoid the appearance
  of approving of  the use of MAC addresses as identifiers that might come
  with some interpretations of the word "can".

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-madinas-use-cases-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

Request for Last Call review by IOTDIR Completed: Ready with Nits. Reviewer: Behcet Sarikaya. Sent review to list. Submission of review completed at an earlier date.

Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Thomas Fossati. Sent review to list. Submission of review completed at an earlier date.

Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Tommy Pauly. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2024-11-28):

From: The IESG
To: IETF-Announce
CC: cjbc@it.uc3m.es, draft-ietf-madinas-use-cases@ietf.org, evyncke@cisco.com, madinas-chairs@ietf.org, madinas@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Randomized and Changing MAC Address: Context, Network Impacts and Use Cases) to Informational RFC


The IESG has received a request from the MAC Address Device Identification
for Network and Application Services WG (madinas) to consider the following
document: - 'Randomized and Changing MAC Address: Context, Network Impacts
and Use
  Cases'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-11-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-madinas-use-cases/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus represent broad agreement, relative to the size of active participants of the WG. It also counts with the support of the Wireless Broadband Alliance (WBA), which has different members as participants to the MADINAS WG and some liaisons.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No, there was not.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A. It is not a protocol document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document does references for example to the Wireless Broadband Alliance (WBA) and the OpenRoaming Standard. Members of the WBA have reviewed the document. Explicit support has been done publicly on the MADINAS mailing list: https://mailarchive.ietf.org/arch/msg/madinas/7T920MVmljHwX8B8JShXFhYxElA/

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I think the document is ready. I've reviewed the document several times during its lifecycle in the WG and I think it reflects the WG consensus and it's technically correct and well written.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues have been identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. The document is purely informative, listing scenarios/use cases and documenting some existing solutions. Datatracker correctly reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. Authors have been reminded and they have confirmed that they are not aware of any IPR relating to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, they have.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are 3 nits that need to be addressed:

== Unused Reference: 'RFC5176' is defined on line 689, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC8174' is defined on line 707, but no explicit
    reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 4941
    (Obsoleted by RFC 8981)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No. All references are OK. All are informational and there is no need for normative references.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A. The document has no normative references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A. The document has no normative references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

N/A. The document has no normative references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There is no need for any IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A. There are no IANA considerations.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus represent broad agreement, relative to the size of active participants of the WG. It also counts with the support of the Wireless Broadband Alliance (WBA), which has different members as participants to the MADINAS WG and some liaisons.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No, there was not.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A. It is not a protocol document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document does references for example to the Wireless Broadband Alliance (WBA) and the OpenRoaming Standard. Members of the WBA have reviewed the document. Explicit support has been done publicly on the MADINAS mailing list: https://mailarchive.ietf.org/arch/msg/madinas/7T920MVmljHwX8B8JShXFhYxElA/

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I think the document is ready. I've reviewed the document several times during its lifecycle in the WG and I think it reflects the WG consensus and it's technically correct and well written.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues have been identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational. The document is purely informative, listing scenarios/use cases and documenting some existing solutions. Datatracker correctly reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. Authors have been reminded and they have confirmed that they are not aware of any IPR relating to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, they have.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are 3 nits that need to be addressed:

== Unused Reference: 'RFC5176' is defined on line 689, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC8174' is defined on line 707, but no explicit
    reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 4941
    (Obsoleted by RFC 8981)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No. All references are OK. All are informational and there is no need for normative references.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A. The document has no normative references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A. The document has no normative references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

N/A. The document has no normative references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There is no need for any IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A. There are no IANA considerations.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/