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

Mark Nottingham <mnot@mnot.net> Mon, 19 July 2021 05:58 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2663A241A for <tsvwg@ietfa.amsl.com>; Sun, 18 Jul 2021 22:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=L67Tqe3a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HBXD5cKJ
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLiTe8DdH3r2 for <tsvwg@ietfa.amsl.com>; Sun, 18 Jul 2021 22:58:29 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD7E3A2410 for <tsvwg@ietf.org>; Sun, 18 Jul 2021 22:58:28 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 08CFE5C0041 for <tsvwg@ietf.org>; Mon, 19 Jul 2021 01:58:26 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 19 Jul 2021 01:58:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:mime-version:subject:message-id:references:to :date; s=fm3; bh=Ef7LUeUKIwN/KvcMzHPFmlyK/RsSAfTl1Mr8Jtan6LI=; b= L67Tqe3akpvaSJXQrljgAL3teDK+d6EG19W0n4Nj6gNxKYas67sNax7/+8I/ZWs9 aDkIVXo3jiUcwOlnQRCqwEs5eKmqPtfL91Cv3QDLKyW9uvsO8/RQkOiQEN18UOSq ICrz87CggQvZwAr1mGyX8IsrwyuSXb6KMUeFdsiTk6XXiMLwvskIJHN0CoW3G44z XEhQ8lJu7mXTBJZr5fTWm584zrJuMz0JjNMG30QJtglhF2zhZimjDkkkMCOsRbyt RI+rb9EZ56ajrJbu0a9ScD28WBPcOinJxuzwwzJW+RC/EDTwEXoyd+7YWqIAW3LB LiOIiDL54qzI4JTK4M6IqQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Ef7LUeUKIwN/KvcMz HPFmlyK/RsSAfTl1Mr8Jtan6LI=; b=HBXD5cKJDKAk/P9xqqsFYGbW68GiwIGWg oaIvtS9JBqNX65Y9k7TA01orBWWhnHro37K04anzn6Z2jkYZ/F6t/YrMiEMyFtOI Y/ETiWY/JyVDybTovvt7LPCN2uGwd/U1rPN+m4UDx+rAoKRn0anfrREHOijQyuY/ UR9VOgYeZwzoJ1q/lhUf0r9Om0gNJ3FoS9xO1PA75007ldA1fYnFAQHw6BP+PNRI ltuzoh165DqgkYEw5oxvWeiqaTvClsD5Fo4asQFHKAaOHDAT3PIItCI0cXHpuHKQ QMzO1qwNMs8oHsV0M/qRh3q5QQJ8jADadeHHr0zBSkWQKVUdSRO+Q==
X-ME-Sender: <xms:gBT1YDqPrbavuYSOvFfFUPGLddA2Ie6NVDFpMCzpowrW03pcy8Tb5Q> <xme:gBT1YNozAlTfgeiOI8ywRTR1jlI5LNx2Tjrq6kAVn3l61iM9nCUG-QkLk2ejnBKih DbYwuxumEWw7F5ltA>
X-ME-Received: <xmr:gBT1YANI3o8VuK6hQdcP4tjV7-CcT4nGt8IfnL645dDWfR-eNHfhLWGoEKzOf55oPADOR51ZNv8o8WBMb3hBtCdR-_TU1Vj_DcHKTxWzWgpOqC3_2QdmO8rs>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdelgdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfukfhfvfffofesrgdtmherhh dtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohht rdhnvghtqeenucggtffrrghtthgvrhhnpeejveehffekuefhleethedujeeljeevtdduve fgueejveeuteduleffheevgeeggeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdif fedrohhrghdptghlohhuughflhgrrhgvrdgtohhmpdhtthhirghsrdgsvgdpmhhitghroh hsohhfthdrtghomhdprhhftgdqvgguihhtohhrrdhorhhgpdhmnhhothdrnhgvthenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmh hnohhtrdhnvght
X-ME-Proxy: <xmx:gBT1YG7H_jfu_a7D43Qtso8ZmRYLGLeXlyKll2ybUExPmYBY0do7-g> <xmx:gBT1YC6CUzh5Oly0kvwG9swo6-evU6NMKWoK7oTtxNIsq6UaF8o29g> <xmx:gBT1YOhd0mnfBO-d6LzFdiFV2outPMUx6wmMcF50cMlnFR4eniQkRQ> <xmx:ghT1YCFnD0DzEMmNDMfTCFN3xQMhv-ehqDp2ehdRQ_VbkpyswA2rJw>
Received: by mail.messagingengine.com (Postfix) with ESMTPA for <tsvwg@ietf.org>; Mon, 19 Jul 2021 01:58:23 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_83AFBD46-BB18-4DF9-89CE-EFEB7DA1CFF0"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Message-Id: <CF409524-96F3-412A-A8DB-E4EFFDD9F4E7@mnot.net>
References: <3985895D-D420-4995-831E-332E33693B79@mnot.net>
To: tsvwg@ietf.org
Date: Mon, 19 Jul 2021 15:58:21 +1000
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/7Fbxa5NryyUzJSWesNFbAx6hs3U>
Subject: [tsvwg] Fwd: UDP source ports for HTTP/3 and QUIC
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jul 2021 05:58:35 -0000

Hi TSVWG,

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 <https://github.com/quicwg/ops-drafts/pull/392>


> Begin forwarded message:
> 
> From: Mark Nottingham <mnot@mnot.net>
> Subject: UDP source ports for HTTP/3 and QUIC
> Date: 15 July 2021 at 10:20:39 am AEST
> To: HTTP Working Group <ietf-http-wg@w3.org>rg>, IETF QUIC WG <quic@ietf.org>
> Resent-From: ietf-http-wg@w3.org
> Archived-At: <https://www.w3.org/mid/3985895D-D420-4995-831E-332E33693B79@mnot.net>
> 
> [ 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., <https://blog.cloudflare.com/reflections-on-reflections/>. 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., <https://ma.ttias.be/linux-increase-ip_local_port_range-tcp-port-range/>
> 
> * On some versions of Windows, ports as low as 1025 are used: <https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements>
> 
> * FreeBSD has used ports as low as 1024 in the past; their documentation is... confused right now. <https://github.com/freebsd/freebsd-src/blob/373ffc62c158e52cde86a5b934ab4a51307f9f2e/sys/netinet/in.h#L272> (I don't run a FreeBSD box to check this)
> 
> * NAT and CGNAT are a thing. <https://www.rfc-editor.org/rfc/rfc4787.html#section-4.2.1> 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   https://www.mnot.net/
> 
> 

--
Mark Nottingham   https://www.mnot.net/