Re: [quicwg/base-drafts] Bundle new client connection ID and path challenge in migration probes (#1730)

MikkelFJ <notifications@github.com> Mon, 10 September 2018 17:26 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 A061B130EEC for <quic-issues@ietfa.amsl.com>; Mon, 10 Sep 2018 10:26:40 -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 vDDKc1E0QAzp for <quic-issues@ietfa.amsl.com>; Mon, 10 Sep 2018 10:26:38 -0700 (PDT)
Received: from out-15.smtp.github.com (out-15.smtp.github.com [192.30.254.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF51120072 for <quic-issues@ietf.org>; Mon, 10 Sep 2018 10:26:38 -0700 (PDT)
Date: Mon, 10 Sep 2018 10:26:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1536600397; bh=C1U0jkt0tkjAxEdK7D8dEs4A6KFZ/hwT6tTL321V/ZQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=y/wQc7fSde6mhhvEcHLfn60BBs49qtvWjtnGvdPUgcYgGbvAlD8sAX35sT4zXvw8J bUMoy+MEjGZuNFByNMzAPqkTloL3OD2x65mb1jfJSOXNsnRL/+se61saUWW483+p6v HwIssdUS23IGJgOLKCIfUUH2gcmVb5WKkF183qXI=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab4013505aa066ceb57b7ce07c0c00ca273c78821792cf0000000117ae6b4d92a169ce155cc367@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1730/review/153879859@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1730@github.com>
References: <quicwg/base-drafts/pull/1730@github.com>
Subject: Re: [quicwg/base-drafts] Bundle new client connection ID and path challenge in migration probes (#1730)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b96a94d28ba4_3b5c3fd0054d45bc1435c5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/H-I4S5VtQZoXiEvtNw_Ox34Jra0>
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: Mon, 10 Sep 2018 17:26:40 -0000

mikkelfj commented on this pull request.



> @@ -2366,11 +2366,16 @@ genuine migrations.  Changing port number can cause a peer to reset its
 congestion state (see {{migration-cc}}), so the port SHOULD only be changed
 infrequently.
 
-Endpoints could also have their activity correlated if their peers keep using
-the same destination connection ID after migration. Nodes that initiate a
-migration need to provide their peers with new connection IDs. The goal is
+Endpoints that use connection IDs with length greater than zero
+could also have their activity correlated if their peers keep using
+the same destination connection ID after migration. If a node receives
+packets through a newly used connection ID, it SHOULD select an

Yes, it would seem rather pointerless to change CID otherwise. Responding with an old CID is the same as the peer never changing CID. The only reason is running out of CID's and not being that sensitive to linkability. As we now, opting out voluntarily does not work well in crypto.

-- 
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/pull/1730#discussion_r216406711