Re: Is the invariants draft really standards track?

[Benjamin Kaduk <[e-mail]>]

On Fri, Jun 19, 2020 at 02:48:48PM -0700, Christian Huitema wrote:
> When under DOS attack, you want to "minimize blowback", i.e., as much as
> possible avoid generating packets in response to attack traffic. So,
> yes, a server may choose to not send stateless resets to anyone when
> under attack; in fact, my recommendation would be that a server SHOULD
> NOT send stateless resets to anyone when under attack.
> 
> That said, Igor raised an interesting point about return traffic. It
> would be very nice if DOS protection boxes could distinguish between
> "validated traffic" that the server presumably intends to process, and
> "unsolicited traffic" that will just consume resource. The box can then
> reserve some share of the resource for validated traffic, and place the
> rest of the traffic in a lower priority queue. Fine, but there needs to
> be a test. The classic test is that incoming traffic is "validated" if
> the protection box can match it with return traffic coming from the
> server -- for some definition of matching.
> 
> From that point of view, stateless reset is definitely not helpful. But
> problematic traffic goes beyond that. The server will reply to a
> client's initial with a server's initial packet. Does that validate the
> response traffic? OK, maybe the protection box can programmed to only
> validate traffic if it sees 1RTT packets. But many servers will send
> 1-RTT packets as 0.5 RTT. Does that validate the response traffic?
> 
> We might say that traffic is validated when the handshake is confirmed,
> but the protection box does not understand the TLS handshake, it just
> sees packet types and packet sizes. It cannot distinguish between 0.5RTT
> data and 1RTT data, and thus the closest approximation of "validation"
> would be seeing more than an initial window worth of traffic coming back
> from the server. That does not sound great.
> 
> On the other hand, things get much better if the server under attack can
> adopt a defensive posture and help the DOS protection box do its job.
> Suppose that a server can detect that it is under attack -- or be
> explicitly configured so. The simplest defensive posture would be to (1)
> disable stateless reset and (2) not send any 0.5RTT packet, including in
> response to 0-RTT. The protection boxes can at that point take the 1-RTT
> packets from the server as indicating validation.
> 
> Maybe we should specify that.

It might also be an interesting thought experiment to see what
kind of things the QUIC server could send to the DoS protection box if
the QUIC server acts as a DOTS (RFCs 8782 and 8783) client to a DOTS
server controlling the DoS protection box.

-Ben