Re: [quicwg/base-drafts] Limit RCID state (#3547)

Kazuho Oku <> Wed, 01 April 2020 04:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDB8D3A0A90 for <>; Tue, 31 Mar 2020 21:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.474
X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[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_28=0.726, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 89gVaI_dJ7R8 for <>; Tue, 31 Mar 2020 21:55:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EA643A0A87 for <>; Tue, 31 Mar 2020 21:55:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8BFE7E15B4 for <>; Tue, 31 Mar 2020 21:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585716946; bh=JhXTGX7L2dM7vbV3so81nYysRWrMWX58TPj1HGgRVQU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lN+IpmrxK7jRWpgVYLr/BAFxDx7PmvjB3FiVQ58Ln0LOY4FMK1MeUMQ/SCovNhlbq 635UjkCrMLrXClTYA7XZL6s+6KBbfJGbcMfsaGKIFuNHG9hzfdAoDhHIGPXsmHL2v+ mfMhghzjSU0ltkT5456leIkZmjjeYWCHhMvypZeY=
Date: Tue, 31 Mar 2020 21:55:46 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3547/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Limit RCID state (#3547)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e841ed27a4d2_2cfa3f8f78acd9641703e9"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Apr 2020 04:55:52 -0000

@kazuho commented on this pull request.

> @@ -1069,6 +1069,15 @@ to cease using the connection IDs when requested can result in connection
 failures, as the issuing endpoint might be unable to continue using the
 connection IDs with the active connection.
+An endpoint SHOULD limit the number of outstanding RETIRE_CONNECTION_ID frames
+to bound the necessary state. In order to allow a peer to retire all previously
+issued connection IDs, the limit on the number of outstanding
+RETIRE_CONNECTION_IDs SHOULD be at least the active_connection_id_limit. An

@martinduke Thank you for the clarification. I now understand the intent. I think that we should adjust the text in this PR.

To mitigate the attacks being discussed, what we need to do is cap the amount of state used for retaining the CIDs that "are intended to be retired." While an endpoint may restrict the number of RCID frames being sent at one time, that is unrelated to the attack, and therefore I would advocate for removing that requirement (as it is an unnecessary design change).

Speaking of your implementation, what matters is 100. 4 (2 * active_connection_id_limit) is an arbitrary choice unrelated to the attack; my argument is that therefore we do not need to specify that in spec.

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