Re: H2: Should there be a limit to tolerance ?

> Am 17.02.2017 um 10:52 schrieb Poul-Henning Kamp <phk@phk.freebsd.dk>:
> 
> In RFC7540, 5.5 we have:
> 
>   Implementations MUST ignore unknown or unsupported values in all
>   extensible protocol elements.  Implementations MUST discard frames
>   that have unknown or unsupported types.  This means that any of these
>   extension points can be safely used by extensions without prior
>   arrangement or negotiation.
> 
> Such unlimited tolerance for what might be plain garbage seems unwise.

Most of "plain garbage" will run against stream state restrictions as described in Section 5.1, I'd assume. Any attempt to start a stream without proper frame type will run into a PROTOCOL_ERROR and the connection will close. So, I'd assume that plain garbage connections will not last very long. If you see other data, I'd be interested.

That leaves the cases where
a) your counterpart speaks a flavour of valid h2 that you do not know. That is the extensibility that the spec tries to achieve, AFAICT.
b) your counterpart is a malicious actor that tries to attack you in some way. The defence against this does not really belong into RFC 7540, I think. But it's good to share here.

> We have covered the trivial case of an endless stream of zero bytes
> (DATA on stream=0 is CONN::PROTOCOL_ERROR) but a surprisingly large
> percentage of random garbage runs straight through the clause above
> and into /dev/null.
> 
> Has anybody else implemented limits to patience in this area, and if
> so should we try to coordinate our criteria ?

Apache httpd has limits in place for clients spamming CONTINUATION frames on a stream and it also gets annoyed by clients that open multiple streams, but are reluctant to send WINDOW_UPDATEs for them. 

-Stefan

> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> 

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Received on Friday, 17 February 2017 10:50:46 UTC