Subject: [Madinas] MADINAS - Proposed Charter v2

From: Juan Carlos Zuniga <[email-masked]>
Date: Fri, 21 May 2021 16:46:48 +0000

Hello all,

The BoF proponents, BoF chairs and ADs have made some revisions to clarify and clean the proposed charter.

The plan is to discuss it at the BoF meeting over IETF 111.

Please let us know if you have any comments.

MADINAS Draft Charter:

The Medium Access Control (MAC) address is the Link Layer address used in IEEE 802 technologies. It is usually assigned statically for each physical network card by the Network Interface Card manufacturer, out of the space reserved by the IEEE Registration Authority Committee (RAC) for globally unique MAC addresses. The MAC address is used as source or destination target when sending and receiving frames. The default static assignment of the MAC address raises privacy concerns for personal devices, which have recently started to be mitigated by end-device vendors implementing and SDOs specifying the use of Randomized and Changing MAC addresses (RCM).
Device identity is important in scenarios where the network needs to know the device or user identity in order to offer, operate and maintain certain services. 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 will break this assumption. This requires update of the current applications to function across MAC address changes.
The MADINAS Working Group will examine the effect of RCM schemes on network and application services in several scenarios identified as relevant. The group will also evaluate various identifiers (beyond the MAC address) that can be used by the network to provide services, as well as scenarios where personal device identity is not required.
For scenarios where personal device identity stability is desirable, the Working Group will recommend protocols that can be used to protect the request and exchange of identifiers between the client and the service provider. 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. The MADINAS Working Group will examine other IETF work that may be applicable.
The Working Group will work together with other IETF WGs (e.g., DHC, IntArea), and will liaise with other relevant SDOs such as IEEE 802 and the Wireless Broadband Alliance (WBA). The Working Group will coordinate on the different recommendations, as well as potential follow-up activities within or outside the IETF.
MADINAS is expected to be a short timeframe (12-18 months) Working Group to quickly assess these needs. Additional solution space documents may be published after a rechartering process is identified as necessary and in coordination with other relevant SDOs.

The group will produce the following deliverables:
- An Informational Problem Statement document, including use cases analysis and requirements.
- An Informational MAC Address Randomization analysis document.
- A Best Common Practices document.
Best,

MADINAS proponents, BoF chairs & ADs.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 21 May 2021 16:36:20 -0700

[Resending without all of the individuals, first time bounced]

Hi,

A few comments inline.

Bob

> On May 21, 2021, at 9:46 AM, Juan Carlos Zuniga <[email-masked]> wrote:
> 
> Hello all,
> 
> The Medium Access Control (MAC) address is the Link Layer address used in IEEE 802 technologies. It is usually assigned statically for each physical

“usually” is no longer correct, otherwise we wouldn’t be discussing this charter.   Suggest changing to “originally”, “in the past" or something similar.

> network card by the Network Interface Card manufacturer, out of the space reserved by the IEEE Registration Authority Committee (RAC) for globally unique MAC addresses. The MAC address is used as source or destination target when sending and receiving frames. The default static assignment of the MAC address raises privacy concerns for personal devices, which have recently started to be mitigated by end-device vendors implementing and SDOs specifying the use of Randomized and Changing MAC addresses (RCM).

Good to make it clear that these devices are shipping in volume now, this is not a future issue.

> Device identity is important in scenarios where the network needs to know the device or user identity in order to offer, operate and maintain certain services. Currently, many use cases and applica…

Suggest /RCM will break/RCM breaks/

If I had written the paragraph, I would have said that use cases and applications took a shortcut that assumed device identity and MAC address were the same, but this was never true because 802 style devices always had the ability to change their MAC address dynamically.

> For scenarios where personal device identity stability is desirable, the Working Group will recommend protocols that can be used to protect the request and exchange of identifiers between the clien…

I think it is important to add to this, that the Working Group will not recommend in any form that RCM not be used.

> - A Best Common Practices document.

