2020年11月17日(火) 3:11 Christian Huitema <[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. > 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. > -- Christian Huitema > > > -- Kazuho Oku
