IETF Logo Mail Archive

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

Stefan Eissing <stefan.eissing@greenbytes.de> Fri, 17 February 2017 10:53 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 8BAF61299B2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Feb 2017 02:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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=greenbytes.de header.b=ehzNjtaD; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=ehzNjtaD
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 aORVgPnHZce7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Feb 2017 02:53:38 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D208A1299B0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 17 Feb 2017 02:53:38 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ceg7n-0004sU-Kj for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Feb 2017 10:50:51 +0000
Resent-Date: Fri, 17 Feb 2017 10:50:51 +0000
Resent-Message-Id: <E1ceg7n-0004sU-Kj@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <stefan.eissing@greenbytes.de>) id 1ceg7i-0004rh-Ba for ietf-http-wg@listhub.w3.org; Fri, 17 Feb 2017 10:50:46 +0000
Received: from mail.greenbytes.de ([5.10.171.186]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <stefan.eissing@greenbytes.de>) id 1ceg7b-0001kE-A6 for ietf-http-wg@w3.org; Fri, 17 Feb 2017 10:50:41 +0000
Received: by mail.greenbytes.de (Postfix, from userid 117) id B864815A03DC; Fri, 17 Feb 2017 11:50:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1487328611; bh=/CMUFJrjv1o+7pQ+dGdJETKtkCIHj/uj6BR10+lvP4c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ehzNjtaD01oSn4geGNah0Aq33/hfkXeSJ0GSxdDjGY2WPxq2nJUFnGnLR9IrGiRq6 JKUOimK0bwd9trjJMtj9lInxWOOf1ETjIzQF84b5QtM19qVwfYpG9RlSD+gM1N4rqF OGalrxx3Nz7FyzxEOLt99la05pZxtREAr18EIQI8=
Received: from [192.168.1.150] (unknown [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 3B8FD15A03DC; Fri, 17 Feb 2017 11:50:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1487328611; bh=/CMUFJrjv1o+7pQ+dGdJETKtkCIHj/uj6BR10+lvP4c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ehzNjtaD01oSn4geGNah0Aq33/hfkXeSJ0GSxdDjGY2WPxq2nJUFnGnLR9IrGiRq6 JKUOimK0bwd9trjJMtj9lInxWOOf1ETjIzQF84b5QtM19qVwfYpG9RlSD+gM1N4rqF OGalrxx3Nz7FyzxEOLt99la05pZxtREAr18EIQI8=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <90502.1487325120@critter.freebsd.dk>
Date: Fri, 17 Feb 2017 11:50:26 +0100
Cc: ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D199BE90-58D7-4E1B-A223-82A7D40651DF@greenbytes.de>
References: <90502.1487325120@critter.freebsd.dk>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
X-Mailer: Apple Mail (2.3259)
Received-SPF: pass client-ip=5.10.171.186; envelope-from=stefan.eissing@greenbytes.de; helo=mail.greenbytes.de
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-1.536, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1ceg7b-0001kE-A6 673cf1f4b062f72a61ed257ecd65fe14
X-Original-To: ietf-http-wg@w3.org
Subject: Re: H2: Should there be a limit to tolerance ?
Archived-At: <http://www.w3.org/mid/D199BE90-58D7-4E1B-A223-82A7D40651DF@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33572
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> 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

v2.27.6 | Report a Bug | By Email | System Status