Re: [quicwg/base-drafts] Detectable Stateless Resets (#3032)

David Schinazi <> Fri, 20 September 2019 05:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10958120026 for <>; Thu, 19 Sep 2019 22:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.281
X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gNsO_6nw4B-9 for <>; Thu, 19 Sep 2019 22:58:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5806912006E for <>; Thu, 19 Sep 2019 22:58:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 65A49660449 for <>; Thu, 19 Sep 2019 22:58:50 -0700 (PDT)
Date: Thu, 19 Sep 2019 22:58:50 -0700
From: David Schinazi <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3032/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Detectable Stateless Resets (#3032)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d846a9a574ba_40dc3fdc330cd95c71447"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
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: Fri, 20 Sep 2019 05:58:54 -0000

@martinduke I think your nightmare scenario is very unlikely, as it requires the three bullets you mentioned, but also depends on the size of client connection IDs. I think we can assume that:

- most browsers will use zero-length client connection IDs
- most servers will use non-zero-length server connection IDs

At that point it's extremely unlikely that NAT/firewall manufacturers will build the "remove port mapping when you observe a 20-byte packet" feature for a minority of traffic, it's not like there's an overwhelming amount of innovation in this space...

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