Subject: Adoption call for <draft-fgont-6man-rfc4941bis-01>

From: Ole Troan <[email-masked]>
Date: Wed, 30 May 2018 09:20:15 +0200

This message starts a two week 6MAN call on adopting:

    Title     : Privacy Extensions for Stateless Address Autoconfiguration in IPv6
    Authors   : F. Gont, S Krishnan, T. Narten, R. Draves
    Filename  : draft-fgont-6man-rfc4941bis-01
    Pages     : 19
    Date      : 2018-03-25

    https://datatracker.ietf.org/doc/draft-fgont-6man-rfc4941bis/ <https://datatracker.ietf.org/doc/draft-fgont-6man-rfc4941bis/>

as a working group item. Substantive comments and statements of support
for adopting this document should be directed to the mailing
list. Editorial suggestions can be sent to the authors.  This adoption
call will end on June 12th, 2018.

Could those who are willing to work on this document,
either as contributors, authors or reviewers please notify the list.
That gives us an indication of the energy level in the working group
to work on this.

Regards,
Bob and Ole

---

From: Peter Hessler <[email-masked]>
Date: Wed, 30 May 2018 14:19:46 +0200

Support adoption

On 2018 May 30 (Wed) at 09:20:15 +0200 (+0200), Ole Troan wrote:
:This message starts a two week 6MAN call on adopting:
:
:    Title     : Privacy Extensions for Stateless Address Autoconfiguration in IPv6
:    Authors   : F. Gont, S Krishnan, T. Narten, R. Draves
:    Filename  : draft-fgont-6man-rfc4941bis-01
:    Pages     : 19
:    Date      : 2018-03-25
:
:    https://datatracker.ietf.org/doc/draft-fgont-6man-rfc4941bis/ <https://datatracker.ietf.org/doc/draft-fgont-6man-rfc4941bis/>
:
:as a working group item. Substantive comments and statements of support
:for adopting this document should be directed to the mailing
:list. Editorial suggestions can be sent to the authors.  This adoption
:call will end on June 12th, 2018.
:
:Could those who are willing to work on this document,
:either as contributors, authors or reviewers please notify the list.
:That gives us an indication of the energy level in the working group
:to work on this.
:
:Regards,
:Bob and Ole
:

---

From: Mark Smith <[email-masked]>
Date: Thu, 31 May 2018 05:52:21 +1000

Hi,

I support adoption.

Regards,
Mark.

On 30 May 2018 at 17:20, Ole Troan <[email-masked]> wrote:

>     https://datatracker.ietf.org/doc/draft-fgont-6man-rfc4941bis/
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 30 May 2018 13:19:13 -0700

I wanted to note that we also asked:

"Could those who are willing to work on this document,
either as contributors, authors or reviewers please notify the list.
That gives us an indication of the energy level in the working group
to work on this."

We haven’t seen anyone respond to this yet.

Bob

> On May 30, 2018, at 12:52 PM, Mark Smith <[email-masked]> wrote:
> 
> Hi,
> 
> I support adoption.
> 
> Regards,
> Mark.
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 31 May 2018 06:31:54 +1000

Hi Bob,

I can be a reviewer and a possible contributor. Not sure I need to offer to
be an author, four should be enough?

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 May 2018 15:59:33 -0700

> We haven’t seen anyone respond to this yet.
Bob,

I would be interested in working on this, however I believe there is a
major issue in RFC4941 that needs to be addressed. This is alluded to
in the draft and RFC:

"Although it might appear that changing an address regularly in such
environments would be to lessen privacy concerns, it should be noted
that the network prefix portion of an address also serves as a
constant identifier."

Given that /64 prefix assignment is now common for mobile network such
that personal devices like phones are assigned prefixes, trying to
ensure privacy in the low sixty-four bits as suggested by RFC4941
would have little effect. If a per device prefix is used and is
persistent, the device (and hence user) are trackable in the Internet
regardless of what is done in the IID space. RFC4941 only mentions
this problem in passing, it doesn't attempt to address it.

