[quicwg/base-drafts] Retaining the largest received packet number (#3541)

Martin Thomson <notifications@github.com> Mon, 23 March 2020 00:50 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 57AFB3A0944 for <quic-issues@ietfa.amsl.com>; Sun, 22 Mar 2020 17:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Status: No, score=-3.099 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_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: 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 0e0VEIce5ShX for <quic-issues@ietfa.amsl.com>; Sun, 22 Mar 2020 17:50:38 -0700 (PDT)
Received: from out-11.smtp.github.com (out-11.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 02DFC3A08EB for <quic-issues@ietf.org>; Sun, 22 Mar 2020 17:50:37 -0700 (PDT)
Received: from github-lowworker-5fb2734.va3-iad.github.net (github-lowworker-5fb2734.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 7A0742615BB for <quic-issues@ietf.org>; Sun, 22 Mar 2020 17:50:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584924637; bh=V3pKwyuHKpgSXj2Uq4jib3bk8TDuJzQCzfdho0KjKOk=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=sijD4JIzBb0eQDzAiePDk8JXVRxPremJ7Tn7Ua7wJ4FP7acqKOzngyCCRTK66DokJ 8+DGWd9RfpWYmR2aclIJf/MSpcZ/VKDuiPX198lguk45PCoh0Ri2ngNxgPSPEin+RX HMmTHa/uQcLqPy0d23AJctYRHl2VDpWyPrAXneEE=
Date: Sun, 22 Mar 2020 17:50:37 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4LMO4SMNEIY2VMZEF4QPUN3EVBNHHCF233TE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3541@github.com>
Subject: [quicwg/base-drafts] Retaining the largest received packet number (#3541)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7807dd34f9f_25d03fdff92cd96846305d"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/e-HRO7wmskAzWXUJnuExXZ5RSAU>
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: Mon, 23 Mar 2020 00:50:41 -0000

In #3537, @ianswett notes that #3315 added this "MUST":

> When discarding unacknowledged ACK Ranges, a receiver MUST retain the largest received packet number.

My understanding is that this prevents the largest acknowledged packet from going backwards.  We use the monotonic increase of the Largest Acknowledged field in two ways:

* In ECN validation, this is used to filter out ACK frames that might have arrived out of order, which might have lower counts legitimately.

* In key updates, where the value of the largest acknowledged is used to drive the change to new keys and to prevent use of old keys after an update.

In my view, having ECN validation fail is quite unfortunate, but likely workable.  On the other hand, uncertainty about largest acknowledged could introduce instability in the key update process.  If an endpoint's conception of what the value is changes, I doubt that we'll see extra key updates (I think that the AEAD would protect us from that), but we might leave open the possibility of interleaving of packets from two different key phases.

I would suggest that we retain this "MUST".

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