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

From: Poul-Henning Kamp <[email-masked]>
Date: Fri, 17 Feb 2017 09:52:00 +0000

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.

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 ?

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

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 17 Feb 2017 11:50:26 +0100

> Am 17.02.2017 um 10:52 schrieb Poul-Henning Kamp <[email-masked]>:
> 
> In RFC7540, 5.5 we have:
> 

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.

> 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

Stefan Eissing

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 17 Feb 2017 11:17:09 +0000

--------
In message <[email-masked]>, Stefan Eissing
 writes:

>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.

Yes, and that's smart & fine & everything.

And in general you can probably expect the counterpart to stop
sending extensions when nothing comes back indicating they make
any difference.

But what if the counterpart just keeps hammering you with frames
which you ignore ?

What if it keeps hammering you with *only* frames which get ignored ?

What if it does so at very high rate, because it is buggy or hostile ?

What if the buggy implementation was in several million Internet-Of-Shit
things that got poured into concrete years ago ?

There's got to be _some_ limit to patience ?

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 17 Feb 2017 12:21:44 +0100

> Am 17.02.2017 um 12:17 schrieb Poul-Henning Kamp <[email-masked]>:
> 
> --------

Sure. But do you think it should be part of the RFC?

Stefan Eissing

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 17 Feb 2017 11:29:31 +0000

--------

>Sure. But do you think it should be part of the RFC?

No, that's probably overdoing it.

But I think it would make sense to loosely coordinate whavever
criteria we chose, so that any future extensions don't have
to navigate a needless minefield.

Right now I'm pondering these two criteria:

  More than N (25?) frames in row didn't cause our state to change.

and

  More than N (250?) extension points ignored.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 18 Feb 2017 09:05:06 +1100

> There's got to be _some_ limit to patience ?

See http://httpwg.org/specs/rfc7540.html#dos

I realize that we don't mention unknown frame types.  That's an oversight.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 17 Feb 2017 23:01:05 +0000

--------

>See http://httpwg.org/specs/rfc7540.html#dos

Yes, I've seen that.

What I'm asking is if we should try to avoid have N different
critieria for N different implementations or if it makes sense
to try to coordinate some sort of same-ish criteria.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 18 Feb 2017 20:59:08 +1100

> to try to coordinate some sort of same-ish criteria.

I'd caution that releasing actual numbers tends to create an exposure,
once someone knows what the limit truly is, they know the limits of
the abuse they can perform.  I think that was why Roberto was
reluctant to pin anything down.  Making the limits configurable might
help avoid some of that problem, for those of us with less of a closed
source viewpoint.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 18 Feb 2017 19:52:16 +0000

--------
In message <[email-masked]>, Martin Thomson writes:
>the abuse they can perform.

Ohh, absolutely, they should be configurable.  I was thinking more
in terms of the criteria rather than the precise limits.