On 11/17/2020 2:29 AM, Kazuho Oku wrote: > > > 2020年11月17日(火) 18:00 Christian Huitema <[email protected] > <mailto:[email protected]>>: > > > 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. > > I believe we require an endpoint to use an unused CID whenever it > attempts to use a new path?
Yes, unless it uses zero-length CID. >> >> >> 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. Yes. That's the beauty of reusing as much as possible of the migration work. We already have the infrastructure in place to issue and retire CID, and to limit how many can be requested. > >>> 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. I have been thinking about variations of that. I think we are making progress here. If we follow your design, we get two constraints: 1) That the receive maintains an acknowledgement list based on the CID through which the packets are received. 2) That the senders guarantee that the same sequence number will not be used more than once with a specific CID. The main implementation cost is for receivers. They have to allocate and maintain a "SACK Dashboard" in the context of each CID that they issue. Senders have lots of control. For example, the "only once" condition is also met if a simple sender uses a single number space, as long as it does not send more than 2^32 packets. That makes the design reasonably easy to implement for constrained implementations. Zero length CID are still possible, but that means the receiver supports only one PN space per sender. Multipath is not impossible, but you end up managing a single RTT and a single recovery structure. Not very good, but similar to what happens if multipath is implemented at the IP level. There is still an issue for coordinating the take down of a path. Suppose that a client was using both Wi-Fi and LTE, and moves out of Wi-Fi range. The server will find out eventually that the packets sent to the Wi-Fi path are never acknowledged, but that may take some time. It would be better if the client could send a message saying something like "Abandon this path". That's not the same semantic as "retire this CID". We need a new frame for that. "Abandon this path" is an extreme case. There are half-way steps, like manage the relative priority of a path. > > >> >> 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
