Subject: [Madinas] MADINAS Side Meeting Notes

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 12 Mar 2021 14:59:25 +0000

Thanks for joining our side meeting yesterday. This is the meeting notes:

Number of Participants - 19
Yiu welcomed people to join the MADINAS side meeting
Yiu recapped the IETF109 BoF and explained the goals for this side meeting
Yiu pointed out a new RSM draft was posted and is available
Jerome stated that this RCM draft tries to describe the current RSM landscape
Kirsty P asked the hosts there was a list of items from the last BOF. Do we have an update?
Yiu answered we were still working on the action items such as engaging
more OS vendors to join the discussion
Jerome explained that people have a mis-conception that there exists THE solution.
However, in the real world, different environments will have different trust
level (e.g., home vs public access point) and support expectation This draft is
to describe the current landscape of using mac-address as device identity
JC clarified best outcome of this meeting would be to focus on the recently
published PS https://datatracker.ietf.org/doc/html/draft-henry-madinas-framework.

There is no agreement what are the next step. It could be a BCP, a new protocol
and everything is up in the air
Jerome walked through the draft
RCM definition, core of doc contribution in section 3:
- new definition of devices as per IEEE802E (shared vs personal)
- different phases of MAC address rotation, every time more dynamic and frequent
- human related entities and roles in network infrastructure
- implications on some IETF protocols, such as DHCP
Tobias - how about implications about SW licenses mapped to MAC addresses?
Juan Carlos - RFC 4191 7217 provide some solutions about IPv6 -
How well would these work under frequent and dynamic MAC address changes?

Kristy - When looking at solutions to the highlighted issues, you should avoid simply changing MAC address by another identifier, as privacy needs should be considered high. How to address AirBnB or Home visitor WiFi use cases?
Yiu - We consider AirBnB more as Hospitality than Home. We are also considering that some services are required in the Home, as Parental Control for instance.
Joey - Who will provide these services? The ISP?
Jerome - Not all scenarios are yet considered.
Yiu - At this moment we are just looking issues and at what can be done to address these issues
Erik - granularity of tracking is also a dimension that should be considered
Juan Carlos - When the user is aware and willingly opted into the service being provided, tracking is reasonable. Otherwise, the default should be not to track
Kristy - Should make clear to the group what the group would like to do and would NOT like to do. Identify Problem and Problem Space, and possible solutions.
User consent, Enterprise, Opting-in
Yiu - User identifier, Network identifier
Jerome - Continuity of services
Eric - Charter is needed to get into WG-forming in July
Juan Carlos - Need to involve OS  vendors, Privacy proponents
Eric - Infra manufacturers (AP, routers, etc.) as well
Next steps - Interim meeting, at about mid-April (doodle to come up)

---

From: Erik Kline <[email-masked]>
Date: Fri, 12 Mar 2021 16:36:28 -0800

(no hats)

I wanted to add a comment I shared with Eric unicast during the session.  I
think -- regardless of whatever might happen with madinas efforts going
forward -- draft-zuniga-mac-address-randomization seems like a good summary
of MAC randomization things today.  I would certainly support advancing
toward publication -- in some form, in some group -- even if only to
capture things for posterity.

On Fri, Mar 12, 2021 at 7:00 AM Lee, Yiu <Yiu_Lee=
[email-masked]> wrote:

> published PS
> https://datatracker.ietf.org/doc/html/draft-henry-madinas-framework.
>
>
>
> Kristy - When looking at solutions to the highlighted issues, you should
> avoid simply changing MAC address by another identifier, as privacy needs
> should be considered high. How to address AirBnB or Home visitor WiFi use
> cases?
>
> Yiu - We consider AirBnB more as Hospitality than Home. We are also
> considering that some services are required in the Home, as Parental
> Control for instance.
>
> Juan Carlos - When the user is aware and willingly opted into the service
> being provided, tracking is reasonable. Otherwise, the default should be
> not to track
>
> Kristy - Should make clear to the group what the group would like to do
> and would NOT like to do. Identify Problem and Problem Space, and possible
> solutions.
>
> --
> Madinas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/madinas
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Mar 2021 19:31:35 -0500

> Thanks for joining our side meeting yesterday. This is the meeting

Sorry to have missed it... had to go outside and see the sun :-)

    > best outcome of this meeting would be to focus on the recently
    > published PS

Thank you, I was unware of this document.

    > Kristy - When looking at solutions to the highlighted issues, you
    > should avoid simply changing MAC address by another identifier, as
    > privacy needs should be considered high.

    > How to address AirBnB or Home
    > visitor WiFi use cases?

    > Yiu - We consider AirBnB more as Hospitality than Home.

AirBNB is precisely the right problem space to be thinking about.
It's NOT Hospitality, because it has no infrastructure or person (today) to
manage this, and it uses off-the-shelf residential equipment, and nothing we
do at the IETF will change that.  So, solve the guest-in-my-house problem is
actually critical.

I am working on a project that provides Parental and/or IoT device controls
on home gateways.  Our lead (Android/Apple) App developer has an Apple mostly
house, and suffers from the MAC randomization today.

