[ipv6hackers] NetworkManager and privacy in the IPv6 internet

[Fernando Gont]

On 12/06/2015 10:05 AM, Matej Gregr wrote:
> snip
> 
>> * 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.
>> 
> 
> 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 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.

IN that case, you might just as well disable slaac and manually
configure your addresses.



>>> 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?
> 
> The RFC 7217 reality is:
> 
> "the algorithm generates the same Interface Identifier when
> configuring an address (for the same interface *, same OS and same
> version of a software used for address generation*) belonging to the
> same prefix within the same subnet"
> 
> Compare it with the original design goal.

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



> 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).
RFC7217 is not about e.g., probing that a node is allowed to use the
address it has configured (a la CGA+certificates). In the same way,
RFC7217 is not about mitigating ND issues (e.g. DAD attacks) -- in that
case, you should e.g. implement first-hop security and/or segment the
network.

Thanks!

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