Date: Sun, 27 Jan 2019 12:17:34 -0800
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab097c58484d398990d9111559129398112ec157c792cf000000011865d3de92a169ce180d1061@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/196843626@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_5c4e11de1889b_58973fecca2d45b4872e5";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/7FoEwQ_YATs8JDle3Bc8CwjX03Q>


----==_mimepart_5c4e11de1889b_58973fecca2d45b4872e5
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

huitema 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

I rewrote this to be generally neutral, while leaving the specific requirements for server and client. Where did we specify that only the client initiates migrations in V1? I know of at least one implementation (not mine) that migrates the connection to a new CID as soon as the handshake is done and it has received "NEW CID" frames from the client.

-- 
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#discussion_r251253257
----==_mimepart_5c4e11de1889b_58973fecca2d45b4872e5
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><b>@huitema</b> commented on this pull request.</p>

<hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/2370#discussion_r251253257">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt; @@ -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
</pre>
<p>I rewrote this to be generally neutral, while leaving the specific requirements for server and client. Where did we specify that only the client initiates migrations in V1? I know of at least one implementation (not mine) that migrates the connection to a new CID as soon as the handshake is done and it has received "NEW CID" frames from the client.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/pull/2370#discussion_r251253257">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AWbkq7n2gtz7tGBktrLbQfsLnOWyhmz0ks5vHglegaJpZM4aUhBL">mute the thread</a>.<img src="https://github.com/notifications/beacon/AWbkqydv1BxU61JmUZYSjuxeIX2j93JSks5vHglegaJpZM4aUhBL.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@huitema commented on #2370"}],"action":{"name":"View Pull Request","url":"https://github.com/quicwg/base-drafts/pull/2370#discussion_r251253257"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2370#discussion_r251253257",
"url": "https://github.com/quicwg/base-drafts/pull/2370#discussion_r251253257",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5c4e11de1889b_58973fecca2d45b4872e5--