[quicwg/base-drafts] Immediate close without state (#3297)

Martin Thomson <notifications@github.com> Wed, 11 December 2019 04:09 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 0C71B120255 for <quic-issues@ietfa.amsl.com>; Tue, 10 Dec 2019 20:09:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2yrEsxf0c2_F for <quic-issues@ietfa.amsl.com>; Tue, 10 Dec 2019 20:09:20 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.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 0E3AA120219 for <quic-issues@ietf.org>; Tue, 10 Dec 2019 20:09:20 -0800 (PST)
Received: from github-lowworker-943b171.ac4-iad.github.net (github-lowworker-943b171.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 6979E1C0B56 for <quic-issues@ietf.org>; Tue, 10 Dec 2019 20:09:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576037359; bh=okZuMThZWk4Evvd+a/yMGSCxB55T3WoyQLL1C/95HHY=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=fkaWEx5zyudI/bLoMFFy4G4rNUo7AsH4uOYJ13DaEygM3wzNyWsD0/OG9p40NfNtv tv177S3PJf+R89KYI+4cnsE18zER9X6q6BDgqB68nBxN541BFlepLTi/LEhi0mr00Q Rk+woLCSuOsV3KiTRQyaZvOfpTocjkbMLvKzAS4w=
Date: Tue, 10 Dec 2019 20:09:19 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK27SJ4QP5KQHIN5Q7F37WPG7EVBNHHB75FWO4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3297@github.com>
Subject: [quicwg/base-drafts] Immediate close without state (#3297)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df06bef5a3fd_cea3fcce90cd960810a2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/vsLcFco4pk87ixSM_1DWNS_IY1o>
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: Wed, 11 Dec 2019 04:09:22 -0000

In some cases, we allow CONNECTION_CLOSE (or immediate close) to be used when there is no state for the associated "connection".  Most notably, this happens when a server receives a bogus Initial from a client (see #3269 for the prime example).

Immediate close works fine for those cases, except that it mandates the creation of state: the timer that runs for the closing period and maybe a packet.  That doesn't make sense, because what you want prior to establishing ANY state is to just send the signal without creating any state.

So, we should allow an exception for immediate close where there is no connection state.  This requires a little finesse as it touches on DoS concerns.  An (unauthenticated) Initial packet might is handled statelessly with the resulting CONNECTION_CLOSE causing the client to kill state.  If the server wanted to keep that state, that might be bad.  For that, there is no perfect answer, because it trades off feedback about errors against a very narrow form of denial of service that we agreed we wouldn't take special steps to protect against.  So we should just explain the trade-off and let the servers decide what to do.

#3292 fixes this one.

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