Re: [tsvwg] UDP source ports for HTTP/3 and QUIC

Joseph Touch <> Thu, 22 July 2021 04:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C2FA3A37FC for <>; Wed, 21 Jul 2021 21:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.317
X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gpccfj-_W7zc for <>; Wed, 21 Jul 2021 21:57:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B5CF93A37FB for <>; Wed, 21 Jul 2021 21:57:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1l0E9LJYmz6RhKkbXphcb2jYVUNM8v6TBrDHmU+3KmY=; b=eNfA+ZyhiwftsS6bVLIO4yXRb3 OafV4xZFA0avEP7IBjGVHRYlBbDNKrP/evJSQjEMm2NcGXgW6ikVvVP2sNy0bZRVcfYi3Fh3813Xt QPmiG2jj+LR63cvYp6aepFoT/zGvefvvz3TcZAU7WA/AUMAHVKBNCK4xqftXsLPBitWbZK7M0RdDt ltmS2d7KPwUBqwTY2oyXjhzlU893W40hECyPCLrFri3xSUkLrPJVNbjUyGE29h3KSw5qEPWMko2es Gt78gPg559wYVzrvOLoMn1ZJOoxiDATSwiODMGEqh/AhjHgn6Kl/hB016Lsi7zY1azO5FE6vfmRP5 tdUSQuGg==;
Received: from ([]:64149 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1m6QlV-0030Yp-Nr; Thu, 22 Jul 2021 00:57:04 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_7235312A-CB31-4E89-9FF9-E131EEAC11D9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Wed, 21 Jul 2021 21:56:56 -0700
Cc: "Holland, Jake" <>, Mark Nottingham <>, "" <>
Message-Id: <>
References: <> <> <> <> <> <> <>
To: "Black, David" <>
X-Mailer: Apple Mail (2.3654.
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tsvwg] UDP source ports for HTTP/3 and QUIC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jul 2021 04:57:10 -0000

Hi, David,

> On Jul 20, 2021, at 12:02 PM, Black, David <> wrote:
> Explaining as an individual, not WG chair ... TL;DR - +1 on Jake's comments, his understanding matches mine.
> Providing some more detail ...
>> As I understand the proposal, it's to say "these source ports
>> happen to match common attack targets that are listening ports
>> for other protocols, and thus commonly get special handling to
>> help avoid reflection attacks against those servers".
> +1 - this is about documenting "running code" that discards traffic that uses one of those UDP source ports.

There’s a hazard with this viewpoint, IMO.

It’s like observing people driving on flat tires and thinking the road is bumpy.

There are two solutions: 
	- document existing practice and describe how road engineers can redesign roads to avoid the problem
	- document that driving on flat tires is incorrect and explain what it impacts

I agree with documenting the problem as a problem, but not as a practice. The latter viewpoint endorses it, which then means we all have to accommodate that behavior.

>>> There’s no precedence for that decision and no registry where
>>> those values would be indicated. 
>> The proposal here is to create such a registry.
> I definitely agree that a new registry is wanted/warranted,

I have no problem making a list of ports that people MISTAKENLY attribute to attacks.

However, those who assume that a packet is bad simply because it uses one of these source ports is ITSELF incorrect. Just because it works when you’re under this attack, doesn’t mean it is safe to do when you’re not.

Let’s please not endorse incorrect conclusions that source port has this sort of meaning.