IETF Logo Mail Archive

Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)

ianswett <notifications@github.com> Sat, 23 May 2020 18:18 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 B2FE63A0D73 for <quic-issues@ietfa.amsl.com>; Sat, 23 May 2020 11:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 io0AUPXuQzdE for <quic-issues@ietfa.amsl.com>; Sat, 23 May 2020 11:18:56 -0700 (PDT)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450EB3A0D12 for <quic-issues@ietf.org>; Sat, 23 May 2020 11:18:56 -0700 (PDT)
Received: from github-lowworker-c5134a3.ac4-iad.github.net (github-lowworker-c5134a3.ac4-iad.github.net [10.52.23.55]) by smtp.github.com (Postfix) with ESMTP id 6AEB78C1169 for <quic-issues@ietf.org>; Sat, 23 May 2020 11:18:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590257934; bh=uYanc8/RAZvyC79+fCO/nVYl1LBZlv6Iv0o/yxM8YDQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sNAUTxshMroIyo6uEglobmFkajFQ91FRrMIJ4Cm3Lbzz1eU2ivyEv+729CIMVntvS IikNkXHO/Uk19YniSzi+wgZs909exUCb7wSrfU7n2VSjl8glBFDRSTmZ5BnkGR10Bp x2FtjDrKY5BOK5Reaw5ZQcvx2OemHVI7v4DZQlpU=
Date: Sat, 23 May 2020 11:18:54 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3KA7R5ZYGHNJ374B542VFA5EVBNHHCKKTHGI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3690/633110291@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3690@github.com>
References: <quicwg/base-drafts/issues/3690@github.com>
Subject: Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ec9690e5b624_4a803fa22bccd960255792"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/e-PhH7ifwCEEVT5xo3wos8wZlvg>
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: Sat, 23 May 2020 18:18:58 -0000

If my reading of our code is correct, we're using PROTOCOL_VIOLATION for that case, but that's not a very informative choice.  In gQUIC, we used public reset for this(as you probably remember), but stateless reset is post-handshake only.

CONNECTION_REFUSED sounds better, but I think an important question is wether we expect clients to treat this error code differently than other error codes which occur during the handshake.  If we're not going to treat it differently, then it matters less.

That being said, I'm a general fan of more granular error codes for debugging.


-- 
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/3690#issuecomment-633110291

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