Subject: Structuring the BKK spin bit discussion

From: Lars Eggert <[email-masked]>
Date: Mon, 29 Oct 2018 17:26:34 +0200

Hi,

you'll have seen that we've set aside a lengthy slot on the agenda in order to finish the discussion on whether the spin bit (described in draft-ietf-quic-spin-exp) should be included in the first version of QUIC the IETF publishes, and if yes, what shape that inclusion would take.

Note that draft-ietf-quic-spin-exp describes what we commonly call the single-bit spin bit variant. We'd like to confirm that the discussion will be limited to that variant.

Next, we'd like to confirm that the WG believes that it is fit-for purpose, i.e., that if a sufficient number of bits were spinning, operators could obtain the information they need. This also includes confirmation that the privacy aspects of the spin bit proposal are understood and acceptable to the WG.

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. We have seen one such statement on the list from Microsoft (thank you!) and would be interested to hear from others, either on the list or during the session in Bangkok.

Finally, if the WG has agreement to include the spin bit in the spec based on the information from and the discussion on the points above, we need to come to consensus on what shape such an inclusion of the spin bit would take, e.g., negotiated extension, conformance requirements (MAY/SHOULD/MUST) for clients and servers, etc.

Please let us know if you have any questions or comments about this approach for structuring the discussion in Bangkok.

Lars and Mark

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 29 Oct 2018 12:08:03 -0400

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.

  - Dmitri.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 09:53:22 -0700

> On Oct 29, 2018, at 9:08 AM, Dmitri Tikhonov <[email-masked]> wrote:
> 

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.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 09:29:53 +1100

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

I had assumed that was part of the analysis and it was covered by the
assumption that spinning could be disabled

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

I've done a little thinking about this one, and it might conflict with
the natural signals the transport emits, along the lines of what
Andrew McGregor has mentioned on a couple of occasions.  If the spin
bit is enabled, then privacy-sensitive endpoints will need to make a
hard call regarding standing out.

Note also that you probably can't hide the fact that you aren't at the
same network location as the address you are using.  Spoofing a
shorter RTT is impossible in general because you have to assume edges
that haven't arrived yet.  If there are no edges you expose the
charade.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 29 Oct 2018 23:58:25 +0100

hi Martin, Christian, all,

> On 29 Oct 2018, at 23:29, Martin Thomson <[email-masked]> wrote:
> 

+1. Probabilistically disabling spinning, which seems necessary if we want some grease to help us reserve the right to change the semantics of the bit at the spin bit's location in the wire image, should ensure that endpoints that want to disable spinning for their own reasons will have a large anonymity set to hide in, even in a future with perfect implementation and deployment of the spin bit.

> that haven't arrived yet.  If there are no edges you expose the

You cannot reliably hide the fact that you're not at the same network location as the address you're using, spin bit or no. Most of the methods I know of for detecting people trying to hide where they're coming from don't rely on RTT at all. (Yes, I'm a Netflix customer who relies on Hurricane Electric's tunnel broker for IPv6 connectivity, why do you ask? ;) )

The recent academic work I'm aware of in this space (Weinberg et al "How to Catch When Proxies Lie", to appear at IMC this week) uses minimum RTT (with injected active measurement traffic) to conservatively draw exclusion circles to show that VPN providers that promise exits in certain countries probably don't actually deliver them. Not being vulnerable to this kind of exclusion analysis requires that you actually inject latency, not just in the spin bit, but over the entire flow (including the handshake).

RTT *higher* (even much higher) than an expected range for a given address pair isn't reliable enough to derive any sort of verdict from, due to the nature of delay and delay variability in the Internet.

