Subject: Re: I-D Action: draft-fgont-6man-rfc4941bis-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2018 08:11:38 +1300

This clean-up is a good idea, but I see one hiccup:

>  6. Temporary addresses are *not* disabled by default.

Specifically, this text was removed:

> Consequently, the use of temporary addresses SHOULD be disabled by	
> default in order to minimize potential disruptions.

My concern is that the disruptions ("some applications may not behave
robustly if temporary addresses are used") haven't gone away, and the
cause may be very hard for ordinary users to diagnose. In fact, I
think some of the cases of help desks advising users to switch off
IPv6 derive from recently shipped operating systems that enable
temporary addresses by default. I've disabled them on a couple of
Windows 10 laptops for this reason.

This text was also removed:

> Individual 		
> applications, which have specific knowledge about the normal duration	
> of connections, MAY override this as appropriate.

That was optimistic. Individual applications (in the cases that I saw,
SMTP and IMAP or POP3) can't guess that a particular service provider
regards frequently changing /128s as suspicious. And anyway, does anyone
know of an application that overrides the source address selection
algorithm in this way?

I realise that we want to encourage privacy by default, so this is
a dilemma. I don't know what the answer is.

Regards
   Brian

On 26/03/2018 16:47, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Privacy Extensions for Stateless Address Autoconfiguration in IPv6
>         Authors         : Fernando Gont
>                           Suresh Krishnan
>                           Thomas Narten
>                           Richard Draves
> 	Filename        : draft-fgont-6man-rfc4941bis-01.txt
> 	Pages           : 20
> 	Date            : 2018-03-25
> 
> Abstract:
>    Nodes use IPv6 stateless address autoconfiguration to generate
>    addresses using a combination of locally available information and
>    information advertised by routers.  Addresses are formed by combining
>    network prefixes with an interface identifier.  This document
>    describes an extension that causes nodes to generate global scope
>    addresses from interface identifiers that change over time.  Changing
>    the interface identifier (and the global scope addresses generated
>    from it) over time makes it more difficult for eavesdroppers and
>    other information collectors to identify when different addresses
>    used in different transactions actually correspond to the same node.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-fgont-6man-rfc4941bis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-fgont-6man-rfc4941bis-01
> https://datatracker.ietf.org/doc/html/draft-fgont-6man-rfc4941bis-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-fgont-6man-rfc4941bis-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 26 Mar 2018 22:14:19 +0000

> On 26 Mar 2018, at 20:11, Brian E Carpenter <[email-masked]> wrote:
> 

Through what impact of using privacy addresses?  What are the problematic applications?

> a dilemma. I don't know what the answer is.

RFC 6724 says prefer privacy addresses; has that recommendation changed?

Tim

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2018 11:52:38 +1300

> Through what impact of using privacy addresses?  What are the problematic applications?

I don't know what the 4941 authors were thinking of. The example
I've seen is mentioned below: a service that considers frequent
changes of IP address to be a sign of illicit activity.

(Remember, my concern is only about the default configuration
and the resulting puzzlement of ordinary users and help desks.)
 
> RFC 6724 says prefer privacy addresses; has that recommendation changed?

Not that I'm aware of. The problem is that it's inconvenient, to say
the least, when a service objects to frequent changes of client address.

(https://tools.ietf.org/html/rfc8273#section-7 might induce the
same problem for services that already tolerate changing addresses
within a given /64.)

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2018 09:11:27 +0100

Hello, Brian,

As always, thanks so much for your great feedback! COmments in-line...

On 03/26/2018 08:11 PM, Brian E Carpenter wrote:
> cause may be very hard for ordinary users to diagnose.

How about changing this text from Section 6:

   An implementation might want to keep track of which addresses are
   being used by upper layers so as to be able to remove a deprecated
   temporary address from internal data structures once no upper layer
   protocols are using it (but not before).  This is in contrast to
   current approaches where addresses are removed from an interface when
   they become invalid [RFC4862], independent of whether or not upper
   layer protocols are still using them.  For TCP connections, such
   information is available in control blocks.  For UDP-based
   applications, it may be the case that only the applications have
   knowledge about what addresses are actually in use.  Consequently, an
   implementation generally will need to use heuristics in deciding when
   an address is no longer in use.

to a SHOULD?

> In fact, I

FWIW, this has been the whole point of:
draft-gont-6man-address-usage-recommendations

> a dilemma. I don't know what the answer is.

If we want privacy, then that should be the default. That said,
applications/nodes should be given guidance and mechanisms to better
leverage IPv6 addresses. BUt that would be out of the scope of this
document, I think (it's a way broader problem).

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2018 09:15:01 +0100

On 03/26/2018 11:14 PM, Tim Chown wrote:
[...
> RFC 6724 says prefer privacy addresses; has that recommendation changed?

(me thinking out loud): "preferred, if configured". But RFC4941 disabled
(by default) configuration of privacy addresses...

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2018 09:35:28 +0100

On 03/26/2018 11:52 PM, Brian E Carpenter wrote:
> I don't know what the 4941 authors were thinking of. 

I guess they were referring to long-lived connections?

> The example

This is tricky already, anyway. With happy-eyeballs sort of behavior,
this can already happen (one connection happens over v4, and a
subsequent happens over v6).

I do believe that, for all such cases, giving apps more control (and
awareness!) regarding v6 addressing and what they can do about it is
needed. But that would be out of cope for this particular document, I think.

That said, we could add a comment about this issue in this document.
Thoughts?

> and the resulting puzzlement of ordinary users and help desks.)

Another part of the problem here is that you cannot hint the network
about what to do. e.g., see draft-gont-6man-managing-slaac-policy

Thanks!

Cheers,

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Mar 2018 13:32:09 -0400

> draft-gont-6man-address-usage-recommendations

I think that we need to extend the IPv6 APIs so that applications
can either request stable addresses or demand a new privacy address.

It probably needs to be settable on a per-socket, per-process,
and per-process(group) basis.

    > document, I think (it's a way broader problem).

I think that we have quite a number of things that merit a revision
to the IPv6 socket API.    I don't know to get this work funded.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2018 08:10:28 +1300

> can either request stable addresses or demand a new privacy address.

Yes. But unfortunately that's outside the scope of the IETF, since we gave
away that API many years ago. I guess we could write a draft and find out
how to get it into the POSIX process.

> to the IPv6 socket API.    I don't know to get this work funded.

That's a very complicated thing... not just POSIX, but every o/s,
and every language with a socket library, needs to be on board.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2018 08:40:05 +1300

> I guess they were referring to long-lived connections?

Probably. What I'm complaining about is services that have some
sort of reputation system based on individual /128s. Temporary
addresses do create a behaviour pattern that doesn't exist for
IPv4 clients.

> That said, we could add a comment about this issue in this document.

Yes, an explanation of this side-effect issue would help. Also perhaps,
replace the old "off by default" text by a requirement that it must be
easy for the user to disable temporary addresses if they cause problems.
IMHO, netsh interface ipv6 set privacy state=disabled store=persistent
doesn't count as "easy" for a normal user.

There are real scenarios where "on by default" can be a problem.
Here are some fragments of the real world:
http://kb.tableau.com/articles/Issue/identifying-and-disabling-temporary-ipv6-addresses
https://lonesysadmin.net/2018/01/23/disable-windows-ipv6-temporary-addresses/

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 28 Mar 2018 10:31:30 +0200 (CEST)

> to the IPv6 socket API.    I don't know to get this work funded.

There is work going on regarding other areas of APIs in NEAT and TAPS 
regarding this, it should be included there.

https://www.neat-project.org/category/standardisation/
https://datatracker.ietf.org/wg/taps/

So for instance:

https://datatracker.ietf.org/doc/draft-dreibholz-taps-neat-socketapi/

With work around PVD awareness etc, making sure that this requirement is 
met should be not a major undertaking (if it's not there already).

I have been advocating work into this area for years, trying to gather 
interested parties. There has been progress and things are looking up.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Thu, 29 Mar 2018 11:23:11 +0000

> On 27 Mar 2018, at 20:40, Brian E Carpenter <[email-masked]> wrote:
> 

The current 6434-bis says

"RFC 4941 SHOULD be supported.  In some scenarios, such as dedicated
   servers in a data center, it provides limited or no benefit, or may
   complicate network management.  Thus devices implementing this
   specification MUST provide a way for the end user to explicitly
   enable or disable the use of such temporary addresses."

Is that the sort of wording you'd like?

(https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-08#page-15)

> http://kb.tableau.com/articles/Issue/identifying-and-disabling-temporary-ipv6-addresses

This one seems largely about using (or not) privacy addresses for servers?

> https://lonesysadmin.net/2018/01/23/disable-windows-ipv6-temporary-addresses/

This is a more pragmatic one, where today ACLs may allow a specific admin's workstation IP access somewhere.
Maybe that's a case for RFC8273, with the ACL on the /64 prefix?  Though if it is an administratively configured system, disabling RFC 4941 should be pretty easy.
Or there are certificate-based solutions, etc.

In general, I agree with Mikael's comment on TAPS, where I think Fernando already has a draft on this topic.

Tim

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Mar 2018 08:25:06 -0400

> how to get it into the POSIX process.

I knew that POSIX adopted it, but I didn't know that we gave up editorial
control.

    > and every language with a socket library, needs to be on board.

Yes, it is. And compliance to the existing API is sketchy in a number of
places.  But I think that we will continue to play stupid L2 and L3 tricks
because we haven't give applications a way to do it right.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Mar 2018 01:20:32 +0100

> how to get it into the POSIX process.

I think there's a difference between an abstract API (that is certainly
within the scope of the IETF), and a concrete API (say, for different
OSes or languages), which are not.

> and every language with a socket library, needs to be on board.

Not really.

What we need to specify is an abstract API which essentially models how
things should work, what types of operations are expected to be
supported (and the associated parameters), etc. *That* abstract API
*then* needs to be mapped into actual implementations -- that's the
complex part you are referring to, which, to a large extent, it's
outside of our scope.

I'd say that, at the very least we should do our work on the abstract API.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Mar 2018 01:07:01 +0100

> and per-process(group) basis.

That was the basis for submitting and presenting
draft-gont-6man-address-usage-recommendations.

I personally believed that, at the very least, the problem statement
belonged here. IMHO, for instance, the API for an app to request
generation of a new address belongs here and not elsewhere.

> to the IPv6 socket API.    I don't know to get this work funded.

started, you meant?

While there's very likely work to be done wrt th sockets API, there also
seems to be work to do to extend the sockets API and other work that
might be even orthogonal.

But probably the first step is to agree on what the problem is, and what
needs t be improved/changed/added.

draft-gont-6man-address-usage-recommendations was/is meant for that.

Comments welcome :-)

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Mar 2018 03:49:20 +0100

Hi, Brian,

> addresses do create a behaviour pattern that doesn't exist for

What kind of reputation system?

For things that do some sort of "authentication" based on the address,
with RFC4941 the address will not change *that* often for such stuff to
fail... (e.g., the old "POP before SMTP" that some ISPs/email providers
used to do).

> doesn't count as "easy" for a normal user.

That's kind of "tricky" .. a console-based system will not be able to do
much beyond that....

For Windows systems, one might expect that the setting is implied by the
"network type" profile that is selected (say "local/trusted",
"untrusted", etc.)

> https://lonesysadmin.net/2018/01/23/disable-windows-ipv6-temporary-addresses/

[off-line now, but will check when back online]

In any case, there are scenarios like Enterprise where disabling
Temporary addresses is usual.

I'm no discussing any of those: My take con rfc4941bis is that, absent
anything else, a node implementing rfc4941 should enable generation of
temporary addresses y default -- we simply cannot expect the user to
manually enable them.

Thanks!

Cheers,

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Mar 2018 11:03:34 -0400

> Comments welcome :-)

There are some extra words in the abstract that need to be sorted.
I like that you will cover "popular scenarios", but I couldn't find
any mention of the Royals or Justin Timberlake :-)

   Typically, when it comes to attack exposure, the longer an address is
   employed the longer an attacker is exposed to attacks (e.g. an
   attacker has more time to find the address in the first place
   [RFC7707]).

I'm really uncomfortable that temporary addresses are being considered a
security (by obscurity) measure.

While at IETF, I was, for instance, dealing with some RBL list does not like
that the address of my outgoing SMTP server is a SLAAC. At least, that's
seems to have been one complaint.  I only use that relay when travelling.

Not all outgoing connections are ephermeral.
Not all incoming connections need to be stable: RTP end points would
benefit from temporary addresses.

I would prefer a different set of terms.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 29 Mar 2018 08:05:41 -0700

> fail... (e.g., the old "POP before SMTP" that some ISPs/email providers
Fernando,

I'm not following this.

The argument seems to be that some services requires addresses to be
persistent for individual clients across connections. But, these
applications already to work in presence of multi-homing, NAT, and
other reasons for address change-- so presumably they have some
unspecified tolerance for address change. On the other hand, the point
of changing addresses like in RFC4941 is to promote privacy, and it's
initutive that the greater the frequency different addresses are used,
the stronger the privacy benefit (maximum benefit comes from use a
different address per connection). I don't see how to rectify these
two points to provide actionable quantifiable guidance to users when
they ask how often they should change addresses.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Mar 2018 16:51:04 +0100

Hello, Michael,

> security (by obscurity) measure.

Well, you cannot attack what you don't see (lots of animals emply the
same technique, for instance). That doesn't mean you should stop there.

> that the address of my outgoing SMTP server is a SLAAC. 

You mean "temporary"? -- Because you cannot really tell how an address
has been configured (see e.g. RFC7217).

DIdn't the above atually have to do with having no reverse mappings for
the aforementioned IPv6 address?

> Not all outgoing connections are ephermeral.

What do you mean?

> benefit from temporary addresses.

Did you mean "long lived"?  -- If so, of curse I agree.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Mar 2018 16:56:44 +0100

Hello, Tom,

On 03/29/2018 04:05 PM, Tom Herbert wrote:
> persistent for individual clients across connections. 

Yes, that's what I meant with the "pop3 before smtp" example.

> But, these

Not sure what you are suggesting.

If what you are suggesting is that there's some advice missing regarding
"how often to change IPv6 addresses", then that's what
draft-gont-6man-address-usage-recommendations-04 is about.

RFC4941 just contains some default settings when your system is flying
blind, because it has not idea of the requirements of the app employing
the addresses.

Thanks!

Cheers,

---

From: Tom Herbert <[email-masked]>
Date: Thu, 29 Mar 2018 09:59:37 -0700

> draft-gont-6man-address-usage-recommendations-04 is about.
Hi Fernando,

I may be missing it, but I don't see in the draft where it directly
answers the question: "How often (literally what frequency) must IPv6
addresses be changed to ensure privacy?".  And if there are
applications that don't tolerate address change across connections,
then what are the exact requirements for dealing rectify the frequency
of change they can tolerate with the frequency needed for privacy?

The common problem with nearly any discussion on privacy and
addressing is that the effects of proposed guidance are seemingly
never quantified. Statements like "The longer an address is employed
(i.e., the more stable it is), the longer such correlation will be
possible." are intuitively true, but they're not quantifiable
statements from which we can elicit any actionable guidance. For
instance, it's reasonable to assume that an address that is persistent
for 12 hrs. is less of privacy risk than one persistent for 24 hrs.
But _how_much_better_ is this privacy benefit to the user? Is the
probability that a users privacy being compromised with a 12 hr.
address 50% of the probability of a 24 hr. address? Probably not!
Unfortunately, there is no means to quantify the privacy to address
persistence relationship except in the case that a different address
is used per connection.

Another problem with much of the guidance is that recommendations may
only be useful for a given point of time. For instance, RFC4941
recommends the default address change to be one hour. Even if that
provided good guidance ten years ago, it is almost certainly not
reasonable today. The capabilities of attackers and data collection
has increased substantially so that they don't need nearly that much
time to do their work. In fact, we proposed a simple exploit in
draft-herbert-ipv6-prefix-address-privacy which would defeat any
frequency of address change to provide privacy except when a different
address is used per connection.

> blind, because it has not idea of the requirements of the app employing
Please look draft-herbert-ipv6-prefix-address-privacy. This deals with
the privacy implications off address particular the problems of of
assigning persistent prefixes to host devices (just changing IIDs is
not sufficient for privacy).

Side note: I think your statements about APIs being so rigid that we
couldn't make necessary changes to ensure user privacy might be overly
pessimistic. APIs are not written in stone and we can change them over
time. Also, there's a lot that can be done even without API changes.
For instance, if we are able to give the stack a pool of one-use
addresses, it would be particularly difficult to change address
binding for client communications to select from that pool. This
wouldn't effect applications that do explicit address binding, and for
the SMPT, POP3 these could opt-out (maybe by an environment variable).

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Mar 2018 09:05:12 +1300

> OSes or languages), which are not.

