On 11/16/2020 10:19 AM, Mikkel Fahnøe Jørgensen wrote: > Why not use the connection ID for encoding the PN? > > Mikkel
First, using the connection ID is a trade-off between ease of management and transmission overhead. Some major client implementations use zero-length CID precisely because of that. The combination of zero-length CID on the client and long CID on the server works well, allows for migration and NAT rebinding, and provides the lowest overhead when the bulk of the transmission is from server to client. Second, the life of the CID is not quite the same as the life of a path. CID are only associated to paths when packets are sent with that CID on that path. If we go for path specific packet numbers and encryption contexts, we may well have transitions between using a given CID with the default encryption context and allocating a specific encryption context to the path. And then, there is the issue of NAT rebinding. Suppose that the receiver identifies a path by its 4 tuple, which is the only option if the CID is zero length. In the case of NAT rebinding, the packets are suddenly arriving on a new path. What key do you use for that new path? I think the only safe way to do that is to carry a PN space identifier in the packet header. My initial feeling is that using a single key and a single PN avoids all that key-management complexity. Clearly that's a trade-off: senders must keep track of which PN was sent on what path, and the ACK frames may become longer due to out-of-order arrivals. I believe this is an OK tradeoff, because managing several number spaces and several encryption keys also adds its own complexity. I prefer the single PN space design because it puts all the complexity on the sender side -- a peer that can't be bothered will just accept packets coming from whatever path, and send on a single return path following pretty much the QUIC V1 logic. -- Christian Huitema > > On 16 November 2020 at 19.12.02, Christian Huitema > ([email protected] <mailto:[email protected]>) wrote: > >> Kazuho, >> >> You are proposing to use a transform, in which the AEAD "sequence" is >> the conjunction of a sequence number space identifier and the number >> within that space. I agree that doing that solves the uniqueness >> requirement, but I have two concerns. >> >> First, your original proposal allocates just 2 bits for the sequence >> number space identifier. You observe that the sequence number is encoded >> as a varint, which can only encode 62 bits of value, and thus we can >> reuse the two high order bits to encode a number space identifier. But >> what happens if the connection uses more than 4 number spaces? >> >> Second, we have a synchronization issue. At what point do nodes start >> using the "path-specific" number space? If we want to be robust, don't >> we need to encode a number space identifier in the packet header? >> >> -- Christian Huitema >> >>
