Re: [Int-area] [EXTERNAL] Re: [homenet] Evaluate impact of MAC address randomization to IP applications

["Lee, Yiu" <[e-mail]>]

Noted and clear. Will keep this in mind in the next update.

Thanks,
Yiu

On 9/22/20, 5:18 PM, "Stephen Farrell" <[e-mail]> wrote:


    Hiya,

    On 22/09/2020 22:08, Lee, Yiu wrote:
    > Hi Stephen,
    >
    > Thanks for the notes. Actually, we believe that there are good
    > privacy reasons to randomize mac-address. This BoF isn't trying to
    > "fix" randomized mac-address. On the contrary, we want the community
    > to embrace it. In order to ease the anxiety for transitioning, we
    > want to document what may break and propose best practice to
    > transition to dynamic mac-address.

    Sure, I get that. However, we've seen a number of these
    efforts start thusly but end up being perceived to be
    partly trying to unwind the privacy benefits, so I think
    a good way to avoid that mis-perception is to also present
    the reasons for (in this case, MAC address randomisation)
    as fully as the description of the challenges caused.

    Cheers,
    S.


    >
    > Thanks, Yiu
    >
    >
    > On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell"
    > <[e-mail] on behalf of [e-mail]>
    > wrote:
    >
    >
    > That agenda and draft seem to make the seemingly common enough
    > mistake of only focusing on what a new privacy or security mechanism
    > breaks and glossing over the good reasons why people introduce these
    > mechanisms. I hope the BoF proponents fix that because otherwise they
    > may end up giving the impression that they would prefer to not see
    > the privacy benefits (which I'd guess is not their goal at all). One
    > reason those good reasons need to be included is that they constrain
    > the kinds of additions that might make sense to better handle the new
    > mechanism.
    >
    > We've seen a number of these kinds of reactions and I figure it'd
    > really be better if the reaction were not to appear purely
    > reactionary;-)
    >
    > If that were fixed, then there may be a better discussion of what, if
    > any, additional things need doing. If that is not fixed, I'd not be
    > surprised if the putative BoF were to devolve into a "it's bad" vs.
    > "no, it's good" bun fight that won't really take us further.
    >
    > Cheers, S.
    >
    > On 22/09/2020 21:40, Michael Richardson wrote:
    >>
    >> Damn. Spelt captive-portal without the s again.  Reposting, sorry
    >> for duplicates. I hate when WG names and list names do not match,
    >> and that we can't have aliases. And I think that reply-to gets
    >> filtered.
    >>
    >> Archived-At:
    >> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/int-area/14Skgm84GslPZ9UcGoWY3uzmK6I__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eprXSEjo$
    >> > To: [e-mail], [e-mail], [e-mail]
    >> From: Michael Richardson <[e-mail]> 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://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_e7alyc8U$
    >>> and the proposal is in
    >>> https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eNfKGqkE$
    >>> . You can also find the draft here
    >>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_erhCF3-A$
    >>> .
    >>>
    >>> 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
    >>>
    >>
    >>
    >> -- Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
    >> consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
    >>
    >>
    >> _______________________________________________ homenet mailing
    >> list [e-mail]
    >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/homenet__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_epVo5mQQ$
    >
    >>
    >
    >
    > _______________________________________________ homenet mailing list
    > [e-mail] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/homenet__;!!CQl3mcHX2A!QmyqyKwbOOxTGfm0x58b5xfYvrm-ivhzQUDCjlF7XvYCa411l20nyTY4Gc-Mvoc$
    >