**Session Date/Time:** 07 Oct 2022 14:00

# [MADINAS](../wg/madinas.html)

## Summary

The MADINAS Working Group met to discuss updates on two foundational drafts: "Randomized and Changing MAC Address Use Cases and Problem Statement" and "MAC Address Randomization Current State of Affairs." Discussions included document scope, terminology, and content organization, particularly regarding existing solutions and a proposed MAC address taxonomy. An update on the Open Roaming experiment planned for IETF London was provided, and a research presentation on "Rotating MAC address for Privacy Protection (ROMA)" was given, prompting discussion on its implications for network resources and session management. The chairs encouraged continued engagement on the mailing list in preparation for the London meeting.

## Key Discussion Points

### Administrative
*   Matthew volunteered to assist with note-taking.
*   The Notewell was presented and acknowledged.

### Randomized and Changing MAC Address Use Cases and Problem Statement (Jerome and Yu)
*   **Document Updates**: The authors updated the document following comments received since July. Key changes included:
    *   Corrections of typos (with an acknowledgement that more may still exist).
    *   Nomenclature change: "Places" were re-labeled as "Environments" (e.g., Home, Managed Residential, Campus, Enterprise, Factory Floor) to better reflect their nature as use cases.
    *   Addition of a new section on "Network Services" (Section 6), describing varying levels of network service expectations (basic, medium, advanced, differentiated services) and their corresponding increase in interaction complexity between devices and the network.
*   **Document Title and Scope**:
    *   Jerome noted ongoing comments about the document title, previously called "framework" and now "use cases." Participants pointed out that it covers more than just use cases, including existing solutions (.1X, Open Roaming) for maintaining privacy with RCM.
    *   Carlos commented that the document’s scope of use cases and requirements aligns with the WG charter. He suggested explicitly including "requirements" in the title and potentially moving the existing solutions section to an Annex to de-emphasize it as a primary goal.
    *   Eric referenced the WG charter deliverables, specifically the "informational use cases and identity requirements" and the "best practices" (BCP) documents. He suggested that the content on existing solutions (e.g., Open Roaming, .1X) from this draft could be foundational for the upcoming BCP document.
*   **Requirement Formulation Section**: Jerome highlighted comments questioning the continued relevance of the "requirement formulation" section (listing eight requirements), as the WG is now formed and more focused.
    *   Carlos distinguished between requirements *for solutions* and requirements *for the community/WG to do*. He suggested clarifying this distinction in the document.
    *   The Chairs indicated that requirements directed at the working group, if not aligned with the charter, should be removed from the draft, focusing the document on technical specifications.

### MAC Address Randomization Current State of Affairs (Carlos)
*   **Document Goal**: To document current practices and approaches to MAC address randomization by SDOs and operating systems.
*   **Key Update**: The section on OS current practices (Section 7) was moved to a GitHub repository, with the document providing a pointer. This approach aims to allow for continuous updates of OS-specific practices without requiring frequent document revisions, addressing concerns about quick obsolescence.
*   **Comments from Michael (July)**:
    *   **BCP 14 Terminology**: A proposal to remove the BCP 14 terminology section was accepted, as the keywords were not consistently used elsewhere in the informational document.
    *   **IEEE 802.11 Header Diagram**: A suggestion to include a figure of the 802.11 header, specifically regarding MAC address encryption, was discussed. Jerome expressed concern about maintaining accuracy due to evolving standards (e.g., 802.11bi encrypting MAC addresses) and suggested pointing to IEEE documents instead of duplicating content. A sense of those present indicated a preference against adding such detailed, evolving content directly into the document.
    *   **Taxonomy of MAC Address Types**: Michael proposed adding a section on taxonomy to categorize MAC addresses (e.g., per vendor, per device generated, per boot, per network, per period).
        *   Jerome acknowledged the value but questioned how the taxonomy would be used, expressing concern about potentially creating a hierarchy of privacy levels or adding complexity in tracking OS/environment specifics.
        *   Matthew suggested including the *duration* of MAC addresses as a key aspect of the taxonomy, given its impact on network resources.
        *   The Chairs noted the importance of considering diverse device types (e.g., IoT) when defining such a taxonomy.

