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

[Tom Herbert <[e-mail]>]

On Fri, Feb 22, 2019 at 2:36 PM Ca By <[e-mail]> wrote:
>
>
>
> On Fri, Feb 22, 2019 at 11:56 AM Tom Herbert <[e-mail]> wrote:
>>
>> 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.
>
>
> Tor is this
> https://www.torproject.org/about/overview.html.en
>
> Tor is what people use today for address anonimity today

Thanks for the reference. It's interesting but then there's
https://www.esecurityplanet.com/open-source-security/the-trouble-with-tor.html.
In any case, I believe it's in IETF's best interest to continually
evaluate security and privacy in IP protocols. Privacy in IP
addressing seems to be an area of weakness in that regard.

Tom

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