[ipv6hackers] NetworkManager and privacy in the IPv6 internet

[Matej Gregr]

On 12/05/2015 04:31 AM, Mark ZZZ Smith wrote:
> 
>       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.

Yes, I agree that servers and router interfaces need stable and constant
addresses. That's the reason why they are configured statically. The
another reason for static configuration is that dynamic address creation
is more vulnerable to local DAD attacks, and RFC 7217 has the
vulnerability as well. So it is often recommended to use static
configuration and disable DAD - see for example Enno's hardening guides
for servers.
So RFC 7217 will probably not be used for servers.

> * 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.).

RFC 7217 doesn't help in this case. The troubleshooting, backtracking of
security incidents or auditing will not be easier. If a user reinstall
os, boot to another OS, etc., the algorithm in RFC 7217 creates a
different privacy address. These things happen. There will be changes in
users addresses in a production network, so nothing changes here.

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

Yes, RFC 7217 is better than EUI64, but thats all. I reread it and it
doesn't even fulfill its own design goals!

E.g. "the algorithm generates the same Interface Identifier
      when configuring an address (for the same interface) belonging to
      the same prefix within the same subnet"

Which is not true.

M.