Subject: Re: Feedback on draft-herbert-ipv6-prefix-address-privacy-00

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Jun 2018 08:33:22 -0700

On Thu, May 31, 2018 at 2:54 AM, Fernando Gont <[email-masked]> wrote:
> Hello, Tom,
>
> Here's my feedback on this I-D:
>
Hi Fernando, thanks for the contents.

Your comments are mostly directed at the solution and not the problem.
Does this mean you acknowledge that privacy in prefix address
assignment is a potential privacy problem in the Internet?

> * As far as I understand, this scheme relies on the network playing
> "good guy" for you. I don't think that's a fair assumption. IN fact, if
> you aim at privacy, you should assume the network to be evil. (Your ISP
> itself might be the guys interested in tracking you, or cooperating with
> the folks willing to track you).
>
Some level of trust is required with any service provider or carrier.
Most providers have policies for disclosure of information that are
either regulated or in contractual obligations. But, this trust should
only extend to the users' local network provider, not everyone on the
Internet. For instance, if I log in to my favorite social app then I
don't want the content provider to log the IP address and and identity
and later allow someone else to use the information to track my
activities on the Internet. Today, this is quite possible and does
happen as described on the "always on" app problem. Untrackable
single-use addresses would eliminate this attack vector.

> * I don't think you can realistically expect to have, say, ISPs include
> state in the network just for this. I think the best you can expect
> (from a privacy perspective), is that each time you detach/reatach you
> get a different prefix (although giving you the same prefix might ake
> things easier for them wrt law enforcement). Then, you'd detach/reattach
> when you expect such prefix to change. -- but anyway, the high order bit
> is the previous bullet: you cannot really expect this to happen.
>
To a large extent, they already maintain this sort of state when they
use CGNAT or run proxies. As the draft points out CGNAT can provide
strong privacy. Privacy may be an unintended side effect, but
nevertheless it can provide essentially untrackable single-use
addresses in the Internet. I am hoping we an get a better solution
than NAT that leverages the large address space of IPv6.

> * No matter what you do with the prefix or IID, I wouldn't call it any
> of this (nor RFC4941 OR rfc7217, for instance) "strong privacy"). It
> just eliminates a very obvious and simple tracking7correlation vector.
>
Right, eliminating a "a very obvious and simple tracking correlation
vector" is precisely the point of this draft. RFC4941 endeavours to do
that also. The difference is that here we are quantifying the privacy
effects of the mechanism. In order to quantify privacy in addressing,
we need a definition and measure of privacy in addressing. Section 5
of the draft lists the proposed criteria for "strong privacy" in
addressing. Please look at these criteria and whether they are
sufficient.

>
> * As long as SLAAC is concerned, a prefix is announced, and you have to
> come upwith an IID to form an address. In that sense, no matter what you
> do with the prefix, you still have to come up with an IID... so what you
> do with the prefix is orthogonal with what you do with the IID (RFC7217,
> RFC4941, o whatever) -- unless you propose to modify SLAAC for the
> network to pic the addresses for nodes... but that wouldn't be SLAAC
> (particularly wouldn't be "autoconfiguration").

Section 6 describes identifier/locator solution. In some sense DHCPv6
works better for privacy since the network can provide pseudo random
addresses within its block to a node. That obviously doesn't scale. It
would be desirable to get a solution that allows hosts to generate
addresses themselves that to the outside world can't be correlated,
but the local network is able to aggregate as belonging to the same
host-- this is the concept of hidden aggregation.

>
>
> Specific comments:
>
>
> Intro, page 3:
>
>>    A common address assignment method is for a network to assign
>>    prefixes to devices. SLAAC and DHCP-PD are two mechanisms for doing
>>    this.
>
> While there has been an RFC on the topic, I wouldn't say SLAAC is a
> mechanism to "assign  prefixes to devices".

Okay, will reword.

>
>
>> While significant effort has gone into IID
>>    generation techniques to protect privacy ([RFC4941], [RFC7721])
>
> Probably s/7721/7217/
>
ack

>
> Section 3.1:
>>
>> 3.1 SLAAC and DHCPv6-PD
>>
>>    SLAAC [RFC4862] and DHCPv6-PD [RFC3633] are mechanisms to assign
>>    network prefixes to devices. Their respective specifications do not
>>    address privacy issues of prefix assignment. Security considerations
>>    are focused on the mechanisms.
>
> I don't think that portrays SLAAC well. In fact, as long as current
> specs are concerned, SLAAC doesn't assign prefixes.

Yes, will reword that.

>
>
> Page 10:
>> 6.1 Overview
>
> The terminology here is confusing: an address is a
> topologically-dependent identifier -- so it still is an identifier 8just
> one of a special kind).

