Re: HTTP/2 GREASE, Results, and Implications

[Willy Tarreau <[e-mail]>]

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