Re: [quicwg/base-drafts] Clarify client anti-amplification response (#3445)

Christian Huitema <> Tue, 18 February 2020 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A38412008B for <>; Tue, 18 Feb 2020 08:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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 Nap7ETBOezmK for <>; Tue, 18 Feb 2020 08:56:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3179120077 for <>; Tue, 18 Feb 2020 08:56:07 -0800 (PST)
Date: Tue, 18 Feb 2020 08:56:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1582044967; bh=4zqpZew6lY88XFFx51GQY6VT84gMy9rIijStUEci1+c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Ya3lkI3Qq971TO3BBYPdyagm6Q8JH+RD5+ItTqKAJhB4X0PepVSCAZzBwXUUPxJo6 tbXPTeKNNgDrEfXQ5b6xDBLkAogo6c3hX23Pn/Yz1mdoQco/GC56iLGbOBGIBYcTLM vzB2v5/rgUYO6BMG25Y5WNpc/89Ei2Kf8uBZeLKk=
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3445/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clarify client anti-amplification response (#3445)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e4c172784ae_76e3f9ace4cd9685057a3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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, 18 Feb 2020 16:56:10 -0000

huitema approved this pull request.

This text addresses the concerns in issue #3395, and would remove the need for PR #3416. I like it. I am just a tiny bit concerned with the implications of sending a Ping that would force an Initial or Handshake response.

> -handshake deadlock, clients MUST 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 MUST send an Initial packet in a UDP datagram of
-at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a
-Handshake packet.
+Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets.  The server
+can reach its anti-amplification limit, but if the client has received
+acknowledgements for all the data is has sent, it has no reason to send more
+packets. In this case, where the client would otherwise not send any
+additional packets, the server will be unable to send because it has not
+received enough from the client or validated the clients address. To prevent
+this deadlock, clients MUST send a packet on a probe timeout, or PTO;
+see Section 5.3 of {{QUIC-RECOVERY}}. In this case, the client MUST send an
+Initial packet in a UDP datagram of at least 1200 bytes if it does not have
+Handshake keys, and otherwise send a Handshake packet.

Yes. The next question is, what content shall the client place in the Initial or Handshake packet? Just PAD? Ping and PAD?

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