True. But in real life, we aren't going to revolutionize the basic design
of the IPv6 socket API, so any new abstractions have to be mappable into
the POSIX model.

> I'd say that, at the very least we should do our work on the abstract API.

I'm not saying that would be a bad idea, but it's a big project if you
want to abstract everything already covered by POSIX plus missing and
new features.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Mar 2018 09:16:46 +1300

On 30/03/2018 05:59, Tom Herbert wrote:
>>> unspecified tolerance for address change. 

Exactly, it's the *unspecified* heuristic that creates a problem for
$NORMALUSER. NAT44 being the norm, heuristics understand that. IPv6
not yet being the norm, still less temporary addresses, the heuristics
may barf. (/64 per host, or temporary /64s, being even less the norm,
the heuristics will have trouble there too.)

>>> On the other hand, the point

Exactly.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Mar 2018 09:20:06 +1300

On 30/03/2018 00:23, Tim Chown wrote:
<snip>

> Is that the sort of wording you'd like?

Yes, except that IMHO it also applies to end systems, not just servers,
for the reasons discussed on this thread. *Anybody* may need to sacrifice
a bit of privacy for address stability (and Cambridge Analytica won't even
notice the difference).

   Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 29 Mar 2018 21:30:22 +0000

> On 29 Mar 2018, at 21:20, Brian E Carpenter <[email-masked]> wrote:
> 

