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

Martin Thomson <> Tue, 31 March 2020 03:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC00A3A199D for <>; Mon, 30 Mar 2020 20:21:09 -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 3YD7dxbyHA5Z for <>; Mon, 30 Mar 2020 20:21:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49A733A199A for <>; Mon, 30 Mar 2020 20:21:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2B8DC960393 for <>; Mon, 30 Mar 2020 20:21:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585624867; bh=blHkrwtzgFOU2kTon8PCkSlAYliO0/a5Kmv2pZym3TE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UShd2yp8GAvRdt8LOej7y2OmM0MxnKR+P7Oq4PJZJHoOQ1L1ml4NFC7EzJYV5wrcE 6b7m2bAcXfRPrGs5zudEG0gbe7rOYTDCb7lfbglcMA1jEm64lm27v6kjlKotTCTvrH WOzHE4h1Uq7xdY1ml9BBGAxE6GfZODtvxQQkMlZw=
Date: Mon, 30 Mar 2020 20:21:07 -0700
From: Martin Thomson <>
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_5e82b7231d79b_4f5c3fa855ccd96c9866f"; 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
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: Tue, 31 Mar 2020 03:21:10 -0000

@martinthomson 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

I don't think that is sufficient or necessary.

1. sufficiency: an adversary can send a long sequence of NEW_CONNECTION_ID frames with seq: N and rpt: N-1.  This is both entirely legitimate and completely outside the spirit of the protocol.

2. necessity: if you track min(unacknowledged RCID) and max(RPT) then you can track as few RCID frames as you like.  It might be nice if people used active_connection_id_limit*2, but that number only optimizes for a complete turnover of connection IDs every round trip.  It is an otherwise arbitrary number.  I don't think that we need to optimize for that case.

The only problem arises with this approach is when that gap widens more than you would like.  At which point you can throw down a CONNECTION_CLOSE and walk away.

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