[ipv6hackers] NetworkManager and privacy in the IPv6 internet

[Mark ZZZ Smith]

      From: Matej Gregr <igregr at fit.vutbr.cz>
 To: ipv6hackers at lists.si6networks.com 
 Sent: Saturday, 5 December 2015, 2:24
 Subject: Re: [ipv6hackers] NetworkManager and privacy in the IPv6 internet
   
On 12/04/2015 04:12 AM, Fernando Gont wrote:
> Hi, Folks,
> 
> FYI:
> <https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-the-ipv6-internet/>
> 
> In a little while Fedora will be shipping with RFC7217 on by default.
> 
> That's really good news!
> 
> Thanks,
> 

Hi,
  dhcpcd [1] supports RFC 7217 as well and it works well.

Btw, I am still quite confused with the whole idea of RFC 7217 if we
have RFC 4941. You argue in your RFC that:

"from a network-management point of view, they tend to increase the
complexity of event logging, troubleshooting, enforcement of access
controls, and quality of service, etc."

I agree with that, however, RFC 7217 also says that temporary addresses
are useful in some cases, e.g., correlation of activity of a host within
the same network. Furthermore, RFC 7217 says that it is not meant as an
alternative for these temporary addresses and that it is orthogonal to
the RFC 4941.

So if there is a demand for untraceability and anonymity on network
layer, we should end up with RFC 7217 together with temporary addresses,
as it is "the best solution".

However, if an OS implements RFC 7217 and creates a temporary address as
well, the whole idea of a stable identifier is useless. According
address selection, temporary addresses will be used for communication
and we are at the beginning. Or I am missing something?


* Think about whether RFC4941s can be effectively used on servers or router interfaces. These types of interfaces need stable and constant addresses, but prior to RFC7217, the only stable types of addresses were EUI64 derived ones, or statically configured ones.
* Some networks want to disable RFC4941s on end-user devices for auditing purposes, but also don't like the privacy issues that EUI64s cause. So RFC7217s are also (somewhat of) a solution for them. (Personally, I think if auditing is important to you, you should be really using link-layer authentication e.g., 802.1X, and then would be able to record any and all addresses that an end-user device uses. MAC addresses and layer 3 addresses identify devices, not the people who are behind them, and devices aren't very tightly physically coupled to their authorised users, unless you use handcuffs, chains or cableties.).

* So broadly, you can think of RFC7217s as stable privacy addresses for inbound connections on devices that need stable addresses, and a better privacy alternative to EUI64s if the temporary nature of RFC4941s is not acceptable on end-user devices.

* Regards,Mark.

M.

[1] http://roy.marples.name/projects/dhcpcd/


_______________________________________________
Ipv6hackers mailing list
Ipv6hackers at lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers