Re: HTTP/2 GREASE, Results, and Implications

Tom Bergan <tombergan@chromium.org> Fri, 15 November 2019 15:14 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4374120879 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Nov 2019 07:14:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 vuMmuRZ6EJb2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Nov 2019 07:13:57 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 F18F9120893 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 Nov 2019 07:13:49 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iVdFL-0006ns-QR for ietf-http-wg-dist@listhub.w3.org; Fri, 15 Nov 2019 15:10:51 +0000
Resent-Date: Fri, 15 Nov 2019 15:10:51 +0000
Resent-Message-Id: <E1iVdFL-0006ns-QR@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <tombergan@chromium.org>) id 1iVdFI-0006n1-QX for ietf-http-wg@listhub.w3.org; Fri, 15 Nov 2019 15:10:48 +0000
Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <tombergan@chromium.org>) id 1iVdFH-0005IF-Eu for ietf-http-wg@w3.org; Fri, 15 Nov 2019 15:10:48 +0000
Received: by mail-ot1-x332.google.com with SMTP id n23so8238378otr.13 for <ietf-http-wg@w3.org>; Fri, 15 Nov 2019 07:10:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F2eBtafgFKZV9tzsKRniDQzrR14OtTWhXkZNFoPFhhU=; b=BHNQ+XdrYRNzaM2kRYvGfC+xeUysugysiAU/97w2WUY99Kr0Nfu/Tb6cPUpe0+/V2o vCDKjOWoijpCp/cV8ExVcBWl6uJswoxE/M40IwRrUhYlULpb4uII2gV+9tE0G9idzbuJ E/tPCsb17qmMSyV4kLwBswXVWGk+xi4KekZXw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F2eBtafgFKZV9tzsKRniDQzrR14OtTWhXkZNFoPFhhU=; b=FzcJbK7TqyoTToleTHtVex/Qgc+2oH8Bi0iq+wwMGjbGkmo0RP2hHOIi71xxXVT0im 3rRCHx4Ry4+F3gr8zdiHpnI//OKAfqE4yRTlBBRKEkf7LmcCC0kUKAJ8saUS+IKozA0E HO7XgoDFZhcTPpeD5WV7EzMZvNh1cokm+OKmzvnLOQgPCY38RjyLr/6rXgSebPgthRDu HR2z6ASZXyAz6m2Dk1/BnjL6DlKKGC3H23JNG9IbpWrOYy7hLaTldpMEpUIp4lH4a+x7 +q5QCqIVAcRkfdGztPSb61eH8fOQuK6XiarOtiEGgZjqmBKxmvAyxEjhwgM62c3yRXbn sHoA==
X-Gm-Message-State: APjAAAVzVOb2MCmLmbgmeZxn0ErW6x8gKYzRoZtBsKzAESZPDw366Ypq joSGYiyemBSa4/gHG1TEYzvyx4Y8x08=
X-Google-Smtp-Source: APXvYqy9h64y7igSABLBHCqvGL05B0AWuIxeDe3KL+KRnr8uyhjwjJKR8q5192KldFyU6L9x2Koy1A==
X-Received: by 2002:a05:6830:1319:: with SMTP id p25mr9013593otq.110.1573830645475; Fri, 15 Nov 2019 07:10:45 -0800 (PST)
Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com. [209.85.210.41]) by smtp.gmail.com with ESMTPSA id n5sm2812003oie.16.2019.11.15.07.10.44 for <ietf-http-wg@w3.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Nov 2019 07:10:44 -0800 (PST)
Received: by mail-ot1-f41.google.com with SMTP id r24so8250587otk.12 for <ietf-http-wg@w3.org>; Fri, 15 Nov 2019 07:10:44 -0800 (PST)
X-Received: by 2002:a9d:344a:: with SMTP id v68mr12153119otb.85.1573830643740; Fri, 15 Nov 2019 07:10:43 -0800 (PST)
MIME-Version: 1.0
References: <BN6PR2201MB1700D10A34C72213C78E09A6DA630@BN6PR2201MB1700.namprd22.prod.outlook.com> <20191031155259.GC30674@1wt.eu> <CACMu3trL5UMukoPd8Nr4W-bMsyH+WKUnwg16yxu3tN5D=uZt8w@mail.gmail.com> <20191031203458.GA31017@1wt.eu> <CACMu3toue60Y_6Qxpzsqw-fOByc3Qjv=AG8Ed_DGvkR1EYn+4w@mail.gmail.com> <20191101131903.GA1988@1wt.eu> <6F4160E3-D460-4DD9-9931-348479F6437F@greenbytes.de> <CACMu3trFUKpywX1GoChNn59B1tOmOUuaPESVFPy2u7Ah3gy0Jw@mail.gmail.com> <20191106202411.GA15081@1wt.eu>
In-Reply-To: <20191106202411.GA15081@1wt.eu>
From: Tom Bergan <tombergan@chromium.org>
Date: Fri, 15 Nov 2019 07:10:31 -0800
X-Gmail-Original-Message-ID: <CA+3+x5GyCgh2JROXwd+mo3Rsew1EDzJ6diyvHoLv3JwbJLg6Xg@mail.gmail.com>
Message-ID: <CA+3+x5GyCgh2JROXwd+mo3Rsew1EDzJ6diyvHoLv3JwbJLg6Xg@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: =?UTF-8?Q?Bence_B=C3=A9ky?= <bnc@chromium.org>, Stefan Eissing <stefan.eissing@greenbytes.de>, Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000755b3b05976400c6"
Received-SPF: pass client-ip=2607:f8b0:4864:20::332; envelope-from=tombergan@chromium.org; helo=mail-ot1-x332.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1iVdFH-0005IF-Eu 51c9e96deb50440c5d3202f6694d6bf2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <https://www.w3.org/mid/CA+3+x5GyCgh2JROXwd+mo3Rsew1EDzJ6diyvHoLv3JwbJLg6Xg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37134
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

