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)

[Behcet Sarikaya <[e-mail]>]

On Fri, Feb 22, 2019 at 4:59 PM Tom Herbert <[e-mail]> wrote:

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

+1

We with Dirk are pursuing this kind of activity in pidloc list
[e-mail] more in the context of Identifier locator separation
protocol context.
Please join pidloc.

 Regards,
Behcet

> 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
> >> >> --------------------------------------------------------------------
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>