[quicwg/base-drafts] Forced connection ID retirement (#3420)

Martin Thomson <notifications@github.com> Wed, 05 February 2020 11: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 []) by ietfa.amsl.com (Postfix) with ESMTP id 5E9A81200A1 for <quic-issues@ietfa.amsl.com>; Wed, 5 Feb 2020 03:50:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jcK-iHSPi8PY for <quic-issues@ietfa.amsl.com>; Wed, 5 Feb 2020 03:50:37 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C5D120090 for <quic-issues@ietf.org>; Wed, 5 Feb 2020 03:50:37 -0800 (PST)
Date: Wed, 05 Feb 2020 03:50:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1580903436; bh=EVVW3Vjbv+7w2sLFS1U9y7THQ24+sSwHup0ua4rTCLE=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=VzDj30rUeph4yjA9OJGW/hdPT6PolgcD0KedKrGGcw8oRuY/cIlytlytyPp1tbU0y pOiYxMsWMStNx8dSyktZYsaoXzOVl39CgYejowSLoydbxcWL4KFZ2l6yZr9PaYFfvq 6ROWvBWEgD9yrKu4ep+TfEXWs3RsZmGmDbaFboAo=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2BXN3DDK3UBVDBIW54I7PIZEVBNHHCCZOS7A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3420@github.com>
Subject: [quicwg/base-drafts] Forced connection ID retirement (#3420)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e3aac0c83d9e_4d2f3fa6882cd96819462d"; 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/KDC1ZxAJKhfOpaXr29H2NzPEzfU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 05 Feb 2020 11:50:39 -0000

Requiring RETIRE_CONNECTION_ID has lead to all sorts of corner cases.  For instance, a server can force a client to retire the connection ID that is still in use for the handshake.  (We're uncertain yet as to whether the newly provided connection ID usable here, so this only *might* cause genuine problems.)

More to the point, this design assumes things about the nature of connection IDs and routing infrastructure that imply a coupling between path and endpoint state.  The reason you might want to retire a connection ID forcibly in this fashion is that it is no longer usable for routing purposes (or that it results in suboptimal routing, perhaps where packets need to be bounced between nodes in a cluster).

All of this implies that the address tuple is part of the routing assessment.  That makes this feature fragile and it also creates some uncertainty about whether it is possible to build such a system without having a stateless reset oracle.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: