Subject: [Madinas] Fwd: [IAB] IETF-111 BOF report: MADINAS

From: Jari Arkko <[email-masked]>
Date: Fri, 30 Jul 2021 14:31:39 +0300

FYI. The IAB members who attend BOFs usually send some reports about the BOF to the AD/IESG and the IAB, as personal perspective of how they saw the BOF. Sending you a copy of my report as well for transparency, but of course this should is just one individual opinion. Thanks for a very well run BOF. I think it is a good idea to create the short-term analysis working group with the deliverables discussed in the meeting. I do have a wish that as your do your analysis, some focus be put on thinking about the different possible approaches you could take (see below).

Jari

> Begin forwarded message:
> 
> From: Jari Arkko <[email-masked]>
> Subject: [IAB] IETF-111 BOF report: MADINAS
> 
> Brief report about this BOF. They met yesterday and had a productive discussion. I missed some parts of the meeting (network issues and fighting to stay awake :-) ) 
> 
> All materials are available in this slide deck: https://datatracker.ietf.org/meeting/111/materials/slides-111-madinas-madinas-bof-consolidated-slides-00. The proposed charter is on page 30. There are no detailed minutes, just some beginnings at https://codimd.ietf.org/notes-ietf-111-madinas There’s some good discussion in https://jabber.ietf.org/jabber/logs/madinas/2021-07-28.html though and of course the recordings are at https://www.youtube.com/watch?v=STz56QG2Dv4&list=PLC86T-6ZTP5ik187oPfRrOUaMw1AuLLi6&index=69
> 
> The bottom line is that the group wants to create a relatively short term WG that would produce use cases, analysis, and common practices, but would not work on solutions. I think the analysis is needed. The participants in the BOF seemed to favour setting up an effort (23 saying the problem statement is clear and useful to solve, and 7 saying not).
> 
> However, I do have some concern that the direction of the work is not as accurately defined as it perhaps could be. The introduction of RCM (Random and Changing MAC addresses) is a deliberate change in the L2 architecture, and brings benefits. It does cause a number of issues in specific situations as well, so we do need to look at that. But it seems to me that there are different directions one could take:
> 
> 1) ensure that RCM works where used, and that, e.g., stacks can handle reassignment of MAC addresses such that IP addressing, DHCP processes, etc do not lead to breakage or privacy issues. For instance, ensure that L3 addresses are changed at the same time
> 2) ensure that RCM is used where it is applicable, and NOT used when it is not
> 3) change protocols and system to have a cleaner separation such that RCM usage is orthogonal to the use of other things and other identifiers than MAC identifiers. E.g., you can change your MAC address but still have to identify yourself to an authentication server — but not have to keep a stable identifier where every switch and local network knows who you are.
> 4) attempt to make all existing network functions work with RCM, with the introduction of other identifiers and mechanisms
> 
> I feel like most of the discussion, requirements, use cases, etc seem to be on #4. But maybe I’m mistaken (?). My preference would be that we work on a combination of #1 and #2, or possibly also #3. Only working on #4  has the danger that we compromise the benefits of RCM while not getting all desired functionality for some uses cases fully done either. Kind of worst of both possible choices.
> 
> Also, the key to better privacy with identifiers is not just the question of whether we have identifiers or not, it is also *who* we communicate them to. A secure RCM system can work well, while still allowing some parties to know some things such as the example above about authentication servers. An authentication at a server owned by your operator for instance does not imply that that any device within a local WLAN network knows about your identity. This is very helpful, because it reduces the ability of random other network users or the equipment in the coffee shop to track you.
> 
> Some more detailed charter comments:
> 
>> Currently, many use cases and applications make an implicit assumption about the unique association between the device identity and its MAC address. This assumption is being used in both control plane and data plane functions and protocols. RCM breaks this assumption. This requires update of the current applications to function across MAC address changes.
> 
> Maybe the wording could be improved here. I think we are talking about network systems or network applications. RCM does not require changing what end users typically perceive as applications, or the end-to-end interactions.
> 
>> For scenarios where privacy is paramount, the group will recommend best practices to ensure that the privacy achieved with RCM is not compromised by the communication of other identifiers.
> 
> This is a bit cumbersome. I feel it would be simpler to say that there are cases where changing addresses can and should be used, and not introduce any new identifiers or other things for those cases.
> 
> Jari
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Jul 2021 20:11:52 -0400

Thank you for the write up to the IAB.

Jari Arkko <[email-masked]> wrote:
    > 1) ensure that RCM works where used, and that, e.g., stacks can handle
    >reassignment of MAC addresses such that IP addressing, DHCP processes,
    >etc do not lead to breakage or privacy issues. For instance, ensure that
    >L3 addresses are changed at the same time

    > 3) change protocols and system to have a cleaner separation such that
    > RCM usage is orthogonal to the use of other things and other
    > identifiers than MAC identifiers. E.g., you can change your MAC address
    > but still have to identify yourself to an authentication server — but
    > not have to keep a stable identifier where every switch and local
    > network knows who you are.

    > 4) attempt to make all existing network functions work with RCM, with
    > the introduction of other identifiers and mechanisms

    > I feel like most of the discussion, requirements, use cases, etc seem
    > to be on #4. But maybe I’m mistaken (?). My preference would be that we
    > work on a combination of #1 and #2, or possibly also #3. Only working
    > on #4  has the danger that we compromise the benefits of RCM while not
    > getting all desired functionality for some uses cases fully done
    > either. Kind of worst of both possible choices.

I concur with you.
Particularly "NOT used when it is not"

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide