- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 16 Jul 2021 10:27:20 +1000
- To: Erik Nygren <erik+ietf@nygren.org>
- Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Adding source ports to Fetch to complement their list of "bad" destination ports is interesting, but probably not sufficient -- NAT and CGNAT vendors tend not to read that document. If we believe both that this should be written down and that more reflection-capable applications are going to emerge, we should probably put this information in a registry. It strikes me that it could be done by adding a column to the port registry <https://www.iana.org/assignments/service-names-port-numbers/>. In other words, TSVWG. Thoughts? Cheers, > On 16 Jul 2021, at 9:25 am, Erik Nygren <erik+ietf@nygren.org> wrote: > > > On Wed, Jul 14, 2021 at 8:21 PM Mark Nottingham <mnot@mnot.net> 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). > > > > Closely related, the Fetch spec's "bad port" list is fairly TCP-specific and could likely > use additions for some of these. I opened https://github.com/whatwg/fetch/issues/1268 > to track that. > > Erik > > -- Mark Nottingham https://www.mnot.net/
Received on Friday, 16 July 2021 00:27:44 UTC