On 11/16/2020 3:33 PM, Kazuho Oku wrote: > > > 2020年11月17日(火) 8:12 Christian Huitema <[email protected] > <mailto:[email protected]>>: > > > 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. > > 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.
But then we are back to square one. In order to decrypt the packet, you need to know the number-space identifier. That means first identifying the incoming path-ID based on four-tuple and CID, and then finding whether the number space associated with the path. That leaves the issue of the initial packets for a path, e.g., the first challenge packets. For those, the path-id may not yet be established, and the path-specific number space not yet initialized. Maybe what we need is just one bit in the header to distinguish between "this packet uses the default number space" and "this packet uses the path specific number space". That, or trial decryption. > 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]. That's incorrect. If the server supports non-zero CID, then the client can do intentional migration, even if the client itself uses zero-length CID. I have tested that behavior for Picoquic, and I believe it is also used in Quic-Go. > 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. > > [1] > https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-5.1.1-8 -- Christian huitema
