On Thu, Dec 06, 2018 at 10:58:01AM -0800, C. M. Heard wrote: > [...]? I would certainly hope > that filtering UDP/443 is not done preemptively without actual evidence that > it is in fact a DDoS vector. I'd expect that networks that filter / rate-limit UDP do it mostly indiscriminately, and wouldn't already have exceptions for port 443. Exceptions would mostly be for things like DNS and NTP (not filtered, obviously, but maybe rate-limited). The port number / application has a lot to do with DDoS potention. E.g., DNS has great amplification potential, so it needs rate limits. TCP has much smaller amplification potential, and more of the TCP state machine is visible to the network than any non-TCP protocol's state machine, so maybe TCP SYNs and maybe even RSTs get rate-limited, but others do not. With TCP there's no need to discriminate by port number or know what the application protocol is. With UDP all you have is port numbers to discriminate by. Without exposing that sort of detail (SYN, RST, ...) to the network, I'd expect operators to scoff, and QUIC to have trouble in the public Internet until operators / kit learn how to handle QUIC. Not that we can expect kit to understand new upper level protocols, or new UDP application protocols, in with any kind of celerity. So it's all a mess :( Also, we can run HTTP and HTTPS over TCP on any ports, not just 80 and 443. That won't be true for QUIC. Each alternative port number will have to get middlebox relaxation de novo. That could be a problem, or maybe a blessing: maybe QUIC should mux multiple apps on one port. (QUIC muxes streams, but not apps). Then again, QUIC is done, right? Nico --