:)

The above text is for all hosts; the example is separate from the MUST in the last sentence.

Tim

---

From: Tom Herbert <[email-masked]>
Date: Thu, 29 Mar 2018 14:43:28 -0700

> a bit of privacy for address stability (and Cambridge Analytica won't even

Cambridge Analytica probably wouldn't notice an improvement in privacy
in addressing, but apparently ICE would ;-)

https://theintercept.com/2018/03/26/facebook-data-ice-immigration/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Mar 2018 11:00:49 +1300

> https://theintercept.com/2018/03/26/facebook-data-ice-immigration/

Interesting, but I suppose that a /64 would be of the same value as
an IPv4 /32 in locating a person as behind a specific CE box. However,
this is exactly the reason for changing the default behaviour in 4941bis.
It's the unintended side effects of changing the default that bother me.

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Thu, 29 Mar 2018 15:29:12 -0700

> It's the unintended side effects of changing the default that bother me.
In the record from FB it showed serveral logins from the "suspect"
that used the same IPv6 address. The record also identifies the
individual user. So if the "authorities" intercept traffic somewhere
in the Internet, they are now able to identify and track the users
activities to completely unrelated sites. Also worrisome, is that the
address might encode physical location of the user which may have also
been exploited. The article mentions that the addresses were
correlated with TMobile records, but I'm not really sure why they
needed that. The record from FB already contains personally
identifying information and mostly persistent address of the target
needed to track the target's activities on the Internet. I guess they
did that to get phone numbers and maybe more accurate location.