We have decided that for the *parent* (owner, manager) device, that, on every
single API request, we check if that device's MAC address has changed so that
we can enable the device to talk to the world.   It's kinda ridiculous, actually.

We need to change from WPA-PSK to WPA-Enterprise, so that we can have
certificate based identities, but this is not so easy to do.

This is the direction that MADINAS needs to go in, and we all know this as an
industry, but many people are afraid to say so, I think.

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Mar 2021 19:36:49 -0500

Erik Kline <[email-masked]> wrote:
    > I wanted to add a comment I shared with Eric unicast during the
    > session.  I think -- regardless of whatever might happen with madinas
    > efforts going forward -- draft-zuniga-mac-address-randomization seems
    > like a good summary of MAC randomization things today.  I would
    > certainly support advancing toward publication -- in some form, in some
    > group -- even if only to capture things for posterity.

I concur: publish this as AD sponsored or do it in OPSAWG, maybe INTAREA.

Based upon how the industry is very fragmented, how CHIP is occuring without
external review, and how the vendors and ISPs prefer consortia like
prplFoundation and wifi alliance, rather than working together in public, I
don't think that an IETF WG would be successful.

This is fundamentally a residential network onboarding problem.

---

From: "Lee, Yiu" <[email-masked]>
Date: Sun, 14 Mar 2021 01:20:44 +0000

Hi Michael,

Maybe I should be more precise. When I said Airbnb was "Hospitality". I refer to the trust and service level. I like the Guest network you mentioned. I see two problem statements: (1) How a device authenticate the network if we believe that every network including home network is untrusted; (2) Once the network is authenticated, how a device securely exchange the identity in exchange for services.  We are trying to point out that every environment will have slightly different setup. For example: WPA-Enterprise may work well in Enterprise and ISP-Managed network but may be not be ideal for Home network and Small-business network.

Best,
Yiu

On 3/13/21, 19:32, "Madinas on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Mar 2021 01:41:22 +0000

Hiya,

> do at the IETF will change that.  So, solve the guest-in-my-house problem is

I agree with that last. And, while it's a bit of a strawman,
the idea that house-guest handling could even possibly be
solved via layer 2 identifier handling (or DNS handling)
seems fairly clearly broken - I'd go so far as to say
attempting to "solve" things that way could clearly be
inhospitable;-)

The problem of how network devices and visitors relate
in households needs re-consideration I think now that
we have "smart-speakers" and many other devices that
can silently impinge on the visitor's preferences - and
being a hospitable person I'd generally prefer not to piss
off my visitors. The implication there is that there are
likely situations where the visiting device's policy is
the one that ought win against the local-network's policy,
which is a weird concept considering how networks have been
managed to date.

I'll admit that I don't know how to handle that kind of
thing, and now having typed all the above I've almost
convinced myself that revisiting guest-handling may be a
problem that warrants more attention than MAC address
bit fiddling;-)

Cheers,
S.

PS: There's a related thread in the ADD wg where the
topic is who gets to determine what DNS servers might
be used and which policy announcements to represent when
handling that problem. As in this case, I suspect that's
one where the "obvious" approach that might preserve the
status-quo is likely the wrong direction.

---

From: Tim Cappalli <[email-masked]>
Date: Sun, 14 Mar 2021 01:45:34 +0000

DPP solves the IoT side. We just need vendor adoption.

While I'm a huge proponent of 1X, I'm not sure it's the right solution for the home or Airbnb scenarios. I believe SAE Password ID solves the residential use cases, but again, need OS vendors to step up here.
________________________________
From: Madinas <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Saturday, March 13, 2021 8:41:22 PM
To: Michael Richardson <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Madinas] MADINAS Side Meeting Notes

Hiya,

Cheers,
S.

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Sun, 14 Mar 2021 13:53:19 -0400

Hi Erik,

We had originally started this draft before MADINAS precisely with that
intention, as we saw the MAC address randomization topic coming back on
different WGs every so often, and every time there was a need to explain
the background of this activity. We had once discussed pushing for
independent submission with Suresh, but things slipped in time.

I agree that it would be useful to publish it so that we can provide a
snapshot of where things are at IETF and elsewhere, and hence we can more
easily understand the problems and potential upcoming proposed solutions.

At the moment we (authors) believe the draft could include some more
activities (e.g. WBA) and it could then be in a good condition for
publication req. Either independent, OPSAWG or INTAREA would work.

Juan Carlos

On Fri, Mar 12, 2021 at 7:36 PM Erik Kline <[email-masked]> wrote:

> (no hats)
>
> I wanted to add a comment I shared with Eric unicast during the session.
> I think -- regardless of whatever might happen with madinas efforts going

---

From: Erik Kline <[email-masked]>
Date: Sun, 14 Mar 2021 17:44:04 -0700

Great to hear.  Let Eric or myself know how we can help.  If no working
group wants to take it on, I'd be happy to try to AD sponsor.

On Sun, Mar 14, 2021 at 10:53 AM Juan Carlos Zuniga <[email-masked]>
wrote:

>>> Juan Carlos - When the user is aware and willingly opted into the
>>> service being provided, tracking is reasonable. Otherwise, the default
>>> should be not to track
>>>