[quicwg/base-drafts] Description of the use of Preferred Address is unclear (#3353)

Kazuho Oku <notifications@github.com> Thu, 16 January 2020 21:47 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 1AD6712004C for <quic-issues@ietfa.amsl.com>; Thu, 16 Jan 2020 13:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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, URIBL_BLOCKED=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eEhMnjkurQr0 for <quic-issues@ietfa.amsl.com>; Thu, 16 Jan 2020 13:47:00 -0800 (PST)
Received: from out-23.smtp.github.com (out-23.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D20012004A for <quic-issues@ietf.org>; Thu, 16 Jan 2020 13:47:00 -0800 (PST)
Date: Thu, 16 Jan 2020 13:46:59 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579211219; bh=H5YMUdpS+OMnf9UNKxQznC9WJzzIfJzylxv/PAo76GQ=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Iwj0nM/2dy951oPu8qcaf71nrkn9dQnJYLwt0ErfxVDEgkXnhm5qxAzilmRc+ef1+ RBMBBdn9uE9+yM4OfhZNRemj+j30EPZaTtgqxXf/HfzReVvuqic5Osz4ZKUiD/XA+k 4B57vBAUl0ZqYv1qZn4RBBQVR/3TX8vlEeYGGYgo=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4Y6UZL2IGG5Y66LZN4FYGFHEVBNHHCBWF2DE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3353@github.com>
Subject: [quicwg/base-drafts] Description of the use of Preferred Address is unclear (#3353)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e20d9d37714a_7823f7e382cd9681748db"; 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/3uWKsANWgyXSgf6nlYiBSO7HlVI>
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: Thu, 16 Jan 2020 21:47:02 -0000

At the moment, [section 9.6.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-communicating-a-preferred-a) states:
> Once the handshake is finished, the client SHOULD select one of the two server's preferred addresses and initiate path validation (see Section 8.2) of that address using the connection ID provided in the preferred_address transport parameter.
> 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.

I think these paragraphs have two issues:

* It begins with "once handshake is finished," but I am not sure if we define when a handshake finishes. I think we should change this to "once handshake is confirmed," as that is the point where we allow connection migration.
* It states that the connection ID to be used on the new path would be the one using TP.preferred_address. I think that is incorrect, as the server might have requested retirement of the CID provided by that transport parameter by the time the client initiates (or finishes) path validation. It should either be an address provided by that transport parameter, _or an unused CID provided by the server (i.e. through NCID frames)_. Note that this problem is orthogonal to #3348, because these actions in relation to preferred address happens at some point after the handshake is confirmed.

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