Addresses are not necessarily topological. They are identifiers for
communication endpoints. For instance virtual addresses typically
don't carry any topological information for a network underlay.

This brings up a seconardary issue that can be addressed by strong
privacy in addressing: network and datacenter operators typically do
not want to encode their internal network topology in addresses
exposed on the the Internet for privacy and security reasons.
Externally visible addresses will rarely be simple topological
addresses within the provider, instead they obfuscate the internal
network topology in some fashion (by NAT, proxy, virtualization,
tunneling, identifier/locator, anycast, etc).

Tom

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

---

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Jun 2018 11:44:09 -0700

On Mon, Jun 4, 2018 at 10:16 AM, Fernando Gont <[email-masked]> wrote:
> On 06/04/2018 06:33 PM, Tom Herbert wrote:
> Anything that reveals some sort of information has implications on privacy.
>
> An address reveals information about the position of a node in the graph
> of a network. It is meant for that. Otherwise, it's not a address.
>
> Might that represent an issue? - Yes.
> Does host have control about it? - No
> May I use an address without disclosing topology information? - No,
> unless someone else is masquerading you or acting as an intermediary (ni
> which case, you leak your info to that other party)
>
>
> The only way in which an address doesn't leak topology information is:
> 1) If you have a flat address space (then you an call your address
> simply "an id"), and you don't do something silly such as reusing
> globally-unique ids.
> 2) Not having an address
>
>
> >From this perspective, from an IP perspective, if this is an issue, it
> is an issue that cannot be solved.
>
>
>
> Either the network is evil, or it is not. If you are concerned about
> privacy, then you don't trust the network.
>
> (This is similar to the recent advocation of free/open resolvers as
> "privacy wise": somehow, for magic reasons, private companies are deemed
> as less evil as ISPs. But if you are coming from a privacy perspective,
> one should deem all of them as evil -- when in fact, unless you do it
> yourself, you're simply deciding what's the (potentially evil)
> organization that you'll leak your information to).
>
>
>
>> either regulated or in contractual obligations.
>
> If the network/isps are evil, why would you expect them to comply with
> anything?
>
> I mean, it is perfectly fine to provide a recommendation along the lines
> of "hey, try to randomize prefixes, because..." (bcp, or whatever). But
> *relying* on that cannot be an option.
>
>
>
>> But, this trust should
> Agreed. But there are operational implications of that, of course.
>
> As noted before, rfc4941bis fixes known issues in RFC4941, which are
> within the scope of RFC4941. RFC4941 can operate without knowledge of
> the application. -- this is obviously a tradeoff.
>
> In order to improve things further, you need to give apps more control
> wrt how they use addresses. But this is out of the scope of RFC4941.
> (except that rfc4941bis could, indeed, note that an address can be
> regenerated when signaled by the upper ap, or be generated in response
> to an app... with details out of scope)
>
>
>
>
> Why should the solution be different?  Yes, I know NATs are
> "unpopular"... but my question remains.
>
>
>> vector" is precisely the point of this draft.
>
> It is fine to say, specify how this can be done. What I'm saying is
> that, from the pov of the host, you cannot rely on it. And, in any case,
> this is orthogonal to the generation of IIDs. They are related.. but
> different problems.
>
>
>
>> RFC4941 endeavours to do
> I did. If you don't want subnet info to leak, the you have to masquerade
> everything form the subnet (including it). Why wouldn't something like,
> say, NPT (with specific algorithms) be appropriate?

> I'm not saying that it wouldn't be sensible to explore the problem. But
> rather that it is a different problem of the selection of IIDs.
> Selection of IIDs is trivial to solve, and RFC4941 took a shot at it,
> albeit with some flaws. Randomizing prefixes is not such a simple
> problem, and what's more, it depends on a third party, rather than your
> own host.
>
Fernando,

I agree. Randomizing addresses (whole address needs to be considered)
is a hard problem. But, so is providing real privacy on the Internet.
I'm not convinced these are unsolvable problems though, and I think
privacy is an important problem that needs to be addressed.

Wrt, RFC4941bis, I think there should be more words about the effects
on privacy and potential limitations. The privacy goal of RFC4941 is:

"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 goal is good (preventing correlations between different addresses
is one of the criteria we listed), however the suggested effect of the
proposed solution is "makes it more difficult for eavesdroppers". What
does "more difficult" mean? That's unquantified and not normative.
This can be contrasted to a security document where the benefits of
security in increasing key length can be quantitatively described
(e.g. based on current computational capabilities how long would it
take to break the key). Similarly, it seems any recommendation to
increase frequency of address change for stronger privacy is based on
intuition more than any empirical data or protocol analysis. So
privacy provided by RFC4941 is really best effort. If someone cares
about privacy (say the political dissident criticizing their unjust
government) then privacy offered by RFC4941 wouldn't be sufficient. If
nothing else, I suggest adding a section to RFC4941bis that describes
the limitations wrt privacy.

