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

[Kazuho Oku <[e-mail]>]

@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