[quicwg/base-drafts] NEW_CONNECTION_ID text is too restrictive on receivers (#3534)

martinduke <notifications@github.com> Thu, 19 March 2020 19:48 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 []) by ietfa.amsl.com (Postfix) with ESMTP id D03523A0E2E for <quic-issues@ietfa.amsl.com>; Thu, 19 Mar 2020 12:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Status: No, score=-1.482 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dQZeXfGZF_OS for <quic-issues@ietfa.amsl.com>; Thu, 19 Mar 2020 12:48:28 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96E23A0E2A for <quic-issues@ietf.org>; Thu, 19 Mar 2020 12:48:27 -0700 (PDT)
Received: from github-lowworker-f1f7af9.ash1-iad.github.net (github-lowworker-f1f7af9.ash1-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 4C5016E11C8 for <quic-issues@ietf.org>; Thu, 19 Mar 2020 12:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584647307; bh=wR7pQZvLvx6BNjSmNFzBVBi8jMZxehkrmfbZ+j6i/8g=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=dP/aXd9OHWGGfbCdmERkcH+506cYftP3lgmBYLS3LCD/s4JQPVVJVGARn7kTrdibX +WdIeKg/evitxjqfZVLtoNnjAMHrM0psx2h3rRh1KRzqz8iHRJC3S13PD3w99K6fKf xwkncprT5q1TBewjq25YoN06ilPFAgAOdGMmT+TM=
Date: Thu, 19 Mar 2020 12:48:27 -0700
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7KO4CFTEYQH2SQFQ54P6WYXEVBNHHCFWJJQQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3534@github.com>
Subject: [quicwg/base-drafts] NEW_CONNECTION_ID text is too restrictive on receivers (#3534)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e73cc8b3bd40_2ed13f949e0cd95c124555"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/-HfSNgjFQZK-O74_hXASI2PoltY>
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: Thu, 19 Mar 2020 19:48:31 -0000

This is a small point, but it's pointlessly creating pain in our implementation and possibly some others. In Sec 19.15 (NEW_CONNECTION_ID frame):

`An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number smaller than the Retire Prior To field of a previously received NEW_CONNECTION_ID frame MUST immediately send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID.`

IMO this is poorly formulated. If the receiver has already sent an RCID frame for the sequence number and that RCID has been acked, it may have thrown away state for that sequence number and shouldn't have to resend a frame the peer has received. In particular, a buggy or malicious peer might send a very old sequence number, or the NCID receiver might have preemptively retired a sequence number it hadn't seen when it got the retire-prior-to field.

Simply appending 'if has not already done so' to the text above would do the trick I think. I'm happy to file a PR unless most people think this is a terrible idea.

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