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

[Michael Richardson <[e-mail]>]

Brian Dickson <[e-mail]> wrote:
    >> 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.

Sure.  If there is a port mapping (or PCP created incoming ACL for IPv6),
which is bound to a particular IPv6 (however assigned), and that the IPv6
changes, then the mapping will break right?
This is independant of MAC address randomization right?
If we changed the MAC address, and then kept the IP address involved, then ND
would fix things up, and things would continue just fine.

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

I strongly disagree here.
We use privacy IPv6 addresses in order to keep legitimate distant end points
(and their associated snoops) from tracking one for place to place.

We use different MAC addresses for different networks to keep from being
tracked by a federation of local snoops from place to place.

We change our MAC address at the same network to hide our time of use and
presence from local snoops.  But, also to deal with malicious attackers who
put up a common ESSID ("Starbucks").   We can, and do encrypt our IPv6
address on those networks.  But, we can't encrypt our MAC address, because as
you say, it used for media access control.

    > 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 hope so too.

    > 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}.

An interesting idea.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


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