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

Kazuho Oku <> Wed, 01 April 2020 05:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7674F3A0C3B for <>; Tue, 31 Mar 2020 22:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Status: No, score=-1.199 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_32=0.001, 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 xo2akdmBRXyu for <>; Tue, 31 Mar 2020 22:24:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E767C3A0C39 for <>; Tue, 31 Mar 2020 22:24:56 -0700 (PDT)
Date: Tue, 31 Mar 2020 22:24:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585718696; bh=gn7ozfdChaY3YtIzTMPk2rxDSRvhiZsqA8pevYpCROs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Cfdgnz8BLcE360tmG7G5r7qSC1LSeGbzm/fN4ltKQitIhw/a9nT/g2zxLEpnXDnZW wPvsGg9K+vktj3lbJZ8LwIZeXHElCE4Rho9OB88A3CQUdi3ML56i42pa+3TiTU475a USKEuGsn0jjauWEvG1ac2NmZYQeh3iGTAEoIxVdU=
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_5e8425a7ee0a6_31083fbbbe4cd95c4979"; 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 05:25:00 -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

PS. To avoid the confusion being discussed in the comments right above, I think my preference goes to having something like:

_An adversarial peer can request an endpoint to retain state for an unlimited amount of connection IDs being retired by withholding acknowledgements for the RETIRE_CONNECTION_ID frames, at the same time sending NEW_CONNECTION_ID frames with updated values in the Retire Prior To fields, or probing and discarding paths repeatedly._

_As a mitigation, endpoints SHOULD limit the amount of state that they retain for retiring the connection IDs. In order to allow a well-behaving peer to request retirement of all the previously issued connection IDs while an endpoint waits for some RETIRE_CONNECTION_ID frames to be acknowledged,  an endpoint SHOULD be capable of tracking at least the active_connection_id_limit plus the number of retirements that the endpoint might initiate at one time. When the amount of state required for tracking the connection IDs being retired exceeds that limit, an endpoint MAY close the connection with a CONNECTION_ID_LIMIT_ERROR._

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