signaling that QUIC is QUIC was Re: Spin bit decision

"Brian Trammell (IETF)" <ietf@trammell.ch> Tue, 02 October 2018 20:17 UTC

Return-Path: <ietf@trammell.ch>
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 B33C113112E for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 13:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
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 THsqORQxMCkE for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 13:17:28 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4170A131110 for <quic@ietf.org>; Tue, 2 Oct 2018 13:17:28 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3693D34118B; Tue, 2 Oct 2018 22:17:26 +0200 (CEST)
X-Iway-Path: 0
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/14501.9690); Tue, 2 Oct 2018 22:17:23 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Tue, 2 Oct 2018 22:17:23 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.83]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 69131424; Tue, 02 Oct 2018 22:17:23 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <475EF632-6078-443F-876C-BA25C17E152B@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_AD1918B1-588A-47E6-8FA7-F6F7F76688EF"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: signaling that QUIC is QUIC was Re: Spin bit decision
Date: Tue, 02 Oct 2018 22:17:22 +0200
In-Reply-To: <CAOYVs2o2AUN7-SV=8EcW31juLo4wZUXWrkfNMGj7+8LSH4recA@mail.gmail.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>, Mike Bishop <mbishop@evequefou.be>, alexandre.ferrieux@orange.com
To: Marten Seemann <martenseemann@gmail.com>
References: <14531_1538460420_5BB30B04_14531_237_4_c0f3a391-9897-80b0-575b-aa73edad0d52@orange.com> <9A63F295-5DC5-4992-9A9C-A98F72C8430D@eggert.org> <22440_1538469028_5BB32CA4_22440_292_2_8e00a462-2bbf-acf0-1195-74269a0c2fbd@orange.com> <3E3DBC15-FE42-47CF-AF7A-1F2597ED2390@eggert.org> <24019_1538484216_5BB367F8_24019_26_1_8e6b0d8e-78f0-56c7-e731-da2ff22cb194@orange.com> <08A9C80F-59E6-46EE-A4D4-1F78F5085CF7@eggert.org> <9737_1538485723_5BB36DDB_9737_147_1_82e0e028-b0e8-5e09-7bd5-e66db97c556a@orange.com> <E7479831-9594-444E-9545-A162E8D9B154@eggert.org> <32072_1538492813_5BB3898D_32072_266_1_8380ff40-29fe-269b-8ed7-4331c9e53f4d@orange.com> <MWHPR22MB0991D93D706031603B077BFCDAE80@MWHPR22MB0991.namprd22.prod.outlook.com> <CAKcm_gM+zAEwfimHsorsWprJgS7O++85EOjpQoNY0LviaQ+KNQ@mail.gmail.com> <CAOYVs2o2AUN7-SV=8EcW31juLo4wZUXWrkfNMGj7+8LSH4recA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hp1mztO-rTzdcskHe7RslIvgb1o>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 02 Oct 2018 20:17:32 -0000

hi Marten,

> On 2 Oct 2018, at 20:07, Marten Seemann <martenseemann@gmail.com> wrote:
> 
> > One of my concerns is unintentional mis-use of the signal, and if it can't be detected reliably in a mixed environment, that means SHOULD is unwise and argues for either not including it or making it a MUST.
> 
> The problem is, even if we decide to make it a MUST, a middlebox still needs to distinguish between QUIC traffic and other UDP traffic. We're not exposing any unambiguous signal to the path that a particular flow actually is QUIC traffic, so middlebox vendors will have to come up with some kind of heuristic to identify QUIC.

Will have to, have already, will continue to. Neither wishful thinking nor stern lectures in RFCs nor the suitable application of strong cryptography will make the *perceived* requirement to distinguish QUIC from not-QUIC go away (without comment on whether this perception is accurate).

> My fear is that if all implementations actually implement the spin bit, and middleboxes learn to rely on that signal (and enforce compliance), we might do great harm to other UDP based protocols (current and future) which happen to use the same code points that middleboxes came to rely on.

Notwithstanding that tracking spin edges to determine whether something is QUIC or not would be a heuristic so heavyweight that widespread deployment of spin-classification would be unlikely, IMO the correct design in the face of this fear has nothing to do with the spin bit at all -- if we care about keeping middleboxes from breaking things accidentally, then we should give these middleboxes something to grab on to that *won't* cause collateral damage: QUIC's invariants should be designed in such a way that a flow as defined by 5-tuple, if not a packet without the context of such a 5-tuple, can be unambiguously and obviously classified as QUIC. We kind of got close to this during the New York interim during the first octet discussion with the "QUIC bit"; maybe we should make that explicit.

> Coming back to Alexandre's question, I think here is little an experiment could do to assuage that fear. This is just another symptom of exposing this signal in the wrong OSI layer.

(as an aside, as to whether transport-experienced end-to-end RTT measurability is a transport or network layer function, see also section 5.1 of draft-trammell-tsvwg-spin.)

Cheers,

Brian

> 
> On Tue, Oct 2, 2018 at 10:18 AM Ian Swett <ianswett=40google.com@dmarc.ietf.org> wrote:
> One piece of information related to the above discussion is whether detecting who is and is not spinning is easy and reliable.
> 
> One of my concerns is unintentional mis-use of the signal, and if it can't be detected reliably in a mixed environment, that means SHOULD is unwise and argues for either not including it or making it a MUST.
> 
> On Tue, Oct 2, 2018 at 12:51 PM Mike Bishop <mbishop@evequefou.be> wrote:
> I don’t think it’s a grim view, I think it’s a pragmatic view.  Our role is to specify the things which are fundamental to the protocol and have to happen for peers to interoperate.  Mis-using normative language for other things is an abuse of the process -- that's kind of the point of RFC 6919.
> 
> 
> 
> RFC 2119 says:
> 
> In particular, [normative language] MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)  For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
> 
> 
> 
> Given that the spin bit is not “actually required for interoperation,” but is the very definition of “try to impose a particular method on implementors,” I’d say that RFC 2119 imperatives are unwarranted.
> 
> 
> 
> -----Original Message-----
> From: QUIC <quic-bounces@ietf.org> On Behalf Of alexandre.ferrieux@orange.com
> Sent: Tuesday, October 2, 2018 8:05 AM
> To: Lars Eggert <lars@eggert.org>
> Cc: IETF QUIC WG <quic@ietf.org>
> Subject: Re: Spin bit decision
> 
> 
> 
> On 10/02/18 16:00, Lars Eggert wrote:
> 
> >
> 
> > The point I can't seem to be getting across is that irrespective of
> 
> > what the WG decides to require, there is no penalty for individual
> 
> > stacks at deployment time (or after) to do whatever they wish, since
> 
> > the spin bit by design has no impact on protocol operation and interop.
> 
> 
> 
> It is getting across, but it is a very grim view of the standardization process itself. Are there many examples of MUST in RFCs that turned out to be ignored by implementations just because they were not part of the core semantics and hence not enforced by other peers ?
> 
> 
> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 
> 
> 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.
> 
> 
>