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 <[email protected]> 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/ >
