Re: [quicwg/base-drafts] Remove DoS vector for spoofed connection migration (#2893)

Eric Kinnear <> Wed, 07 August 2019 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B29221200B3 for <>; Tue, 6 Aug 2019 17:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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, 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 W1IYoyjzhRmr for <>; Tue, 6 Aug 2019 17:38:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B080E1200BA for <>; Tue, 6 Aug 2019 17:38:32 -0700 (PDT)
Date: Tue, 06 Aug 2019 17:38:31 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1565138311; bh=+VLYmoeSe6y9G3czfgALxjQknYF6EGtGJ03RnPHV1R4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UFaB6W9CJ2Y5JhX2jcAXOTHwkgjkxXJdTGDP9qtMrqJgXjKAIivKOVOejQkScgjye T9/T5lIgdQpWXek5FYw9zGCss3q0kkIFzQoQrqCfXp1exh7iLHJice6ImmO5nTjnJK 2sDY/GdOW5NF0pReKBYowWzfjU6yNmOT2jN7VZZY=
From: Eric Kinnear <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2893/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Remove DoS vector for spoofed connection migration (#2893)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d4a1d8799b0a_70503facad4cd968192285"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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, 07 Aug 2019 00:38:35 -0000

@pravb I think we got to the point where either (a) the packets miraculously get to the right place and then the endpoint can choose to either honor them or drop them or (b) they don't, in which case that's sad, but that's what happens when your infrastructure doesn't handle NAT rebinding or any other changes to the 4-tuple.

In neither case do you want to close the connection with an error, in case someone else has injected a packet with a different source address.

>21.8. Stateless Reset Oracle
>Stateless resets create a possible denial of service attack analogous to a TCP reset injection. This attack is possible if an attacker is able to cause a stateless reset token to be generated for a connection with a selected connection ID. An attacker that can cause this token to be generated can reset an active connection with the same connection ID.
>If a packet can be routed to different instances that share a static key, for example by changing an IP address or port, then an attacker can cause the server to send a stateless reset. To defend against this style of denial service, endpoints that share a static key for stateless reset (see Section 10.4.2) MUST be arranged so that packets with a given connection ID always arrive at an instance that has connection state, unless that connection is no longer active.

Should you be in a situation where the client will accept your stateless reset for a connection that's active if someone spoofs a source address and the packet ends up on a server that has no state? If that can happen, that seems like we should open a new issue, since that's something that can happen at any time (although seems to me to be pretty much covered by the text in 21.8).

The point of this change is to be clear that the purpose of the TP is to instruct the endpoint sending the packets to not intentionally change its address or port, but that the server receiving the packets (if for whatever reason they still get there) needs to not close the connection if it sees that happening. It can drop the offending packets, or process them, but it's a problem if it does the previous behavior which was to close the connection.

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