Subject: comments on the spin bit, in lieu of the mic line

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 6 Nov 2018 17:02:39 +0100

Greetings, all,

As I might not make it to tomorrow's discussion remotely, I wanted to go ahead and say a few things that I would say in the mic line. To the questions posed in the agenda:

- Yes, we should consider only the 1-bit variant. The VEC protects the fidelity of the signal very well (indeed, well beyond the bounds of network conditions the transport will tolerate), but (1) Marcus' work in particular has shown that even in challenging network conditions, relatively simple heuristics at the observers can compensate for not having it, so (2) at the cost of two extra bits the marginal value is low.

- Yes, the spin bit is clearly fit for purpose. I'll note we've done more research on this question than for any other single feature under consideration for inclusion in QUIC.

- I am not at this time responsible for any sizeable deployment, so I can't speak directly to the third question. While I hope we'll hear from more implementers during the discussion tomorrow that they intend to implement, IMO even just a deployment from Microsoft would be sufficient to generate enough spinning flows to make deployment of observers useful. 

- The spin bit should be included in the specification. It provides the continued ability to measure RTT passively in a future world where TCP traffic is increasingly replaced by QUIC traffic, at negligible complexity cost, essentially zero runtime overhead, with negligible privacy impact, and what negligible impact it may have on privacy in certain corner cases can be easily mitigated.

- As to requirement levels, I'd stick with my own recommendation from the earlier thread: client and server SHOULD implement, though server SHOULD is IMO marginally more important than client SHOULD.

Now some details (presuming, of course, that the discussion gets that far):

