Subject: handling a QUIC accept backlog

From: Marten Seemann <[email-masked]>
Date: Wed, 21 Feb 2018 16:39:55 +0000

When using a socket API for a QUIC server, it can happen that there are
more incoming connections than the server can accepts at that moment. I
imagine that a server will implement some sort of queue containing
connections that have the handshake completed. Do we need any guidance on
what should happen when that queue is full?

There are multiple ways how a server could handle this situation:

   - Drop all Initial packets.
   - Send a CONNECTION_CLOSE as a response to an Initial.
   - Reply with Retries to Initial packets, but drop Handshake packets.
   - Something more sophisticated?

Should we write anything about this in the spec, or is this something that
implementations have to figure out for themselves without any guidance?

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 21 Feb 2018 19:13:10 +0100

Hi Martin,

I think that could fit well in the applicability doc. If people agree, please go ahead and file an issue or a PR.

As a general note, both the applicability and the manageability statements are outdated, as things are so much in move still and therefore we didn’t put effort in to sync up with every revision. As soon as things (especially around the wire image and handshake) have settle a bit more, we will do an update.

Mirja

> Am 21.02.2018 um 17:39 schrieb Marten Seemann <[email-masked]>:
> 
> When using a socket API for a QUIC server, it can happen that there are more incoming connections than the server can accepts at that moment. I imagine that a server will implement some sort of queue containing connections that have the handshake completed. Do we need any guidance on what should happen when that queue is full?
> 
> 	• Drop all Initial packets.
> 	• Send a CONNECTION_CLOSE as a response to an Initial.
> 	• Reply with Retries to Initial packets, but drop Handshake packets.
> 	• Something more sophisticated?
> Should we write anything about this in the spec, or is this something that implementations have to figure out for themselves without any guidance?
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 21 Feb 2018 19:45:33 +0000

This is somewhat related to DoS attack mitigation and could go into “Security and Privacy Considerations” section of either the transport or the applicability draft with some recommendation on the attack vectors and mitigations.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
Sent: Wednesday, February 21, 2018 10:13 AM
To: Marten Seemann <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: handling a QUIC accept backlog

Hi Martin,

Mirja

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 21 Feb 2018 15:15:51 -0500

There is also the argument for HTTP 500 Server Busy - could be protocol
specific.
But load balancer might also want to know when routing encrypted data.
LB signals could also happen through the CID sub protocol -
helping load balancers might otherwise also help DoS attackers?
It could also be an ECN signal + drop.

Unless we really want to help load balancers, I agree it is more an
applicability thing.

On 21 February 2018 at 20.45.42, Praveen Balasubramanian (
[email-masked]) wrote:

This is somewhat related to DoS attack mitigation and could go into
“Security and Privacy Considerations” section of either the transport or
the applicability draft with some recommendation on the attack vectors and
mitigations.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
Sent: Wednesday, February 21, 2018 10:13 AM
To: Marten Seemann <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: handling a QUIC accept backlog

Hi Martin,

I think that could fit well in the applicability doc. If people agree,
please go ahead and file an issue or a PR.

As a general note, both the applicability and the manageability statements
are outdated, as things are so much in move still and therefore we didn’t
put effort in to sync up with every revision. As soon as things (especially
around the wire image and handshake) have settle a bit more, we will do an
update.

Mirja

> Should we write anything about this in the spec, or is this something
that implementations have to figure out for themselves without any
guidance?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Feb 2018 10:50:43 +1100

Marten's question is a design one, I think.  But as an operational
practice, some additional documentation elsewhere could help.

I don't think that I had any expectation, but it seems like a good
idea to have some way that a server can signal "not now".  That
increases DoS risk (to the other discussion this week), but I think
that in terms of our agreed principle on trying to stop that sort of
attack, we shouldn't worry too much about that right now.

Dropping Initial packets works.  It's probably something to do in the
extreme case.
CONNECTION_CLOSE is probably better (better yet if we had an "I'm
overloaded" code, PR wanted).
Retry doesn't really work unless you think an extra round trip will
cool things down enough.
If you get to the point of receiving Handshake, then CONNECTION_CLOSE
is all you really have, but you probably want to avoid doing that
(because you already sunk a ton of effort into the first round of
Handshake messages).

Note that a server with too many connections can (and probably should)
use HTTP Alternative Services to shed load, but that won't necessarily
help in the short term.