2020年11月17日(火) 8:12 Christian Huitema <[email protected]>: > > On 11/16/2020 2:05 PM, Kazuho Oku wrote: > > > > 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. > > 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. > That's a good point. I think there isn't a strong reason to tie CID sequence number to packet numbers, if we are going to have "path identifiers" as a separate concept. Anyways, that identifier can be embedded in the nonce.
> 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. > IIUC, endpoints using zero-length CID cannot issue new connection IDs, and therefore cannot sustain through intentional migration [1]. > 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. > Agreed. > -- Christian Huitema > [1] https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-5.1.1-8 -- Kazuho Oku
