Subject: [Int-area] Evaluate impact of MAC address randomization to IP applications

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 22 Sep 2020 19:49:29 +0000

Hi team,

We proposed a BoF. The agenda is in https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and the proposal is in https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md. You can also find the draft here https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.

At this stage, we are looking for inputs for more use cases and interests of working together in this domain. Please post your comments in the mailing list.

Thanks

---

From: Andy Smith <[email-masked]>
Date: Tue, 22 Sep 2020 16:22:30 -0400

Yiu-

I’d like to help here.   Is the problem that residential devices can’t be reliably tracked for purposes of policy enforcement?     Or is it an IP address depletion issue?  

I noticed iOS 14 does allow for disabling of random MAC addresses.  

Andy

Sent with emacs for iOS

> On Sep 22, 2020, at 15:50, Lee, Yiu <[email-masked]> wrote:
> 
> 
> Hi team,
>  
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Sep 2020 16:34:33 -0400

This thread was started today on the INTAREA WG ML.

While I don't object to a BOF, I don't know where it goes.
What I see is that much of this problem needs to be resolved through 
increased use of 802.1X: making WPA-Enterprise easier to use and setup, 
this changing core identity from MAC Address to IDevID.

My understanding is that Apple intends to randomize MAC every 12 hours, 
even on the same "LAN" (ESSID), and that they will just repeat the WPA 
authentication afterwards to get back on the network.   If the 
per-device unique policy (including CAPPORT authorization) can be tied 
to the device better, than the MAC address based "physical" exception 
can be updated.

But, WPA-PSK doesn't work, because it does not, in general, distinguish 
between different devices.

It can be made to work if every device is given a unique PSK, and there 
are some successful experiments doing exactly that.  Mostly it just 
works, but the challenge is communicating the unique PSK through an 
unreliable human.
BRSKI can certainly do this, and it can leverage that unencrypted ESSID 
present at most hospitality locations to get onto the encrypted 
WPA-Enterprise.  Or BRSKI-TEEP, or some other BRSKI-EAP method.  The 
unencrypted SSID is not going away at those locations.

Thus QR-code based methods are best, yet those do not work for many IoT 
devices.   EMU's EAP-NOOB can help in certain cases, but we, as a 
community need be clear on what direction we want to go.  One answer is 
that IoT devices have little reason to randomize their MAC if they are 
not generally ported.

On 2020-09-22 3:49 p.m., Lee, Yiu wrote:
> Hi team,
> 
> We proposed a BoF. The agenda is in 
> https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and 
> the proposal is in 
> https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md. 
> You can also find the draft here 
> https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.
> 
> At this stage, we are looking for inputs for more use cases and 
> interests of working together in this domain. Please post your comments 
> in the mailing list.
> 
> Thanks
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Sep 2020 16:35:23 -0400

On 2020-09-22 4:22 p.m., Andy Smith wrote:
> Yiu-
> 
> I’d like to help here.   Is the problem that residential devices can’t 
> be reliably tracked for purposes of policy enforcement?     Or is it an 
> IP address depletion issue?
> 

On a per-ESSID basis?
While this might work for your home, it's going to be annoying at 
hotels, and it may be exactly at that location that you want to avoid 
tracking.

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 22 Sep 2020 20:57:40 +0000

Hi Andy,

Happy to have you to help.

There exists applications that make assumption of the static mac-address and rely on the static mac-to-ip mappiing. For example: common implementation of sticky dhcp relies on static mac-address. Also, some community wifi implementations rely on static mac-address once the device is authenticated. At this stage, we are gathering use cases and interests of working together for this domain. The goal is to document the potential impacts and propose any best practice for transitioning IP applications to dynamic mac-address.

Best,
Yiu

From: Andy Smith <[email-masked]>
Date: Tuesday, September 22, 2020 at 4:22 PM
To: "Lee, Yiu" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [Int-area] Evaluate impact of MAC address randomization to IP applications

Yiu-

Andy

Sent with emacs for iOS

We proposed a BoF. The agenda is in https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md<https://urldefense.com/v3/__https:/github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!XJKIJylv4qDPaoljnJC9w_oDvCGJOQnWkTObSp2qbikyEV2f4xMuW7bu5IdA4oA$> and the proposal is in https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md<https://urldefense.com/v3/__https:/github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md__;!!CQl3mcHX2A!XJKIJylv4qDPaoljnJC9w_oDvCGJOQnWkTObSp2qbikyEV2f4xMuW7buwRTQxpg$>. You can also find the draft here https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!XJKIJylv4qDPaoljnJC9w_oDvCGJOQnWkTObSp2qbikyEV2f4xMuW7bupd0LL0o$>.

