RE: handling a QUIC accept backlog

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 21 February 2018 20:15 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D621201F2 for <quic@ietfa.amsl.com>; Wed, 21 Feb 2018 12:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNRU0aov_VPa for <quic@ietfa.amsl.com>; Wed, 21 Feb 2018 12:15:52 -0800 (PST)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E4412D94A for <quic@ietf.org>; Wed, 21 Feb 2018 12:15:52 -0800 (PST)
Received: by mail-it0-x22c.google.com with SMTP id o9so3620014itc.1 for <quic@ietf.org>; Wed, 21 Feb 2018 12:15:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SZamusqWT4pv49T+Z+KLUssz2E0utWUTr4bi8WPJ15g=; b=WpHpt8vcASzPTsaB3RGRJ6KfHsUf7oOFQ8EBEAoHxa5zSNP/bRLuP8aRwau+RSeW5H W2U8LRAe3yrEzAr2/Y9LyIwXL6Y3qgznReKeHpEzdxnbweZ6YboH46k/Jp4m1J7yZcYT nVjf5P7qyms8/BKOVD5vSBO3e0lnvWybyDuKfrtcUgrfJq22ByXZo7cy0ActY8+ijlGD Y8r7hG7KUKsoOX3eNS254Bp5yReOg1CZCnB9Hl7BE0dlHqxpzxwjoWcso4Dy8MnzTBJj +1u+5KlzDSbzDekjyqZXF4BzJWqMfnAcHdGssdto5altmlRmvXCi5N/PYRzvX0V6RlIR 3LTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SZamusqWT4pv49T+Z+KLUssz2E0utWUTr4bi8WPJ15g=; b=jny9A4eB7TAiwG9er9UQY57+L9Ki4J93x+3ANblm9I5zK4IlTYd6dLhILRClKmO1PT PUZcRATDLD4TFCzYmqcLZKEHuohuNyRm+v5e3Oj/2paDT+xO38NGpxtYLCZuFieiXNRc 9fXgk0INihHiDCQZhwI7Tx2zP8EoDvgtc9v23u8QVttTrr0XYRLx4Blt0hnwS+xGWwJ1 BthFfcAUuwsMYB+TWpy+WaG/FwnbZC9rYzQwk1dRenjRqy2YaF3MD24AH1NnU113dWch 43aXPUdmhps5eK2iZ0zjzZ03Ua6/hb+jw/WTWyXFA2qqZioIl0kbNtaz3X+B/5LeTKBE F78Q==
X-Gm-Message-State: APf1xPCu5C8VvQmXqmve7qWbLQL1lEvIqfTV2Z4G5N+cHZ4nyaWmAVrL 0du/WwOZTJ3kOec/8UB4Dd/xULVcTKxTIy+uVyI=
X-Google-Smtp-Source: AH8x226iV/5Cppg2CnnOqSAmnCtWbiqgqWP7U2gmFo6k0ZBsBsMd7lf3LY+U8iwYctegCcPleE7Fb55s/lYQiFo0n78=
X-Received: by 10.36.123.198 with SMTP id q189mr5040169itc.118.1519244151979; Wed, 21 Feb 2018 12:15:51 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Feb 2018 15:15:51 -0500
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <CY4PR21MB01336E0007959CF0DF01D330B6CE0@CY4PR21MB0133.namprd21.prod.outlook.com>
References: <CAOYVs2p=wdOMLxdMatoY4f=P3ZMCNOBHeg4-ep+dNJ8TRM7zEA@mail.gmail.com> <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch> <CY4PR21MB01336E0007959CF0DF01D330B6CE0@CY4PR21MB0133.namprd21.prod.outlook.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 21 Feb 2018 15:15:51 -0500
Message-ID: <CAN1APdeJjOqR08Y9p-qPa6h59sLf8F5Jr=9nimhBg4yCFairOw@mail.gmail.com>
Subject: RE: handling a QUIC accept backlog
To: Marten Seemann <martenseemann@gmail.com>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Praveen Balasubramanian <pravb@microsoft.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114760b20190d70565be98b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hIhkmUORaNIR9387uv3Ux-6kZ28>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Feb 2018 20:15:56 -0000

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 (
pravb@microsoft.com) 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:quic-bounces@ietf.org] On Behalf Of Mirja Kühlewind
Sent: Wednesday, February 21, 2018 10:13 AM
To: Marten Seemann <martenseemann@gmail.com>
Cc: QUIC WG <quic@ietf.org>
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



> Am 21.02.2018 um 17:39 schrieb Marten Seemann <martenseemann@gmail.com>om>:
>
> 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?
>