- In any case, both server and client SHOULD independently randomly disable spinning on some proportion of connections (1/8 to 1/16) to target a given proportion (1/4 to 1/8) of connections spinning, as in [section 4 of the author's copy of spin-exp](https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc.section.4). This is to ensure that those endpoints that wish to opt out have a large anonymity set to hide in.

- If we want to maintain the principle of linkability reduction across CIDs, then this non-spinning-state should be independent for each CID. In contrast to what's in section 4 of spin-exp, non-spinning spin bits shouldn't be set to zero, rather to a random value on a per-CID basis. This is easily recognizable by an observer in all cases (client/server participate/nonparticipate-1/nonparticipate-0), and reduces the risk of ossification around nonparticipant action. (This risk is small, to be sure, but we should not clamp a bit to a constant value, if only because we want the protocol's design to consistent.)

- As to whether non-spinning should be negotiated (see [the appendix in the author's copy](https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc.appendix.A)) versus "discretionary", I was originally a fan of negotiation (as it provides a better-than-greasing way to exercise the version negotiation mechanism), but the rules for maintaining the principle of linkability reduction across CIDs become more complicated for negotiated spin, and the benefits for observers (i.e., that an observer can classify flows by version) become far less clear in the face of that linkability reduction. So I would lean toward the discretionary approach for the sake of simplicity -- we'll just have to exercise version negotiation by shipping version 2 soon after version 1. ;)

If I can't join, have fun tomorrow. Cheers,

Brian

---

From: Lars Eggert <[email-masked]>
Date: Tue, 6 Nov 2018 23:13:39 +0700

Hi

thanks Brian (and best wishes!)

If others who aren't going to be able to make it to the meeting, or who would prefer to make comments in writing would do so, that would be helpful in making sure we are receiving the full community input.

Lars

On 2018-11-6, at 23:02, Brian Trammell (IETF) <[email-masked]> wrote:
> - In any case, both server and client SHOULD independently randomly disable spinning on some proportion of connections (1/8 to 1/16) to target a given proportion (1/4 to 1/8) of connections spinning, as in [section 4 of the author's copy of spin-exp](https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc..section.4). This is to ensure that those endpoints that wish to opt out have a large anonymity set to hide in.
>

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 7 Nov 2018 06:57:47 +0700

> - As to whether non-spinning should be negotiated (see [the appendix in the author's copy](https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc.appendix.A)) versus "discretionary", I wa…

Brian, thank you for starting the discussion.

I’m attending, but let me respond here, because I would like to
“optimize to avoid” people using their brain to parse my broken
English expressed verbally :-)

If we are to adopt spin bit, my view is that the use MUST be negotiated.

It seemed to me that we agree to the fact that at least in extreme
cases (e.g. a client or a server behind a intercontinental VPN), there
is a privacy concern in exposing the spin.

Assuming that is true, an endpoint cannot discretionary start exposing
spin bits, because it exposes to the observer who knows the location
of the endpoint (which is the common case) how far the peer is from
it's VPN gateway.

It might be true that negotiating the use makes implementations
slightly complex. But the complexity should not be used as a reason to
ignore privacy concerns, especially in case where the additional
complexity is small.

-- 
Kazuho Oku

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Nov 2018 08:15:14 +0700

Hi Kazuho,

Some responses in-line.
On Wed, Nov 7, 2018 at 6:58 AM Kazuho Oku <[email-masked]> wrote:

> > As I might not make it to tomorrow's discussion remotely, I wanted to go
> ahead and say a few things that I would say in the mic line. To the
> questions posed in the agenda:
> >
> >
> > - Yes, we should consider only the 1-bit variant. The VEC protects the
> fidelity of the signal very well (indeed, well beyond the bounds of network
> conditions the transport will tolerate), but (1) Marcus' work in particular
> has shown that even in challenging network conditions, relatively simple
> heuristics at the observers can compensate for not having it, so (2) at the
> cost of two extra bits the marginal value is low.
> >
> > - Yes, the spin bit is clearly fit for purpose. I'll note we've done
> more research on this question than for any other single feature under
> consideration for inclusion in QUIC.
> >
> > - I am not at this time responsible for any sizeable deployment, so I
> can't speak directly to the third question. While I hope we'll hear from
> more implementers during the discussion tomorrow that they intend to
> implement, IMO even just a deployment from Microsoft would be sufficient to
> generate enough spinning flows to make deployment of observers useful.
> >
> > - The spin bit should be included in the specification. It provides the
> continued ability to measure RTT passively in a future world where TCP
> traffic is increasingly replaced by QUIC traffic, at negligible complexity
> cost, essentially zero runtime overhead, with negligible privacy impact,
> and what negligible impact it may have on privacy in certain corner cases
> can be easily mitigated.
> >
> > - As to requirement levels, I'd stick with my own recommendation from
> the earlier thread: client and server SHOULD implement, though server
> SHOULD is IMO marginally more important than client SHOULD.
> >
> >
> > - In any case, both server and client SHOULD independently randomly
> disable spinning on some proportion of connections (1/8 to 1/16) to target
> a given proportion (1/4 to 1/8) of connections spinning, as in [section 4
> of the author's copy of spin-exp](
> https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc..section.4).
> This is to ensure that those endpoints that wish to opt out have a large
> anonymity set to hide in.
> >
> > - If we want to maintain the principle of linkability reduction across
> CIDs, then this non-spinning-state should be independent for each CID. In
> contrast to what's in section 4 of spin-exp, non-spinning spin bits
> shouldn't be set to zero, rather to a random value on a per-CID basis. This
> is easily recognizable by an observer in all cases (client/server
> participate/nonparticipate-1/nonparticipate-0), and reduces the risk of
> ossification around nonparticipant action. (This risk is small, to be sure,
> but we should not clamp a bit to a constant value, if only because we want
> the protocol's design to consistent.)
> >
> > - As to whether non-spinning should be negotiated (see [the appendix in
> the author's copy](
> https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc.appendix.A))
> versus "discretionary", I was originally a fan of negotiation (as it
> provides a better-than-greasing way to exercise the version negotiation
> mechanism), but the rules for maintaining the principle of linkability
> reduction across CIDs become more complicated for negotiated spin, and the
> benefits for observers (i.e., that an observer can classify flows by
> version) become far less clear in the face of that linkability reduction.
> So I would lean toward the discretionary approach for the sake of
> simplicity -- we'll just have to exercise version negotiation by shipping
> version 2 soon after version 1. ;)
>
I pointed out that this privacy concern also exists for the handshake, and
I did not see a response.  Did I miss a mitigation there, or do you agree
that watching the handshake would also disclose this?

> of the endpoint (which is the common case) how far the peer is from

While I don't personally see that this reveals any new data beyond the
handshake data, I think making this discretionary handles this cases very
well.  A local configuration that says not to spin when going out a tunnel
interface eliminates this risk completely.  The large window of randomly
disabled other flows means that this discretionary choice is not
highlighted in the data.

> I think the complexity of including a configuration option for "no
spinning on tun0-like interfaces" is less than the negotiation complexity.
I would even support that being a default configuration, if that allays
your concerns.

best regards,

Ted Hardie

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 07 Nov 2018 08:30:28 +0700

+1

I agree with Ted that the time for a QUIC handshake would give away the use of a tunnel much the same as the spin bit would. The one case in which a connection could indeed hide the use of a tunnel better would be to establish over a non-tunneled path, and then migrate the connection to a path over a tunnel. This would eliminate performing a handshake over a path that includes a tunnel.

Regardless, my understanding is that negotiation for the spin bit is an added complexity that doesn't provide too much value. Each of the client and the server may have a desire to not spin if they are concerned about a given situation (say, the use of a VPN tunnel). If the client is aware of this situation on its end, it can choose not to spin the bit. If the server is aware of this situation on its end, it can choose to not reflect changes to the bit. This awareness must be present in order to make a negotiated spin bit possible, so it seems like this situation is strictly no worse.

Thanks,
Tommy

> On Nov 7, 2018, at 8:15 AM, Ted Hardie <[email-masked]> wrote:
> 
> Hi Kazuho,
> 
> Some responses in-line.
> On Wed, Nov 7, 2018 at 6:58 AM Kazuho Oku <[email-masked] <mailto:[email-masked]>> wrote:
> 2018年11月6日(火) 23:03 Brian Trammell (IETF) <[email-masked] <mailto:[email-masked]>>:
> >
> > Greetings, all,
> >
> > - In any case, both server and client SHOULD independently randomly disable spinning on some proportion of connections (1/8 to 1/16) to target a given proportion (1/4 to 1/8) of connections spinning, as in [section 4 of the author's copy of spin-exp](https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc..section.4 <https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc..section.4>). This is to ensure that those endpoints that wish to opt out have a large anonymity set to hide in.
> >
> > - As to whether non-spinning should be negotiated (see [the appendix in the author's copy](https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc.appendix.A <https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc.appendix.A>)) versus "discretionary", I was originally a fan of negotiation (as it provides a better-than-greasing way to exercise the version negotiation mechanism), but the rules for maintaining the principle of linkability reduction across CIDs become more complicated for negotiated spin, and the benefits for observers (i.e., that an observer can classify flows by version) become far less clear in the face of that linkability reduction. So I would lean toward the discretionary approach for the sake of simplicity -- we'll just have to exercise version negotiation by shipping version 2 soon after version 1. ;)
> 
> I pointed out that this privacy concern also exists for the handshake, and I did not see a response.  Did I miss a mitigation there, or do you agree that watching the handshake would also disclose this?
> 
> While I don't personally see that this reveals any new data beyond the handshake data, I think making this discretionary handles this cases very well.  A local configuration that says not to spin when going out a tunnel interface eliminates this risk completely.  The large window of randomly disabled other flows means that this discretionary choice is not highlighted in the data.
> 
> 
> I think the complexity of including a configuration option for "no spinning on tun0-like interfaces" is less than the negotiation complexity.  I would even support that being a default configuration, if that allays your concerns.
> 
> best regards,
> 
> Ted Hardie
> 
>  
> >

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 7 Nov 2018 08:44:32 +0700

Ted, thank you for the response. My comments inline.

> I pointed out that this privacy concern also exists for the handshake, and I did not see a response.  Did I miss a mitigation there, or do you agree that watching the handshake would also disclose…

My response to that point is that exposing a RTT once (during
handshake) and exposing once per every RTT gives an observer a
different accuracy on what the exact latency is. While I agree that
there are other ways to observe RTT, having spin bits is likely to be
a good way to improve the accuracy from observer's point of view.

FWIW, I think I have pointed that out on
https://www.ietf.org/mail-archive/web/quic/current/msg04935.html, but
was not a response to you.

> While I don't personally see that this reveals any new data beyond the handshake data, I think making this discretionary handles this cases very well.  A local configuration that says not to spin w…

My bad. I was confused with another option of a spin-bit design that
does not require a peer to coordinate. I agree that the current
mechanism requires the peer's cooperation to expose the RTT.

> I think the complexity of including a configuration option for "no spinning on tun0-like interfaces" is less than the negotiation complexity.  I would even support that being a default configuratio…

Yeah. That is exactly why I asked if there is a privacy concern for
client devices hiding behind a carrier-grade NAT.

Brian's response was that it is not a concern if the distance of the
hidden path is behind 3,000km, while Mike and Roland pointed out that
in case of a user on a roaming the distance could go well above that.

That makes me wonder how you can build a sensible mechanism to detect
when spin bit should be enabled / disabled. Do you have any
suggestions?

--
Kazuho Oku