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

Mark Nottingham <mnot@mnot.net> Tue, 20 July 2021 03:43 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 538033A0BB1 for <tsvwg@ietfa.amsl.com>; Mon, 19 Jul 2021 20:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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=V02J7R1N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZFxBJsQd
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 AMEpg-84pKyD for <tsvwg@ietfa.amsl.com>; Mon, 19 Jul 2021 20:43:33 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8763A0BAD for <tsvwg@ietf.org>; Mon, 19 Jul 2021 20:43:32 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C4E123200912; Mon, 19 Jul 2021 23:43:28 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 19 Jul 2021 23:43:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=i M82OQFpWdOTKVLGkydYQnFsP4FcEIk7uFDnDoHyFK8=; b=V02J7R1N17bM44dAn 887QHVZ25BdOpYLw+dPV43aeur3fGhgOyrGIqjIlOS+doWT3kqbygay3qiMXDYmr i+DHOAAsZmwMFd9Qngyo4sWQ5HaaMhg6OGX+v3YA0lvSDKZPLR1UwWQeooB44aUR on7vuH7O4sujQt/SYpdj+bWdQlDADsQ+q2FIRfqPqSvNYqc9dsnR6SavV3k4i66H 3WQWRH4i/n/Lgv2TtDAuBby/2+tuFkr8W3LWZQugEjQgzaRMz0ZDZUF+p60YVGbP /IIy2icWWvedLnrlxtptkVVhlJjbPJ7/pz6n/ealjX74YFASvBjt/fiKziXHeKIG 2rb4g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to: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=iM82OQFpWdOTKVLGkydYQnFsP4FcEIk7uFDnDoHyF K8=; b=ZFxBJsQdb5kp6NjQf3ByfPi3W2RAcTthZqSMfZanxvMv1ZfgoijVvrj3w cLubV3zw20csVd62uLwgukMqf5yW5ixZq2eGEkBJ0uPAFZpjEJEozp9m8LMUnZvD piGS9HKdKT026LV11lp7L+BNuvZWY4FM1RJo2kyvZDqt8vEJWSmBNHqCw68X76u3 uu4w4J1rvN+PobclAKQBNWMB6PkhmDqET39cas/hPwwsRuEam3Et1mQ1BqlHAT/b f1sDug/5lRotuJZK9yEa01fGXM6ia1A3aL9h/cKbaVGXa4moOdg5LX2SnDrwwQwk UdEoOKEDlRtcX/PoJ+2RiT06yu67w==
X-ME-Sender: <xms:Xkb2YMBX9Tp4Wcu3StP8E9bsn103vFobyl84r7F9uwUV4AtVU7m77Q> <xme:Xkb2YOj4QjSenpB-E5o-huflwtWqVR-6qaQy6wvCHnOZ1Y5kG3lQoEnsJ-9tDQlCu wwS7cnGR7_CzNf4ZQ>
X-ME-Received: <xmr:Xkb2YPnCZAk8exIxPhFgynwzgKKUAq8ihmIfqOniYAT_EDdDpngnCbKSvuVtuI9hixGs2jigLKV3SH71zdMdTer4DicrXVUPs7chGlD15dHCHK-Go8nx3K_E>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfedugdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepuddvueduveehleevffefheffgfekvdfgveelgfdttdevvedvlefghfelfeeufedu necuffhomhgrihhnpehgihhthhhusgdrtghomhdpfiefrdhorhhgpdgtlhhouhgufhhlrg hrvgdrtghomhdpthhtihgrshdrsggvpdhmihgtrhhoshhofhhtrdgtohhmpdhrfhgtqdgv ughithhorhdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:Xkb2YCwmgncYz_CeKX_LAhTqJWeouMOozWe7Rb4qylVHr9_sHRLEvQ> <xmx:Xkb2YBSNiWU9lwOk_ZTJjCaWHUpRe6C43XkLQqUCzqQ75F2V41DVQQ> <xmx:Xkb2YNalp7coH9yE9L7v3qyjpWO8TZkbKMh9STqvR8PiQZ9qskJjUQ> <xmx:YEb2YDewMpRUXciD_cXf2Z9CLrTwIwL-loNB4OwVNO1ct8EwFuOo7w>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 19 Jul 2021 23:43:25 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <E62515E7-38FD-4197-8CF0-2D196FB6D6C4@strayalpha.com>
Date: Tue, 20 Jul 2021 13:43:22 +1000
Cc: tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <16CD883B-9561-41A5-97E0-43EF3618333C@mnot.net>
References: <3985895D-D420-4995-831E-332E33693B79@mnot.net> <CF409524-96F3-412A-A8DB-E4EFFDD9F4E7@mnot.net> <E62515E7-38FD-4197-8CF0-2D196FB6D6C4@strayalpha.com>
To: Joseph Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/FE6q8HnFMYyQAxSopkpCAY0lBEo>
Subject: Re: [tsvwg] 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: Tue, 20 Jul 2021 03:43:38 -0000

Hi Joe,

> On 20 Jul 2021, at 1:15 pm, Joseph Touch <touch@strayalpha.com> wrote:
> 
> 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.

And yet, we have text like this in RFC5905:

> dstport: UDP port number of the client, ordinarily the NTP port
   number PORT (123) assigned by the IANA.  This becomes the source port
   number in packets sent from this association.

and this in RFC6762:

> A compliant Multicast DNS querier, which implements the rules
   specified in this document, MUST send its Multicast DNS queries from
   UDP source port 5353 (the well-known port assigned to mDNS)

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

I don't follow. 

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

Based upon the preliminary discussions we've had on the QUIC list, I don't think there's consensus to do that.


> Joe
> 
> (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 <mnot@mnot.net> wrote:
>> 
>> 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>, 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/
>> 
> 

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