IETF Logo Mail Archive

Re: [quicwg/base-drafts] Forwarding upstream errors, and the implications (#3300)

Mike Bishop <notifications@github.com> Fri, 27 December 2019 15:51 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C5A12004A for <quic-issues@ietfa.amsl.com>; Fri, 27 Dec 2019 07:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 qk4HZzSLLUji for <quic-issues@ietfa.amsl.com>; Fri, 27 Dec 2019 07:50:58 -0800 (PST)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF20F120026 for <quic-issues@ietf.org>; Fri, 27 Dec 2019 07:50:58 -0800 (PST)
Received: from github-lowworker-45eca55.ac4-iad.github.net (github-lowworker-45eca55.ac4-iad.github.net [10.52.25.70]) by smtp.github.com (Postfix) with ESMTP id BED646E1480 for <quic-issues@ietf.org>; Fri, 27 Dec 2019 07:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1577461857; bh=bOoWGKRUP8qsFRWkzcsx3nxX7ga0RO17y9uQGytKHTQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rWnC1GpqobPOC6TlHlgp6PawhoSw47FeWCjEselDIh/5odR9lJzUylLNVuZQUsoO/ qFOlPZYuA5h5aMmQ91hYPf+rM+xIEFeUZyy/z8T3gQU8IuUcn95D6JsrImpOhnEn7K bc9rudYDX6/Gz/BGC6Ek3qXq+6Eut2wbTf40k26E=
Date: Fri, 27 Dec 2019 07:50:57 -0800
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6DABATOUBEMR2PAFN4CNNODEVBNHHCABYU5A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3300/569295073@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3300@github.com>
References: <quicwg/base-drafts/issues/3300@github.com>
Subject: Re: [quicwg/base-drafts] Forwarding upstream errors, and the implications (#3300)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e062861aec5d_67333f8c4cccd9649266e6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/fGKqwk0qv_5ngOqf-0mNxBI5dWA>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Dec 2019 15:51:00 -0000

I think there's a larger idea here:  We took a series of PRs to make any protocol misbehavior connection-fatal.  However, when there's an intermediary, it's not necessarily clear whether the misbehavior is on the part of the intermediary or the origin.  And it's not necessarily clear to the client whether there's an intermediary, so it generally will have to assume one or the other all the time.

The takeaway for me is that we overreached -- if the trigger for an error could be attributed to the origin rather than the intermediary, then the error should not be connection-fatal.  If there are things in this class that we believe need to be connection-fatal anyway, the corollary is that the intermediary MUST check for and sanitize these things.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3300#issuecomment-569295073

v2.23.0 | Report a Bug | By Email