Re: Packet number spaces in multipath (was Re: What to do about multipath in QUIC)

[Kazuho Oku <[e-mail]>]

2020年12月7日(月) 8:24 Martin Thomson <[e-mail]>:

> As this wasn't mentioned in the discussion:
>
> On Wed, Nov 25, 2020, at 14:34, Jana Iyengar wrote:
> > First though, a point on terminology: the receiver maintains a separate
> > "ReceivedPackets" for each CID, probably for each CID sequence number
> > (CSN). Let's please not call this a SACK Dashboard, to avoid confusion.
> >
> > On the question of sending more than 2^32 packets, I think that
> > resetting the packet number (PN) is ok on new CIDs.
>
> A design like this would require changes to the way that keys are
> generated.  Unfortunately, I think that this also increases the cost of key
> generation a little for reasons specific to the internal workings of the
> key derivation function.
>
>
I think Jana is discussing a different problem. Let me go through.

For multipath, I think that it is a good idea to have packet number spaces
for each path.

Then, the question is if we want to use different encryption keys for each
path, or if we want to use the same keys. As AEAD prevents nonce reuse, the
sensible option here is to use the 32-bit unused space of 96-bit nonce to
contain the identifier of the path (note: RFC 5116 recommends AEAD should
support nonce of at least 96 bits). Therefore, we do not need to restrict
the number of packets being sent on one path to 2^32 or whatever.

However, there is a separate issue. That is that the packet format of QUIC
v1 does not allow an endpoint to start from a CID that is greater than 2^31.

Therefore, if an endpoint intends to use a new path ID (which is being the
CID sequence number), but wants to continue using packet number space of a
different CID, then it needs to ensure that the next packet number to be
used is below 2^31.

IIUC this is the problem that Jana is referring to, and arguing that it is
okay because an endpoint can always reset the packet number to zero on a
new path.

-- 
Kazuho Oku