Re: Address privacy (was: Re: RFC4941bis: consequences of many addresses for the network)

[Tom Herbert <[e-mail]>]

On Sat, Jan 25, 2020 at 11:57 AM Ca By <[e-mail]> wrote:
>
>
>
> On Sat, Jan 25, 2020 at 11:48 AM Tom Herbert <[e-mail]> wrote:
>>
>> On Sat, Jan 25, 2020 at 11:21 AM Michael Richardson
>> <[e-mail]> wrote:
>> >
>> >
>> > Ted Lemon <[e-mail]> wrote:
>> >     > Another solution that could be useful is to do connections through an
>> >     > anonymity concentrator that tunnels your flow to the selected server.
>> >     > The idea here is that your ISP (but it doesn’t have to be your ISP!)
>> >     > has a bunch of anonymity boxes sitting in their data centers, and when
>> >     > you want to connect to foo.com <http://foo.com/>, you establish a
>> >     > connection to the anonymity server.   The anonymity server constructs a
>> >     > new 5-tuple using its own fixed IP address.   This is effectively a NAT
>> >     > translation, and of course it can maintain a set of IP addresses large
>> >
>> > Except that instead of doing it at layer 4, you do it with IPsec, and extrude
>> > that /128 to your machine.  This is already a thing :-)
>> >
>> >     > Another solution I’ve considered is to have a giant anonymity mesh,
>> >     > with every ISP’s user participating, and forward flows through this
>> >     > mesh, treating each customer as an anonymity server.   I think this is
>> >
>> > This is also a thing called Tor.
>> >
>
>
> +1, dont re-invent Tor
>
>>
>> Michael,
>>
>> Doesn't that require that the users must explicitly configure when
>> they want privacy? I think a general solution should be transparent to
>> the user and "just works" to ensure their privacy. That in fact is one
>> of the arguments for NAT. If there is a significantly large enough
>> pool of users behind a NAT device, then the obfuscation is transparent
>> to the use and seems to be pretty good privacy (good enough that law
>> enforcement is concerned about NAT). I suppose a similar effect could
>> be achieved with a transparent proxy.
>
>
> CGN/NAT logs all your sources and destinations.
>
> The network operators will say they must do it for LEA compliance.
>
Ca,

Yes, but beyond the operator boundary the addresses are obfuscated. At
some level it seems we need to trust the provider which is the entity
delegating addresses to users.

> But once it is logged and stored it is available for nefarious hackers and big data marketing folks.
>
That's a problem for any collected PII. Those collecting the
information may not implement sufficient safeguards to protect the
information. That's a more general problem that we can't solve in the
context of 6man or probably even IETF.

> That said, most of you in north america have ipv6 on your phones. Do you feel that behavior of cycling addresses is not sufficient (barring ATT which proxies all HTTP afaik) ?

Without a quantitative analysis of the privacy attributes offered to
the user I wouldn't venture to say whether it's sufficient. This is
the problem with RFC 4941 and 4941bis, the techniques for improving
privacy are only described and analyzed in qualitative terms. For
instance, 4941bis states:

"Using temporary address alone may not be sufficient to prevent all
forms of tracking. It is however quite clear that some usage of
temporary addresses is necessary to improve user privacy."

It's intuitive that temporary addresses improve privacy. But the
question quickly becomes _how_ do temporary addresses improve privacy,
and more specifically what is the lifetime of temporary addresses
needed to ensure any level of privacy. For instance, if one user has
an address lifetime of 2 hrs. and one has a lifetime of 1 hr. does
that mean that the user with 1 hr. address has 50% the risk of privacy
being compromised? I very much doubt it works that way, but I'm not
even sure that we can say there's any material difference in user
privacy between them. Without a way to quantify the effects, we're
only left with heuristics and intuition. Note the contrast with
security in this, for instance the effects of crypto algorithms and
correlation between key length and breakability is well studied. I
wish there was an equivalent study of privacy.

Tom

>
>
>
>>
>> You might want to take a look at draft-herbert-ipv6-prefix-address-privacy-00.
>>
>> Tom
>>
>> > --
>> > Michael Richardson <[e-mail]>, Sandelman Software Works
>> >  -= IPv6 IoT consulting =-
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------