Re: Disabling temporary addresses by default?

[David Farmer <[e-mail]>]

On Wed, Jan 29, 2020 at 3:04 AM <[e-mail]> wrote:

> Lorenzo, et al,
>
> > Changing subject because many participants are likely to just ignore yet
> another "SLAAC vs DHCPv6" thread. :-)
> >
> > On Tue, Jan 28, 2020 at 11:27 PM <[e-mail]> wrote:
> > In the context of 4941bis last call, it might be prudent of us to
> revisit this change:
> >
> > https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-05#section-8
> > 6.  Temporary addresses are *not* disabled by default.
> >
> > Saying that temporary addresses should be disabled by default (assuming
> hosts actually do that) seems like a terrible privacy problem. It means
> that by default, a host that doesn't change prefix will use the same IPv6
> address to communicate with *everyone* on the internet until the end of
> time. That provides lots of opportunities for cross-site tracking, and the
> user can do very little to protect themselves because they don't have
> control over IP addressing like they do over higher-layer identifiers
> (e.g., users can clear cookies, or use different browser profiles or
> different browsers/apps for different sites).
>
> This seems like an exaggeration. Temporary addresses does not provide
> privacy. They provide a small piece of a much larger and complex puzzle.
> One which likely requires not technological solutions but regulatory ones.
>
> How efficient and useful that piece is compared to e.g. 7217 iids I have
> not seen any data on.
> If we don't have any data for the 4941 effectiveness, operational
> experience and implementation experience (ICE, MPTCP, applications), then
> all we can do here is to offer our anecdotal data. Although given your
> affiliation perhaps you could tell us how little or how much value
> temporary addresses have for tracking?
>
> > I don't think 4191bis should advance if it says that privacy addresses
> are disabled by default. It would be a strong statement by the IETF that we
> don't care about privacy of IP addresses and would be a terrible signal to
> send.
> >
> > Instead of disabling, why not change the default of the number of
> addresses maintained? For example, instead of maintaining 1 permanent + 1
> valid + 7 deprecated, why not just default to maintaining 1 permanent + 1
> valid + 1 deprecated. That means that applications would have to
> re-establish their connections once a day instead of once every 7 days. But
> if they use privacy addresses, they already need to re-establish
> connections after 7 days. And they can always use not to use privacy
> addresses via the appropriate socket option.
>
>
> The current (draft standard) text in 4941 is:
>    "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."
>
> I would like to understand the rationale for removing that text.
> Note, 4941bis in it's current form does not have an opinion regarding a
> default.
>

This is all about trade-offs, the use of temporary addresses by no means
guarantees privacy, there is no perfect privacy, it's not an absolute,
privacy is relative. Furthermore, the only way to provide perfect privacy
is to not communicate with anyone over the Internet or by any other means
for that matter. All communications risks interception,
information leakage, that compromise your privacy. We risk this
interception, information leakage and compromise of privacy, for the
rewards communications bring us.

That said, using the same address over an extended period of time (months
to years) is an obvious and unwarranted threat to privacy, in my opinion.
The use of temporary addresses helps prevent this, and while they are not
appropriate in all cases, neither is saying that that temporary addresses
should be disabled by default.

I think something like the following needs to be added to RFC4941bis;


While using the same address over an extended period of time (months to
years) is an obvious and unwarranted threat to privacy, in that it allows
for an easy correlation of a user to an address over this extended period
of time. However, this same correlation of user to an address, at least in
the short-term (hours to days), that this technique seeks to limit, is
frequently a necessary first step in most troubleshooting activities.
Therefore, changing temporary addresses too frequently will likely
exacerbate operational problems, frustrating attempts to correct them, and
in extreme cases could impact the operational stability of networks.
Furthermore, the successful troubleshooting of intermittent problems
occurring over a period of time (especially over several days) may require
a stable address and at least the short-term disabling of the use of
temporary addresses.

The choice of default timers in this document attempts to balance this
trade-off between privacy, the effective troubleshooting of problems, and
the operational stability of networks, all of which are in individual
users' and network operators' mutual interest.

Finally, changing temporary addresses at a high-frequency (minutes to
hours) will have operational impacts especially in troubleshooting as
discussed above. However, changing temporary addresses at these
high-frequencies will also likely impact network stability and host
performance due to the unreasonably high levels of neighbor discovery
traffic necessitated by such high-frequency changing of
temporary addresses, this is especially true when amplified by a large
number of hosts changing their temporary addresses at a high-frequency.


If I were to make any changes to the default timers in the document I would
shorten the TEMP_VALID_LIFETIME from 1 week to something like 2 or 2.5
days. I think TEMP_PREFERRED_LIFETIME of 1 day is a reasonable compromise
between privacy, the effective troubleshooting of problems, and the
operational stability of networks.

Thanks.
--
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================