Subject: Avoidng gaps in packet numbs at connection migration

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 16 Nov 2017 09:00:54 +0100

Initial packet randomisation is being proposed removed in
https://github.com/quicwg/base-drafts/issues/850

Connection migration still randomises at gap length as per transport
section 7.7.1.1.

This made me consider: how about resetting the packet number when the
connection ID changes? Or alternatively avoiding the gap and encrypting or
encoding packet numbers based on connection ID such that all packet numbers
increment by one after decoding.

Randomizing gaps would reveal that a migration took place on short lived
connection if #850 is in effect which might or might be considered a
privacy issue. Large gaps during migration also eats into the 2^64 packet
space.

The following considers a packet number reset (not claiming this is
preferably to encoding packet numbers).

By resetting the packet number and ensuring all packet numbers increment by
one, it becomes practically impossible to exhaust the packet number space,
thus removing the need for tearing down a connection, except if running out
of stream ID’s.

The internal packet number would then be larger than 64 bit, adding 2^64 on
each migration.

RTT measurements etc. would also trivially be able to avoid comparing
timestamps across different connections.

A major downside to this is that working with more than 64 bit packet
numbers is a real pain. One workaround for this is to require connection
migration after at most, say 2^48 packets and allow the high bits to roll
over if there are many migrations. To prevent the off chance of an old
packet getting through with the wrong packet number, AEAD could take the
connection ID into account thus rejecting old packets.

Due to the above downside of having a larger internal packet number space,
or the complexity of working around this, I tend to prefer encoding packet
numbers if feasible.

Kind Regards,
Mikkel Fahnøe Jørgensen