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)

[Tom Herbert <[e-mail]>]

On Fri, Feb 22, 2019 at 10:06 AM Ca By <[e-mail]> wrote:
>
>
>
> 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?

The customer of this is political dissident that is speaking out
against injustice of a corrupt government. There is nothing that
prevents a solution that provides the privacy for the dissident, but
still allows their network provider to maintain records that correlate
address to identity is available to LEA for the local jurisdiction
under lawful order. This really isn't different than other areas of
privacy on the Internet (like the logs that Facebook or Google keep).
The point is that anonimity is needed to prevent unauthorized third
parties from breaking someones privacy.

>
> 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.
>

I'm not sure what "provided via Tor" means.

> 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.
>
Yes, it is expected that the local provider has full view of all
associations of address to some device, that's pretty much a given and
we have to trust the local provider to some extent. What we're trying
to prevent is untrusted external parties from deducing identity or
location of users.

>
>>
>> > 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
>> --------------------------------------------------------------------