Re: Address privacy

[Mark Smith <[e-mail]>]

On Wed, 29 Jan 2020, 13:47 Tom Herbert, <[e-mail]> wrote:

> On Tue, Jan 28, 2020 at 4:35 PM Ted Lemon <[e-mail]> wrote:
> >
> > On Jan 28, 2020, at 7:17 PM, Tom Herbert <[e-mail]> wrote:
> >
> > It is quantified. If a flow uses a unique address then the risk of
> > using the address of packets in the flow to correlate to other flows
> > is zero.
> >
> >
> > Er, no, because the address contains a lot of bits that don’t change.
> 64, typically.  Those bits can be used to correlate other flows.
>
> Addresses might be correlated to a provider, but no correlations can
> be made between addresses within the provider space so attributing
> different flows to the same user cannot be done.

A NAT device with a
> large number backend users would exhibit these properties even in
> IPv4.
>

I think this is assuming that IP addresses are the only way to identify
people and their devices

NAT made people resort to much smarter ways that don't rely on IP addresses.

https://panopticlick.eff.org

Internet search for "browser fingerprinting" for other examples.

All we can do, being limited to the IPv6 layer, is improve baseline and
default privacy, while also trying to avoid it impacting typical end-user
experience. The conservative 24 hour preferred lifetime should cover the
maximum length of any typical end-user's transport layer connection.

RFC4291bis is "better than nothing" IID privacy.


If an end user wants assured privacy they need to have mechanisms and
methods that work at all layers from IPv6 upwards.

That could include running the connection through an application layer
anonymising proxy that strips out all possible identifiers at all layers.

To the external destination, the anonymising proxy would be
indistinguishable from a single native client.

Ideally the anonymising proxy is reached internally with ULA addresses, and
hosts only have ULA addresses. That should mean failing safe if the
application layer anonymising proxy fails.


Regards,
Mark.



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