Re: UDP source ports for HTTP/3 and QUIC

[Mikkel Fahnøe Jørgensen <[e-mail]>]

It is perhaps worth noting that due to QUIC (optionally) having unique connection identifiers, it is feasible to have many connections on the same source port. Therefore that could be a recommendation in cases where some source ports might be blocked.

As others have pointed out, I would suspect an RFC with a port list would quickly become outdated.

Mikkel

> On 15 Jul 2021, at 02.20, Mark Nottingham <[e-mail]> wrote:
> 
> [ 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/
>