In any case the exploitation of IP addresses to track individuals
demonstrated in this use case is worrisome and underscores why
discussion on privacy in addressing is important (without giving any
opinion whether the tracking was justified).

Tom

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Mar 2018 19:35:52 -0400

> What do you mean?

SMTP connections are an example.  They are outgoing.
The sending system has some significant investiment (reputation: whether via
RBL or SPF records) in the originating address. Picking a new one regularly
is detrimental.

    > Did you mean "long lived"?  -- If so, of curse I agree.

Perhaps I mean long-lived addresses.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Fernando Gont <[email-masked]>
Date: Fri, 30 Mar 2018 23:39:31 +0100

> RBL or SPF records) in the originating address. Picking a new one regularly

You can advertise prefixes in SPF. No need to advertise a single address.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 31 Mar 2018 00:02:52 +0100

>> On Thu, Mar 29, 2018 at 8:56 AM, Fernando Gont <[email-masked]> wrote:
[....]
>> of change they can tolerate with the frequency needed for privacy?

Either you have an appropriate API, or you don't.

We currently have a lot of addressing capabilities, but apps fly blind.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 31 Mar 2018 00:35:31 +0100

On 03/29/2018 05:59 PM, Tom Herbert wrote:
> addresses be changed to ensure privacy?".

