[quicwg/base-drafts] Prevent connection ID exhaustion (#1468)

Martin Thomson <notifications@github.com> Fri, 22 June 2018 00:50 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F252A12F1A6 for <quic-issues@ietfa.amsl.com>; Thu, 21 Jun 2018 17:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 8Kc_Dw27BgOZ for <quic-issues@ietfa.amsl.com>; Thu, 21 Jun 2018 17:50:00 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567271294D0 for <quic-issues@ietf.org>; Thu, 21 Jun 2018 17:50:00 -0700 (PDT)
Date: Thu, 21 Jun 2018 17:49:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1529628599; bh=CBFoaDcbjqrjLlqrJ5pc9oH3XxwH8SQuD5E7WiJToWM=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=FX8x7SkFISv19BNMzYIkni5xnchxuzKYne/0JLs5T+9CgXkph2zArbJ13t17bU7iv H2B5BmIyt+ciXktKsjwqjd0igKgj84oPG3mq/5RXDRg4LKdh/WDzPlVHjXl75AO+Qk qh6t2pIJLCXXW0WUUw5COZnvgr3EdOyFJ74qs05A=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab17f000a9bd740f8253036f6bf917d57a51aebf0d92cf00000001174409b792a169ce13f33b45@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1468@github.com>
Subject: [quicwg/base-drafts] Prevent connection ID exhaustion (#1468)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b2c47b76ee6c_6a032ac5898d4f54834a7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/XY1NmBBXrh_WVPAWC8UqeC097Kw>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2018 00:50:04 -0000

In #1452, we realized that we need connection ID sequence numbers back, and it seems like the design in #1465 depends on symmetry: if you see connection ID X, then you have to use at least connection ID X (and not X-1).

In that case, there will never be a case where an endpoint is going to want to provide significantly more connection IDs than its peer.  If any of those are used, it won't be able to send anything in response.  So that suggests a simple solution to exhaustion: if you receive NEW_CONNECTION_ID, you are required to provide NEW_CONNECTION_ID frames up to the sequence number you have received.

Then, an endpoint that wants to maintain N spare connection IDs can simply issue NEW_CONNECTION_ID frames until it has made that many connection IDs available to its peer.  It's peer is then obligated to provide the same number in return.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1468