Re: [quicwg/base-drafts] Deduplication window suggested by RFC 4303 is insufficient (#3692)

Martin Thomson <notifications@github.com> Mon, 25 May 2020 06:36 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 626DF3A0C39 for <quic-issues@ietfa.amsl.com>; Sun, 24 May 2020 23:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level:
X-Spam-Status: No, score=-1.483 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, RCVD_IN_MSPIKE_H2=-0.001, 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 LmGfVfdSc-3d for <quic-issues@ietfa.amsl.com>; Sun, 24 May 2020 23:36:20 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B2D3A0907 for <quic-issues@ietf.org>; Sun, 24 May 2020 23:36:19 -0700 (PDT)
Received: from github-lowworker-cf59896.ash1-iad.github.net (github-lowworker-cf59896.ash1-iad.github.net [10.56.112.26]) by smtp.github.com (Postfix) with ESMTP id B05181C068D for <quic-issues@ietf.org>; Sun, 24 May 2020 23:36:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590388578; bh=UXILjoGBukCLm2deEyo0dhXkRPk2rHMGzolzsMRgfQk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qkY0r39tidl9WEC/jG/kqPUVbVs/uMaTlaeg/AKXANUX0upP89swz4NACH7wh7vY9 8OXL8/y1S0ZiFZQ4jmfx3QIk6UZlQNcMtMOZAEZsdvbB3jSaBtfgEWJo0chTCIOfXG QLgcfO/nN62S1O++rwzywi0tXo/9GOG/ES5j7NN8=
Date: Sun, 24 May 2020 23:36:18 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4GOJ6OPYWRICJBH3F425EGFEVBNHHCKMO44M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3692/633404227@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3692@github.com>
References: <quicwg/base-drafts/issues/3692@github.com>
Subject: Re: [quicwg/base-drafts] Deduplication window suggested by RFC 4303 is insufficient (#3692)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ecb6762a0d6f_44f3fe9d6ccd96826475c"; 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/9yqnLlmD4FjL-g1qgsNAmA2zz0c>
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, 25 May 2020 06:36:23 -0000

I agree that RFC 4303 is showing its age here.  32 packets is probably woefully inadequate here.  But there is an additional insight that is important: you need to drop all packets older than the oldest packet you are individually tracking or you are vulnerable to duplication attack.  It's a little awkward restating that.

It's not obvious that you need to allow for an increase of half of the difference between the current min_rtt and some maximum value either, so it is worth saying that.  Noting that the collective packet rate on all paths affects any limit is similarly non-intuitive.

The nice thing about this is that the most obvious packet-tracking structures (aside perhaps from those that are subject to DoS) are not susceptible to this problem.  For instance, many people are tracking ranges and limiting the total number of ranges.  If you do that, you only run into problems after the number of slow probes sent within one of these extra-long round trip times exceeds the number of ranges the receiver is tracking.  Most implementations are tracking more ranges than there are packets in an initial congestion window, so you won't get issues.

-- 
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/issues/3692#issuecomment-633404227