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

[Brian Dickson <[e-mail]>]

On Tue, Sep 22, 2020 at 4:25 PM Michael Richardson <[e-mail]>
wrote:

>
> Bob Hinden <[e-mail]> wrote:
>     > I have read the emails and the draft
> <draft-lee-randomized-macaddr-ps-01>.   I am not clear what the goal of the
> BOF is.
>
>     > Could the proponents state it clearly?
>
> I can't speak for the proponents, but at the simplest, one could add:
>   "how can we do X if the MAC cannot be used as identity"
>
>     > • LAN gateway NAPT forwarding - (PRESENTER TBD)
>     > • Static NAPT policies - (PRESENTER TBD)
>     > • Persistent DHCP IP address assignments - (PRESENTER TBD)
>     > • Device-to-user or group association for malware protection -
> (PRESENTER TBD)
>     > • Device-to-user or group association for parental controls -
> (PRESENTER TBD)
>     > • Device-to-user or group association to restrict or authorize
> unwanted
>     > or unverified device connections to the LAN - (PRESENTER TBD)
>
> I don't get the NAPT issue though.
> The NAPT issues are because DHCP gave the device a different IP(v4), right?
> If you solve persistent DHCP, then you solve those, don't you?
>

I think there are some environments where that isn't technically accurate,
or might not be 100% accurate.
E.g. The difference between DHCP6 and that other wacky thing that is doing
random self-assigned IPv6 addresses.

Basically if MAC addresses change during the lifetime of any assignment
(externally provided or self-assigned), the L3/L2 mapping itself also needs
to be updated or redone.

And how that is done can break security and/or connectivity and/or privacy,
or possibly all three.

(E.g. maintaining the IP address when the MAC changes, defeats at least one
possible purpose of changing the MAC.)

I sense a potential rat-hole, but also the possibility of finding common
ground to fix a bunch of things that are problematic to some degree or
another.

I'm hopeful that something like 802.1x can be made use of effectively, but
again a lot depends on the use cases and will likely require pretty deep
dives on each of the relevant technologies and implementations.

IMNSHO, MACs should be relegated to the role reflected in their name: Media
Access Control, basically a disambiguator, not an identity.

Maybe MACs should be used the way the initial values selected by the two
parties doing DH key exchange are used, just as a stepping stone in
establishing a cryptographically-strong "thing" that only they know.
I.e. use the initial MAC (regardless of what it is) as an initial layer-2
communications things, during the set-up of {whatever the BOF/WG output
is}, after which the MAC gets changed to {something else}.

The work being done by the exposure notification may be a good reference
model.
(Google Apple Exposure Notification, aka GAEN, for the SARS-CoV-2 aka
Covid-19 protocols for privacy-first automatic exposure notification over
BLE).
That too uses identifiers that are non-linkable and rotate periodically (on
the order of 10 minutes IIRC).

Brian