Subject: [Dots] Fwd: Is the invariants draft really standards track?

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 19 Jun 2020 15:17:20 -0700

Happening over on [email-masked], if there is anything interesting to note.

-Ben

On Fri, Jun 19, 2020 at 02:53:25PM -0700, Benjamin Kaduk wrote:
> 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
>