Subject: [quicwg/base-drafts] Connection migration should be indistinguishable from a new connection (#203)

From: Lucas Clemente <[email-masked]>
Date: Mon, 23 Jan 2017 00:58:37 -0800

One of the major features of QUIC over TCP is the option of seamless connection migration. One can conceive of a situation where a network middle-man (e.g. an ISP, firewall implementer, etc) might have an interest in blocking this feature, e.g. by detecting connection migrations to their network and dropping those packets. I propose that we think of a way to make a connection migration indistinguishable from a "normal" new connection.

One solution I can think of would be to have the client send a "fake" initial packet with 0-RTT encryption (which would then be discarded by the server as undecryptable). The first few packets sent on the new address would also need to have the version bit set – which the server would have to ignore.

This would also require initial packet number randomization (see #35).

Thanks for @lcolitti for pointing this issue out.

-- 
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/203

---

From: ianswett <[email-masked]>
Date: Mon, 23 Jan 2017 02:07:38 -0800

Agreed that it should look as much like a new connection as possible.

I've heard middleboxes had to add explicit support for MPTCP, so at the very least, we don't want to be in a situation where middleboxes need to change their behavior to accommodate QUIC connection migration or multipath.

The question becomes how much does it need to look like a new handshake?  ie: Is it sufficient to send a fake CHLO followed by forward secure data, or do we need to wait an RTT?  How realistic does the CHLO need to 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/203#issuecomment-274446488

---

From: mirjak <[email-masked]>
Date: Mon, 23 Jan 2017 12:21:52 -0800

I really don't support this solution because faking something to the network is unnecessary complex and therefore error prone (I think we can only do this wrong because it's fake) and probably also not really feasible given that the sender might not know that anything changed in the network. 

My solution would be the other way around: Don't make the handshake look special and try to make  all packets look the same for the network as much as possible. This goes back to the idea of "don't expose any data that you don't what the network to use because those will be ossified"and I think we should really follow this principle here as much as possible. (As a side note, this also means that there are cases where it is useful to expose information to the network and ossify this information and its representation such that it can be used for e.g.network diagnosability without changing all network devices for each version of quic.)

-- 
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/203#issuecomment-274605397

---

From: Marten Seemann <[email-masked]>
Date: Mon, 23 Jan 2017 15:35:27 -0800

I agree with @mirjak in principle, the best solution would be if a handshake is indistinguishable from a connection migration. However, when using TLS, the first packet of a handshake always contains unencrypted data, which is something trivial to detect for a middle-man.
Given this constraint, the solution @lucas-clemente proposed might unfortunately be the best we can do. 

-- 
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/203#issuecomment-274653016

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 24 Jan 2017 16:05:38 -0800

@marten-seemann But @mirjak makes a valid point. The sender may be unaware. It could be a case of a NAT rebinding (new outgoing UDP port) or you are on a WiFi spot provided by a cell-connected router that just migrated to a different operator.

Trying to confuse the network, you are confusing the server as well (unless your server is a single lonely box on a rack somewhere). CDNs are complex networks with multiple machines coordinating to present you with a nice "server" abstraction. If you are successful in confusing the network, you will confuse CDNs and as a result end users will get suboptimal performance and reliability for their connections.

-- 
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/203#issuecomment-274979665

---

From: Lucas Clemente <[email-masked]>
Date: Tue, 24 Jan 2017 16:29:17 -0800

You're right of course, the client may not know about a network change. 

Then I still think we should think more about making the first packet undistinguishable from the rest of the connection. Of course this will not strictly be possible (since you can always trial-decrypt it), but we can at least make it harder.

Maybe one possibility would be to randomly send public headers similar to the initial packet, e.g. set the version flag and include a greased version list every Nth packet or so.

-- 
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/203#issuecomment-274983700