I've written an I-D on this
(https://tools.ietf.org/html/draft-herbert-ipv6-prefix-address-privacy-00).
That might provide some input for RFC4941-bis for this issue.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 May 2018 11:19:59 +0300

Hi, Bob,

> We haven’t seen anyone respond to this yet.

Just curious: isn't the support of wg adoption somehow an implicit
agreement that folks are willing to work on the document by e.g.
reviewing it?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 May 2018 11:39:04 +0300

Tom,

On 05/31/2018 01:59 AM, Tom Herbert wrote:
> major issue in RFC4941 that needs to be addressed.

These two are orthogonal. That is, no matter what you do with prefixes,
host will still need to select an IID for temporary addresses. And this
is what this document is about.

In particular, RFC4941, with known flaws, is out there... and this bis
document addresses such issues.

> This is alluded to in the draft and RFC:
> 
> would have little effect.

Please see the above.

> If a per device prefix is used and is

The host can't do it. Since you don't control the prefix that is giving
to you, of course you are at the mercy of your ISP to "track you" based
on the prefix.

> That might provide some input for RFC4941-bis for this issue.

I will provide a review now. Apologies for not doing it before, since I
had promised I'd do it.

Thanks!

Cheers,

---

From: Tom Herbert <[email-masked]>
Date: Thu, 31 May 2018 09:23:36 -0700

On Thu, May 31, 2018 at 1:39 AM, Fernando Gont <[email-masked]> wrote:
>> major issue in RFC4941 that needs to be addrese sed.
>

Hi Fernando,

Actually, the document is about assigning temporary addresses for the
explicit purpose of providing privacy. "Privacy" is the first word in
the title and the RFC specifically raises tracking of user activities
by third parties (via identifiers) as a primary concern: "Any time the
same identifier is used in multiple contexts, it becomes possible for
that identifier to be used to correlate seemingly unrelated
activity.".

> document addresses such issues.

There are some other issues that you might want to consider.

RFC4941 suggests that temporary addresses provide privacy and should
be changed periodically so they aren't persistent. However, it doesn't
attempt to quantify the privacy that temporary addresses provide.
Neither does it quantify the correlation between frequency of address
regeneration and privacy afforded to the user. For instance, if
someone doubles the frequency of address regeneration in their system
does that mean that the chances of the their privacy being compromised
is halved? We don't really know. Also, the RFC recommends that are
addresses are regenerated with a default frequency of one day. Maybe
such a recommendation made sense eleven years ago when RFC4941 was
written, but I'm doubtful that makes sense today. Data collection in
the Internet and attackers have gotten far more sophisticated. For
instance, the prevalence of "always on" apps with a login that
reconnect after each address change means that third parties can
maintain a running log that associates specific users to IP address
(see http://www.complex.com/life/2018/03/ice-can-access-private-facebook-data-to-find-and-track-immigrants
for real world example).

In short, I think it's a fair question to ask what the tangible impact
of RFC4941 is on user privacy. I'm not sure there's a better answer
than something like "we don't precisely know since it's unmeasurable,
but believe that it is beneficial". Note that this can be contrasted
with CGNAT for which some law enforcement agencies at least has
provided clear feedback that it can provide strong user privacy.

Tom

---

From: Bob Hinden <[email-masked]>
Date: Thu, 31 May 2018 11:22:27 -0700

Fernando,

> On May 31, 2018, at 1:19 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Bob,
> 

I theory yes, but in practice, not so much  :-(

Bob

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Jun 2018 02:35:12 +0300

> that identifier to be used to correlate seemingly unrelated

The document title is "Privacy extensions for *SLAAC*", rather than "how
to make addresses perfect from a privacy pov. In SLAAC, routers
advertise prefixes, and host generates IIDs. Hence, the host only gets
to play with the IID. The prefix is managed by the network. And if you
care about privacy, you cannot really rely on the network.

> attempt to quantify the privacy that temporary addresses provide.

I don't think you can quantify privacy as such.

> regeneration and privacy afforded to the user. 

You can't, either. In fact, even if you could, it would be mostly
meaningless. The idea is simple: As long as you keep using the same
address, activities can be correlated. If you change addresses extremely
fast (say once every second), but still there are two activities that
are extremely important that happen during such 1 second, then they can
be correlated.

> For instance, if
> is halved? 

I don't even know what that would mean. As noted: no matter how fast you
change your addresses as long as you reuse such addresses, correlation
is possible. And in a sense, if you change your addresses very slowly
8or don't change them at all), but you simply not emit any packets,
there's no activity to be correlated.

> We don't really know. Also, the RFC recommends that are
> written, but I'm doubtful that makes sense today.

We may want to incorporate something along the lines of bullet 2 of
draft-gont-6man-non-stable-iids-04:

   2.  The lifetime of an address MUST be further reduced when privacy-
       meaningful events (such as a node attaching to a new network)
       takes place.

And provide a couple of examples regarding what might be considered
"privacy.meaningful events". In reality, as per the example I gave
above, the specific frequency doesn't really matter -- what matters, if
anything, is that you regenerate addresses at the point you want to stop
correlation with previous activities.

> Data collection in

The way to solve this is not by trying to come up with a specific magic
time value for regenerating privacy addresses, but by something alone
the lines of
draft-gont-taps-address-analysis/draft-gont-taps-sockets-api-limitations,
along with the specification of an IP that allows applications to
trigger address regeneration, "please generate an address to be used
only by my process", and the lie.

> but believe that it is beneficial".

I believe that something along the lines of RFC4941bis mitigates network
activity correlation based on IPv6 addresses, by limiting the amount of
time over which such correlation is possible, and by preventing
correlation of network activity that involves different prefixes.
This can be improved with a roper API that gives more control to
applications.

But clearly, I think it's impossible to come up with some sort of number
that tries to quantify this.

I wouldn't mind incorporating a sentence or two like the one you
suggested... also I'd say that such a thing would be sort of a better
fit for a RFC7721 kind of document...

> Note that this can be contrasted

Same agencies assume that if IPv6 is deployed (and assuming the
aforementioned assertion is valid), attackers will use IPv6 to perform
attacks, rather than the allegedly more-privacy-wise IPv4/CGNAT. --
attackers are usually smarter than that. :-)

Thanks!

Cheers,

---

From: Tom Herbert <[email-masked]>
Date: Thu, 31 May 2018 17:55:08 -0700

On Thu, May 31, 2018, 4:38 PM Fernando Gont <[email-masked]> wrote:

> > (see
> http://www.complex.com/life/2018/03/ice-can-access-private-facebook-data-to-find-and-track-immigrants
> > for real world example).
>

Fernando,

Yes, single use addresses are the solution (where the prefix is
sufficiently randomized). Using a single address per connection is the only
frequency of address use for which privacy in addressing can be qualified
and I believe shown to be strong. "Strong privacy" can be defined with
criteria like in section 5 of my draft (please take a look). As already
discussed, addresses assigned per RFC4941 wouldn't generally meet these
criteria.

Note that in NAT, each connection effectively can have a single use address
and if there is sufficient number of nodes behind a NAT the strong privacy
in addressing criteria can be met. So a solution is possible, but I am
hoping for a solution better than NAT that leverages the large address
space in IPv6.

Tom