Re: What to do about multipath in QUIC

[Kazuho Oku <[e-mail]>]

2020年11月17日(火) 8:12 Christian Huitema <[e-mail]>:

>
> On 11/16/2020 2:05 PM, Kazuho Oku wrote:
>
>
>
> 2020年11月17日(火) 3:11 Christian Huitema <[e-mail]>:
>
>> 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