Re: [quicwg/base-drafts] No need for RCID if the peer increases Retire Prior To (#3550)

Kazuho Oku <notifications@github.com> Sun, 29 March 2020 01:02 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 75ACD3A0C3C for <quic-issues@ietfa.amsl.com>; Sat, 28 Mar 2020 18:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 nOk89XVRxDgR for <quic-issues@ietfa.amsl.com>; Sat, 28 Mar 2020 18:02:26 -0700 (PDT)
Received: from out-27.smtp.github.com (out-27.smtp.github.com [192.30.252.210]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFC33A0C85 for <quic-issues@ietf.org>; Sat, 28 Mar 2020 18:02:26 -0700 (PDT)
Received: from github-lowworker-f045d1f.ac4-iad.github.net (github-lowworker-f045d1f.ac4-iad.github.net [10.52.19.54]) by smtp.github.com (Postfix) with ESMTP id 01C62E05E4 for <quic-issues@ietf.org>; Sat, 28 Mar 2020 18:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585443745; bh=n4O8AIm8boyW1sUzsD4mqMZODoMj32+IW6a6S82t6QA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LR2u2Elc0We+X84nlvwaGYUA3eERhKft3A/+WtS1yJShWsMHa8I4lw7ByBr7z79CC Ss2vjhgAPQVy4clXb3d13L8INqo+PgSOO4CIHGVJDNLZ5LtlKAUOre0lux77Om6diw +yxCJXOvYbaq+amLSZ/CBOcEcnQ49u9XsJqK/Ea0=
Date: Sat, 28 Mar 2020 18:02:24 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZ4PNHZ6JHQ62LKWOV4RPKKBEVBNHHCGJORCE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3550/c605540981@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3550@github.com>
References: <quicwg/base-drafts/pull/3550@github.com>
Subject: Re: [quicwg/base-drafts] No need for RCID if the peer increases Retire Prior To (#3550)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7ff3a0e53d0_55a63f91068cd968201835"; 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/aagtuR5zGqoCNnYiyn30_WSV0Fs>
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: Sun, 29 Mar 2020 01:02:27 -0000

@ianswett 
> Thanks for reminding me @kazuho I think this text mitigates that issue:
"An endpoint MUST NOT provide more connection IDs than the peer's limit. An endpoint that receives more connection IDs than its advertised active_connection_id_limit MUST close the connection with an error of type CONNECTION_ID_LIMIT_ERROR."

That text does not mitigate the issue, because te the endpoint that sends RCID, a CID becomes inactive when (or before when) it sends the RCID frame carrying that CID for the first time.

When the peer receives that RCID frame, it peer is allowed to provide a new CID before sending an ACK, or before that ACK is being received by the peer.

> However, if a peer sends a NCID and doesn't increase Retire Prior To in this case, then it's unclear which RETIRE_CONNECTION_ID frame(s) were received. In that case, is it ever clear which RETIRE_CONNECTION_ID frames were received? I'm not sure #3547 actually solves this, or just makes it much less likely?

IIUC, the defense in #3547 is that the endpoint is allowed (recommended) to cease sending RCID frames carrying some CIDs under extreme circumstances. This approach will work regardless of an attack (at the theoretical cost of having interoperability problems, though it would be unlikely assuming that each endpoint would track sufficient number of CIDs being retired).

> I'm starting to think we need a max_connection_id in RETIRE_CONNECTION_ID(or a separate MAX_CONNECTION_ID frame) as a flow control style mechanism to solve this fully?

I share the view that that is the cleanest way of fixing the issue.

-- 
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/3550#issuecomment-605540981