Subject: Re: Structuring the BKK spin bit discussion

From: Roland Zink <[email-masked]>
Date: Thu, 1 Nov 2018 11:27:57 +0100

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 <[email-masked]> *On Behalf Of * Marcus Ihlar
> *Sent:* Wednesday, October 31, 2018 7:40 AM
> *To:* Kazuho Oku <[email-masked]>; Christian Huitema 
> <[email-masked]>
> *Cc:* Lars Eggert <[email-masked]>; IETF QUIC WG <[email-masked]>; 
> Dmitri Tikhonov <[email-masked]>
> *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 <[email-masked] <mailto:[email-masked]>> för 
> Kazuho Oku <[email-masked] <mailto:[email-masked]>>
> *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 <[email-masked] 
> <mailto:[email-masked]>>:
> >
> >
> >
> > > On Oct 29, 2018, at 9:08 AM, Dmitri Tikhonov 
> <[email-masked] <mailto:[email-masked]>> 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
>

---

From: Roland Zink <[email-masked]>
Date: Thu, 1 Nov 2018 11:39:44 +0100

Am 31.10.2018 um 19:04 schrieb Christian Huitema:
> On 10/31/2018 10:16 AM, Brian Trammell (IETF) wrote:
>
>> In the case that...
>>
>> - ...an end-to-end connection actually terminates at a location different than the apparent location in the endpoint IP address, because the endpoint IP address is a VPN tunnel endpoint
>> - ...the "hidden" endpoint is very far (> ~3000-5000km) from the apparent location
>> - ...that VPN tunnel exists solely to make the end-to-end association appear to originate from at or near the VPN tunnel endpoint (e.g., anti-geofencing)
> The actual scenario relates to UDP/QUIC proxies, and how they would
> compare to TCP/TLS proxies.
>
> Today, I can build a TCP/TLS proxy that accepts connections at port 443,
> examines the (possibly encrypted) SNI in the client Hello, establishes a
> TCP connection to the hidden destination, and relays TLS packets between
> the 2 connections. TCP is hop by hop, TLS is end to end, examining TCP
> sequence numbers and ACKs does not reveal the hidden leg of the service.
>
> Suppose that I build a QUIC proxy that accepts UDP packets at port 4433,
> and then does pretty much the same job as load balancer: look for the
> (possibly encrypted) SNI inside the client hello for initial packets;
> look for the destination connection ID in other packets; forward the UDP
> packets to the hidden server based on that, and vice versa in the other
> direction. This is sort of equivalent to the TCP/TLS proxy scenario: UDP
> is hop by hop; QUIC and TLS is end to end. The QUIC messages are
> encrypted and don't reveal much, but the spin bit will reveal the
> end-to-end RTT.

I guess this shows that some privacy is lost with the spin bit enabled. 
When writing a proxy you may put some more effort and provide a TOR like 
proxy where the outer QUIC connection is only to the proxy and a inner 
QUIC connection is end to end.

Roland

> Of course, examining the content and timing of packets might in both
> cases reveal the end-to-end RTT, but layering makes a difference. The
> application may be able to implement end-to-end measures to counter the
> analysis of end-to-end traffic, but the application cannot easily
> influence the spin bit.
>
> -- Christian Huitema
>
>
>

---

From: "Roni Even (A)" <[email-masked]>
Date: Sat, 3 Nov 2018 10:49:31 +0000

Hi,
Inline

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Kazuho Oku
Sent: Thursday, November 01, 2018 5:06 AM
To: Brian Trammell
Cc: Lars Eggert; [email-masked]; Christian Huitema; IETF QUIC WG; Dmitri Tikhonov
Subject: Re: Structuring the BKK spin bit discussion

Hi,

Marcus, Alexandre, Brian, thank you for the responses. My comments below.

2018年10月31日(水) 23:18 Brian Trammell (IETF) <[email-masked]>:
>
> hi Kazuho, Marcus,
>
> +1 to this; the intra-network latency variation on the mobile segment of the mobile networks we looked at via the MONROE in the testbed in our PAM paper the followed from the RTT DT work (see https://github.com/mami-project/rtt-privacy-paper/blob/master/rtt-privacy.pdf, especially section 3.1 and figure 2(b)) makes RTT measurement on a mobile network useless for geolocation.
>
> We did notice (not shown in the paper) that different carriers (n = 4, if I recall correctly) had distinct latency distributions, so with traffic from all Japanese mobile users you could probably use RTT data in the aggregate to build a "carrier classifier". This is of course a useless exercise because you can already tell which carrier a subscriber is coming from by looking at the IP address of the CGNAT exit.
>
> IMO there are only a few edge cases where there are actual potential geoprivacy issues raised by the spin bit with respect to tunneled VPN traffic. All of these involve trans- or intercontinental tunnels (>30ms of additional RTT, for 3000km of location uncertainty -- how far is it from Okinawa to Hokkaido?). In every case the handshake latency gives you away as well, but in every case long RTTs might also have non-distance related causes. So while I see disabling the spin bit as a necessary feature, especially for clients to have, IMO its utility is more useful for peace of mind and information reduction than for actual information elimination.

Thank you for sharing the research.

FWIW, inhabited islands of Japan span across 3,000km, however the longest hidden path of the carrier-grade NAT will be around 2,000km because Tokyo is located near the middle. So it's a bit shorter than your numbers.

I can understand that there are other factors that have impact on the RTT exposed by the spin bit, and that might overshadow the distance.

OTOH, I think it's important to remember that the spin bit expose many RTT samples (every once an RTT) compared to handshake which is a one time thing for each connection, or compared to other behavior like client issuing HTTP requests.

For cases like large file download (in which the only output from the receiver would be ACKs), I would assume that the spin bit would be by far the most accurate piece of information for an observer to determine the RTT to the connection.

Roni Even: In this case since there are large packets to one direction and short to the other an observer can map the download file to its ack message and calculate the RTT without the spin bit

>
> Cheers,
>
> Brian
>
> > On 31 Oct 2018, at 13:40, Marcus Ihlar <[email-masked]> wrote:
> >
> > 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 <[email-masked]> för Kazuho Oku 
> > <[email-masked]>
> > 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 <[email-masked]>:
> > >
> > >
> > >
> > > > On Oct 29, 2018, at 9:08 AM, Dmitri Tikhonov <[email-masked]> 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.
> > > >
> > > 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.
> >
> > 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?
> >
> > > 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
>

--
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 4 Nov 2018 08:52:03 +0700

> Roni Even: In this case since there are large packets to one direction and short to the other an observer can map the download file to its ack message and calculate the RTT without the spin bit

My understanding is that you cannot.

Because the payload of the packets are encrypted, you cannot tell
which ACK packets sent by the client correspond to which packets sent
by the server. All you can observe is that something is flowing
steadily from the server to the client.

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 4 Nov 2018 01:24:40 -0800

On 4 November 2018 at 02.52.44, Kazuho Oku ([email-masked]) wrote:

> Roni Even: In this case since there are large packets to one direction
and short to the other an observer can map the download file to its ack
message and calculate the RTT without the spin bit

If there are timing gaps or traffic rate changes in the transmission, it is
not hard to associate packets with high probability. Gaps can occur due to
source task switching or when congestion control adapts the flow rate, or
when other connections appear or disappear. They can also appear due to
buffering in middle boxes.