Could you provide more detail on what is intended to be in these documents?   I admit to be a little confused as to what the desired outcome is here beyond analyzing the problem caused by RCM.

> --
> Madinas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/madinas

---

From: Bob Hinden <[email-masked]>
Date: Fri, 21 May 2021 16:33:28 -0700

Hi,

A few comments inline.

Bob

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 24 May 2021 14:01:48 +0000

HI Bob,

Thanks for the suggested edits. 

Regarding your question:

> Could you provide more detail on what is intended to be in these documents?
> I admit to be a little confused as to what the desired outcome is here beyond
> analyzing the problem caused by RCM.
> 

[JCZ] The idea is to 1) analyze the problems on above-L2 protocols and 2) provide recommendations with existing solutions. This is mentioned a couple of paragraphs earlier:

" For scenarios where personal device identity stability is desirable, the Working Group will recommend protocols that can be used to protect the request and exchange of identifiers between the client and the service provider. 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. The MADINAS Working Group will examine other IETF work that may be applicable."

[JCZ] We wanted to keep it clear and avoid redundancy, but if adding some more details about the contents of the docs would add clarity we can do so.

Best, Juan Carlos

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 24 May 2021 10:52:00 -0500

Hi all,

I read the charter proposal and support it.
I have a few editorial comments below:

On Fri, May 21, 2021 at 12:08 PM Juan Carlos Zuniga <
[email-masked]> wrote:

> The Medium Access Control (MAC) address is the Link Layer address used in
> IEEE 802 technologies. It is usually assigned statically for each physical
> network card by the Network Interface Card manufacturer, out of the space
> reserved by the IEEE Registration Authority Committee (RAC) for globally
> unique MAC addresses. The MAC address is used as source or destination
> target when sending and receiving frames. The default static assignment
> of the MAC address raises privacy concerns for personal devices,
>

> which have recently started to be mitigated by end-device vendors
> implementing and SDOs specifying the use of Randomized and Changing MAC
> addresses (RCM).
>

 maybe replace it with:  which have recently started to be mitigated by SDOs
specifying the use of Randomized and Changing MAC addresses (RCM) and
end-device
vendors implementing it.

Device identity is important in scenarios where the network needs to know
> the device or user identity in order to offer, operate and maintain certain
> services. 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 will break this assumption. This
> requires update of the current applications to function across MAC address
> changes.
>
> The MADINAS Working Group will examine the effect of RCM schemes on
> network and application services in several scenarios identified as
> relevant. The group will also evaluate various identifiers (beyond the MAC
> address) that can be used by the network to provide services, as well as
> scenarios where personal device identity is not required.
>
> For scenarios where personal device identity stability is desirable, the
> Working Group will recommend protocols that can be used to protect the request
> and exchange of identifiers between the client and the service provider.
> 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. The MADINAS Working Group will
> examine other IETF work that may be applicable.
>
> The Working Group will work together with other IETF WGs (e.g., DHC,
> IntArea),
>

I thought DHC WG is closed?

> and will liaise with other relevant SDOs such as IEEE 802 and the Wireless
> Broadband Alliance (WBA)
>
What about Wi-Fi Alliance?

Behcet

> . The Working Group will coordinate on the different recommendations, as
> well as potential follow-up activities within or outside the IETF.
>
> MADINAS is expected to be a short timeframe (12-18 months) Working Group
> to quickly assess these needs. Additional solution space documents may be
> published after a rechartering process is identified as necessary and in
> coordination with other relevant SDOs.
>
>
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 24 May 2021 10:52:36 -0700

Juan Carlos,

> On May 24, 2021, at 7:01 AM, Juan Carlos Zuniga <[email-masked]> wrote:
> 
> HI Bob,
> 

I think some more detail would be helpful.

One other topic that comes to mind, if it turns out that if a new secure identification protocol is needed to allow a node to share it’s identity with it’s local routers (to provide a similar function to what is done with static MAC addresses), is it in scope for this w.g. to develop that, our is the goal to just identify the need?

