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

Joseph Touch <> Tue, 20 July 2021 03:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D118B3A041A for <>; Mon, 19 Jul 2021 20:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 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, 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 ZMuLfSYib2-5 for <>; Mon, 19 Jul 2021 20:15:33 -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 A3A6F3A0412 for <>; Mon, 19 Jul 2021 20:15:32 -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=6RzaKK5VCQkQl1aP9YSlSqvGZQM7Trgr8l5Gt6xEmF8=; b=ihqxKm6MJZJ3is4FXwtZC98w6L BGrgHHpFht+3jJ+aS9V0hZ0rQtxdHFHDTOT7hs8J3Svm9X1n5Ia4SCUQfHZSqWnU1fe+mzNXJe+h8 GA1Lsgj8o9l/fjS9VogG1hve7K5EqQ/+lDau8A4CLuwXZdZZS0YO5J6qr3LtIvvRNpWapuo8B7t2h cKhlNwReN4pBKJzkNnikMbOGqHpHJDIe/h9yAEhrR8VDLqVtbqw6GnVi+8MuGwqm1iRfhQ22zjUhl vCt1WDRr2y5rKFqPBY3t6vIvyZVI5U4lFLFM8V/URV5MdRRTMvFSvxzE6+cmOoqGMcEtyRBT/dvGP ce06EbOA==;
Received: from ([]:60708 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1m5gEA-002dvW-L2; Mon, 19 Jul 2021 23:15:31 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_83F74649-7435-41CB-92C3-65701E970150"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Mon, 19 Jul 2021 20:15:25 -0700
Message-Id: <>
References: <> <>
To: Mark Nottingham <>
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: Tue, 20 Jul 2021 03:15:39 -0000

Hi, Mark,

All ports are permitted as *source* ports. They are not assigned by IANA nor do any have special meaning, AFAICT.

Port values have meaning most specifically in socket pairs; they are assigned/reserved by IANA and have meaning for a RFC793-style socket ONLY when there is a corresponding RFC793-style listen listen that allows the source port to float AND when there is no more specific binding to a socket pair.

This suggests we should neither create a registry nor document this approach, to avoid either giving the impression of endorsing this behavior.

At best, we should document why this behavior is incorrect and should be avoided.


(NB: I’m referring to RFC793 sockets and listens, not how Unix ior other OSes implement these)

> On Jul 18, 2021, at 10:58 PM, Mark Nottingham <> wrote:
> I started a conversation on the HTTP and QUIC mailing lists regarding the somewhat common practice of server-side blocking of UDP source ports that can be used for reflection attacks; see below.
> Doing so interacts poorly with QUIC and HTTP/3, because it not only requires a new connection to be established (thereby increasing latency), but many implementations also take it as a sign that UDP is blocked on that particular network path, so they don't attempt to use QUIC for some time afterwards to that particular host -- effectively downgrading.
> We seem to have some agreement there that documenting this is a good idea, but that putting it in an RFC doesn't make a lot of sense,[1] because (unfortunately) the list of such protocols is likely to grow.
> So, a registry might do the trick. Rather than spinning up a purpose-built registry, I was wondering whether we could write add a column to the Service Name and Transport Protocol Port Number Registry, something along the lines of 'Potential Reflection Vector'.
> What do folks here think about that?
> Cheers,
> P.S. Please CC me on responses, as I'm not subscribed.
> 1. However, see < <>>
>> Begin forwarded message:
>> From: Mark Nottingham < <>>
>> Subject: UDP source ports for HTTP/3 and QUIC
>> Date: 15 July 2021 at 10:20:39 am AEST
>> To: HTTP Working Group < <>>, IETF QUIC WG < <>>
>> Resent-From: <>
>> Archived-At: < <>>
>> [ bringing this up on both lists because it's not yet clear what the right scope is ]
>> It's not uncommon for servers to block certain UDP source ports to avoid being overwhelmed by certain reflection attacks. In particular:
>> * 53 - DNS
>> * 123 - NTP
>> * 1900 - SSDP
>> * 5353 - mDNS
>> * 11211 - memcached
>> ... among other candidates.
>> See, eg., < <>>. This isn't done to avoid protocol vulnerabilities as such -- it's to avoid volumetric attacks (usually DDoS). 
>> If a client chooses source ports from the ephemeral port range, this shouldn't be an issue. However, some implementations (or deployments) extend the source port range "downwards" to avoid exhaustion:
>> * On Linux, it's pretty common to tune to extend the ephemeral port range, e.g., < <>>
>> * On some versions of Windows, ports as low as 1025 are used: < <>>
>> * FreeBSD has used ports as low as 1024 in the past; their documentation is... confused right now. < <>> (I don't run a FreeBSD box to check this)
>> * NAT and CGNAT are a thing. < <>> recommends that source ports in the range 1024-65535 be reassigned within that range, which can cause collisions. 
>> Overall, the chance of collision (i.e., a client or a NAT choosing a blocked source port) is quite low, but at Internet scale it'll happen, leading to the client needing to open a new connection, thereby adding perceived latency. 
>> At a minimum, it seems like a good thing for client and NAT developers to be aware that some ports are likely to be blocked, so that they can avoid them if they care about perceived performance. This e-mail might be enough for that immediate purpose.
>> My question is whether there's a need for more coordination -- e.g., a very short RFC outlining such ports, to help bring this to folks' attention (especially in the NAT crowd)?
>> Cheers,
>> --
>> Mark Nottingham <>
> --
> Mark Nottingham <>