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

ekr <> Mon, 11 May 2020 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AA913A0921 for <>; Mon, 11 May 2020 04:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Status: No, score=-3.1 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_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 Z3KJ5qkesQ5v for <>; Mon, 11 May 2020 04:59:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA2E83A08E9 for <>; Mon, 11 May 2020 04:59:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 297F126156E for <>; Mon, 11 May 2020 04:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1589198349; bh=oDiDda2OXHV/3vYT4GY0S8XS7una4RKkvhJiSlTbKWs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=F8sMozGXNJgURW1ndBG/sAAE15kSJ3d792WZc9uuJ+XyRSWuENWA61uvkioLn/wuh L2zMZJYotgRnzzGwSEmxJDNr9e12wovLT0WEOFaJmLrHuCb8RyDfMiryaNshqngEU3 aMGFEGDjxh2yEvxpkFfYrY6TI4GRpCrbqmaw4XgM=
Date: Mon, 11 May 2020 04:59:08 -0700
From: ekr <>
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_5eb93e0cb83dc_2ead3fd3cf2cd96c1253d5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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 11:59:18 -0000

@ekr commented on this pull request.

> @@ -1084,10 +1084,10 @@ Sending a RETIRE_CONNECTION_ID frame indicates that the connection ID will not
 be used again and requests that the peer replace it with a new connection ID
 using a NEW_CONNECTION_ID frame.
-As discussed in {{migration-linkability}}, endpoints limit the use of a
-connection ID to a single network path where possible. Endpoints SHOULD retire
-connection IDs when no longer actively using the network path on which the
-connection ID was used.
+As discussed in {{migration-linkability}}, endpoints MUST limit the use of a
+connection ID to packets sent from a single local address.  Endpoints SHOULD
+retire connection IDs when they are no longer actively using the network path on
+which the connection ID was used.

Perhaps the problem is the use of "network path". As I understand it, the requirement here is that from your perspective the 5-tuple be the same, right? The issue is that with NAT your perspective and others may different. So  perhaps "MUST limit the use of a connection ID to a single pair of remote/local address"

> @@ -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.

Do we actually have to make this exception? I haven't been tracking all of the conversations, but why not just have endpoints use a new CID in this case.

In general an endpoint MUST limit the use of a connection ID to a single pair of remote and local addresses. This prevents linkage between network paths. However, if an endpoint may experiences unexpected NAT rebinding, that endpoint's peer may receive a packet from a new remote address but reusing an existing connection ID, thus apparently violating this rule linking those paths. [TODO: Something about how you have to accept this?]
As an exception to the rule above, if an endpoint sees a given connection ID reused from a new remote address, it MAY also reuse its corresponding connection ID when sending to that address, as long as it sends from the same local address.

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