There's no answer for such question.  Network activity can be correlated
as long as you  reuse the same address. So, if you want no correlation
at all (to the extent of RFC4941), then you'd never reuse an IPv6
address. Again see
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04

>  And if there are

As noted in draft-gont-6man-address-usage-recommendations-04, we need
appropriate APIs to fully leverage IPv6 addressing. At the very least,
for apps to be able to specify desired addressing properties such as
"stability".

> statements from which we can elicit any actionable guidance.

What kind of quantification would you expect?

> For

"It depends" (of course). What else is the system doing? Simultaneously?
etc.

> address 50% of the probability of a 24 hr. address? Probably not!

That depends on so many factors (apps being employed, activities taing
place, etc., etc., etc.) which, IMO, if you expect to get any sort of
"quantifier", it will be meaningless.

> reasonable today.

rfc4941bis is essentially an improvement of RFC4941bis (addressing known
issues that are within the scope of RFC4941, and incorporate errata).
What you want can't be addressed in rfc4941bis.

draft-gont-6man-address-usage-recommendations-04 tries to elaborate on
the problem statement.

> The capabilities of attackers and data collection

I'll take a look at your I-D.

> not sufficient for privacy).

I'll certainly take a look.

That said: topologically-dependent information will certainly identify
the node.

There's nothing you can do in terms of privacy when your upper node
controls how you get your addresses (whether that's because you are
leased addresses with DHCPV6, or whether because you are given a unique
prefix).

