[ipv6hackers] NetworkManager and privacy in the IPv6 internet

Enno Rey erey at ernw.de
Sun Dec 6 08:43:38 CET 2015


Hi,

Mark wrote:

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

It should be noted that we do *not* recommend static configuration as a general approach at all, for the exact reasons you mention (operational effort). Our approach (which indeed has a certain focus on enterprise environments) can be summarized as follows:

a) IPv6 has a certain architecture model which implies a high degree of autonomy and self-organization of nodes.

b) Furthermore IPv6's address configuration mechanisms are - in contrast to IPv4 - _not_ mutually exclusive (in IPv4 going with a static config automatically meant that the dynamic approach [DHCP] does not happen), so if you really want to have static configuration you have to disable all the automatic stuff (e.g. local processing of RAs) in parallel.

c) Disabling the local processing of RAs is in fundamental opposition to IPv6's general architecture model (I often say: "disabling the processing of RAs is like removing the wheels from a car and putting it on tracks. it might work but it's against the way how things are supposed to work and there's a high chance it won't work very efficiently").
In addition - given the important role of RAs in IPv6 world (to use another flowery analogy: in IPv6 an RA is like "the kiss of the sleeping beauty", it injects life) - if you do so (disable RA processing) you risk that compiling a new kernel or installing a service pack in Win world will re-enable them again which means it becomes even more operationally costly to keep a system in a consistent state.
In short: "disabling local processing of RAs" is a heavy "deviation from default" (change sth from a given default state to another state) which by itself is always operationally costly in large scale networking (in particular in heterogenuous environments = pretty much all large enterprise networks).
Even shorter: "just don't do it".

d) if you *still* want to do it, because you're a "control freak" and "human nature of controlling things dominates your thinking" (and "because we have done things in that way before"), *then* you might follow the guidelines laid out in our "IPv6 Hardening Guides".

I wish everybody a great second advent Sunday

Enno


-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================


More information about the Ipv6hackers mailing list