On 11/16/2020 5:41 PM, Kazuho Oku wrote: > > > 2020年11月17日(火) 9:26 Christian Huitema <[email protected] > <mailto:[email protected]>>: > > > 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. > > Then, I might go back to encoding the CID sequence number in the AEAD > nonce. > > A sender does not have to reset PN for each CID. It can retain its > internal N:1 mapping between CIDs and the paths. A receiver can decode > packets using the CID and PN, retain ACK queue for each active CID, > then send ACKs for each CID identified by the sequence number.
You could do that, but the sender has to guarantee that a given CID will always map to the same PN Space. Otherwise, duplication can happen. > > > 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. > I think that if we go for "CID Sequence in PN Space", we probably need this bit to distinguish between probe packets sent with a PN from the space number 0 (the default) and further packets sent on a PN Space negotiated per path. >> 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. > > Thank you for pointing that out. I think you are correct. > > I tend to think that the multipath extension can be simpler if we > avoid introducing the concept of "path identifiers," and instead use > CID sequence numbers for identifying the paths, as stated above. But > that does prohibit clients using zero-length CIDs. I am unconvinced. If we have different PN spaces, we need different ACK spaces, a new ACK format that somehow includes an ID of the PN space. Unless you have a struct 1-1 mapping between PN space and CID space, I think that you end up requiring a new identifier. > > Personally I am fine with eliminating this asymmetry in the > specification that allows only clients to use zero-length CIDs, but > maybe others have different opinions. > >> 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 >> >> <https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-5.1.1-8> > -- Christian Huitema
