Date: Wed, 14 Jun 2017 14:34:25 +0200 From: Mark Martinec <Mark.Martinec+freebsd@ijs.si> To: freebsd-net@freebsd.org Cc: Garrett Wollman <wollman@hergotha.csail.mit.edu>, Rui Paulo <rpaulo@me.com> Subject: Re: Enable IPv6 Privacy Extensions by default Message-ID: <a0a86938fb5d0f48ece16754e9e02685@ijs.si> In-Reply-To: <1497417261.2220.5.camel@me.com> References: <20170611215904.4612ee41@kalimero.tijl.coosemans.org> <D05BDD5A-F7ED-4DFE-8835-DE444A12C771@lists.zabbadoz.net> <20170612131912.42537b13@kalimero.tijl.coosemans.org> <1497408664.2220.3.camel@me.com> <201706140257.v5E2vRDE029173@hergotha.csail.mit.edu> <1497417261.2220.5.camel@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The temporary (i.e. "privacy addresses", RFC4941) address use is a no-no
for enterprise environments, which require address (user) accountability
and
stability. It is also inappropriate for servers. Add to this the
nightmare
of multicast caches overflowing in routers (as mentioned by others).
The common advocacy for temporary addresses is hiding the MAC address
and preventing location tracking for mobile computers. Both of these
problems are addresses/solved by "Stable, Semantically Opaque IIDs":
[RFC7217]
"A Method for Generating Semantically Opaque Interface Identifiers
with IPv6 Stateless Address Autoconfiguration (SLAAC)",
which retains the benefits of SLAAC, hides MAC addresses and ensures
the IID changes when a computer moves to another network - without
disadvantages of temporary ("privacy") addresses.
Please do not enable classical RFC 4941 temporary addresses by default!
I think it is a about time that FreeBSD makes it possible to configure
"Stable, semantically opaque" address with a simple rc.conf setting,
as some other™ operating systems have done by now!
The RFC 7721 (IPv6 Address Generation Privacy) summarizes the
"Stable, semantically opaque" address selection mechanism
as follows:
4.5. Stable, Semantically Opaque IIDs
[RFC7217] specifies an algorithm that generates, for each network
interface, a unique random IID per IPv6 link. The aforementioned
algorithm is employed not only for global unicast addresses, but also
for unique local unicast addresses and link-local unicast addresses
since these addresses may leak out via application protocols (e.g.,
IPv6 addresses embedded in email headers).
A host that stays connected to the same IPv6 link could therefore be
tracked at length, whereas a mobile host's activities could only be
correlated for the duration of each network connection. Location
tracking is not possible with these addresses. They also do not
allow device-specific exploitation or address-scanning attacks.
To repeat what I have recently written elsewhere:
| I wish FreeBSD would adopt the dhcpcd daemon from the NetBSD project
| (2-clause BSD license) as a standard DHCP client for IPv4 and IPv6,
| as some other OSes have done by now. It is currently available in
| FreeBSD ports as net/dhcpcd.
|
| Among other features it supports RFC 7217, i.e. stable privacy
address,
| which should be as easy to configure in FreeBSD as is now the
| (mostly undesirable) ipv6_privacy="YES", but is currently much
| too complicated for an average user.
Mark
2017-06-14 07:14, Rui Paulo wrote:
> On Tue, 2017-06-13 at 22:57 -0400, Garrett Wollman wrote:
>> In article <1497408664.2220.3.camel@me.com>, rpaulo@me.com writes:
>>
>> > I don't see any reason why we shouldn't have privacy addresses
>> > enabled
>> > by default. In fact, back in 2008 no one voiced their concerns.
>>
>> Back in 2008 most people hadn't had their networks fall over as a
>> result of MLD listener report implosions when a thousand machines
>> report (via multicast, natch) their eight[1] single-member
>> solicited-node multicast groups in the space of a few seconds.
>>
>> -GAWollman
>>
>> [1] Assuming the vendor actually implemented the thing correctly.
>> Some of us have seen what happens when one machine reports eight
>> hundred single-member solicited-node multicast groups in the space of
>> a few milliseconds.
>
> Pretty sure these problems have been addressed by now, given the amount
> of computers, smart phones, tablets, etc. running with privacy
> extensions enabled.
>
> If you still think this is a big problem, then FreeBSD could simply
> implement CGA .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a0a86938fb5d0f48ece16754e9e02685>