Re: Expected Client Response to SERVER_BUSY

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Why not deal with this at the DNS layer and work with the designs that are floating?

Other than that I agree with Roberto and Kazuho.


________________________________
Fra: QUIC <[e-mail]> på vegne af Kazuho Oku <[e-mail]>
Sendt: torsdag, februar 21, 2019 2:01 AM
Til: Roberto Peon
Cc: Töma Gavrichenkov; Ian Swett; Mirja Kühlewind; Christian Huitema; Nick Banks; Brian Trammell (IETF); IETF QUIC WG
Emne: Re: Expected Client Response to SERVER_BUSY

2019年2月21日(木) 5:49 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).

I think I mostly agree with Roberto here.

Anyways, the issue is with H3, not QUIC as a transport protocol. HTTP
is unique in sense that it can use either TCP or QUIC as a transport.
We cannot expect every application protocol to have that kind of
property.

And even in case of H3, our conclusion might depend on how the H3
endpoint was discovered. We might argue that it makes sense to permit
the fallback when the H3 endpoint was discovered due to an upgrade
from TCP (e.g. alt-svc). But the situation would be different if the
H3 endpoint was discovered through other means (e.g., extension field
of ESNI record).

> -=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
>
>
>


--
Kazuho Oku