Bob

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 24 May 2021 14:34:39 -0400

> Hi all,
...

> I thought DHC WG is closed?

DHC is still an active WG: https://datatracker.ietf.org/wg/dhc/about/

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

Behcet

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Tue, 25 May 2021 14:40:32 +0000

Hi Bob,

> I think some more detail would be helpful.
[JCZ] Ok, we'll note that for the next revision.

> One other topic that comes to mind, if it turns out that if a new secure
> identification protocol is needed to allow a node to share it’s identity with it’s
> local routers (to provide a similar function to what is done with static MAC
> addresses), is it in scope for this w.g. to develop that, our is the goal to just
> identify the need?
[JCZ] It is not in the current proposed charter to do any protocol development. The idea is to identify needs/problems and existing solutions. 
If ever these were not sufficient or adequate, we could consider rechartering to expand the scope. 

Best, Jc

---

From: Bob Hinden <[email-masked]>
Date: Tue, 25 May 2021 08:29:49 -0700

Juan Carlos,

> On May 25, 2021, at 7:40 AM, Juan Carlos Zuniga <[email-masked]> wrote:
> 
> Hi Bob,
> 

Unless I missed it, good to actually say that in the charter that the working group is not chartered to do protocol development.

> If ever these were not sufficient or adequate, we could consider rechartering to expand the scope.

Understood.

Bob

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Tue, 25 May 2021 18:52:23 +0000

Hi Behcet,

From: Behcet Sarikaya <[email-masked]>
Sent: May 25, 2021 11:50 AM
To: Donald Eastlake <[email-masked]>
Cc: Juan Carlos Zuniga <[email-masked]>; Weil, Jason <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; Jerome Henry (jerhenry) <[email-masked]>; Juan Carlos Zuniga <[email-masked]>; [email-masked]; CARLOS JESUS BERNARDOS CANO <[email-masked]>; [email-masked]; Erik Kline <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>; Lee, Yiu <[email-masked]>
Subject: Re: [Madinas] MADINAS - Proposed Charter v2

On Mon, May 24, 2021 at 1:34 PM Donald Eastlake <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, May 24, 2021 at 12:04 PM Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
...
Device identity is important in scenarios where the network needs to know the device or user identity in order to offer, operate and maintain certain services. 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 will break this assumption. This requires update of the current applications to function across MAC address changes.
The MADINAS Working Group will examine the effect of RCM schemes on network and application services in several scenarios identified as relevant. The group will also evaluate various identifiers (beyond the MAC address) that can be used by the network to provide services, as well as scenarios where personal device identity is not required.
For scenarios where personal device identity stability is desirable, the Working Group will recommend protocols that can be used to protect the request and exchange of identifiers between the client and the service provider. 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. The MADINAS Working Group will examine other IETF work that may be applicable.
The Working Group will work together with other IETF WGs (e.g., DHC, IntArea),

DHC is still an active WG: https://datatracker.ietf.org/wg/dhc/about/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fwg%2Fdhc%2Fabout%2F&data=04%7C01%7Cjuancarlos.zuniga%40sigfox.com%7C18b67bbd543f4df90c8d08d91f94c1e8%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637575546034057322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YVlUlbFIlp31K4KqZzpdWbFhwFOGR7wLwimmlrYyG5Y%3D&reserved=0>

Yeah but they have not met since IETF 106.

Having said that I would have appreciated a reply from JC.

[JCZ] Sorry about that. Don was faster than me, so I didn't think I needed to repeat.
As for the editorial comments, your suggestions have been noted.
Thanks,
Jc

Behcet
Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]<mailto:[email-masked]>

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 25 May 2021 10:49:49 -0500

On Mon, May 24, 2021 at 1:34 PM Donald Eastlake <[email-masked]> wrote:

>>> and exchange of identifiers between the client and the service
>>> provider. 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. The MADINAS
>>> Working Group will examine other IETF work that may be applicable.
>>>

Behcet