Thanks

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/int-area__;!!CQl3mcHX2A!XJKIJylv4qDPaoljnJC9w_oDvCGJOQnWkTObSp2qbikyEV2f4xMuW7bue8Q39nY$>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 22 Sep 2020 21:23:53 +0000

Hi Michael,

Thanks for the notes. At this stage, our #1 objective is to document the use cases that may broke and propose best practice to transition to dynamic mac-address. We don't have the full picture of the impact. We think IETF is a good platform to gather more information.

Thanks,
Yiu

On 9/22/20, 4:34 PM, "Int-area on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    On 2020-09-22 3:49 p.m., Lee, Yiu wrote:
    > https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgWZ_LjWDQ$  and
    > the proposal is in
    > https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgWZbxZn_w$ .
    > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgWBEXWl54$ .
    >

    _______________________________________________
    Int-area mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgW20rPBDw$

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 23 Sep 2020 07:26:50 +0200

Moin!

On 22 Sep 2020, at 22:34, Michael Richardson wrote:

> increased use of 802.1X: making WPA-Enterprise easier to use and 
> setup, this changing core identity from MAC Address to IDevID.
>
> My understanding is that Apple intends to randomize MAC every 12 
> hours, even on the same "LAN" (ESSID), and that they will just repeat 
> the WPA authentication afterwards to get back on the network.
I of course don’t know Apples intentions, but what you are describing 
is the behaviour of early iOS 14 beta versions. However this behaviour 
has changed in later beta versions and the released iOS 14.0 version to 
have a random Mac per ESSID and not change that over the lifetime of the 
device (at least no so far on my devices at home), which I think is more 
in line what the rest of the industry does.

So long
-Ralf
——-
Ralf Weber

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 23 Sep 2020 11:37:42 +0100

So I am curious, and probably out of touch.

MAC addresses are supposed to be unique hardware device addresses  that ultimately come from a registry administered by IEEE and are supposed to be allocated exactly once to one hardware entity.

Is MAC address randomisation something that IEEE approve of, in which case how does the registry work, or are we at risk of working on a problem that results in an interSDO dispute?

- Stewart

> On 22 Sep 2020, at 21:22, Andy Smith <[email-masked]> wrote:
> 
> Yiu-
> 
>> We proposed a BoF. The agenda is in https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md <https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md> and the proposal is in https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md <https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md>. You can also find the draft here https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01 <https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01>.
>>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Sep 2020 08:32:30 -0400

Ralf Weber <[email-masked]> wrote:
    >> authentication afterwards to get back on the network.

    > I of course don’t know Apples intentions, but what you are describing is the
    > behaviour of early iOS 14 beta versions. However this behaviour has changed
    > in later beta versions and the released iOS 14.0 version to have a random Mac
    > per ESSID and not change that over the lifetime of the device (at least no so
    > far on my devices at home), which I think is more in line what the rest of
    > the industry does.

That's interesting news.
Why did they try something different in the beta?  Maybe they thought that
the industry was ready for this, but were wrong?
I heard about this change from Tiru Reddy.

It would be great if this BOF elicited public statements and/or public policies about
Google and Apple's intentions in this space.  If it's their goal to go in the
direction I outlined, then it would be good to know.

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 23 Sep 2020 14:02:03 +0000

In another century, DECnet phase 4 was also changing the MAC address (and if not mistaken IBM SNA also) but flipping the universal/local bit of the MAC address

-éric

From: Int-area <[email-masked]> on behalf of Stewart Bryant <[email-masked]>
Date: Wednesday, 23 September 2020 at 12:38
To: Andy Smith <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Int-area] Evaluate impact of MAC address randomization to IP applications

- Stewart

On 22 Sep 2020, at 21:22, Andy Smith <[email-masked]<mailto:[email-masked]>> wrote:

Yiu-

Andy

Sent with emacs for iOS

On Sep 22, 2020, at 15:50, Lee, Yiu <[email-masked]<mailto:[email-masked]>> wrote:
Hi team,

Thanks

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

---

From: Joseph Touch <[email-masked]>
Date: Wed, 23 Sep 2020 07:26:36 -0700

FWIW, 802 MAC addresses may be “set at birth” but also have long required support for multiple MAC addresses per interface, setting other MAC addresses, and disabling the “birth” address.

Long as in 25+ yrs.

Joe

