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

Kazuho Oku <> Tue, 04 February 2020 11:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C87312013A for <>; Tue, 4 Feb 2020 03:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.595
X-Spam-Status: No, score=-6.595 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, 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, URIBL_BLOCKED=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 wl7fyFDvwdcY for <>; Tue, 4 Feb 2020 03:26:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9651120108 for <>; Tue, 4 Feb 2020 03:26:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 115026E07DD for <>; Tue, 4 Feb 2020 03:26:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1580815572; bh=5beezJsSx2151cGjzPSNG5TCOkaqmfvFjW3Kf0Jcwyo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JRQsg0dLJ9sJlOkYuNmc3cxUl92O2H43f68COcqXzLWcnyz5O3a5bNFS34zj5gRBg 23x8pMA2sVDZVhnchl8nNxrgfe2O3arUXDmDOBnus5WDTDNYj4Glwtw2YcWUr7D8j4 6eIEA5tIQejm6zrWtn9uvmG4NsZhaCdAT0rj6fwo=
Date: Tue, 04 Feb 2020 03:26:12 -0800
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_5e3954d42d4a_3c3f3fb8b0ccd96087197"; 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: Tue, 04 Feb 2020 11:26:14 -0000

I share @ianswett's concern regarding 0-RTT packets.

At the moment, [section 8.1]( states:
> In order to avoid this causing a handshake deadlock, clients SHOULD send a packet upon a probe timeout, as described in [QUIC-RECOVERY]. If the client has no data to retransmit and does not have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least 1200 bytes.

As you can see, we do not require the probe to be an Initial packet. They could be purely 0-RTT packets. If we are to allow an endpoint calculate amplification factor at QUIC packet level, we need to change this provision.

And that change should require the client to send probes as Initial packets that are large enough. It cannot simply be a packet that contains only one byte PADDING (or PING).

To me, that seems a bit too complicated.

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