So while I guess you can lie with the spin bit (even using rudimentary signal processing magic to take an assumed real RTT and make it look like a given lower target RTT, as long as you're not too worried about getting caught when your assumptions fail to hold), it's probably neither necessary nor sufficient to do so to hide a VPN exit. It's cheaper and more effective to just turn it off and hope.

Cheers,

Brian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Oct 2018 16:08:09 -0700

Just to add one additional piece of data here that was the basis of a lot
of discussion in the design team:  consider whether the handshake alone
discloses the data you are trying to protect.  For the case where you are
trying to obscure a hidden path segment like a VPN, a comparison of
handshake time to expected time is almost certainly enough.

regards,

Ted

On Mon, Oct 29, 2018 at 3:58 PM Brian Trammell (IETF) <[email-masked]>
wrote:

> >> 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.
> >
> +1. Probabilistically disabling spinning, which seems necessary if we want
> some grease to help us reserve the right to change the semantics of the bit
> at the spin bit's location in the wire image, should ensure that endpoints
> that want to disable spinning for their own reasons will have a large
> anonymity set to hide in, even in a future with perfect implementation and
> deployment of the spin bit.
>
> >> 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.
> >
> You cannot reliably hide the fact that you're not at the same network
> location as the address you're using, spin bit or no. Most of the methods I
> know of for detecting people trying to hide where they're coming from don't
> rely on RTT at all. (Yes, I'm a Netflix customer who relies on Hurricane
> Electric's tunnel broker for IPv6 connectivity, why do you ask? ;) )
>
> The recent academic work I'm aware of in this space (Weinberg et al "How
> to Catch When Proxies Lie", to appear at IMC this week) uses minimum RTT
> (with injected active measurement traffic) to conservatively draw exclusion
> circles to show that VPN providers that promise exits in certain countries
> probably don't actually deliver them. Not being vulnerable to this kind of
> exclusion analysis requires that you actually inject latency, not just in
> the spin bit, but over the entire flow (including the handshake).
>
> RTT *higher* (even much higher) than an expected range for a given address
> pair isn't reliable enough to derive any sort of verdict from, due to the
> nature of delay and delay variability in the Internet.
>
> So while I guess you can lie with the spin bit (even using rudimentary
> signal processing magic to take an assumed real RTT and make it look like a
> given lower target RTT, as long as you're not too worried about getting
> caught when your assumptions fail to hold), it's probably neither necessary
> nor sufficient to do so to hide a VPN exit. It's cheaper and more effective
> to just turn it off and hope.
>
> Cheers,
>
> Brian
>
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:27:47 -0700

> +1. Probabilistically disabling spinning, which seems necessary if we want some grease to help us reserve the right to change the semantics of the bit at the spin bit's location in the wire image,…

I opened PR https://github.com/quicwg/base-drafts/pull/1931 to discuss this.

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 30 Oct 2018 07:00:57 +0000

In the Netflix case it just takes 16 connections by the same user, or less when multiple users originate from the sane IP range. Is it really practical (and thus worthwhile) to hide probabilistically as in Huitemas PR?

________________________________
From: QUIC <[email-masked]> on behalf of Christian Huitema <[email-masked]>
Sent: Tuesday, October 30, 2018 5:27:47 AM
To: [email-masked]
Subject: Re: Structuring the BKK spin bit discussion

On 29 Oct 2018, at 23:29, Martin Thomson <[email-masked]><mailto:[email-masked]> wrote:

On Tue, Oct 30, 2018 at 3:54 AM Christian Huitema <[email-masked]><mailto:[email-masked]> wrote:

-- Christian Huitema

---

From: Marcus Ihlar <[email-masked]>
Date: Tue, 30 Oct 2018 11:55:57 +0000

Making it more difficult to differentiate explicit opt-out from random opt-out is likely useful even if it doesn't help in the particular Netflix case.

Furthermore, just like Brian points out it is necessary to grease the bit if we want to change the bit semantics later on.

I think the proposal has low enough complexity and potential benefits to be worthwhile.

From: QUIC <[email-masked]> On Behalf Of Mikkel Fahnøe Jørgensen
Sent: den 30 oktober 2018 08:01
To: Christian Huitema <[email-masked]>; [email-masked]
Subject: Re: Structuring the BKK spin bit discussion

  _____

From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Christian Huitema <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 30, 2018 5:27:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: Structuring the BKK spin bit discussion

   -- Christian Huitema

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 30 Oct 2018 14:37:04 +0100

hi Marcus, all,

So let me step back a bit and suggest a starting point (borrowing heavily from MT in an offlist discussion) for discussing what we want to do in BKK. (Or rather, I should say, let me suggest a starting point for y'all to discuss, because I doubt I'll be in a position to join remotely at 03:00 next Wednesday local time. Have fun! :)

There seem to be three broad options we've discussed to date:

- No spin bit. Grease it if we can't use it for something else.

- "Discretionary" spin: reserve the bit for spinning, implementations MAY/SHOULD/whatever spin. MUST doesn't make any sense here, since there's no impact on end-to-end interop or the end-to-end properties the protocol guarantees.

- "Negotiated" spin: reserve the bit for spinning, define two versions, one in which the endpoints MUST NOT spin the bit, one in which the endpoints MUST spin the bit. This has the nice property that negotiation of the spin bit is an actual exercise of the version negotiation mechanism, which will keep it flexible for future use better that greasing alone. (This was discussed in a thread after the NYC interim, but there's no text for it in spin-exp. I'd be happy to try and bang out a PR for it if that'd make it easier for people to understand/discuss in BKK.)

Beyond this, there seem to be a few other qualities we want, and the details matter for these. The most important quality discussed is the maintenance of an anonymity set of non-spinning flows so that an endpoint that does not want to spin will not immediately stick out. So we can define some parameters that meet those qualities for both of the discretionary and negotiated variants. Let me propose the following values for these parameters, as a starting point for discussion in BKK:

(1) No spin bit: no parameters. If the bit is reserved, it must be greased. (I'd submit that experimental use of the spin bit is a good form of greasing, so an implementation can offer discretionary spin if it likes, but without large-scale implementation, such experimental use is seen on a tiny minority of traffic and becomes a wholly academic exercise.)

(2) Discretionary spin bit: here we want to determine compliance levels and participation probability. I'd suggest:

- client SHOULD implement and server SHOULD implement (I acknowledge this is a personal preference; I suggest it because I think it will drive deployment better than MAY/SHOULD or MAY/MAY).

- both client and server SHOULD allow the application and/or user/system configuration to force a given connection or set of connections to spin (for targeted diagnostic purposes) or not to spin. (This is a REALLY SHOULD, only because MUST on the interface doesn't make a lot of sense.)

- in the absence of such configuration, both client and server SHOULD independently decide to spin the bit on a given connection with a set probability. I'd suggest probabilities at each endpoint of 7/8, so 3/4 of flows between implementing endpoints will expose RTT. This is a wild guess at a good starting point, though, picked to cause a large proportion of flows to spin even if only a small number of large implementations decide to implement; it is possible to set the recommendation smaller if it looks like the majority of implementations will spin. These proportions SHOULD be user/system/application configurable.

- when not spinning, each of the client and server should randomly select a value for the spin bit for each new CID the duration of the connection, and send that value on every packet with that CID.

This will ensure that even in a future with perfect deployment, the set of flows that aren't spinning because of deliberate configuration at any given time will have a large enough anonymity set to hide in. It also makes the job of recognizing non-spinning flows easy. In any case, it is important that all non-spinning flows (due to non-implementation, random choice, or deliberate configuration) non-spin in the same way.

(3) Negotiated spin bit: same question. I'd suggest that the starting points be chosen to result in the same proportion of spinning bits as in discretionary case (2) above, so:

- client SHOULD implement and server SHOULD implement (same comment as above)

- both client and server SHOULD allow the application and/or user/system configuration to force a given connection to offer/accept to spin, or to not offer/refuse to spin.

- in the absence of such configuration, the client SHOULD offer to spin (request the spin version of the protocol) with a set probability, and the server SHOULD accept an offer to spin with a set probability. Suggest 7/8 as above, for target probability 3/4, same caveats.

- when negotiated, both endpoints MUST spin the bit (as described in quic-spin-exp). If one endpoint detects the other is not spinning, it MUST terminate the connection, as this may indicate an error in the version negotiation mechanism itself.

- when not negotiated, each of the client and server should randomly select a value for the spin bit for each new CID the duration of the connection, and send that value on every packet with that CID.

The additional properties negotiated spin has with respect to discretionary spin are that it is a real exercise of the version negotiation mechanism, and that it provides an explicit signal to on-path devices that a given connection will spin.

I suggest we try to start from these three points, separating the question of which pattern (none, discretionary, negotiated) we prefer, from the questions about the particular parameters applied thereto. Key is that we can tweak the parameters for either pattern to arrive at a given deployment curve and proportion of spinning bits in the network.

Thanks, cheers,

Brian

P.S.: I'm not ignoring the "hold two other bits out for measurement experimentation" question, but I consider it to be an orthogonal question to these; I think it's worth discussing, but we can treat it separately, so we should. In any case I think the work you (Marcus) have done has shown that relatively simple heuristics at the measurement point deliver most of the benefit in terms of measurement fidelity in the presence of loss and reordering that the VEC can for realistic loss and reordering rates, for two fewer bits per packet. So the spin bit is worth doing on its own.

> On 30 Oct 2018, at 12:55, Marcus Ihlar <[email-masked]> wrote:
> 
> Making it more difficult to differentiate explicit opt-out from random opt-out is likely useful even if it doesn’t help in the particular Netflix case.
> In the Netflix case it just takes 16 connections by the same user, or less when multiple users originate from the sane IP range.. Is it really practical (and thus worthwhile) to hide probabilistically as in Huitemas PR?
>

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 30 Oct 2018 10:55:17 -0700

Brian, (and Martin),

I like this structuring of the discussion, and I think it'll be good to use
this structure for the discussion in BKK.

- jana

On Tue, Oct 30, 2018 at 6:37 AM Brian Trammell (IETF) <[email-masked]>
wrote:

> hi Marcus, all,
>
> So let me step back a bit and suggest a starting point (borrowing heavily
> from MT in an offlist discussion) for discussing what we want to do in BKK.
> (Or rather, I should say, let me suggest a starting point for y'all to
> discuss, because I doubt I'll be in a position to join remotely at 03:00
> next Wednesday local time. Have fun! :)
>
> - "Discretionary" spin: reserve the bit for spinning, implementations
> MAY/SHOULD/whatever spin. MUST doesn't make any sense here, since there's
> no impact on end-to-end interop or the end-to-end properties the protocol
> guarantees.
>
> - "Negotiated" spin: reserve the bit for spinning, define two versions,
> one in which the endpoints MUST NOT spin the bit, one in which the
> endpoints MUST spin the bit. This has the nice property that negotiation of
> the spin bit is an actual exercise of the version negotiation mechanism,
> which will keep it flexible for future use better that greasing alone.
> (This was discussed in a thread after the NYC interim, but there's no text
> for it in spin-exp. I'd be happy to try and bang out a PR for it if that'd
> make it easier for people to understand/discuss in BKK.)
>
> Beyond this, there seem to be a few other qualities we want, and the
> details matter for these. The most important quality discussed is the
> maintenance of an anonymity set of non-spinning flows so that an endpoint
> that does not want to spin will not immediately stick out. So we can define
> some parameters that meet those qualities for both of the discretionary and
> negotiated variants. Let me propose the following values for these
> parameters, as a starting point for discussion in BKK:
>
>
> (1) No spin bit: no parameters. If the bit is reserved, it must be
> greased. (I'd submit that experimental use of the spin bit is a good form
> of greasing, so an implementation can offer discretionary spin if it likes,
> but without large-scale implementation, such experimental use is seen on a
> tiny minority of traffic and becomes a wholly academic exercise.)
>
>
> (2) Discretionary spin bit: here we want to determine compliance levels
> and participation probability. I'd suggest:
>
> - client SHOULD implement and server SHOULD implement (I acknowledge this
> is a personal preference; I suggest it because I think it will drive
> deployment better than MAY/SHOULD or MAY/MAY).
>
> - both client and server SHOULD allow the application and/or user/system
> configuration to force a given connection or set of connections to spin
> (for targeted diagnostic purposes) or not to spin. (This is a REALLY
> SHOULD, only because MUST on the interface doesn't make a lot of sense.)
>
> - in the absence of such configuration, both client and server SHOULD
> independently decide to spin the bit on a given connection with a set
> probability. I'd suggest probabilities at each endpoint of 7/8, so 3/4 of
> flows between implementing endpoints will expose RTT. This is a wild guess
> at a good starting point, though, picked to cause a large proportion of
> flows to spin even if only a small number of large implementations decide
> to implement; it is possible to set the recommendation smaller if it looks
> like the majority of implementations will spin. These proportions SHOULD be
> user/system/application configurable.
>
> - when not spinning, each of the client and server should randomly select
> a value for the spin bit for each new CID the duration of the connection,
> and send that value on every packet with that CID.
>
> This will ensure that even in a future with perfect deployment, the set of
> flows that aren't spinning because of deliberate configuration at any given
> time will have a large enough anonymity set to hide in. It also makes the
> job of recognizing non-spinning flows easy. In any case, it is important
> that all non-spinning flows (due to non-implementation, random choice, or
> deliberate configuration) non-spin in the same way.
>
>
> (3) Negotiated spin bit: same question. I'd suggest that the starting
> points be chosen to result in the same proportion of spinning bits as in
> discretionary case (2) above, so:
>
> - both client and server SHOULD allow the application and/or user/system
> configuration to force a given connection to offer/accept to spin, or to
> not offer/refuse to spin.
>
> - in the absence of such configuration, the client SHOULD offer to spin
> (request the spin version of the protocol) with a set probability, and the
> server SHOULD accept an offer to spin with a set probability. Suggest 7/8
> as above, for target probability 3/4, same caveats.
>
> - when negotiated, both endpoints MUST spin the bit (as described in
> quic-spin-exp). If one endpoint detects the other is not spinning, it MUST
> terminate the connection, as this may indicate an error in the version
> negotiation mechanism itself.
>
> - when not negotiated, each of the client and server should randomly
> select a value for the spin bit for each new CID the duration of the
> connection, and send that value on every packet with that CID.
>
> The additional properties negotiated spin has with respect to
> discretionary spin are that it is a real exercise of the version
> negotiation mechanism, and that it provides an explicit signal to on-path
> devices that a given connection will spin.
>
>
> I suggest we try to start from these three points, separating the question
> of which pattern (none, discretionary, negotiated) we prefer, from the
> questions about the particular parameters applied thereto. Key is that we
> can tweak the parameters for either pattern to arrive at a given deployment
> curve and proportion of spinning bits in the network.
>
> Thanks, cheers,
>
> Brian
>
>
>
> P.S.: I'm not ignoring the "hold two other bits out for measurement
> experimentation" question, but I consider it to be an orthogonal question
> to these; I think it's worth discussing, but we can treat it separately, so
> we should. In any case I think the work you (Marcus) have done has shown
> that relatively simple heuristics at the measurement point deliver most of
> the benefit in terms of measurement fidelity in the presence of loss and
> reordering that the VEC can for realistic loss and reordering rates, for
> two fewer bits per packet. So the spin bit is worth doing on its own.
>
>
>
>
>
> > Making it more difficult to differentiate explicit opt-out from random
> opt-out is likely useful even if it doesn’t help in the particular Netflix
> case.
> > Furthermore, just like Brian points out it is necessary to grease the
> bit if we want to change the bit semantics later on.
> > In the Netflix case it just takes 16 connections by the same user, or
> less when multiple users originate from the sane IP range.. Is it really
> practical (and thus worthwhile) to hide probabilistically as in Huitemas PR?
> >
> > +1. Probabilistically disabling spinning, which seems necessary if we
> want some grease to help us reserve the right to change the semantics of
> the bit at the spin bit's location in the wire image, should ensure that
> endpoints that want to disable spinning for their own reasons will have a
> large anonymity set to hide in, even in a future with perfect
> implementation and deployment of the spin bit.
> >

---

From: Christian Huitema <[email-masked]>
Date: Tue, 30 Oct 2018 11:39:52 -0700

On 10/30/2018 4:55 AM, Marcus Ihlar wrote:
> opt-out is likely useful even if it doesn’t help in the particular
> Netflix case.
>
> *From:*QUIC <[email-masked]> *On Behalf Of *Mikkel Fahnøe Jørgensen
> *Sent:* den 30 oktober 2018 08:01
> *To:* Christian Huitema <[email-masked]>; [email-masked]
> *Subject:* Re: Structuring the BKK spin bit discussion
>
>  
>
> less when multiple users originate from the sane IP range.. Is it
> really practical (and thus worthwhile) to hide probabilistically as in
> Huitemas PR?
>

Mikkel is correct, we may not want a purely random per connection
behavior, but rather something "random per destination". This would
better mimic the opt-out behavior of a privacy-sensitive endpoint, which
would always opt out when contacting a specific destination. If I had to
implement it, I would not use a PRNG, but rather something compute the
hash of a local secret and either the peer address or the peer name.
That way, the client would opt out for all 16 Netflix connections, or
for none of them.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Oct 2018 09:55:33 +1100

On Wed, Oct 31, 2018 at 5:42 AM Christian Huitema <[email-masked]> wrote:
> Mikkel is correct, we may not want a purely random per connection behavior, but rather something "random per destination". This would better mimic the opt-out behavior of a privacy-sensitive endpoint, which would always opt out when contacting a specific destination. If I had to implement it, I would not use a PRNG, but rather something compute the hash of a local secret and either the peer address or the peer name. That way, the client would opt out for all 16 Netflix connections, or for none of them.

Or are we looking for random per-path?

That notion would seem to tilt the balance more in favour of the
"discretionary" option over the "negotiated" one on the basis that
spinning/not doesn't become a linkability consideration.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 30 Oct 2018 16:52:17 -0700

On Tue, Oct 30, 2018 at 3:55 PM Martin Thomson <[email-masked]>
wrote:

> behavior, but rather something "random per destination". This would better
> mimic the opt-out behavior of a privacy-sensitive endpoint, which would
> always opt out when contacting a specific destination. If I had to
> implement it, I would not use a PRNG, but rather something compute the hash
> of a local secret and either the peer address or the peer name. That way,
> the client would opt out for all 16 Netflix connections, or for none of
> them.
>

Yes, per path makes sense to me. I think the linkability concern here is
weak, but it doesn't hurt any to do this per path.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 30 Oct 2018 17:05:27 -0700

This might overcomplicate things but a client could perhaps downsample the
spin bit by only changing phase every second time the server does, or other
harmonics. If this is done randomly it could hide some latency.

On 31 October 2018 at 00.52.29, Jana Iyengar ([email-masked]) wrote:

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 31 Oct 2018 12:22:22 +0900

> spinning/not doesn't become a linkability consideration.

Even though spin-bit is a per-path thing, I am not sure if the
probabilistic opt-out needs to be per-path. This is because what we
need to ensure is having at least some portion of QUIC packets flows
floating on each path not using the spin bit.

That can be achieved either by having QUIC endpoints turning off the
spin-bit for every path at a fixed probability, or by having them
turning off the spin-bit for every connection at a fixed probability.

-- 
Kazuho Oku

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 31 Oct 2018 09:38:43 +0100

hi Martin,

> On 30 Oct 2018, at 23:55, Martin Thomson <[email-masked]> wrote:
> 

Yeah, I noticed this when writing up https://github.com/quicwg/base-drafts/pull/1937 -- if a handshake negotiating a spin version commits both endpoints to spin on that connection for every subsequent CID, then if endpoints implementing spin are relatively rare (which may be the case no matter what early in the deployment curve), this sticky state is a potential linkability issue. If endpoints willing to negotiate spin are widely deployed, linkability becomes negligible.

One can fix this by allowing endpoints that have negotiated spinning to transition to discretionary non-spinning on a CID change, since for this to be a useful exercise of the version negotiation machinery, the MUST spin is only important for the CID directly after the handshake.

But you're right, the additional complexity starts making negotiation look less attractive.

Cheers,

Brian

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 31 Oct 2018 09:51:18 +0100

Greetings, all,

I've merged Christian's PR #1931 which covers discretionary spin, and my PR #1937 which covers negotiated spin, into draft-ietf-quic-spin-exp. For those of you who'd like text in a draft to accompany this discussion, have a look at the editor's copy:

https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html

Note that the document has two different suggestions as to what endpoints should do with the spin bit when not spinning it: either pin it to 0, or select a random value per CID. Picking one is a detail question. IMO, either is fine; the latter has a (probably negligible) greasing effect.

Cheers,

Brian

> On 30 Oct 2018, at 18:55, Jana Iyengar <[email-masked]> wrote:
> 
> Brian, (and Martin),
> 
> I like this structuring of the discussion, and I think it'll be good to use this structure for the discussion in BKK.
> 
> - jana
> 
> On Tue, Oct 30, 2018 at 6:37 AM Brian Trammell (IETF) <[email-masked]> wrote:
> hi Marcus, all,
>

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 31 Oct 2018 19:20:51 +0900

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

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.

-- 
Kazuho Oku

---

From: Ian Swett <[email-masked]>
Date: Wed, 31 Oct 2018 07:11:52 -0400

Thanks Brian, please do not pin it to 0.  I have a strong feeling that
could end badly, particularly if early clients and/or servers do not spin.

On Wed, Oct 31, 2018 at 4:51 AM Brian Trammell (IETF) <[email-masked]>
wrote:

> Greetings, all,
>
> I've merged Christian's PR #1931 which covers discretionary spin, and my
> PR #1937 which covers negotiated spin, into draft-ietf-quic-spin-exp. For
> those of you who'd like text in a draft to accompany this discussion, have
> a look at the editor's copy:
>
> Note that the document has two different suggestions as to what endpoints
> should do with the spin bit when not spinning it: either pin it to 0, or
> select a random value per CID. Picking one is a detail question. IMO,
> either is fine; the latter has a (probably negligible) greasing effect.
>
> Cheers,
>
> Brian
>
>
>
> > I like this structuring of the discussion, and I think it'll be good to
> use this structure for the discussion in BKK.
> >
> > - jana
> >
> > So let me step back a bit and suggest a starting point (borrowing
> heavily from MT in an offlist discussion) for discussing what we want to do
> in BKK. (Or rather, I should say, let me suggest a starting point for y'all
> to discuss, because I doubt I'll be in a position to join remotely at 03:00

---

From: Marcus Ihlar <[email-masked]>
Date: Wed, 31 Oct 2018 12:40:06 +0000

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

--
Kazuho Oku

---

From: <[email-masked]>
Date: Wed, 31 Oct 2018 14:05:29 +0100

On 10/31/2018 01:40 PM, Marcus Ihlar wrote:
> 
> 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.

+1.

Moreover, the same applies to an already established connection when a new 
request fitting in a single packet is emitted by the browser after some idle 
time. Simple temporal filtering allows an on-path observer to extract those 
events even though the handshake is long over.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 31 Oct 2018 15:18:41 +0100

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.

Cheers,

Brian

> On 31 Oct 2018, at 13:40, Marcus Ihlar <[email-masked]> wrote:
> 
> Hi Kazuho,

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 31 Oct 2018 16:32:36 +0000

Since the handshake exposes the RTT information, what is the geolocation privacy issue resulting from the spin bit? Brian, what are the edge cases you refer to where handshake latency will be different than what is measured by spin bit? 

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Brian Trammell (IETF)
Sent: Wednesday, October 31, 2018 7:19 AM
To: Marcus Ihlar <[email-masked]>
Cc: Lars Eggert <[email-masked]>; IETF QUIC WG <[email-masked]>; huitema <[email-masked]>; Dmitri Tikhonov <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: Re: Structuring the BKK spin bit discussion

hi Kazuho, Marcus,

Cheers,

Brian

> > >> implement and deploy, if the WG decided to include the spin-bit 
> > >> in the spec.
> > >

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 31 Oct 2018 18:16:28 +0100

hi Praveen,

> On 31 Oct 2018, at 17:32, Praveen Balasubramanian <pravb=[email-masked]> 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)

then the handshake RTT gives you one sample per flow, and on a per-flow basis, that is not enough evidence to definitively classify that flow as having a far hidden endpoint. The spin bit provides more evidence, since the upper bound on network RTT is the minimum RTT over all samples, and the spin bit gives you more samples per flow.

This is a contrived example, but the additional marginal geoprivacy risk in this specific instance is nonzero, if epsilon. I don't think it's a practical additional marginal risk, though, because:

- the (non-research) techniques I know of that are deployed to prevent breaking of geofences don't rely on latency measurement, rather on lookups in IP address geolocation databases *.
- given that one sample per flow in the handshake RTT and the fact that an endpoint will often generate multiple flows, it will eventually be found out anyway. The answer to the question of using a VPN for robust endpoint hiding is "don't do that". a far endpoint actually wants to remain hidden, it should be using a transport-terminating proxy or an anonymity network like Tor, as opposed to a simple L3.5 VPN.

As I said, turning off the spin bit is about peace of mind and information reduction; in my opinion, even in the absence of practical threat, that's reason enough to provide the option.

Cheers,

Brian

* one of the cool things hiding in that IMC paper I cited upthread is the fact that there's at least one anti-geofencing VPN provider that sells the ability to have your traffic appear to come from any country on earth. While the authors do not come right out and say it, it appears that said provider discovered it was sufficient for their business model to have the traffic originate from one of three easy-to-get-to, near-an-IXP datacenters, on three different continents, and to do some Layer 9 work to have the specific IPs labeled as coming from the desired countries in the commercial IP geolocation databases. Hacking the database is way easier than hacking the speed of light. :)

---

From: Roland Zink <[email-masked]>
Date: Wed, 31 Oct 2018 19:25:27 +0100

> then the handshake RTT gives you one sample per flow, and on a per-flow basis, that is not enough evidence to definitively classify that flow as having a far hidden endpoint. The spin bit provides…

Often devices have patterns where the RTT can be determined. Android and 
iOS devices (and the Chrome browser) for example keep connections to 
push servers and may do periodic keep-alives. Similar when a video is 
watched using adaptive bitrate like MPEG DASH then there are 
periodically idle times followed by a new request and response. So when 
it is only about the privacy of the users RTT then the privacy isn't 
very high anyway and detection isn't restricted to the handshake.

Regards,

Roland

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 31 Oct 2018 11:30:27 -0700

Obviously some research effort has been put into this, but I find it hard
to believe that you cannot approximately geolocate within 3000km
considering that you derive an AES key based on remote timing attacks.

On 31 October 2018 at 19.25.45, Roland Zink ([email-masked]) wrote:

Am 31.10.2018 um 18:16 schrieb Brian Trammell (IETF):
>> Since the handshake exposes the RTT information, what is the geolocation
privacy issue resulting from the spin bit? Brian, what are the edge cases
you refer to where handshake latency will be different than what is
measured by spin bit?
> 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
> - ...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)
>
> then the handshake RTT gives you one sample per flow, and on a per-flow
basis, that is not enough evidence to definitively classify that flow as
having a far hidden endpoint. The spin bit provides more evidence, since
the upper bound on network RTT is the minimum RTT over all samples, and the
spin bit gives you more samples per flow.

Regards,

Roland

> This is a contrived example, but the additional marginal geoprivacy risk
in this specific instance is nonzero, if epsilon. I don't think it's a
practical additional marginal risk, though, because:
>
> - the (non-research) techniques I know of that are deployed to prevent
breaking of geofences don't rely on latency measurement, rather on lookups
in IP address geolocation databases *.
> - given that one sample per flow in the handshake RTT and the fact that
an endpoint will often generate multiple flows, it will eventually be found
out anyway. The answer to the question of using a VPN for robust endpoint
hiding is "don't do that". a far endpoint actually wants to remain hidden,
it should be using a transport-terminating proxy or an anonymity network
like Tor, as opposed to a simple L3.5 VPN.
>
> As I said, turning off the spin bit is about peace of mind and
information reduction; in my opinion, even in the absence of practical
threat, that's reason enough to provide the option.
>
> Cheers,
>
> Brian
>
> * one of the cool things hiding in that IMC paper I cited upthread is the
fact that there's at least one anti-geofencing VPN provider that sells the
ability to have your traffic appear to come from any country on earth.
While the authors do not come right out and say it, it appears that said
provider discovered it was sufficient for their business model to have the
traffic originate from one of three easy-to-get-to, near-an-IXP
datacenters, on three different continents, and to do some Layer 9 work to
have the specific IPs labeled as coming from the desired countries in the
commercial IP geolocation databases. Hacking the database is way easier
than hacking the speed of light. :)
>> Cc: Lars Eggert <[email-masked]>; IETF QUIC WG <[email-masked]>; huitema
<[email-masked]>; Dmitri Tikhonov <[email-masked]>;
Kazuho Oku <[email-masked]>
>> +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.
>>> 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.
>>>> 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.
>>>> 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.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Oct 2018 11:04:23 -0700

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

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: Kazuho Oku <[email-masked]>
Date: Thu, 1 Nov 2018 07:06:27 +0900

Hi,

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

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

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.

-- 
Kazuho Oku

---

From: Mike Bishop <[email-masked]>
Date: Thu, 1 Nov 2018 03:47:40 +0000

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,

Från: QUIC <[email-masked]<mailto:[email-masked]>> för Kazuho Oku <[email-masked]<mailto:[email-masked]>>

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

--
Kazuho Oku