### Open Roaming Experiment Update (Jesse)
*   **Planned Experiment**: The WG is discussing with the Wireless Broadband Alliance (WBA) to run an Open Roaming experiment at the upcoming IETF meeting in London.
*   **Open Roaming Overview**: It simplifies Wi-Fi authentication, allowing users with existing identity provider accounts (e.g., cloud provider, enterprise, retail) to automatically connect to roaming networks within the Open Roaming federation. It relies on 802.1X and radius, aiming to preserve privacy and provide a seamless user experience.
*   **London Logistics**: The plan is to enable Open Roaming on the IETF wireless network at the London venue. Discussions are ongoing with WBA to connect to external roaming networks in London (e.g., near the Hilton Metropole, social event locations) to demonstrate broader roaming capabilities.
*   **Technical Discussion**: Matthew inquired about the privacy preservation mechanisms and identity handling. It was clarified that Open Roaming relies on 802.1X and Radius, with the access network finding the identity provider. A more detailed technical discussion, potentially as a side meeting or demo slot, is being considered for London.

### Rotating MAC address for Privacy Protection (ROMA) (Matthew)
*   **Problem Statement**: While MAC randomization is effective when a device is not connected, continuous rotation for connected devices is challenging due to reconnection downtime and potential resource collisions.
*   **ROMA Proposal**: The research proposes "Rotating Mac address for Privacy Protection (ROMA)" which uses multiple virtual wireless interfaces in parallel on a single physical interface. Each virtual interface periodically rotates its MAC address, ensuring at least one interface remains connected at all times, thus maintaining continuous network connectivity.
*   **Technical Challenges**: The implementation relies on specific hardware and driver support for virtual interfaces, which is not universally available.
*   **Performance Impact**: Experiments showed that while there might be minor glitches during interface switching, overall throughput and connectivity are maintained. The overhead of spreading traffic across virtual interfaces was found to be limited.
*   **Network Resource Implications**: This approach leads to higher consumption of logical network resources (e.g., Access Point slots, DHCP IP addresses) as a single device effectively uses multiple MAC addresses. Matthew emphasized the need to ensure IP addresses are released promptly.
*   **Discussion**:
    *   Eric raised concerns about IPv6 (neighbor cache) and TCP session disruption, suggesting Multi-Path TCP (MP-TCP) or QUIC as potential solutions for session continuity. Matthew confirmed these are areas for future exploration.
    *   Jesse inquired about future development and funding for the ROMA project.
    *   Yu suggested exploring network-assisted protocols, where the client could request multiple IP addresses with associated MAC addresses from the DHCP server and receive guidance on rotation timing, allowing for a more fluid interaction between client and network. Matthew found this a valuable idea for future work.

## Decisions and Action Items

*   **"Randomized and Changing MAC Address Use Cases and Problem Statement" (draft-ietf-madinas-use-cases)**:
    *   The document will remove requirements specifically targeting the working group's actions, focusing solely on technical requirements.
    *   A proposal by Eric to transition content related to existing solutions (e.g., .1X, Open Roaming) from this document to a new, separate draft intended to evolve into a BCP document was accepted as a potential way forward.
*   **"MAC Address Randomization Current State of Affairs" (draft-ietf-madinas-mac-randomization)**:
    *   The section on BCP 14 terminology will be removed.
    *   The question of adding a taxonomy for MAC address types will be brought to the mailing list for broader discussion and feedback.
*   **Open Roaming Experiment**: The Chairs will continue coordinating with WBA and external entities to enable an Open Roaming experiment at IETF London.

## Next Steps

*   **Mailing List Discussion**: Participants are encouraged to continue technical discussions on the mailing list, particularly regarding the proposed MAC address taxonomy and the future direction of the "use cases" document content.
*   **IETF London Meeting**: Prepare for a productive meeting in London, including:
    *   Further updates on the Open Roaming experiment, potentially including a detailed technical discussion or demo slot.
    *   Continued progress on the current drafts, incorporating feedback from the meeting and mailing list.
*   **Open Roaming Information**: The Chairs will share links and summarize the intentions/status of the Open Roaming experiment on the mailing list for participants to review before London.