Re: Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity? (Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios)

[Ca By <[e-mail]>]

On Fri, Feb 22, 2019 at 10:12 AM Tom Herbert <[e-mail]> wrote:

> On Thu, Feb 21, 2019 at 11:35 PM Mark Smith <[e-mail]>
> wrote:
> >
> > Hi Tom,
> >
> > On Fri, 22 Feb 2019 at 10:04, Tom Herbert <[e-mail]> wrote:
> > >
> > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith <[e-mail]>
> wrote:
> > > >
> > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E
> > > > <[e-mail]> wrote:
> > > > >
> >
> > <snip>
> >
> > > >
> > > > So I think there's commonly a big different between works and works
> > > > well. NAT may work, however compared to stateless IPv6 (and IPv4)
> > > > forwarding, it doesn't work anywhere as near as well.
> > > >
> > > Mark,
> > >
> > > I agreee with that with one exception. I believe that NAT/IPv4 can
> > > offer better privacy in addressing than IPv6 given current addess
> > > allocation methods.
> > >
> >
> > So I don't think addressing privacy via NAT is really all that
> > valuable if there are many other ways, some quite easy, to uniquely
> > identify an anonymity desiring end-point/end-user, whose effectiveness
> > aren't impacted at all by NAT.
> >
> > For example, this website is coming over IPv4 for me, and I'm using
> > IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I shouldn't
> > be able to tracked.
> >
> > https://amiunique.org/
> >
> > Yet it is saying I can be with both Chrome and Firefox on Fedora 29 in
> > Incognito/Private windows mode on this host. It says the same about my
> > Android 9 phone with Chrome in Incognito mode.
> >
> > Going into the detail of how, they don't seem to be using IP address
> > at all for any identification, it is all browser attributes.
> >
> > We have IPv6 temporary addresses, which makes using addresses harder
> > to use to identify a node. I think that is a lot better than nothing.
>
> Mark,
>
> Yes, but by that same rationale a simple substitution cipher is better
> than nothing in cryptography!
>
> What pretty much any conversation about privacy in addressing seems to
> lacking is a quantitative description of privacy and any empiracal
> data on the impact that privacy mechanisms, like those defined in
> RFC4941, have had. You might say it "makes using addresses harder to
> use to identify a node". But then the obvious question is _how_ much
> harder? Is this really protecting anyone's privacy, or it is just a
> minor inconvenience to attackers and only giving users a false sense
> of security?
>
> The irony is that CGN seems to have the best supporting evidence for
> being a mechanism that impacts privacy, but it was never even intended
> to be a privacy mechanism. The evidence is in the form of concerns
> form law enforcement that the privacy side effect is too strong and
> impedes their investigations
> (https://www.theregister.co.uk/2017/10/18/europol_cgnat/).
>
> So I don't think "Is addressing privacy via NAT really achieving much
> compared to a privacy goal of anonymity?" is the right question. The
> right question to ask is "Is addressing privacy via any IETF defined
> mechanism achieving much compared to a privacy goal of anonymity?"
>
> Tom
>



1.  Network service providers cannot provide address anonymity.  LEA
requirements in the USA and many jurisdictions simply do not allow it, so
who is the customer of such a standard?  Who would make and deploy it?

2. Network address annonimity today is generally provided via Tor.  How
could the ietf provide something better than existiting tor solutions,
knowing that it will not be baked into the network — meaning it must be
over the top.

3. CGN is not private. It throw off per session logs of every transaction,
so this is a full click stream archived ... with varing levels of
intentional monetization and security from hackers.



> > However, I don't see how IPv6 NAT would improve it much, and it
> > introduces the other drawbacks of NAT.
> >
> > Regards,
> > Mark.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > Tom
> > >
> > > > Regards,
> > > > Mark.
> > > >
> > > >
> > > >
> > > > > Bert
> > > >
> > > > _______________________________________________
> > > > v6ops mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/v6ops
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>