On 11/16/2020 2:05 PM, Kazuho Oku wrote: > > > 2020年11月17日(火) 3:11 Christian Huitema <[email protected] > <mailto:[email protected]>>: > > 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? > > > The "nonce" of AEAD, which is used for encoding the "packet number" of > QUIC, has more space than 64 bits. I know that some of the TLS stacks > only expose an AEAD API that lets applications specify 64-bit packet > number, but they are (I am) just lazy. > > Quoting from RFC 5116, > > Each AEAD algorithm MUST accept any nonce with a length between > N_MIN and N_MAX octets, inclusive, where the values of N_MIN and N_MAX > are specific to that algorithm. The values of N_MAX and N_MIN MAY be > equal. Each algorithm SHOULD accept a nonce with a length of twelve > (12) octets. > > AES-GCM and chacha20-poly1305 have N_MIN and N_MAX of 12. > > Therefore, we have 34-bit space (12 * 8 - 62 = 34) to encode the path > identifier.
I suppose that 32 bits path-id would be enough, yes. > > > 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? > > > In QUIC, each CID has a sequence number, and the use of CIDs with a > non-zero sequence number happens after the handshake is confirmed, at > which point negotiation of the protocol features would have completed. > > Therefore, multipath-aware endpoints can determine the path identifier > (i.e. sequence number) from the CID it sends / receives, and encode > that as part of the nonce that they use to encrypt / decrypt packets. Are you going to conflate CID sequence number and PN Number Space identifier? That would have interesting effects on scenarios in which the CID changes for other reasons than creating a new path. There would also be an interesting relation between "retiring a CID" and "managing acknowledgements". It would also make the creation of new CID significantly more heavy weight than it is today -- the peer that creates a new CID would have to allocate a selective ACK dashboard for packets received through that CID. Then there is the issue of peers who want to use zero length CID. I suppose that if the peer has zero length CID, all packets sent to that peer will be in the same number space. That may well be just fine if that peer is not sending a lot of data, e.g., for clients that mostly send short requests and acks. Then there is the issue of key rotation. In this "path sequence" scheme, we have only one key, so I assume that it will rotate simultaneously for all CID. -- Christian Huitema
