Re: Structuring the BKK spin bit discussion

[Roland Zink <[e-mail]>]

Often the data of roaming users is tunneled back to the home operator. 
Coming back to the question about NAT and VPN use case I would consider 
this as the mobile network acts as a VPN and this isn't related to NAT. 
The same would happen when the mobile network operator wouldn't do NAT.

Regards,

Roland


Am 01.11.2018 um 04:47 schrieb Mike Bishop:
>
> But data connections when roaming run back to the home operator, IIUC, 
> so the size of Japan doesn’t mitigate this concern.  That means a 
> roaming user’s distance from Tokyo still gets disclosed, and it’s more 
> than measurement error if that user is roaming on a different continent.
>
> *From:* QUIC <[e-mail]> *On Behalf Of * Marcus Ihlar
> *Sent:* Wednesday, October 31, 2018 7:40 AM
> *To:* Kazuho Oku <[e-mail]>; Christian Huitema 
> <[e-mail]>
> *Cc:* Lars Eggert <[e-mail]>; IETF QUIC WG <[e-mail]>; 
> Dmitri Tikhonov <[e-mail]>
> *Subject:* SV: Structuring the BKK spin bit discussion
>
> Hi Kazuho,
>
> I believe the biggest difference is the size of the hidden network 
> segment.
>
> In the NAT case the client and NAT are still in the same country or 
> continent.
>
> A quick glacne at distancecalculator.net shows that the city farthest 
> from Tokyo in Japan is Naha-Shi, at 1554 km.
>
> That translates to roughly 5ms at the speed of light, so the kinds of 
> measurements to determine distance from Tokyo based on RTT will be 
> extremely sensitive and error prone.
>
> Please note that the distance analyis can be performed on handshake 
> RTT as well, for connections where the initial handshake is visible at 
> the measurement point.
>
> ------------------------------------------------------------------------
>
> *Från:*QUIC <[e-mail] <mailto:[e-mail]>> för 
> Kazuho Oku <[e-mail] <mailto:[e-mail]>>
> *Skickat:* den 31 oktober 2018 11:20
> *Till:* Christian Huitema
> *Kopia:* Lars Eggert; IETF QUIC WG; Dmitri Tikhonov
> *Ämne:* Re: Structuring the BKK spin bit discussion
>
> 2018年10月30日(火) 1:54 Christian Huitema <[e-mail] 
> <mailto:[e-mail]>>:
> >
> >
> >
> > > On Oct 29, 2018, at 9:08 AM, Dmitri Tikhonov 
> <[e-mail] <mailto:[e-mail]>> wrote:
> > >
> > >> On Mon, Oct 29, 2018 at 05:26:34PM +0200, Lars Eggert wrote:
> > >> We'd specifically like to ask client and server implementors with
> > >> projected sizable deployments to indicate whether they intent to
> > >> implement and deploy, if the WG decided to include the spin-bit in
> > >> the spec.
> > >
> > > LiteSpeed Technologies will support the spin bit -- both in our
> > > server and client QUIC implementations -- if it make it into the
> > > draft.
> >
> > My implementation is not used in any large scale deployment, but it 
> does support the spin bit. In fact, it has configuration options to 
> support spin bit variants: node, just spin, spin + vec, spin + QR.
> >
> > I think the strongest objection to the spin bit was put up by Marten 
> during the last interim: measuring the RTT with the spin bit discloses 
> the use of hidden path segments like VPN. This issue was not discussed 
> during the privacy analysis.
>
> May I ask if the VPN users are the only ones that lose some privacy
> with spin bits?
>
> I ask this because I live in a country where IIUC the mobile carriers
> place their nation-wide carrier-grade NAT near the capital city (i.e.,
> Tokyo). That means that for people living in the country, having spin
> bits turned on could reveal their distance from Tokyo.
>
> So the question is: if VPN users need special care, do some NAT users
> as well? Or if the answer is no, what is the difference from between
> the two groups?
>
> Generally speaking, I am not against giving users the freedom to
> expose spin bits, however I am wondering how the endpoints should
> provide the freedom of choice (UI question) as well as what the
> default should be.
>
> >
> > The privacy issue could be mitigated by turning off the spin bit at 
> privacy sensitive clients, but this would make these clients "stick out".
> >
> > One solution would be to remove the spin bit from the spec, trading 
> off better privacy for worse management. I am considering another 
> solution in which privacy sensitive clients hide the RTT by 
> controlling the spin, for example spinning at fixed intervals. I plan 
> testing that option in Picoquic.
> >
> > -- Christian Huitema
> >
> >
>
>
> -- 
> Kazuho Oku
>