IETF Logo Mail Archive

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

Marten Seemann <notifications@github.com> Sun, 24 May 2020 04:27 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 6883B3A10C3 for <quic-issues@ietfa.amsl.com>; Sat, 23 May 2020 21:27:32 -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 e-SvjYWDw3xk for <quic-issues@ietfa.amsl.com>; Sat, 23 May 2020 21:27:30 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2D43A10C1 for <quic-issues@ietf.org>; Sat, 23 May 2020 21:27:30 -0700 (PDT)
Received: from github-lowworker-0eea13f.ash1-iad.github.net (github-lowworker-0eea13f.ash1-iad.github.net [10.56.109.26]) by smtp.github.com (Postfix) with ESMTP id C23E06A03AC for <quic-issues@ietf.org>; Sat, 23 May 2020 21:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590294449; bh=yLzXh3S8kzTAJOWIkYiE0OYVafjEmpqiNjZ2AQfa1kM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=p8V1RLh+fh1rU6otEMGzXyXd3dNx3z+L5yY/5AKzfgIBYUzjYq6NdF+hiRweiFJl1 3VnN35x+JvM+w0fB2ryb2f8UBfrljl9hRGaBSF742oMs6kv3vgS+kQVKJi2ilffZyj vAUZhchJiqR7fQf5ErZ+bWBPV1GL21oxFg8wlK18=
Date: Sat, 23 May 2020 21:27:29 -0700
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK34SJBFRFCYHCDEDVN42XMLDEVBNHHCKKTHGI@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/633177355@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_5ec9f7b1b1930_48a63fd19accd96c11864a5"; 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/JYfZsuVUBw20IrlYxUa3elbh4xI>
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: Sun, 24 May 2020 04:27:33 -0000

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

I guess a reasonable policy regarding errors received during the handshake would be:
* INVALID_TOKEN: try again immediately
* SERVER_BUSY: try again after a few minutes
* CONNECTION_REFUSED: don't try again for a day / week or so
* other errors: I can see TRANSPORT_PARAMETER_ERROR and FRAME_ENCODING_ERROR (and their generic subsitute, PROTOCOL_VIOLATION) being reasonably sent in response to a ClientHello. So that means that either your or your peer's implementation is broken, so maybe you shouldn't speak QUIC at all?

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

v2.23.0 | Report a Bug | By Email