Additions to "bad port list" for UDP due to HTTP/3

[enygren]

With the introduction of HTTP/3, Fetch should likely have additions to the bad port list covering common UDP attack vectors. As @davidben mentions in #1189 this should also probably explicitly apply to Alt-Svc and SVCB/HTTPS RR port targets. For example, @mnot raised on the HTTP & QUIC WG this list:

• 53 - DNS (already a "bad port")
• 123 - NTP (already a "bad port")
• 1900 - SSDP
• 5353 - mDNS
• 11211 - memcached

The alternative may be to switch to a "good port" list (#1189)

[martinthomson]

Note that @mnot raised this specifically for source ports, whereas the blocklist in the spec exists for destination ports. It's really important to be clear on this point.

I know that @annevk already has designs on unifying the port number blocklist for destination ports, but the introduction of a blocklist for source ports is new and likely unique to UDP.

[ricea]

Many systems use the IANA suggested ephemeral ports 49152–65535 for source ports and so avoid most registered ports. However, it's complicated: https://en.wikipedia.org/wiki/Ephemeral_port

[martinthomson]

Yep, it's not simple. It's even worse than that when you consider the effect of NAT on source ports. I think that IETF action is probably the best way to move on this.

[ricea]

We've been discussing w3c/webtransport#229 and I think we might need a separate list of source ports to block for UDP-based protocols.

From the point of view of a NAT device, a TCP connection has a clear client and server, so usually only the destination port is interesting. But UDP is more ambiguous, and a packet going from an internet host to a client may cause a NAT binding to be formed.

Regardless, the WebTransport W3C standard would like to delegate to the Fetch standard for the list of ports to block.