Re: [quicwg/base-drafts] Backoff on CONNECTION_CLOSE (#3157)

Kazuho Oku <notifications@github.com> Tue, 29 October 2019 04:25 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 4E1A912008C for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 21:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzt9y201lADj for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 21:25:25 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FB1120043 for <quic-issues@ietf.org>; Mon, 28 Oct 2019 21:25:24 -0700 (PDT)
Date: Mon, 28 Oct 2019 21:25:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572323123; bh=SULcAw9R8IJCyZ3q725TmLv5CFNEv41gh4fC22Qpr2Q=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Rnd7tn7S6lKK2TF9RmExwKLpby6Fz3pLj2O7Hijs+0WJbZk2XSYtT0dMSxecSxhNI CDeYPczuoCEqaQxykWik7K5ZeBT6p9Qt4WwIcvmH9tG/8WpN7rAk9q5MwaLWy6bZBD tU5Wwqgi0EhR+c2Mw+VhNAPrHv5UBGmg46ZAC9SQ=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7ZQGYES47UDVFJNEV3YTY3HEVBNHHB5FPVAE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3157/review/308269684@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3157@github.com>
References: <quicwg/base-drafts/pull/3157@github.com>
Subject: Re: [quicwg/base-drafts] Backoff on CONNECTION_CLOSE (#3157)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db7bf33d5aec_3c673fde520cd9684874"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/BSSleFSKtRRjynmwqDHoSGhMK7M>
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: Tue, 29 Oct 2019 04:25:26 -0000

kazuho commented on this pull request.



> @@ -2379,15 +2379,23 @@ terminate the connection immediately.  A CONNECTION_CLOSE frame causes all
 streams to immediately become closed; open streams can be assumed to be
 implicitly reset.
 
-After sending a CONNECTION_CLOSE frame, endpoints immediately enter the closing
-state.  During the closing period, an endpoint that sends a CONNECTION_CLOSE
-frame SHOULD respond to any packet that it receives with another packet
-containing a CONNECTION_CLOSE frame.  To minimize the state that an endpoint
-maintains for a closing connection, endpoints MAY send the exact same packet.
-However, endpoints SHOULD limit the number of packets they generate containing a
-CONNECTION_CLOSE frame.  For instance, an endpoint could progressively increase
-the number of packets that it receives before sending additional packets or
-increase the time between packets.
+After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the
+closing state.
+
+During the closing period, an endpoint that sends a CONNECTION_CLOSE frame
+SHOULD respond to any incoming packet that can be decrypted with another packet

Could you please elaborate a bit more?

My understanding is that we need "that can be decrypted." The reason we are adding MUST for endpoints that drop the keys when entering the closing state is because they cannot validate the packet using the keys. In this paragraph, we are talking about the flip side. That means that the endpoints MUST validate the incoming packets by unprotecting them.

Or are you specifically suggesting that we need to talk about how duplicates are to be handled?

-- 
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/pull/3157#discussion_r339889443