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

From: Christian Huitema <[email-masked]>
Date: Sun, 04 Feb 2018 18:32:00 -0800

Who says that we have to send fake packets?

The plausible solution is to treat the connection migration as a special form of session resume. The resume ticket would need to encode that this really is a continuation of the existing QUIC session, but that seems reasonably OK to engineer. These would have to be passed to the client somehow, maybe as "MIGRATION RESUME TOKEN" frames, replacing the "NEW CONNECTION ID" mechanism. The connection setup would provide an implicit path validation, removing the need for the PATH CHALLENGE and RESPONSE frames. Not sure whether the result would be more or less complex than the present mechanism, probably similar in complexity.

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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 05 Feb 2018 08:13:40 +0000 (UTC)

For MPTCP, we *had to* make a new MPTCP subflow look like a new TCP connection, because otherwise middleboxes wouldn't pass it. My guess is that we should do this for QUIC too, so that middleboxes can stay as simple as possible, i.e., don't need to distinguish between the a first and additional subflows. (Because some will get that wrong -> ossification.)

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 05 Feb 2018 00:56:36 -0800

If ossification is the concern, I think we should eliminate the distinction between long and short packet headers.

There is no need for INITIAL and HANDSHAKE to have their packet type and version number sent in cleartext. The fields can be sent as part of the AEAD-encrypted payload. We can always use short header, and when seeing an unidentified CID, do a trial decryption to see if it is a pre-1-RTT packet that contains a type and version number.

If privacy is a concern, we need to generate and emit a new ECDH keyshare every time the connection migrates. I am not sure if we want to do that.

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 05 Feb 2018 09:06:38 +0000 (UTC)

I imagine CID can be used to reject or prioritise packets before full AEAD in some scenarios. For this to work, it is probably helpful to have visible headers. Scrambling could be done by extending packet number encryption to cover the entire header.

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 05 Feb 2018 04:59:23 -0800

@mikkelfj
> Scrambling could be done by extending packet number encryption to cover the entire header.

Yes. IMO that is also a good approach.

Anyways, I think that this might be a good opportunity to consider what properties we want to expose to on-path observers when starting to use a new path (i.e. 5 tuple).

With variants, packet number encryption and spin-bits, etc., it seems to me that we are starting to explicitly determine what should be observable, at the same time trying to scramble all other properties in order to avoid possible ossification. The same approach can be applied to how we use a path.

One option is to expose nothing. If that is the case, pre-1RTT and 1RTT packets should not be easily distinguishable. There could be various approaches in accomplishing that, as @mikkelfj and I have pointed out.

Another option is to have a signal that notifies the start of using a new path. In such case, we should expose 1 bit that can be used to distinguish start-of-use vs. in-use. I am not sure if we need (or want to) expose the internals of the handshake (i.e. INITIAL, HANDSHAKE, RETRY).

My tendency goes to exposing nothing. The primary reason is that switching to a new path can happen due to NAT rebinding. In such case, it is impossible for a client to mark the first packet that is sent using a new path differently from other packets.

Therefore, I believe that we should merge long packet header and short packet header so that pre-1RTT packets would not be easily distinguishable from 1-RTT packets, _if_ ossification is a concern.

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 05 Feb 2018 13:03:45 +0000 (UTC)

> Another option is to have a signal that notifies the start of using a new path. In such case, we should expose 1 bit that can be used to distinguish start-of-use vs. in-use. I am not sure if we nee…

This somewhat relates to the retry concern of asymmetric CID's
https://github.com/quicwg/base-drafts/issues/1089

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