I would like to revisit the ambiguity that Willy pointed out in this
thread. On the one hand, we have this statement, which appears in Sections
4.1 and 5.5:

1. Implementations MUST discard frames that have unknown or unsupported
types.

On the other hand, we have statements like the following, which appear in
Section 5.1:

2a. idle: Receiving any frame other than HEADERS or PRIORITY on a stream in
this state MUST be treated as a connection error.

2b. half-closed (remote): If an endpoint receives additional frames, other
than WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in this
state, it MUST respond with a stream error

If this ambiguity is resolved in favor of Section 5.1, then it becomes
difficult or impossible to define a new priority scheme in an HTTP/2
extension. In particular:

- It might be desirable to send a NEW_PRIORITY frame before HEADERS, as a
replacement for priority information that is built into HEADERS. This
conflicts with (2a).

- It might be desirable to send a NEW_PRIORITY frame after END_STREAM, so
the client can reprioritize a lengthy response. This conflicts with (2b).

For this reason, I propose that this ambiguity should be resolved in favor
of Section 5.5. We should release an errata which clarifies that the rules
in Section 5.1 do not apply to frames of unknown type. If an extension
defines a new frame type, it must explicitly enumerate the states in which
that frame can be sent and received. Willy also raised a concern about new
frame types that include END_STREAM. I think this is covered by Section
5.5, which says "Extensions that could change the semantics of existing
protocol components MUST be negotiated before being used." If a new frame
type can end the stream, this adds an edge to the state diagram in Section
5.1, therefore, support for the new frame type must be negotiated before it
can be used.

Thoughts?

On Wed, Nov 6, 2019 at 12:27 PM Willy Tarreau <w@1wt.eu>; wrote:

> Hi Bence,
>
> On Wed, Nov 06, 2019 at 03:03:18PM -0500, Bence Béky wrote:
> > Hi,
> >
> > I added two simple command line flags to Chrome to trigger sending
> greased
> > HTTP/2 elements, and they are available since version 80.0.3960.0 (not on
> > Linux quite yet).
>
> OK, thanks for letting us know.
>
> > --http2-grease-settings adds one settings parameter with a reserved
> > identifier and random value to every SETTINGS frame sent (one per HTTP/2
> > connection).
> >
> > --http2-grease-frame-type sends one frame of reserved type and random
> short
> > payload after every SETTINGS and HEADERS frame, including HEADERS frames
> > with END_STREAM flag set.  This is what caused problems apparently with
> > Cloudflare and Akamai.
>
> And haproxy, given that this violates the rule of no frame type other than
> the few allowed one in half-closed remote state. The problem with allowing
> new frame types during forbidden states is that we could make it way
> harder to implement these new frame types later without risking to see
> them behave differently depending on implementations. I suspect that if
> we want to go down that route we'll need to either reserve certain frame
> types as carrying no payload for streams and others as possibly having
> some :-/ In addition, frame flags are defined per-frame, eventhough we
> all know they are the same. But new frames exhibiting an END_HEADERS
> flag or an END_STREAM flag cannot be completely ignored. Frames
> designating an idle stream ID which are not HEADERS frame will also
> possibly create a stream or not and cause issues. I think that at the
> moment the only way we have to continue to ignore frames is :
>
>   - ignore the unknown ones on stream 0
>   - ignore the unknown ones on non-idle, non-half-closed(remote) streams
>   - respect existing rules for existing states (i.e. reject what doesn't
>     match certain types for idle, half-closed, reserved.
>   - and likely define how to deal with known flags in the remaining
>     cases.
>
> Just my two cents.
>
> Cheers,
> Willy
>
>