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

Marten Seemann <notifications@github.com> Sat, 23 May 2020 00: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 []) by ietfa.amsl.com (Postfix) with ESMTP id C5DD53A0E70 for <quic-issues@ietfa.amsl.com>; Fri, 22 May 2020 17:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rEhSbevAEjtp for <quic-issues@ietfa.amsl.com>; Fri, 22 May 2020 17:51:40 -0700 (PDT)
Received: from out-10.smtp.github.com (out-10.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE7A3A0E6F for <quic-issues@ietf.org>; Fri, 22 May 2020 17:51:40 -0700 (PDT)
Received: from github-lowworker-3a0df0f.ac4-iad.github.net (github-lowworker-3a0df0f.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 0DD51121245 for <quic-issues@ietf.org>; Fri, 22 May 2020 17:51:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590195100; bh=F6yR6Dqlg9+Zxb6AaedtATyerjFVqP1zrXxR1LzMul0=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Kf1bQKUKXPy/moZhRljd+T4h7HQRLMYZ29pHStd8bL0N0akDBrV3leF6zuJzQ3bk2 ZiR/ew8I7I07M64u56nxnlSnWJYAHP3dXkn5bft9MX3s6sdf5vcua75J6KLjtlYuTh poo+OOjwy4LCUC5+IxCDzA9DdHqoKrWMgo3sswJ8=
Date: Fri, 22 May 2020 17:51:39 -0700
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7GWFKYEFG2FA35KPV42RKJXEVBNHHCKKTHGI@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@github.com>
Subject: [quicwg/base-drafts] How to reject a connection attempt (#3690)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ec8739bbcad8_42833f9e6f2cd95c156571f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/tXrkdA_Wq3a2OQN8LqrL6vRpHXI>
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 00:51:43 -0000

Assume that a server has a blacklist of IP addresses, that it doesn't accept connections from.

One way of implementing this would be to drop all packets from those IP addresses. But this would lead to clients time out, which is sad. Let's say the server wants to be more helpful and allow the client to quickly recover from this situation.
Sending a CONNECTION_CLOSE would seem like the right thing to do in that case. However, we don't have an error code that fits here. SERVER_BUSY is used to reject connection attempts, but it's a bad fit here. Retrying later is not likely to succeed in this case. APPLICATION_ERROR also seems too broad, as it's used for *any* application-level error (in Initial packets).

Do we need a new error code to cover this use case? Something like CONNECTION_REFUSED?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: