Re: Long Headers and Version Negotiation

Martin Duke <martin.h.duke@gmail.com> Mon, 08 January 2018 02:58 UTC

Return-Path: <martin.h.duke@gmail.com>
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 545F2126CF9 for <quic@ietfa.amsl.com>; Sun, 7 Jan 2018 18:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xakqshXg6QdQ for <quic@ietfa.amsl.com>; Sun, 7 Jan 2018 18:58:43 -0800 (PST)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDAE61200C1 for <quic@ietf.org>; Sun, 7 Jan 2018 18:58:42 -0800 (PST)
Received: by mail-wr0-x22c.google.com with SMTP id p17so9293527wre.7 for <quic@ietf.org>; Sun, 07 Jan 2018 18:58:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p0JcbxHcNtRyZ9jvVqUE77mC8xhPtYyi2Ow+p+jNXHc=; b=bAntdkYYFQs5DKYBAb/4c4JT9CmJjMkFe77uaQlrY3ZYE/YPYsy1id6hyNNxWoIElj Fa6PYAgyM5nuoP+TJFAyRdku/QPEK77JlhHmOkGWzQhhXGwQq3fm/GKQdwW8s5O6WVRF 06tqputUide2G+2fQ4KoFNxU3WJgd5Uw2DGFa2txNq5vmB/oMlI/uWpZPZ09NLarEwmU E+RhAmpIMBOHly22M2Lz1ER8zBT0viudrJW9pQsnTFK5uSaDpjjxn224xt9aOP8rRxY5 oc/l5gWv/n2sMLC09aJw2Lkcv89gm5cCvIelGxL4JDSNSB8kV3NgeZl4AoBfiswdzoGU unXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p0JcbxHcNtRyZ9jvVqUE77mC8xhPtYyi2Ow+p+jNXHc=; b=VxRYiMze9FJHsEkMsWJoCsIw3dP2znbFKtS+hh9sFBbZrBB0/WF5CtKGsILoReelSa OjqBmR6bWf3PR+m3nIHOTQmOkIrbJTOonOCalIr7OOz3+XtuB7eifw2ptmRP8JibPnqv 4xYN9e1IlErp7riOpRoSnXKHpoi5zEnxFpYj4bbcY82/POKVf7aIz6vFRlhUuaHCAg7e lM9fK6wxqQKEDcP2gxmMLx7mmrx/e8X/y8L0gG+G0282CaXE6Aw5q2J5hv2OjUMdOLnc /dKnjKjRzMHj2WQxKMuw1lLI97SGNZuOzqQ7ffznyXFwHFe65FHICsKlxzHe/LcfyGYB 0PkA==
X-Gm-Message-State: AKGB3mI+1ijSdlvmUtAmFzW5eDcuclb6b9WoMOhMzllc6mo7FGHC6M9I yb4KSV6jgBY5GU+ATNq1dULLprca/dWjiPHhNPU=
X-Google-Smtp-Source: ACJfBotjKihrs/Co8uJKKDhAws7TXpD9Z4z14b92a7icoiJPWl5Jng+uZiwHboJs9KyDliUZDjcP25fA6evM2vyQZ+I=
X-Received: by 10.223.150.213 with SMTP id u79mr2180554wrb.137.1515380321246; Sun, 07 Jan 2018 18:58:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.128.1 with HTTP; Sun, 7 Jan 2018 18:58:40 -0800 (PST)
Received: by 10.223.128.1 with HTTP; Sun, 7 Jan 2018 18:58:40 -0800 (PST)
In-Reply-To: <CABkgnnWUqv2Y2UCaq6EF1cBBKiAzgvua-KQzobPMVHZBcpXvXw@mail.gmail.com>
References: <CAM4esxRroE5rOXEHgqJ-_5Vdm-=odN7VmWBweKQgTnT5pU87XA@mail.gmail.com> <BN6PR21MB01788D37BFE5700EB00F392AB31C0@BN6PR21MB0178.namprd21.prod.outlook.com> <CABkgnnWUqv2Y2UCaq6EF1cBBKiAzgvua-KQzobPMVHZBcpXvXw@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Sun, 7 Jan 2018 18:58:40 -0800
Message-ID: <CAM4esxQzrvwBwFr5tTk9ni+-gEs7xzXvzHp1ADy847w4SrNTwQ@mail.gmail.com>
Subject: Re: Long Headers and Version Negotiation
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f54d2bf654c05623af96c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/zAnxnsfdfrio-7bdSqIrN_R5KV8>
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 02:58:45 -0000

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
>