On Fri, Dec 17, 2021 at 2:22 PM Brian E Carpenter
<brian.e.carpen...@gmail.com> wrote:
>
> On 18-Dec-21 10:58, Tom Herbert wrote:
> > On Fri, Dec 17, 2021 at 12:07 PM to...@strayalpha.com
> > <to...@strayalpha.com> wrote:
> >>
> >> Globally unique != static.
> >>
> >> They can be randomized and varied over time, e.g., as are Ethernet MAC
> addresses, exactly for the reasons you note.
> >
> > I would agree with that if the time to randomize is basically so small
> > that a client can use a unique and un-correlatable address for each
> > connection. Given the data collection abilities and compute resources
> > available to those that want to engage in surveillance, any time for
> > randomizing addresses, be it a day, an hour, or a few minutes, that is
> > greater than this minimum only provides a false sense of security with
> > respect to trying to prevent third parties from making correlations
> > about the sender's identity between different flows on the Internet.
> > Interestingly, CGNAT with enough users behind it can provide these
> > properties (attested by the fact the law enforcement has complained
> > about it).
>
> If we care about the peer-to-peer property, varying addresses require a
> rendezvous process based on a non-varying identifier. It's then the latter
> that becomes the handle for surveillance and forensics. The real impact of
> CGNAT is to push that factoid into surveillance models; it gives IPv4 the
> same privacy assist that temporary addresses give IPv6.
Brian,
I believe CGNAT is better than IPv6 in terms of privacy in addressing.
In fact one might argue that IPv4 provides better privacy and security
than IPv6 in this regard. Temporary addresses are not single use which
means the attacker can correlate addresses from a user between
unrelated flows during the quantum the temporary address is used. When
a user changes their address, the attacker can continue monitoring if
it is signaled that the address changed. Here is a fairly simple
exploit I derived to do that (from
draft-herbert-ipv6-prefix-address-privacy-00).
The exploit is:
o An attacker creates an "always connected" app that provides some
seemingly benign service and users download the app.
o The app includes some sort of persistent identity. For instance,
this could be an account login.
o The backend server for the app logs the identity and IP address
of a user each time they connect
o When an address change happens, existing connections on the user
device are disconnected. The app will receive a notification and
immediately attempt to reconnect using the new source address.
o The backend server will see the new connection and log the new
IP address as being associated with the specific user. Thus,
the server has
a real-time record of users and the IP address they are using.
o The attacker intercepts packets at some point in the Internet.
The addresses in the captured packets can be time correlated
with the server database to deduce identities of parties in
communications that are unrelated to the app.
The only way I see to mitigate this sort of surveillance is single use
addresses. That is effectively what CGNAT can provide.
Tom
>
> So perhaps what we need is a surveillance-proof rendezvous mechanism.
>
> Brian
>
> >
> > Tom
> >
> >>
> >> Joe
> >>
> >> —
> >> Joe Touch, temporal epistemologist
> >> www.strayalpha.com
> >>
> >> On Dec 17, 2021, at 11:46 AM, Brian E Carpenter
> >> <brian.e.carpen...@gmail.com> wrote:
> >>
> >> On 18-Dec-21 07:48, Geoff Huston wrote:
> >> ...
> >>
> >> So, to repurpose some graffiti from the 1970’s, we need globally unique
> >> addresses like fish need bicycles! :-)
> >>
> >>
> >> They have residual value for surveillance and possibly other forensic
> >> uses, which may of course be actively harmful to the user.
> >>
> >> But on the other hand, while what you say about economics is undoubtedly
> >> true, don't we want to keep the peer-to-peer option open *as a matter of
> >> principle*? After all, we still have that option for phone calls, even
> though it's now a minority usage pattern for mobile devices.
> >>
> >> Brian
> >>
> >> _______________________________________________
> >> Int-area mailing list
> >> Int-area@ietf.org
> >> https://www.ietf.org/mailman/listinfo/int-area
> >>
> >>
> >> _______________________________________________
> >> Int-area mailing list
> >> Int-area@ietf.org
> >> https://www.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