> pessimistic.

I'm not saying they are rigid. THey are just *extremely basic* for the
addressing capabilities of IPv6.

>  APIs are not written in stone and we can change them over

Doing that is just guesswork on other side (a different rehash of the
guesswork in rfc4941). We should let app specify their requirements
regarding IPv6 addressing. *They* know better.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 31 Mar 2018 00:49:26 +0100

HI, Brian,

(added Dave Thaler to CC)

> of the IPv6 socket API, so any new abstractions have to be mappable into

Not sure. But, again, I think a first step is to have a problem
statement, and a second is to have requirements. Third would be an
abstract api that achieves those requirements. And from there 8or while
there), one could think possible implementation approaches.

> want to abstract everything already covered by POSIX plus missing and

It's probably big. But at this point we have all this bunch of addresses
of different kinds (scopes, stability properties, etc.), and, as is, we
cannot leverage them -- or even worse, it may lead to problems.

So, we have all these potentially useful things with almost no interface
to use them...

---

From: Tom Herbert <[email-masked]>
Date: Fri, 30 Mar 2018 17:35:17 -0700

> https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04
Right, single use addresses are the one case that could reasonably
claim to provide any quantifiable level of privacy.

> for apps to be able to specify desired addressing properties such as
Maybe, but then this pushes the impetus to the applications to
understand the ramifications on privacy when presented with choices.

> What kind of quantification would you expect?
Well, for instance, in security the strength of crytosystem can be
measured but the computational effort needed to break keys. I wish
there were equivalent metrics for privacy. We aren't going to find
something like that here, but we should be able to define what
quantifiable strong privacy in addressing would be (section 5 of
draft-herbert-ipv6-prefix-address-privacy-00). As pointed out in that
draft, NAT can meet those criteria for strong privacy so that might at
least provide a baseline for comparison.

> "quantifier", it will be meaningless.
Right, so we're just left with providing unquantified "soft" guidance
to users for which privacy might be a critical concern.

> That said: topologically-dependent information will certainly identify
Yes, that is why we need identifier/locator split. Other than a
provider prefix, addresses wouldn't contain any topological
information.

> leased addresses with DHCPV6, or whether because you are given a unique
Right, the privacy problem needs to be addressed in the network.
RFC4941 acknowledged this, but somehow addresses created per that RFC
came to be known as "privacy addresses".

> addressing capabilities of IPv6.

It would be interesting to see a proposed API.

> regarding IPv6 addressing. *They* know better.

I'm not convinced of that given recent revelations for some major
applications concerning privacy and addressing.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Sat, 31 Mar 2018 00:57:05 +0100

On 03/29/2018 12:23 PM, Tim Chown wrote:
[....]
> Is that the sort of wording you'd like?

Well, this talks about *support* of RFC4941. There's still the question
of whether such support should be enabled by default or not?

> Maybe that's a case for RFC8273, with the ACL on the /64 prefix?

Or just RFC7217.

>  Though if it is an administratively configured system, disabling RFC 4941 should be pretty easy.

FWIW, what we posted on TAPS is essentially some flavor of
draft-gont-6man-address-usage-recommendations

Thanks!

Cheers,