2020年12月7日(月) 8:24 Martin Thomson <[email protected]>: > 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
