2020年11月17日(火) 18:00 Christian Huitema <[email protected]>:
> > On 11/16/2020 5:41 PM, Kazuho Oku wrote: > > > > 2020年11月17日(火) 9:26 Christian Huitema <[email protected]>: > >> >> On 11/16/2020 3:33 PM, Kazuho Oku wrote: >> >> >> >> 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. >> >> 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. > I believe we require an endpoint to use an unused CID whenever it attempts to use a new path? > > >> 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. > I'm not sure if I agree. I tend to think that there would be a M:1 mapping between CIDs and paths. In most cases, M will be one, as the peers might stop issuing new CIDs at any moment. > > 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. > Yes, we need to change the ACK format to include the CID sequence number, because the receiver does not have the concept of paths. My point is that "path" can be an internal property of the sender, that maps M:1 to the CID, where M can be 1. > > 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 >> >> >> -- Christian Huitema > -- Kazuho Oku
