Re: Expected Client Response to SERVER_BUSY

[Töma Gavrichenkov <[e-mail]>]

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) <[e-mail]>; 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