Re: [quicwg/base-drafts] Anti-amplification limits should count junk too (#3340)

Kazuho Oku <> Wed, 15 January 2020 04:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7B2812011F for <>; Tue, 14 Jan 2020 20:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.596
X-Spam-Status: No, score=-1.596 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, GB_SUMOF=5, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 auXnivUfH47Y for <>; Tue, 14 Jan 2020 20:59:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0AAF512006B for <>; Tue, 14 Jan 2020 20:59:23 -0800 (PST)
Date: Tue, 14 Jan 2020 20:59:21 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579064361; bh=MOxDQJQwL7RrtO/L/Gv1Luuo6W1bRdc9+r65HsMoVIE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=kJv+bZ6k7ULvMDotv++fbbGU6IdgYbJIZjwe/4lkojd10coVKdGdXyjwuvtsyE9wt jH+1grYpz76dQQUP8G7PDszg5WRG5EGl3c4lron1xCR8h4gBzf5SE0m8m0RHg1TTZv dPcIBzxWvDjsuiNTP7Ideck3zZeSpETvlchnz8wk=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3340/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Anti-amplification limits should count junk too (#3340)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1e9c29b3c21_729a3ffbf5acd95c326897"; 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
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: Wed, 15 Jan 2020 04:59:27 -0000

> If our intention is to include 0-RTT packets, it would be sufficient to count all datagrams that are received with the same QUIC DCID (no matter if they're actually processed or not).

I might actually prefer this definition (i.e. sum of QUIC packets sent on the correct path using correct CIDs, regardless of if they were processable), above a definition that states that the amplification limit is 3x the sum of the size of UDP datagrams that an endpoint has received on the correct path.

It is easier to implement (because all the logic can be implemented at the QUIC packet processing layer), and it has the nice side-effect of deterring padding outside QUIC packets (#3333).

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