Spin bit discussion - where we're at

Mark Nottingham <mnot@mnot.net> Wed, 22 November 2017 08:06 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220D512711A for <quic@ietfa.amsl.com>; Wed, 22 Nov 2017 00:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=o6gq04qK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YYyB7IT1
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NneQ2ZaJSBZ for <quic@ietfa.amsl.com>; Wed, 22 Nov 2017 00:06:53 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF88126CBF for <quic@ietf.org>; Wed, 22 Nov 2017 00:06:53 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EB35D20DDB; Wed, 22 Nov 2017 03:06:52 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 22 Nov 2017 03:06:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=tOHCH4Axj7RDKeZJgETOjZmTlhIcCwM1Z6KezLf6+Z8=; b=o6gq04qK RbR9oJOi6eWB+6ILoLtOp31k77W2yAzn3KN7uWKFsxbGVBRazSnhL+dLL4Qh9dhq tzUmzhXL5CJsIDYNhczyYZkFHYygF2eUp9TwDCrObobIynFebzLteVRdUS+eVKTx gTEuDhzUz0NIPpJRBgCa7Kw0rpsZLvpWLLkmRh8JP8q3G1LyMIsyb0w73HhOsTm/ VsbGJocX9xmgEHwDyoCyufMv2p9/hs8UB0wZO5zOHCuNIFe53sSkbc68khpKDkZx JGOpvKr1+Zs4NKZ5QN6lakr8aWP5j9TfxywJUUxBolWel22dfC+QDHJQycfwzT7W xjM43wFmwaeBRw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=tOHCH4Axj7RDKeZJgETOjZmTlhIcC wM1Z6KezLf6+Z8=; b=YYyB7IT1/OsUzLR/cy4eNRMdSmc0coR8+XhALzdYn2rwO sFa2CgCMXUe09vL81H3deGFCyYTuC231Amo54mQPbH16stho0aXYHV5qMHLYNOgB IJ+cAXBR/U6e5OnHQlZRnEFzouBCvCtyyQWmOdY32iwuSHsR4CEn1Mseqh93htUT eDE16CwyqssFPpzObc84xktoShSnqS5E5g/CDu9fjlPPD3JioyK66x+JlfLgi8zM QCQJSX8/1asTwb3aTJLtu5GNVXSAJaQq+EY82SXnBObzajYDseZnkRvLzmczjK39 DXBdt6wY83l6+pzwpGbTNT28iLAySK67mPEaBlI2w==
X-ME-Sender: <xms:HDAVWt0K-2b6p8amlI0xdKwNDTsIBnawvrNbe4AV68XZeHFCX5ogYw>
Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id EDBE4244E7; Wed, 22 Nov 2017 03:06:51 -0500 (EST)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Spin bit discussion - where we're at
Message-Id: <AFEE7BBA-E5DC-4064-AA19-33921EAF4C01@mnot.net>
Date: Wed, 22 Nov 2017 19:06:48 +1100
Cc: Lars Eggert <lars@netapp.com>
To: QUIC WG <quic@ietf.org>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DzHbWfr11RjpTrRg6VAS5dGjYlQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2017 08:06:56 -0000

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