> On Sep 23, 2020, at 7:02 AM, Eric Vyncke (evyncke) <evyncke=[email-masked]> wrote:
> 
> From: Int-area <[email-masked] <mailto:[email-masked]>> on behalf of Stewart Bryant <[email-masked] <mailto:[email-masked]>>
> To: Andy Smith <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On 22 Sep 2020, at 21:22, Andy Smith <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Yiu-
>>  
>>> On Sep 22, 2020, at 15:50, Lee, Yiu <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi team,
>>>  
>>> We proposed a BoF. The agenda is inhttps://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md <https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md> and the proposal is inhttps://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md <https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md>. You can also find the draft herehttps://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01 <https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01>.
>>>  
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 23 Sep 2020 16:02:51 +0100

Yes, but DEC decided that was a bad idea and stopped doing it in phase V.

Phase iV stared pre-bridging where the extend of the LAN was only the directly connected devices.

These days LANs are huge and I am simply asking about where the IEEE who are the design authority for Ethernet approve of MAC address randomisation?

Stewart

> On 23 Sep 2020, at 15:02, Eric Vyncke (evyncke) <[email-masked]> wrote:
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 23 Sep 2020 11:10:26 -0400

> These days LANs are huge and I am simply asking about where the IEEE who are the design authority for Ethernet approve of MAC address randomisation?

  It's actively being pursued:

https://www.ieee802.org/11/Reports/rcmtig_update.htm

https://mentor.ieee.org/omniran/dcn/19/omniran-19-0002-00-CQ00-random-mac-impact.pptx

  Alan DeKok.

---

From: tom petch <[email-masked]>
Date: Wed, 23 Sep 2020 15:40:29 +0000

From: Int-area <[email-masked]> on behalf of Eric Vyncke (evyncke) <evyncke=[email-masked]>
Sent: 23 September 2020 15:02

<tp>
Not so much SNA as token ring which almost always used configured local addresses (which made management so much easier).  SNA did not care much about layer 2 as long as it was fast and reliable.  SNA over DIX Ethernet or over 802.3 I would expect to see using universal (burnt-in) addresses.

Tom Petch

-éric

- Stewart

Yiu-

Andy

Sent with emacs for iOS

Thanks

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 30 Sep 2020 18:33:19 -0400

Yiu,

Just FYI, this issue came up several years ago with regard to randomized
MAC addresses in Ethernet frames contained in Ethernet pseudowires. Stewart
and I wrote RFC 8469 to address the resulting effects that were encountered
in the field.

Cheers,
Andy

On Tue, Sep 22, 2020 at 3:50 PM Lee, Yiu <[email-masked]> wrote:

> At this stage, we are looking for inputs for more use cases and interests
> of working together in this domain. Please post your comments in the
> mailing list.
>
>
>
> Thanks
>
>
>
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 1 Oct 2020 02:51:41 +0000

@Andy: Thanks for the pointer. I quickly gazed through RFC 8469. If I read it right, RFC 8469 tackles the problem in PW where the PW would confuse an ethernet packet with IP packet. Therefore, the RFC recommends to include CW in all PW. For this particular discussion, we want to document the impacts and hope the community can provide guidelines to transition the current applications that rely on persistent mac-addresses.

Best,
Yiu

From: "Andrew G. Malis" <[email-masked]>
Date: Wednesday, September 30, 2020 at 6:33 PM
To: "Lee, Yiu" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Stewart Bryant <[email-masked]>
Subject: [EXTERNAL] Re: [Int-area] Evaluate impact of MAC address randomization to IP applications

Yiu,

Just FYI, this issue came up several years ago with regard to randomized MAC addresses in Ethernet frames contained in Ethernet pseudowires. Stewart and I wrote RFC 8469 to address the resulting effects that were encountered in the field.

Cheers,
Andy

On Tue, Sep 22, 2020 at 3:50 PM Lee, Yiu <[email-masked]<mailto:[email-masked]>> wrote:
Hi team,

We proposed a BoF. The agenda is in https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md<https://urldefense.com/v3/__https:/github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!QWbd6a1T0QMccEhGrOtXVKTHTdHLnwMA4DxlOanMLZEGXFaL_FpvfezzG2N2rPY$> and the proposal is in https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md<https://urldefense.com/v3/__https:/github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md__;!!CQl3mcHX2A!QWbd6a1T0QMccEhGrOtXVKTHTdHLnwMA4DxlOanMLZEGXFaL_FpvfezzZRWfJ-E$>. You can also find the draft here https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!QWbd6a1T0QMccEhGrOtXVKTHTdHLnwMA4DxlOanMLZEGXFaL_FpvfezzMRRggvA$>.

Thanks

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/int-area__;!!CQl3mcHX2A!QWbd6a1T0QMccEhGrOtXVKTHTdHLnwMA4DxlOanMLZEGXFaL_FpvfezzNQSpLLI$>