[ipv6hackers] NetworkManager and privacy in the IPv6 internet

[Fernando Gont]

Hi, Mark,

[....]
>> 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.

Yep.



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

Ok, please let me explain.

RFC4941 assumes that you deploy temporary addresses along with stable
addresses (at the time, stable == traditional SLAAC with the embedded
address). The reason for that is that in general, you need/want to have
an address that is stable, for server-like functions. Otherwise, e.g.
directory services should be updated more often, etc.  Besides, stable
addresses allow you to have e.g. long-lived TCP connections: if you
establish an SSH session with temporary addresses, then eventually the
addresses will become invalid, that the SSH session will be teared down.

Therefore, you need stable addresses no matter whether you also
implement/use temporary addresses or not.

That's why RFC7217 says that they are orthogonal: even if you're
implementing RFC4941, there's a reason to do RFC7217.

That said, I believe that RFC7217 is good enough that in most cases,
you'd just do RFC7217 and disable RFC4941. The only "improvement" of
RFC4941 over RFC7217 (in terms of privacy) is that, in thery it mitigaes
correlation of network activity over time.. But, if the network *prefix*
is stable, then changing the IID will not buy you much. e.g., I could
still infer that activity is originating from your home based on the
stable prefix.

And since RFC4941 is much of an operational mess, I don't think they are
much worth the mess when RFC7217 is available.


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

Agreed. BUt please see above what I said regarding the netwrk prefix.



> 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?

In that case you could probably say that it is useless for relieving you
from the operational pain of RFC4941 (you're obviously using them,
so...). But if e.g. you want to establish an SSH session that will last
for as long as you want, then they server one fo their purposes.



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

Exactly.


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

Agreed, too. But having stable addresses help for simply stuff like
identifying nodes that got infected in your network, or e.g. enforcing
simple ACLs.

There are scenarios in which this sort of thing is "good enough" but
RFC4941 would prevent you from doing that.



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

Exactly. That's the way I think about RFC7217.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492