Spin bit discussion - where we're at

[Mark Nottingham <[e-mail]>]

Hi everyone,

First, thanks to everyone for their input to date on this issue, whether as part of the Design Team (DT), in the meetings, or on the list. It'd good to see that we can stay civil and professional even when discussing contentious issues.

Since the DT didn't return a recommendation, several people have asked how we're going to move forward. After talking to our Area Director, we'd like to share our current thinking in this area.

The most important things here are to establish that there isn't any significant security or privacy exposure associated with proposed mechanism(s) to improve the manageability of QUIC, and to assure that the mechanism we ship actually serves its purpose. How we assess these two things are fundamentally different; security and privacy exposures are notoriously difficult to find (often only becoming apparent years after a protocol is adopted), while value to network operators is (comparatively) much easier to assert.

We can't prove that there is *no* security or privacy exposure (see: Russell's teapot), but we can take reasonable steps to assess proposals for risk. The Design Team performed this assessment for the Spin Bit proposal, and did not identify any immediate exposure. That does not mean it does not exist, but we've done a reasonable first review for that proposed mechanism. Further review of the Spin Bit can take place by circulating a full specification among security researchers (see below).

Importantly, any further proposals (e.g., for a "loss bit", or for alternative means of determining RTT) will need to undergo similar review and will therefore require a similar level of documentation.

There are a number of things that we think will help clarify the value provided by the Spin Bit:

1) A description of the use case(s) that motivate this proposal. We understand that the goal is to measure RTT, but some people are still unclear as to why that's necessary to operate a network. Detailed scenarios and ideally real-world examples (e.g., from TCP) would help tremendously. Saying "I need to debug the network" is not enough detail.

2) An actual protocol specification for the Spin Bit, including Privacy Considerations. There seems to be a fairly good common understanding of it (especially in the DT), but it would be helpful to have it written down, so we can make sure we're talking about the same thing. If it were proposed as an extension, current implementations (reminder: we have 12) could implement it to see how it works on the network. Doing so would also give the security research community something to look at (see above).

3) Data showing that the Spin Bit is fit for purpose under real-world conditions. Piet's experiment is a start here, but we need much more. Analysis of how well that data meets the use cases is also necessary. This might form part of the Manageability Considerations of the draft.

4) A comparison of other potential solutions to measuring delay, and their relative merits. Again, ideally with detailed, real-world data.

5) An exploration of what the effects of deploying the spin bit are likely to be. E.g.: Will even the perception of privacy issues change endpoint behaviour? Will networks treat traffic differently based upon the spin bit? If so, can that be gamed? Will firewalls and other gateways police spin bit behaviour (e.g., to prevent data loss), and what effects will that have?

We're looking for volunteers to start drafting one or more documents along these lines. If you're interested, please indicate this on-list, so you can coordinate with other interested parties. They won't (yet) be WG documents, but since the DT didn't resolve the issue, we will discuss them in the WG.

In terms of timeline - resolving this is NOT a blocking issue; i.e., we can discuss this concurrently with other work on the protocol, and because it's such a small change in the packet layout, we can add it right before shipping the protocol to the IESG.

In light of that, we will NOT discuss this (or related) issues at the Melbourne interim. That will allow the people attending to focus on continued protocol development, and means that people don't feel the need to travel to discuss just this issue. We would like to be able to move the discussion forward at IETF101 in London, provided that significant progress is made on the items above.

Cheers,


Your Chairs, Mark and Lars