Tom

> Of course, the address is tologically-significant within its own layer.
> So a virtual address depends on the topology of the virtual network.
>
> See e.g., https://tools.ietf.org/html/rfc1498
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks

---

From: Fernando Gont <[email-masked]>
Date: Mon, 4 Jun 2018 22:22:41 +0300

> privacy is an important problem that needs to be addressed.

An address, by definition, leaks information. If it doesn't, it's not an
address.

Selecting appropriate IIDs is a problem that it is easy fo solve,
because they do not need to leak information.

> used in different transactions actually correspond to the same node."

One could add more, or simply note that there's more to it, and point to
e.g. RFC7721.

> does "more difficult" mean? That's unquantified and not normative.

Requirements are here:
https://tools.ietf.org/html/draft-gont-6man-non-stable-iids-04

> take to break the key).

Which is an example that any such sort of quantification is deemed to be
absolete by the time you publish a document.

> Similarly, it seems any recommendation to
> intuition more than any empirical data or protocol analysis.

There's no experiment that is useful here.

Again: If the only thing an attacker wants is to correlate two different
network activities, as long that he's able to do that the rest doesn't
matter. (if you regenerate every second the attacker might still be able
to accomplish his goal)

This depends on so many aspects that are specific to each scenario, that
whatever experiment you make, it is not going to be representative or
applicable to toher scenarios.

> So privacy provided by RFC4941 is really best effort. If someone cares

I reiterate this: rfc4941bis is trying to address flaws in RFC4941,
which in turn mitigates the privacy-insensible approach of embedding
stable identifiers (e.g. stable & global scope mac address) in IIDs.

If you are a political dissident, then:

* you don't trust your network, and in fact use some network you don't
normally use
* You don't do multiple things at once, or in same session, or same
place, or whatever
* you use your device for this single purpose, and not anything else
* you use tor
* you probably use a sequence of VPSes
* and if what you are doing really matters, you probably destroy your
device right after you do what you do

RFC4941 simply mitigates the long hanging fruit. And again, operates
transparently to the application.