Date: Wed, 23 Aug 2017 03:54:21 +0000 (UTC)
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab4ce5083b5b5146cdfad9929398f980f075dcfe3b92cf0000000115b4be6d92a169ce0f074cba@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/746/review/57967334@github.com>
In-Reply-To: <quicwg/base-drafts/pull/746@github.com>
References: <quicwg/base-drafts/pull/746@github.com>
Subject: Re: [quicwg/base-drafts] Avoid attack on address validation during
 connection migration (#746)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_599cfc6d679c4_46d63fe4d1b51c38606e4";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/50KY61c6KE1RzeFSXkgfX6hEK7Q>

----==_mimepart_599cfc6d679c4_46d63fe4d1b51c38606e4
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

huitema commented on this pull request.

I think we are still missing something. We need to somehow tie the packets to the new path, in a cryptographic way. One potential solution is to use a new connection ID for the new path. That way, third parties cannot forward a PING or PONG meant for one path to the other path. But this needs work. And yes, it is very close to multipath.

> @@ -1453,6 +1453,10 @@ return.  A PING frame containing 12 randomly generated {{?RFC4086}} octets is
 sufficient to ensure that it is easier to receive the packet than it is to guess
 the value correctly.
 
+Note:
+
+: Retransmissions of the PING frame MUST also use the same remote address.
+
 If validation of the new remote address fails, after allowing enough time for

Really? That seems to contradict what you are saying later.

> +received, but it could also mean ceasing retransmissions of the PING frame.  An
+endpoint that doesn't retransmit a PING frame might receive a PONG frame, which
+it MUST ignore.
+
+
+## Spurious Connection Migrations
+
+A connection migration could be triggered by an attacker that is able to capture
+and forward a packet such that it arrives before the legitimate copy of that
+packet.  Such a packet will appear to be a legitimate connection migration and
+the legitimate copy will be dropped as a duplicate.
+
+After a spurious migration, validation of the source address will fail because
+the entity at the source address does not have the necessary cryptographic keys
+to read or respond to the PING frame that is sent to it, even if it wanted to.
+Such a spurious connection migration could result in the connection being

The text is correct, except if the man on the side manages to play "man in the middle". It knows that the first packet to the new address will be a PING. It could forward it to the old address, capture the next packet from that old address, and forward it again to the target. Bingo, the PONG succeeds.

-- 
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/746#pullrequestreview-57967334
----==_mimepart_599cfc6d679c4_46d63fe4d1b51c38606e4
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><b>@huitema</b> commented on this pull request.</p>

<p>I think we are still missing something. We need to somehow tie the packets to the new path, in a cryptographic way. One potential solution is to use a new connection ID for the new path. That way, third parties cannot forward a PING or PONG meant for one path to the other path. But this needs work. And yes, it is very close to multipath.</p><hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/746#discussion_r134651605">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt; @@ -1453,6 +1453,10 @@ return.  A PING frame containing 12 randomly generated {{?RFC4086}} octets is
 sufficient to ensure that it is easier to receive the packet than it is to guess
 the value correctly.
 
+Note:
+
+: Retransmissions of the PING frame MUST also use the same remote address.
+
 If validation of the new remote address fails, after allowing enough time for
</pre>
<p>Really? That seems to contradict what you are saying later.</p>

<hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/746#discussion_r134651864">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt; +received, but it could also mean ceasing retransmissions of the PING frame.  An
+endpoint that doesn&#39;t retransmit a PING frame might receive a PONG frame, which
+it MUST ignore.
+
+
+## Spurious Connection Migrations
+
+A connection migration could be triggered by an attacker that is able to capture
+and forward a packet such that it arrives before the legitimate copy of that
+packet.  Such a packet will appear to be a legitimate connection migration and
+the legitimate copy will be dropped as a duplicate.
+
+After a spurious migration, validation of the source address will fail because
+the entity at the source address does not have the necessary cryptographic keys
+to read or respond to the PING frame that is sent to it, even if it wanted to.
+Such a spurious connection migration could result in the connection being
</pre>
<p>The text is correct, except if the man on the side manages to play "man in the middle". It knows that the first packet to the new address will be a PING. It could forward it to the old address, capture the next packet from that old address, and forward it again to the target. Bingo, the PONG succeeds.</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/746#pullrequestreview-57967334">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AWbkq66LncTaOMI1SBQBvWIkVdGYwjwmks5sa6JtgaJpZM4O_Y89">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AWbkqz7Q8okiCvY9csRKfHKJSX5ovJylks5sa6JtgaJpZM4O_Y89.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/quicwg/base-drafts/pull/746#pullrequestreview-57967334"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<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://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@huitema commented on #746"}],"action":{"name":"View Pull Request","url":"https://github.com/quicwg/base-drafts/pull/746#pullrequestreview-57967334"}}}</script>
----==_mimepart_599cfc6d679c4_46d63fe4d1b51c38606e4--