Subject: [quicwg/base-drafts] Migration before handshake completed is very messy (#2309)

From: Christian Huitema <[email-masked]>
Date: Sun, 06 Jan 2019 20:54:24 -0800

In migration interop tests, the Picoquic client was starting to simulate NAT rebinding just after obtaining the 1-RTT read and write key. That turns out to be very messy, because at that point there is no proof that the server has received the client finished message, let alone acknowledged it. As far as tests are concerned, there is an easy fix: only start the migration tests after the client has received from the server an ACK of one of its 1-RTT packet. That's the moment when the client knows for sure that the handshake is successful.

The migration before handshake complete is messy because the client will try to re-transmit handshake messages that have not been acknowledged, and has some kind of dilemma. Should these re-transmissions aims at the original DCID used during the handshake, or at one of the new CID selected during the migration? What if the continuity of the new path has not been yet verified? What if the continuity test was lost?

Do we have an actual need to support migration before the handshake is fully completed? In practice, the handshake packets create a NAT mapping, and it is rather unlikely that this mapping will just disappear before the few RTT required to complete the handshake. In fact, it is possible, maybe likely, that packets received from an alternative address during the handshake comes from attackers, not from the actual client.

I think the implementations would be simpler and more robust if the spec stated that clients should not initiate "voluntary" migration before the handshake is fully complete. This means 1-RTT ACK received, or ACK of last handshake packet from the client, whichever comes first. Similarly, servers should not try to migrate connections before receiving at least one 1-RTT packet from the client through the same addresses and ports as the Initial messages.

-- 
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/issues/2309

---

From: Marten Seemann <[email-masked]>
Date: Sun, 06 Jan 2019 21:02:27 -0800

Since we decided to use timers to drop drop Handshake keys, a peer can never be sure when the other side actually finished the handshake, unless it proactively sends 1-RTT packets. This leads to problems in the case where you just pre-connect a QUIC connection, but neither peer has any data to send.

-- 
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/issues/2309#issuecomment-451822693

---

From: Christian Huitema <[email-masked]>
Date: Sun, 06 Jan 2019 21:24:48 -0800

In theory the key event is "server receives the client Finished message", which the server sees directly, and the client notices when the Finished message is acknowledged. So there is always that, even if the connection is idle. Plus, migration supports requires sending NEW CONNECTION ID frames to the peer, which I suppose do count as "proactively sent 1-RTT packets".

-- 
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/issues/2309#issuecomment-451825419

---

From: erickinnear <[email-masked]>
Date: Sun, 06 Jan 2019 21:28:39 -0800

I think stating that endpoints should not initiate migration before the handshake is fully complete would make a lot of sense. 

In addition to reducing the potential for added complexity around those interactions and the handshake, it seems like the need for migration at that point in the timeline can mostly be satisfied by a new connection on an alternate path.

If we don't have a lot of activity happening yet on the connection (although interesting thought about the NEW_CONNECTION_ID frames), it seems like you don't really lose a whole lot by opening a new connection instead of migrating a pre-connected connection that hasn't otherwise been used.
That makes me less concerned about when the threshold should be.

-- 
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/issues/2309#issuecomment-451825917

---

From: Marten Seemann <[email-masked]>
Date: Sun, 06 Jan 2019 21:40:17 -0800

> In theory the key event is "server receives the client Finished message", which the server sees directly, and the client notices when the Finished message is acknowledged.

The ACK for that could be lost. The client will then start the handshake timer and keep retransmitting the Finished, until it receives an ACK (assuming that the server keeps the keys around for long enough, which it currently doesn't, see #2267).

-- 
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/issues/2309#issuecomment-451827436

---

From: Christian Huitema <[email-masked]>
Date: Sun, 06 Jan 2019 23:09:32 -0800

I get the issue in #2267. But regardless, there is an issue with engaging in migration when the handshake is not complete...

-- 
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/issues/2309#issuecomment-451841423

---

From: ianswett <[email-masked]>
Date: Mon, 07 Jan 2019 06:46:04 -0800

I thought we decided that we shouldn't support migration before completing the handshake.  It's probably not written down, so we should state that explicitly.  The value is tiny and the complexity is substantial.

-- 
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/issues/2309#issuecomment-451957662

---

From: David Schinazi <[email-masked]>
Date: Mon, 07 Jan 2019 11:51:57 -0800

Isn't this already made explicit in Section 9 `Connection Migration`?

> 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.

-- 
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/issues/2309#issuecomment-452059909

---

From: Christian Huitema <[email-masked]>
Date: Mon, 07 Jan 2019 12:06:01 -0800

@DavidSchinazi I think there are two separate issues:

1) There is some fuzziness about what "handshake is finished" actually means. The messiness that we observed in the tests was due to repeating the CFIN handshake packet while engaged in migration. Thinks get much better if the client waits until CFIN is acknowledged.

2) The problem is with server response to NAT Rebinding. Even if the client does not initiate migration, a NAT could decide to change its translation. My take is that both sides should ignore such NAT rebinding before the handshake is finished. That is, have exactly one address pair for the connection and stick to it until handshake done, don't even think of changing midway.

The justification for (2) is that changing addresses mid-handshake in response to NAT rebinding opens an interesting attack surface, with man-on-the-side sending copies of good packets with spoofed IP addresses. Given that actual rebinding just after a mapping is created is pretty rare, chances are that most "rebinding during handshake" will be of the "man on the side" variety. It is more robust to just ignore them.

-- 
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/issues/2309#issuecomment-452064161

---

From: ianswett <[email-masked]>
Date: Mon, 07 Jan 2019 12:09:22 -0800

Thanks @DavidSchinazi for finding the text.  Ah, the CFIN, the gift that keeps on giving.

I agree with @huitema on 2. We previously discussed whether changing the 5-tuple during the handshake was allowed, and decided it opened up a huge number of attacks we weren't sure we could fix, so we should require it be fixed until handshake completion.

-- 
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/issues/2309#issuecomment-452065144

---

From: David Schinazi <[email-masked]>
Date: Mon, 07 Jan 2019 12:30:18 -0800

I agree with @huitema, we could add text to that section to clarify what handshake finished means and what servers should do if they detect a NAT rebinding during the handshake.

-- 
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/issues/2309#issuecomment-452071221

---

From: MikkelFJ <[email-masked]>
Date: Mon, 07 Jan 2019 12:50:04 -0800

There is also the client cert auth post handshake thing (which I don't understand, but I would assume it also depends on a clear definition of when the handshake is complete.

-- 
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/issues/2309#issuecomment-452076995

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 15:41:50 -0800

Based on there being existing text, I think that we'll just use this for clarifying where the boundary is.  PRs sought.

-- 
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/issues/2309#issuecomment-452122275

---

From: Christian Huitema <[email-masked]>
Date: Sat, 26 Jan 2019 19:26:28 -0800

Started Pr #2370 

-- 
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/issues/2309#issuecomment-457885844

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jan 2019 02:25:39 +0000 (UTC)

Tokyo conclusion: the answer to #2267 will provide a basis for defining the transition point.  @huitema has a PR and can update that when we have an answer there.

-- 
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/issues/2309#issuecomment-459190390