Re: Expected Client Response to SERVER_BUSY

[Roberto Peon <[e-mail]>]

In some circumstances, falling back to TCP may be something that the application shouldn't do (TCP offers the wrong semantics, or there are concerns about visibility).

I think this is very much an application-level thing, and not so much a transport-level thing.

-=R

On 2/20/19, 1:02 PM, "Praveen Balasubramanian" <[e-mail]> wrote:

    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