You are not logged in.
Since procps-ng 3.3.3-3, IPv6 Privacy Extensions are enabled by default:
https://bugs.archlinux.org/task/30278
This thread is for 2 purposes:
1) Heads up to those using IPv6, this may break things (especially ACL's and firewall rules). It certainly did in my environment (unable to mount my /home on my NAS because NFS ACL failed).
2) Am I the only one who doesn't think this is a sane default?
Those who are concerned about the issues of being tracked by their IPv6 address are likely to enable Privacy Extensions themselves. Yes, I know that argument goes both ways in that those who don't care/believe it's an issue can disable it (like I have)... But to me that feels like we should enable DHCP by default too, since most people "probably" want/use/need that and those that don't can disable it.
It also goes against the upstream default (both procps-ng and kernel).
Thoughts from others? Maybe I am the black sheep here, but want to get a feel if that is the case or not.
Last edited by fukawi2 (2012-08-18 05:59:38)
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
I asked something similar some time ago: https://bbs.archlinux.org/viewtopic.php … 6#p1099096 and following
Offline
I asked something similar some time ago: https://bbs.archlinux.org/viewtopic.php … 6#p1099096 and following
Did not see that, thanks.... Looking at the RFC, we are also going against that (no surprises Microsoft and Apple do, but that's their problem)
Devices implementing this specification MUST provide a way for the
end user to explicitly enable or disable the use of temporary
addresses. In addition, a site might wish to disable the use of
temporary addresses in order to simplify network debugging and
operations.
.....
The use of temporary addresses may cause unexpected difficulties with
some applications. As described below, some servers refuse to accept
communications from clients for which they cannot map the IP address
into a DNS name. In addition, some applications may not behave
robustly if temporary addresses are used and an address expires
before the application has terminated, or if it opens multiple
sessions, but expects them to all use the same addresses.
Consequently, the use of temporary addresses SHOULD be disabled by
default in order to minimize potential disruptions. Individual
applications, which have specific knowledge about the normal duration
of connections, MAY override this as appropriate.
Emphasis added by me.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
In my view the set of those default options is very sane indeed to protect Arch users with a security-wise safe default for the time being.
There seems to be no other KISS options for those settings, if one acknowledges the privacy-relevance for most Arch users at all.
I see your points, but autoconf IPv6 addressing is one of those changes that should entail an informed opt-in IMO - at least at this time of adoption. Plus it is easy to change persistently.
One way forward might be to add reasonably long TTL options for the temporary IPv6s in sysctl. Setting those to a time longer than the average reboot time might make away with side-effects and inefficiencies by multiple assigned temp IPs.
Offline
In my view the set of those default options is very sane indeed to protect Arch users with a security-wise safe default for the time being.
AFAIK, there are no security issues around Privacy Extensions... I assume you meant privacy.... If we are to patch for privacy, then we should disable javascript, cookies etc in all browsers in the official repos. That would be akin to patching for security, where we should set AllowRootLogin = no in sshd_config, and enable iptables to block all traffic by default.
I see your points, but autoconf IPv6 addressing is one of those changes that should entail an informed opt-in IMO - at least at this time of adoption.
It's no different to connecting to a network and obtaining a DHCP lease, except more information is generated by your computer rather than a (possibly unknown/untrusted) network administrator
Plus it is easy to change persistently.
Once you know how and what you're looking for, hence I thought it might be useful to have this thread.
One way forward might be to add reasonably long TTL options for the temporary IPv6s in sysctl. Setting those to a time longer than the average reboot time might make away with side-effects and inefficiencies by multiple assigned temp IPs.
That could be a valid compromise in the situation. I would like to suggest setting the option to '1', but I'm not sure even what the point of this setting is since the kernel will prefer the stateless address for outgoing connections, the PE addresses would only be useful for incoming traffic, which is kind of pointless when the address will change within a very short lifetime (compared to an IPv4 address, or "static" stateless IPv6 address).
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
AFAIK, there are no security issues around Privacy Extensions... I assume you meant privacy.... If we are to patch for privacy, then we should disable javascript, cookies etc in all browsers in the official repos. That would be akin to patching for security, where we should set AllowRootLogin = no in sshd_config, and enable iptables to block all traffic by default.
You have a point, and that's a creepy one. Let's wait for some developer to make an illuminating statement about this topic
Offline
@work: We all here think it is good fukawi2 triggered a thread in discussion about this. There were already two developers reacting in the thread-links up there.
@fukawi2: (I go without quoting from the bottom of your answer up)
d) AFAIK it is just as you write yourself: Setting it to "1" does nothing to achieve privacy for outgoing connections. For incoming (e.g. port 631) it brings exactly the usage problems you want to avoid. So: True, nothing gained with that IMO as well.
c) Network troubleshooting will be more difficult with the default "2" enabled, sure. That's the main argument in your RFC quote also.
b) Yes, agreed - in other words: Those bits of extra information make it totally different to DHCP, because they include the globally unique interface identifier which is sent with _every_ TCP/IP connect over its lifespan.
a) I meant it can be security relevant not to enable them also.
Example:
a1) Security: Let's say the service running on port 631 becomes vulnerable. With a typical setup of a client-PC the IPv4 will be different next reboot/lease (vector is lost; not even taking NAT into account). With a non-temp IPv6 the vector re-appears each time the box is turned on.
a2) Privacy: I fully agree, with one addition: Apart from some 'esoteric' ad-tracking techniques, the typical end-user has control over the cookies et al. With the user using a default unique IPv6, that control may be forgone altogether. That's the main privacy issue, I am sure you agree to that.
--
Our ISP here has had press coverage for its IPv6 roll-out (happening right now). They provide customers with network identifier blocks and the ability to change the identifier by click/periodically. I doubt that many ISPs will take that effort (see bug report).
That overall made me conclude for myself Arch turning on those options to "2" by default is the KISS option available at this time.
Offline
Let's wait for some developer to make an illuminating statement about this topic
I'm not expecting a dev to be reading this thread; I'm just hoping to get some opinions from other users.
a1) Security: Let's say the service running on port 631 becomes vulnerable. With a typical setup of a client-PC the IPv4 will be different next reboot/lease (vector is lost; not even taking NAT into account). With a non-temp IPv6 the vector re-appears each time the box is turned on.
True, but the root problem is still there. Security by Obscurity, isn't. This is confusing Security with Privacy again though.
a2) Privacy: I fully agree, with one addition: Apart from some 'esoteric' ad-tracking techniques, the typical end-user has control over the cookies et al. With the user using a default unique IPv6, that control may be forgone altogether. That's the main privacy issue, I am sure you agree to that.
I do not argue the potential privacy issues around the topic; I do argue whether it should be a default.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline