[ipv6hackers] NetworkManager and privacy in the IPv6 internet

[Matej Gregr]

Hi Fernando,

On 12/06/2015 10:02 PM, Fernando Gont wrote:
> Hi, Matej,
> 
> On 12/06/2015 05:08 PM, Matej Gregr wrote:
>>>> If I use the same hw and OS, but I switch from network manager to 
>>>> dhcpcd, the privacy address will be different. If I change a
>>>> software used for address configuration, it is also a different
>>>> end-node for you?
>>>
>>> Could you provide a sample case for which you'd want to do that?
>>>
>>
>> I don't want to do that. It can just happen. Last year, Linux kernel was
>> responsible for IPv6 address configuration on my system. Regular system
>> update updated my version of dhcpcd and dhcpcd overrode the in-kernel
>> IPv6 autoconfiguration.
> 
> Just curious: Distro? -- and... dhcpd is doing RFC7217 by default?
> 

Gentoo. Yes, dhcpcd uses rfc7217 by default. Side note, dhcpcd and dhcpd
(sometimes called isc-dhcp) are different packages.

>> Right now, the user space app is responsible for
>> ipv6 address config. The point is, that changes in address configuration
>> can happen without an user intervention. My system remains the same.
>> So a sample case is, that your favorite Linux distribution switches to a
>> different network-conf package. I will probably see it again, when my
>> distribution switches from openrc to systemd.
> 
> What I would expect in that case is that as part of the process of
> updating, the "updater" takes the same secret that was used in the
> previous package, and employs it for the new one.

That would be nice, but note that dhcpcd uses 512 bit secret and network
manager uses 256 bit.

> Yes, I'm not sure to what extent that's doable. And, at the same time,
> you could argue that, in theory, they each package could e.g. use a
> different hash function, or use the hash parameters in different order,
> etc. (thus leading to a different IID).

Yes, that's true. The same problem is with the secret length.

> In all these cases, I'd blame the update process. You're essentially
> changing the secret, or changing the algorithm implementation. In that
> case, it should be the OS update the one making things happen
> auto-magically.
> 

Yes, you can blame the update process. Similarly I can blame the RFC :)
No, I understand that it is hard to write an RFC that has the stable
behavior I would like to see.

> 
>>> I can only/mostly think of text-only console vs. full GUI. At which
>>> point yes, I consider that a different system.
>>> Besides, if you change that you're more of sys admin than a user.
>>
>> I don't think you have to be a sysadmin. It can be just a regular update.
> 
> I see the case you were thinking about. But please se my note above.
> 
> 
>>> As far as I understand: node=software+hardware.
>>>
>>> If you reinstall the OS, and the OS doesn't care to e.g. keep the
>>> secret, than that's a different system.
>>> The software for address generation is part of the OS. For instance,
>>> much of what network manager does is part of the OS, rather than an "app".
>>
>> Currently, Linux's in-kernel address configuration is overridden by an
>> "app" in several distributions. Every app uses a different secret. The
>> secret is not part of the Linux OS.
> 
> Well, the OS is not just the kernel, but the whole thing.
> 
> I believe that if the OS decides to reorganize things differently, that
> shouldn't break, where possible, your configuration.
> 
> e.g., and if they decide not to make this happen automagically, then I
> guess this "update" should actually be part of an upgrade to a new
> relase, rather than just a regular update.
> 

I still cannot grasp your idea, that when I upgrade my laptop from e.g.,
ubuntu 13.04 to 14.04 or MAC from 10 to 11, it's a different system for
you, but ok.

> 
>>>> Don't get mi wrong, I don't have anything against RFC 7217. I am
>>>> using it on my systems. However, I had an impression from initial
>>>> design goals that the RFC will help me to simplify address accounting
>>>> in my network. It didn't happen. That's all.
>>>
>>> It does simplify address accounting. However, RFC7217 is not about
>>> preventing users from changing the OS (if you allow your users to do
>>> that, then that's your fault. Or, if they do that, having been notified
>>> not to do so, then it's your fault if you don't fire them).
>>
>> I don't have a control over users system and users software. I cannot
>> forbid them to reinstall or update their OS. However, I have to provide
>> them an access to a network and have a reasonable way how to account
>> them. I though that RFC 7217 will simplify our system for address
>> accounting, but it will not. Apparently because of a different
>> understanding on what is and what is not stable IID.
> 
> Please see my note above regarding OS updates. Besides that, if you
> don't control the OS, at the end of the day the user can manually
> configure an address and make your life miserable in that respect.

Yes, that's true, but it is the reality we are living in (and many
others as well). Thanks for the discussion!

M.