Re: Expected Client Response to SERVER_BUSY

[Ian Swett <[e-mail]>]

For HTTP/3, my intent was to close the connection immediately with a
connection close as you suggest, then the client would fall back to TCP,
and then ensure the next Alt-Svc advertisement via TCP cleared any existing
Alt-Svc entry so QUIC wasn't tried again in the immediate future.

I hadn't thought of assigning semantics to a specific error code, but I'm
reluctant to do so.  In our case, I think a more likely error code would
indicate the infrastructure doesn't support QUIC, rather than DDoS, but the
desired behavior of falling back to TCP and not attempting QUIC for a while
is the same.

The assumption I made above is that the client immediately falls back to
TCP.  That of course depends upon the type of client it is.  I'd expect a
browser to fall back, but I wouldn't expect curl or wget to.

There is a decent amount of text on fallback in the Applicability draft:
https://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicability.md



On Tue, Feb 19, 2019 at 5:11 PM Nick Banks <nibanks=
[e-mail]> wrote:

> Hello Folks,
>
>
>
> I’ve been looking at interim DDoS mitigation strategies for QUIC until we
> can have a more complete and QUIC aware DDoS and LB solution. One thing I
> came up with is just trying to force the client to fallback to TCP.
> Eventually, we will use Stateless Retry but that still requires a good bit
> of design work and cooperation between the offload device and the backend
> server. Until that is complete, a simple solution could be a device in path
> just responding to new QUIC connection attempts (while an attack is in
> progress) with a connection close frame containing the SERVER_BUSY error.
> The logic to implement a simple device to do that should be quite trivial.
>
>
>
> To that end, I was trying to figure out what the expected client response
> to any immediate (in the first RTT) connection close packets/frames would
> be and it seems we don’t have anything in the spec. What about SERVER_BUSY
> specifically? Is the client supposed to retry a new connection attempt?
> Should they fallback to TCP immediately? Should we say anything in the spec?
>
>
>
> Thanks,
>
> - Nick
>