Re: Expected Client Response to SERVER_BUSY

[Roberto Peon <[e-mail]>]

I believe that the solution to this problem (what a client does when the server is being DoS'd) is inherently out-of-band, and thus not part of the QUIC protocol.

Clients should do whatever they want to do as a response to SERVER_BUSY. We can't make the malicious ones stop, and anything we do to allow non-malicious ones to respond appropriately requires pre-sharing of something, or for the connection to succeed (which is essentially establishing a context for such sharing).

Designing policy around that is probably fodder for another discussion (that I hope we get together and have in the context of the HTTP wg).

-=R

On 2/20/19, 11:44 AM, "QUIC on behalf of Töma Gavrichenkov" <[e-mail] on behalf of [e-mail]> wrote:

    On Wed, Feb 20, 2019 at 10:49 AM Christian Huitema <[e-mail]> wrote:
    > the proposition here allows a middle-box or a man-on-the-side to send an
    > unencrypted signal and have the client immediately immediately drop the
    > connection. That does not feel right.
    
    A man-on-the-side (don't even mentioning a box-in-the-middle) could
    *always* make a client drop a connection, e.g., by sending a large
    amount of junk packets towards the client that the client would be
    unable to correctly handle. It's just a matter of how much harm does
    that box need to do to the network.
    
    Any opposite approach I can think of requires to put the private key
    of the server on a DDoS handling machine or to deploy it onto a DDoS
    mitigation cloud, which not only increases exposure of the users' data
    but is also explicitly forbidden in certain countries for companies
    from certain industries. It's already only narrowly possible to avoid
    doing so with QUIC (and that already requires either a collaboration
    between the QUIC library supplier and the DDoS mitigation vendor —
    which in turn leads to vendor lock — or a reverse engineering-based
    design), so until we have a v2 which is (hopefully) more LB and
    DDoS-aware, this is the lesser of two evils.
    
    --
    Töma