Re: Expected Client Response to SERVER_BUSY

[Ian Swett <[e-mail]>]

Agreed it's not amazing, but stateless reset isn't available until the
handshake completes.  Did you have any suggestions?

On Wed, Feb 20, 2019 at 1:49 PM Christian Huitema <[e-mail]>
wrote:

> Can we do better than an unauthenticated signal to "drop QUIC
> immediately and use something else"?
>
> I understand the desire of protecting servers against DOS attacks, but
> 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.
>
> -- Christian Huitema
>
>
> On 2/20/2019 7:38 AM, Töma Gavrichenkov wrote:
> > I mean, yes, handling such a case explicitly totally makes sense. I
> > just wanted to point out that there's an additional use case when UDP
> > transmission just suddenly stops under an attack.
> >
> > Note that a DDoS attack towards a QUIC server isn't the only possible
> > scenario, the other one being a DDoS towards a client. In the latter
> > scenario, given the not-so-likely-but-completely-possible case when a
> > newly discovered DDoS amplifying protocol would be using port 443/udp,
> > even selective blackholing won't help to preserve QUIC connectivity.
> > As a matter of fact, there's no way to handle it
> > transport-protocol-wise, but maybe adding a timeout-related suggestion
> > of a SHOULD CONSIDER style to the spec would be a good idea.
> >
> > | Töma Gavrichenkov
> > | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
> > | mailto: [e-mail]
> > | fb: ximaera
> > | telegram: xima_era
> > | skype: xima_era
> > | tel. no: [phone]
> >
> > On Wed, Feb 20, 2019 at 7:19 AM Nick Banks <[e-mail]>
> wrote:
> >> I want to support something a bit more efficient than simple rate
> limiting and packet drops. The client might have relatively large timeout
> in that case before falling back to TCP. If possible, I want to be able to
> give an immediate indication that it should try to fallback.
> >>
> >> - Nick
> >>
> >> -----Original Message-----
> >> From: Töma Gavrichenkov <[e-mail]>
> >> Sent: Wednesday, February 20, 2019 7:04 AM
> >> To: Nick Banks <[e-mail]>
> >> Cc: Ian Swett <[e-mail]>; Brian Trammell (IETF)
> <ietf@trammell..ch>; IETF QUIC WG <[e-mail]>; Mirja Kühlewind <
> [e-mail]>
> >> Subject: Re: Expected Client Response to SERVER_BUSY
> >>
> >> On Wed, Feb 20, 2019 at 6:50 AM Nick Banks <nibanks=
> [e-mail]> wrote:
> >>> It would be nice to have a way for the server to say “QUIC is
> >>> temporarily unavailable right now, please go use TCP instead.”
> >> One issue here is that under a DDoS attack an ISP would just apply
> selective blackholing or flow specification which would simply drop all the
> incoming UDP traffic to protect the last mile. Depends on the attack
> pattern somewhat, sometimes blackholing might be more granular, but all in
> all you should expect that.
> >>
> >> The only hope here is that a client would interpret response timeout in
> the same way as SERVER_BUSY.
> >>
> >> --
> >> Töma
>