RE: Expected Client Response to SERVER_BUSY

[Praveen Balasubramanian <[e-mail]>]

Agreed that we cannot mandate any client behavior for malicious clients, but have clear guidance for well-behaved clients to fall back to TCP. This mechanism provides a very low CPU cost fast fallback to TCP under DoS attacks until all infrastructure can support QUIC natively. Certainly a big step up from just rate limiting UDP traffic. This way well behaved clients will have a good chance for connectivity and the malicious ones will be rate limited. And as pointed out middleboxes can do other bad things like drop all CIs.

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Roberto Peon
Sent: Wednesday, February 20, 2019 12:48 PM
To: Töma Gavrichenkov <[e-mail]>; Christian Huitema <[e-mail]>
Cc: Nick Banks <[e-mail]>; Brian Trammell (IETF) <[e-mail]>; Ian Swett <[e-mail]>; IETF QUIC WG <[e-mail]>; Mirja Kühlewind <[e-mail]>
Subject: Re: Expected Client Response to SERVER_BUSY

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