[ipv6hackers] NetworkManager and privacy in the IPv6 internet

[Mark ZZZ Smith]

      From: Matej Gregr <igregr at fit.vutbr.cz>
 To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com> 
 Sent: Sunday, 6 December 2015, 11:10
 Subject: Re: [ipv6hackers] NetworkManager and privacy in the IPv6 internet
   
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.

* By whom? There are 100s of millions of routers in homes that don't have statically configured addresses on router interfaces and will never have statically configured addresses because that is beyond the capabilities of the devices' owners. Many servers and server-type devices (e.g., printers) don't need statically addressed either, because they announce their presence and their address using multicast-DNS.

 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.

* I don't agree with that advice at all. I used IPv4 before DAD, and experienced what having duplicate addresses without DAD was like.

* If Enno's hardening guide doesn't specify in what context a DAD attack is a likely threat that needs to be be mitigated, it is not good general advice. If a DAD attack is a threat, then you probably shouldn't be using a link type that makes nodes easily vulnerable to them. (I call these types of links Constrained Broadcast Multi-Access - https://tools.ietf.org/html/draft-smith-6man-link-locals-off-link-00)

* (You and Enno seem to be coming from the perspective that the only type of network on the Internet is an Enterprise one that can afford to pay operational people to configure things like static addresses. That used to be the common case, but isn't any more since the rise of broadband Internet access. Methods such as RFC7217, SLAAC, DAD etc. are all about making networks operate without that sort of operational expertise and overhead. The risk of an on-link DAD attack is low on a residential network in comparison to the risk of privacy violating tracking of end-user devices across different networks when they derive their IID from hardware embedded EUI64/MAC addresses.)


So RFC 7217 will probably not be used for servers.


* So you think it is a good idea that they by default use EUI64 derived addresses instead? How can you be absolutely sure they'll be configured with static addresses that aren't predictable by a remote attacker? RFC7212s should be the default for servers rather than EUI64 derived as they are now. 


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

* Of course it will create a different address. If the OS is replaced or a different OS is booted, it is in effect a different end-node. The purpose of RFC7217 is not to create permanent, globally unique, unalterable, hardware embedded device identifiers that are impervious to OS replacement. Even MAC addresses don't qualify as those, despite that being the original intent.

 These things happen. There will be changes in
users addresses in a production network, so nothing changes here.


* I don't agree with disabling privacy addresses on end-user devices, but for those who want to, RFC7217s are much better than EUI64s derived addresses.

* This use case came from the US government Defence Research and Engineering Network, as explained in the RFC.

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

* You'll have to explain that one. What do you know that Fernando, the people listed in the Acknowledgements section of the RFC and more broadly the IETF, since they published it, don't?

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