Re: [quicwg/base-drafts] Clarify text around preferred address (#3589)

Eric Kinnear <> Mon, 11 May 2020 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19D343A0C75 for <>; Mon, 11 May 2020 12:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.272
X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oRBRRn48uncl for <>; Mon, 11 May 2020 12:48:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E1933A0C55 for <>; Mon, 11 May 2020 12:48:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 65453960729 for <>; Mon, 11 May 2020 12:48:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1589226488; bh=r3/23qj2hyQBlvgpXDeekhECuSwqsekacq/s/TC2RNw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TpnLcZR2HiyBtIHD4euyQ+RqR5uIENluEKbcPGC4f2/KSeAf0LrwwzvQh3azLQA8u R2P3oVigWe87FbAO+SB2naiKXgQoK0LtdWj4psYmRfwTuolD2RSC9GPa8Zwh9rHM2R x1epizf+99LuUWCqKuwSZ/FGhfH0KTHpwch/xy5c=
Date: Mon, 11 May 2020 12:48:08 -0700
From: Eric Kinnear <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3589/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clarify text around preferred address (#3589)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eb9abf8559d8_1b763fadcb2cd964419222"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 May 2020 19:48:25 -0000

@erickinnear commented on this pull request.

> @@ -2277,11 +2278,21 @@ linked by any other entity.
 At any time, endpoints MAY change the Destination Connection ID they send to a
 value that has not been used on another path.
-An endpoint MUST use a new connection ID if it initiates connection migration as
-described in {{initiating-migration}} or probes a new network path as described
-in {{probing}}.  An endpoint MUST use a new connection ID in response to a
-change in the address of a peer if the packet with the new peer address uses an
-active connection ID that has not been previously used by the peer.
+An endpoint MUST NOT reuse a connection ID when sending from more than one local
+address, for example when initiating connection migration as described in
+{{initiating-migration}} or when probing a new network path as described in
+Similarly, an endpoint MUST NOT reuse a connection ID when sending to more than
+one destination address.  However, if an endpoint receives packets from a new
+source address with the same destination connection ID, it MAY continue to use
+the current connection ID with the new address.

I like the framing of the last sentence you have there, although it's interesting to think through the question about if we really need an exception here. 

In theory, the problem with changing for this is that a NAT rebinding can cause us to "burn" a CID, making it so that instead of having 2 linked CIDs, we now have 3 linked CIDs. As long as we retire the old one (which is already in the text) once we change to the new one, we should be able to keep a steady supply of those around, although it would mean that someone in the middle of the network could fiddle with things to keep us generating and exchanging more and more CIDs. 

So, the idea is that if someone on the network changes without your knowledge, we've already linked those two 5-tuples by the fact that you've got the same CID in one direction, there's no harm in continuing to keep using that CID in the other direction. 

It does seem better to keep doing that, rather than opening ourselves up to letting someone on the network arbitrarily churn through CIDs.

This would mean the text becomes much like what you have in the TODO above, essentially we're saying that the _sender_ of the packet MUST follow these restrictions, but if you see that your peer did not, then \<the text you have above\>.

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