Re: [quicwg/base-drafts] Stronger migration handshake (#2370)

MikkelFJ <notifications@github.com> Sun, 27 January 2019 06:22 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 BC9701294FA for <quic-issues@ietfa.amsl.com>; Sat, 26 Jan 2019 22:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.552
X-Spam-Level:
X-Spam-Status: No, score=-12.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 qgGMxkzBH-IC for <quic-issues@ietfa.amsl.com>; Sat, 26 Jan 2019 22:22:37 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497E91288BD for <quic-issues@ietf.org>; Sat, 26 Jan 2019 22:22:37 -0800 (PST)
Date: Sat, 26 Jan 2019 22:22:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1548570156; bh=Y2wBclC5g/4SjFCYSk5JliLQB9ulqXyMiS/YSLNoVH0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dxImcnxmzv0YTG3x9eVnjFGxj9iyiB/8peD+hFm8UwyITbi8xBPuBMjsMKZaxKNsF dWue1x/ltUqYkuTcLAJUoXQh8worY2QXNDDYPdcCbTvHmUziB4gfNoF72KePzQ9VMG ZWyT/Yz7YwqSfQPxihY00+2xBqX79gBTz+/qqgQE=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab9e7de6dcea99200df197c5ca7e0b5e8e0c14ef0a92cf000000011865102c92a169ce180d1061@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2370/review/196813615@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2370@github.com>
References: <quicwg/base-drafts/pull/2370@github.com>
Subject: Re: [quicwg/base-drafts] Stronger migration handshake (#2370)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c4d4e2c62bd3_7c563f9161cd45c480859"; 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/gIUCqHbX2UoT6EGVhiMTYgnzRxo>
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: Sun, 27 Jan 2019 06:22:39 -0000

mikkelfj commented on this pull request.



> @@ -1847,6 +1847,11 @@ endpoint migrates to a new address.
 An endpoint MUST NOT initiate connection migration before the handshake is
 finished and the endpoint has 1-RTT keys.  The design of QUIC relies on
 endpoints retaining a stable address for the duration of the handshake.
+Clients MUST NOT initiate connection migration before they are
+certain that their peer also considers the handshake finished. This
+means that in addition to waiting for availability of 1-RTT keys,
+clients MUST wait acknowledgement by the server of one of their
+1-RTT messages before initiating connection migration.
 
 An endpoint also MUST NOT initiate connection migration if the peer sent the
 `disable_migration` transport parameter during the handshake.  An endpoint which

Not in this PR, but why do we use both client, server, peer, and endpoint, when migration can only happen from the client in V1 (or did I miss something?)

-- 
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/2370#pullrequestreview-196813615