Re: What to do about multipath in QUIC

[Yanmei Liu <[e-mail]>]

Hi Christian and Lucas,

Thanks a lot for the advice :-)

> The use of AEAD is only safe if the same packet number is not reused
twice with the same key. If we use multiple packet number contexts, AEAD is
only safe if these contexts use different encryption keys. This requires
adding a key derivation procedure for the "sub connection", and also adding
ways to identify the relevant key in the incoming packets. This gets
complicated very quickly, especially if we want to keep the possibility of
using zero-length connection identifiers on the client side.
> I use a concept very similar to the sub-connection, but only as a way to
manipulate paths, so the client can instruct the server when paths ought to
be abandoned. Otherwise, I just keep track of which PN maps to which path.

We have tried to use the same packet number space in all the paths (or
sub-connections) before, and have found that it brought much complexity in
implementation for loss recovery.
In the meanwhile, the AEAD security problem mentioned above should be
solved. Another way to solve this problem is using different keys in
different paths, but it also brings much complexity in key derivation as
you have mentioned.

We have found a third solution in
https://tools.ietf.org/id/draft-huitema-quic-mpath-req-01.txt : create
nonces by mixing the IV with both the path specific connection ID and the
packet sequence number.
If we can mix Destination Connection ID in for each packet's AEAD nonce,
then it will be safe to use the same key in all the paths with different
packet number spaces.
But since QUIC-TLS has been in the last-call period, would it be able to
add this modification into QUIC-TLS?


Thanks,
Yanmei




On Fri, 13 Nov 2020 at 01:04, Christian Huitema <[e-mail]> wrote:

>
> On 11/12/2020 3:10 AM, Mikkel Fahnøe Jørgensen wrote:
>
>   1. We think QUICv1 has already laid down the foundation to build a general-purpose multi-path since migration can be viewed as a special type of multi-path. Therefore, we think one should reuse the design of migration in QUIC-v1 as much as possible, along with the features such as PATH_CHALLENGE/PATH_RESPONSE for path challenge and address validation, and NEW_CONNECTION_ID/RETIRE_CONNECTION_ID for CID renegotiation of new path(which is called Sub-connection in our draft). Reusing these features of QUIC-v1 with small extensions has enabled us to get general-purpose multi-path features with very little efforts in
> Alibaba’s XQUIC(an implementation of QUIC-v1).
>
> Yes. That's a major investment in QUIC V1, and we should keep it.
>
>   2. We find that the simplest way to add a second path is to use a sub-connection. The concept of sub-connection is directly inherited from connection in QUIC-transport, defined as the logic session of each physical path. Similar to a connection, each sub-connection has its own packet number space for the purpose of loss detection and recovery.
>
>
> I did not want to do that in my own draft for a couple of reasons. The
> main one is the interaction with encryption.
>
> The use of AEAD is only safe if the same packet number is not reused twice
> with the same key. If we use multiple packet number contexts, AEAD is only
> safe if these contexts use different encryption keys. This requires adding
> a key derivation procedure for the "sub connection", and also adding ways
> to identify the relevant key in the incoming packets. This gets complicated
> very quickly, especially if we want to keep the possibility of using
> zero-length connection identifiers on the client side.
>
> I use a concept very similar to the sub-connection, but only as a way to
> manipulate paths, so the client can instruct the server when paths ought to
> be abandoned. Otherwise, I just keep track of which PN maps to which path.
>
>
>   3. To merge the gap between migration and the general-purpose multi-path, several new features need to be supported:
>   - (1) how to manage the lifecycles of individual sub-connections.
>   - (2) how to distinguish packets coming from different sub-connections.
>   - (3) how to co-operate with a multi-path scheduler.
>
> We would appreciate hearing any thoughts, comments and suggestions.
>
>
> I think we need more work on the "multi-path scheduler". We have heard of
> three application scenarios: maintaining the lowest RTT when sending voice
> segments (Apple Siri), avoiding buffering delays when playing music (Apple
> Music), and using two available links with equal preference (Ali Baba "high
> speed train"). I wish that we could distillate that into a couple of simple
> concepts.
>
> -- Christian Huitema
>
>