RE: Expected Client Response to SERVER_BUSY

[Nick Banks <[e-mail]>]

The best thing I could think of is some client side logic that has a timer to wait for a possible valid server response for some short time after it receives the conn close frame. If it comes, ignore the close.

- Nick

From: Ian Swett <[e-mail]>
Sent: Wednesday, February 20, 2019 10:52 AM
To: Christian Huitema <[e-mail]>
Cc: Töma Gavrichenkov <[e-mail]>; Nick Banks <[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

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]<mailto:[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]<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]<mailto:[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]<mailto:[e-mail]>>
>> Sent: Wednesday, February 20, 2019 7:04 AM
>> To: Nick Banks <[e-mail]<mailto:[e-mail]>>
>> Cc: Ian Swett <[e-mail]<mailto:[e-mail]>>; Brian Trammell (IETF) <ietf@trammell..ch<mailto:ietf@trammell..ch>>; IETF QUIC WG <[e-mail]<mailto:[e-mail]>>; Mirja Kühlewind <[e-mail]<mailto:[e-mail]>>
>> Subject: Re: Expected Client Response to SERVER_BUSY
>>
>> On Wed, Feb 20, 2019 at 6:50 AM Nick Banks <nibanks=[e-mail]<mailto:[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