Re: [quicwg/base-drafts] Coalescing different CIDs for same connection (#3800)

Kazuho Oku <notifications@github.com> Tue, 14 July 2020 23:30 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 E34773A0657 for <quic-issues@ietfa.amsl.com>; Tue, 14 Jul 2020 16:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8juBc16q2jgK for <quic-issues@ietfa.amsl.com>; Tue, 14 Jul 2020 16:30:15 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978693A0407 for <quic-issues@ietf.org>; Tue, 14 Jul 2020 16:30:15 -0700 (PDT)
Received: from github-lowworker-d93c4b6.va3-iad.github.net (github-lowworker-d93c4b6.va3-iad.github.net [10.48.17.47]) by smtp.github.com (Postfix) with ESMTP id 4E424520784 for <quic-issues@ietf.org>; Tue, 14 Jul 2020 16:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1594769414; bh=3TYSn5/lsD2ZlbY/HNCt7qN1VYK0IPbMYGVV95Rqwhw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YbGOriiv8ee4+m2pH7fBPK3uiwH1LYZL+SV+F+qcN6JufgCEGs5hbAZJItbJsnuPD L6/O8htVnHNROt6tHw+NRIeM3mLDo9uTnRqJeJzE++kXXjlS4Rcp5if1UNeFaJqT4g Gt+L0Bl/lybMCd8L8shzrChGU6jTvlbiC+wR/++A=
Date: Tue, 14 Jul 2020 16:30:14 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK37NXCDILYWY2TUZPF5DIQQNEVBNHHCNJ65QE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3800/658462267@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3800@github.com>
References: <quicwg/base-drafts/issues/3800@github.com>
Subject: Re: [quicwg/base-drafts] Coalescing different CIDs for same connection (#3800)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f0e40063e9e5_30973f9097ccd960227471"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/beG1j1V0uIp4_Jb5Y4CApJoGcSE>
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: Tue, 14 Jul 2020 23:30:17 -0000

@hardie 
> I think "high probability" is probably app-dependent, because there may be cases where there are significant numbers of parallel connections.  In the case of proxied queries, for example, the use of the same 4-tuple but a different CID could turn out to be common, because the proxy may prefer to keep traffic from its different clients separate even if they could be served by the same upstream server.

I might be missing something, but if an endpoint wants to cut linkability between the packets used during the handshake and the packets used in 1-RTT, that endpoint has to switch to a new CID *after* the peer has dropped its Initial and Handshake keys, regardless of the outcome of this issue. That is because if the endpoint switches to a new CID while the peer is still sending Initial or Handshake packets, we allow the peer to use that new CID in the long header packets sent in response.

Therefore, I do not think that requiring endpoints to use one DCID in all the coalesced QUIC packets help us in practice.

-- 
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/3800#issuecomment-658462267