[ipv6hackers] NetworkManager and privacy in the IPv6 internet

[Fernando Gont]

On 12/05/2015 09:10 PM, Matej Gregr wrote:
[....]
>> 
>> * 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.

I disagree with this. A DAD attack is just one single attack among a
plethora of attacks that can be performed against ND. (see e.g.:
<http://www.si6networks.com/tools/ipv6toolkit/si6networks-ipv6-nd-assessment.pdf>).

If you want to address ND attacks then:
1) segment your network, and/or
2) Implement First-Hop Security


If you disable DAD I can still launch any of the other ND attacks, so...
what's the point?



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

Firstly, if the user reinstalls the OS he's the system admin. Secondly,
if he can do all that, he might as well just manually configure any
address that he wants. Obviously, RFC7217 doesn't aim to mitigate that,
and cannot even mitigate that.

Last, I should say that the reason for which we put this:

          An implementation MAY provide the means
          for the system administrator to display and change the secret
          key.

in RFC7117 is so that you can set the same secret key in some events.

Also from our point of view, once you reinstall the OS, the systems is a
new one. -- why would you consider the system to be "a new one" only
when the hardware changes? Why would hardware be "more important" in
such case?



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

So.. could you please describe in which situation this would not be
true?  As noted above, an OS-reinstall makes the system a new and
different one.

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