Re: [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

[Nico Williams <[e-mail]>]

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
--