Re: [quicwg/base-drafts] Better describe the use of Preferred Address (#3354)

Martin Thomson <notifications@github.com> Mon, 20 January 2020 08:34 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 99484120074 for <quic-issues@ietfa.amsl.com>; Mon, 20 Jan 2020 00:34:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZzPgpql3JR1 for <quic-issues@ietfa.amsl.com>; Mon, 20 Jan 2020 00:34:37 -0800 (PST)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D13120041 for <quic-issues@ietf.org>; Mon, 20 Jan 2020 00:34:37 -0800 (PST)
Date: Mon, 20 Jan 2020 00:34:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579509276; bh=udslWa7QcmBH6B7hUo+luIzPmGLkamITbv4eXfqPcyw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=aiKkjkosIfO+ditIGXzUNxHJRhuU2nZI4FwD8KQSmcfVDsFQ/JEfaW1BrHzwnXldQ e37X9fF6EOVytKYoOYl+IQjC1qKUIM+nyHYX2zI7ruKJdOZQAhSC+Ls54KuZK6KFXd ao0i137QEwCmKtK3TLcxFg1HNwe1zyIVsr/SgUSE=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZAYFGO3EZVKFKNYVN4GKMJZEVBNHHCBWRIJQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3354/review/345140615@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3354@github.com>
References: <quicwg/base-drafts/pull/3354@github.com>
Subject: Re: [quicwg/base-drafts] Better describe the use of Preferred Address (#3354)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e25661c7db6b_744f3ffa820cd96c4029cc"; 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/UBb93n4wrXwUqlINiJq1T1v_Cqg>
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, 20 Jan 2020 08:34:40 -0000

martinthomson commented on this pull request.



> @@ -2194,11 +2194,13 @@ 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 use a new connection ID when it initiates connection migration
+as described in {{initiating-migration}} or {{preferred-address}}, or when it
+probes a new network path as described in {{probing}}, and MUST NOT reuse

The "MUST NOT" stands on its own in that case:

> An endpoint MUST NOT use a connection ID on a given network path if it has used the same connection ID to send packets on another network path.

The intended meaning of "new" in this text is to imply "previously unused", which might be more clearly stated as:

> An endpoint MUST use a connection ID that it has not previously used when it initiates connection migration ({{initiating-migration}}), including using a preferred address ({{preferred-address}}).  Similarly, an endpoint MUST use an unused connection when probing a new network path ({{probing}}).   An endpoint MUST use a previously-unused 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 [...as above].

This covers all the existing reasons to use a previously unused connection ID.  You could restate as a list instead, I guess:

> An endpoint MUST use a new connection ID when it:
> * migrates to a new network path ({{initiating-migration}}), including migrating to a server's preferred address ({{preferred-address}});
> * probes a new network ({{probing}}); or,
> * sends a packet on a new network path as a result of responding to the migration of a peer, where the peer uses a connection ID that has not been used on another path.
>In all cases, an endpoint MUST NOT use a connection ID on a given network path if it has used the same connection ID to send packets on another network path.


>  
 If path validation succeeds, the client SHOULD immediately begin sending all
-future packets to the new server address using the new connection ID and
-discontinue use of the old server address.  If path validation fails, the client
-MUST continue sending all future packets to the server's original IP address.
-
+future packets to the new server and discontinue use of the old server address,
+and retire the connection ID that was used for the original path
+({{retiring-cids}}).  If path validation fails, or if the client decides not to
+migrate to the preferred address, it MUST continue sending all future packets to
+the server's original IP address, and retire the connection ID provided by the
+preferred_address transport parameter.  Retirement of either of these connection
+IDs notifies the server of the address the client has chosen.

Let me try to be clearer about my objection to this last sentence.

This implies a semantic to the retirement of connection IDs that is not already defined.  It says that in addition to releasing the resource, the server can say definitively that those other network paths won't be used.  But this is misleading because retiring CID 1 does not prevent CID 4 from being used on that path.  Nothing says that the connection IDs sent in NEW_CONNECTION_ID have to be used on one or other path.  Better to keep the requirement where it is: don't migrate back if you use a preferred address.  

Yes, that means that servers can't be sure of behaviour of clients here, but they can use the destination address to confirm acceptance of the preferred address or not.  That should suffice.

> @@ -4635,8 +4640,13 @@ preferred_address (0x000d):
   transport parameter is only sent by a server. Servers MAY choose to only send
   a preferred address of one address family by sending an all-zero address and
   port (0.0.0.0:0 or ::.0) for the other family. IP addresses are encoded in
-  network byte order. The CID Length field contains the length of the
-  Connection ID field.
+  network byte order.
+
+  The Connection ID field and the Stateless Reset Token field contain an

This might fix the formatting issue.

```suggestion
: The Connection ID field and the Stateless Reset Token field contain an
```

-- 
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/3354#pullrequestreview-345140615