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

[Mark Nottingham <[e-mail]>]

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 <[e-mail]>
> Subject: UDP source ports for HTTP/3 and QUIC
> Date: 15 July 2021 at 10:20:39 am AEST
> To: HTTP Working Group <[e-mail]>, IETF QUIC WG <[e-mail]>
> Resent-From: [e-mail]
> Archived-At: <https://www.w3.org/mid/[e-mail]>
> 
> [ 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/