RE: handling a QUIC accept backlog

Praveen Balasubramanian <pravb@microsoft.com> Wed, 21 February 2018 19:45 UTC

Return-Path: <pravb@microsoft.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 A902312DA3F for <quic@ietfa.amsl.com>; Wed, 21 Feb 2018 11:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 ofrVq6LL1cYI for <quic@ietfa.amsl.com>; Wed, 21 Feb 2018 11:45:35 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0096.outbound.protection.outlook.com [104.47.38.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5C312DA25 for <quic@ietf.org>; Wed, 21 Feb 2018 11:45:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DWk4nPZmb5xlVuTgoxpaBcygJc5q9TiGwS7Ty5Jvb7g=; b=ijI8OpSHOwrIch+wS0WCAqorv2+6jJJEtEcanmXL6PqBmcD5eGtScE40+oorx0g3aPuCTNJJ4heOIgng8ak4L8iXU8LKgrWYHo8UV0up3fKnnJNoT7tLMErBaC3dsvPSyGPtRgSCFdgWC6YsBeiw1uhNrzl16vMYHHCAIsyjfqQ=
Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0775.namprd21.prod.outlook.com (10.173.192.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.1; Wed, 21 Feb 2018 19:45:33 +0000
Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::9df5:45b9:854a:4f16]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::9df5:45b9:854a:4f16%9]) with mapi id 15.20.0548.005; Wed, 21 Feb 2018 19:45:33 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Marten Seemann <martenseemann@gmail.com>
CC: QUIC WG <quic@ietf.org>
Subject: RE: handling a QUIC accept backlog
Thread-Topic: handling a QUIC accept backlog
Thread-Index: AQHTqzKuknd4i4lDqEaeH45SGqZBy6OvKN0AgAANCZA=
Date: Wed, 21 Feb 2018 19:45:33 +0000
Message-ID: <CY4PR21MB01336E0007959CF0DF01D330B6CE0@CY4PR21MB0133.namprd21.prod.outlook.com>
References: <CAOYVs2p=wdOMLxdMatoY4f=P3ZMCNOBHeg4-ep+dNJ8TRM7zEA@mail.gmail.com> <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch>
In-Reply-To: <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:5::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0775; 7:+7v86HlH+LIdssEmwAx1iYAAABe+WpXbm4fY0Y3qN7vA+ryugQe72qLmp8gaJTwzfQoiHahTcJpjUQmKN+904QGku0AeF5+KCdhREuDj1aVVHIN25NZM+VYAg/4ly7qUNwvB0va9Sa6dwTSnFpcbKvkZEYq6KfufM/Lv18em78Mk/qmo3pTuHWxOPaOgI2/OaF0MCdQWnpmXQdlgevRf4GWdmZdNj0t6K2wMT+gcXP9XKgYxy4rb6gjbRKaw+HlN
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 6177d8ce-0f1f-47b1-b638-08d57963abfa
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0775;
x-ms-traffictypediagnostic: CY4PR21MB0775:
x-microsoft-antispam-prvs: <CY4PR21MB07750F335CC94D1F0A83B807B6CE0@CY4PR21MB0775.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001070)(61425038)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231158)(944501161)(52105067)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0775; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0775;
x-forefront-prvs: 0590BBCCBC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(396003)(366004)(376002)(346002)(51444003)(199004)(189003)(13464003)(57704003)(229853002)(10290500003)(478600001)(25786009)(9686003)(3660700001)(39060400002)(102836004)(53546011)(6506007)(55016002)(8936002)(6436002)(59450400001)(76176011)(68736007)(2950100002)(4326008)(6346003)(305945005)(14454004)(33656002)(53936002)(7736002)(74316002)(99286004)(6116002)(2900100001)(7696005)(81156014)(81166006)(97736004)(10090500001)(86362001)(22452003)(6246003)(3280700002)(316002)(8676002)(86612001)(8990500004)(186003)(2906002)(110136005)(106356001)(105586002)(5660300001)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0775; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-message-info: zo8+LG7vMvTYQTggUCzralnGRWwQSwMxpO+Oy4HGVm/Hcxktwlf6TWn5s1kQZJ233OPKI5RRoArH1nHiqzK7pQ5NeNH+sZQdZWsWORMRiEl5bBjRSrM9yP/l2YEgWZLE7RUpX3/GL9bJSaQPm0qDhe+MuTWf+LHdq57CSVLDV4k=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6177d8ce-0f1f-47b1-b638-08d57963abfa
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2018 19:45:33.6069 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0775
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/z9Uqa7bJCO5h-60CXKZBxSK5DLk>
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 19:45:38 -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: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>:
> 
> 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?
>