Migration before handshake completed is very messy

[huitema]

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.

[marten-seemann]

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.

[huitema]

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

[erickinnear]

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.

[marten-seemann]

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

[huitema]

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

[ianswett]

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.

[DavidSchinazi]

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.

[huitema]

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

[ianswett]

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.

[DavidSchinazi]

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.

[mikkelfj]

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.

[martinthomson]

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

[huitema]

Started Pr #2370

[martinthomson]

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.

[huitema]

Updated the text to reference the output of PR #2673 as agreed during the London interim.

[martinthomson]

@mnot, @larseggert, this one looks good to go.

[larseggert]

Quick question: We're forbidding active migration during the handshake here, but what about a passive NAT rebinding that may happen? We obviously can't forbid that, so we must either handle it or have the connection die quickly?

[martinthomson]

That's an issue, but a different one.

[huitema]

What @martinthomson said. I would personally treat NAT rebinding during handshake as an error, on the assumption that it will be extremely rare and is caused by a broken NAT.

We generally assume that NAT keep a UDP mapping active for at least 30 seconds -- the BEHAVE recommendation was 2 minutes. Having a mapping change in fewer than 2 RTT means the NAT is broken.

[ianswett]

Closing the connection introduces yet another way an attacker can interrupt the handshake. It may be the preferable option, but it's worth noting.

[huitema]

@ianswett You don't have to close the connection to protect against NAT rebinding. Ignoring packets from the wrong addresses during the handshake is simpler and more robust. The picoquic implementation does something like that: accept the content of the handshake packet (not initial) if it decrypts correctly, ignore any address change until the handshake is confirmed.

[ianswett]

Good point, that SGTM.

[huitema]

Waiting on PR #2370 to close this issue.