Re: Long Headers and Version Negotiation

Christian Huitema <huitema@huitema.net> Mon, 08 January 2018 03:12 UTC

Return-Path: <huitema@huitema.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 841E9126C83 for <quic@ietfa.amsl.com>; Sun, 7 Jan 2018 19:12:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 hUkI7uUJ5KAz for <quic@ietfa.amsl.com>; Sun, 7 Jan 2018 19:12:19 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDAB1200C1 for <quic@ietf.org>; Sun, 7 Jan 2018 19:12:18 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eYNrE-00031f-WA for quic@ietf.org; Mon, 08 Jan 2018 04:12:17 +0100
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eYNr7-00073K-6n for quic@ietf.org; Sun, 07 Jan 2018 22:12:13 -0500
Received: (qmail 3459 invoked from network); 8 Jan 2018 03:12:06 -0000
Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <martin.thomson@gmail.com>; 8 Jan 2018 03:12:06 -0000
Content-Type: multipart/alternative; boundary="Apple-Mail-3B06F8BB-06AE-4698-BDB3-C84CD1ABC77D"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15C153)
In-Reply-To: <CAM4esxQzrvwBwFr5tTk9ni+-gEs7xzXvzHp1ADy847w4SrNTwQ@mail.gmail.com>
Date: Sun, 07 Jan 2018 17:12:02 -1000
Cc: Martin Thomson <martin.thomson@gmail.com>, Nick Banks <nibanks@microsoft.com>, IETF QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <FB5E9997-E32A-4506-A76D-4AA4F4EFB34D@huitema.net>
References: <CAM4esxRroE5rOXEHgqJ-_5Vdm-=odN7VmWBweKQgTnT5pU87XA@mail.gmail.com> <BN6PR21MB01788D37BFE5700EB00F392AB31C0@BN6PR21MB0178.namprd21.prod.outlook.com> <CABkgnnWUqv2Y2UCaq6EF1cBBKiAzgvua-KQzobPMVHZBcpXvXw@mail.gmail.com> <CAM4esxQzrvwBwFr5tTk9ni+-gEs7xzXvzHp1ADy847w4SrNTwQ@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
Subject: Re: Long Headers and Version Negotiation
X-Originating-IP: 168.144.250.223
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5ktM4Bl8WbbX1qK5NOS07wUXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fstaMFyb7j8NwtrhJTPSNsRB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUx851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XsxRC3Cl5agFgis4e3pTrPTmWL20QDaTB8w3xrEB2b tyezQf64yyfdoQUaciQGLMoHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFCFnwGKkv+DIQGXVP+Qhqh8ibYT4C2qF2lnc18bVJn66D gV2QUMK+k1EjVCaSYktzReNB51/o9aOmbBfZE6T1DDwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTcmOtKpb1oAulsHm1CrhdOljI1dRH6f16eQCtvwPkeoyl2uO1aNahU3xgdP6yeyunl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/LrmHUpb5mvbLXcEz7dcSUZvQ4uE>
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: Mon, 08 Jan 2018 03:12:21 -0000

About 0xFF invariant -- that was one of the issues we found during the December 18 interop. The first byte in the VN packet is unspecified so picoquic was setting it to 0xFF. Legit, but somewhat unexpected.

Another point about VN storms. Servers can of course implement some kind of pacing. They should also only send VN in response to packets that are at least 1200 bytes, since CI must be at least that.

-- Christian Huitema 

> On Jan 7, 2018, at 4:58 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> I am not all that concerned about the VN storm. I'll file an issue, and would like input on "treat all long headers as initials" vs. "Make 0xff invariant".
> 
>> On Jan 7, 2018 3:19 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>> We had a similar concern with TLS, in that a server that advertises
>> 0-RTT support could later decide to disable TLS 1.3.  That leads to a
>> similar sort of issue: 0-RTT data hitting a server that doesn't know
>> how to handle it.  We concluded that advertising 0-RTT was a
>> commitment to support that configuration until the 0-RTT ticket
>> expired (at least to the extent that the server wouldn't choke on
>> 0-RTT).
>> 
>> Mike's right in saying that QUIC is somewhat better able to cope.  Not
>> using ordered delivery means that this turns into a flood of version
>> negotiation packets rather than anything immediately fatal.  That
>> said, we could recommend that servers treat 0-RTT-enabled tickets as a
>> commitment to support a given version.  That effectively means
>> disabling 0-RTT on versions that you plan to decommission.  Maybe
>> that's a manageability consideration more than a protocol one.
>> 
>> On Sat, Jan 6, 2018 at 9:46 AM, Nick Banks <nibanks@microsoft.com> wrote:
>> > If you are sending 0-RTT packets then you have connected to this server
>> > before and should be able to remember the version you used. The only issue
>> > then, is if the server stops supporting a particular version and then you
>> > try to reconnect. Either way, a server might want to have some throttling
>> > logic for VN packets sent out; but I don’t think it would be the end of the
>> > world if it didn’t.
>> >
>> >
>> >
>> > - Nick Banks
>> >
>> >
>> >
>> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Duke
>> > Sent: Friday, January 5, 2018 2:39 PM
>> > To: IETF QUIC WG <quic@ietf.org>
>> > Subject: Long Headers and Version Negotiation
>> >
>> >
>> >
>> > The invariants draft only reserves the 0x80 and 0x40 codepoints in the first
>> > byte of the packet.
>> >
>> >
>> >
>> > The transport draft suggests that only initial packets should trigger
>> > version negotiation. However, the Initial Packet byte (0xff) is not
>> > invariant. So for version negotiation to work at all, servers must send VN
>> > packets for any long header type where the version is unsupported --
>> > otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 servers
>> > would ignore it.
>> >
>> >
>> >
>> > On the other hand, in 0RTT cases this might create a storm of VN packets if
>> > the version is wrong. I suppose clients are probably not sending 0RTT if
>> > they don't know the supported versions.
>> >
>> >
>> >
>> > Am I thinking about this correctly? If so, I'm happy to file an issue, and a
>> > PR if we agree that the correct solution is to reply with VN to all long
>> > headers with unsupported versions.
>> >
>> >
>> >
>> > - Martin Duke