Re: What to do about multipath in QUIC

[Kazuho Oku <[e-mail]>]

2020年11月16日(月) 16:32 Yunfei Ma <[e-mail]>:

> Dear Kazuho,
>
> Thanks for providing this alternative solution. I think it's great, but
> please correct me if I am wrong. In the quic-tls-32 section 5.3., it reads:
>
> *"The exclusive OR of the padded packet number and the IV forms the AEAD nonce."*
>
>
> So my question is: if we want to embed the sequence number of the connection ID into the AEAD nonce, don't we need to incorporate this method into section 5.3.?
>
>
That's true. AEAD takes three inputs: secret, IV,  nonce.

In order to avoid reuse, we need to make either of the three a per-path
variable. My point is that changing the definition of nonce is the easiest,
because it is a value that is calculated for each encrypt / decrypt
operation, and because we have space to incorporate the path identifier
(being the sequence number included in the NEW_CONNECTION_ID frame).

That's going to be a small enough change that can be made in the multipath
extension.


> Thanks,
>
> Yunfei
>
>
> On Sun, Nov 15, 2020 at 9:19 PM Kazuho Oku <[e-mail]> wrote:
>
>>
>>
>> 2020年11月16日(月) 8:25 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.
>>>
>>
>> Or as an alternative, we can encode the sequence number of the connection
>> ID directly in the unused part of AEAD nonce (size of nonce is 96 bits in
>> AES-GCM, 128 bits in chacha20-poly1305, but we only use 62 bits). The
>> benefit of such an approach is that endpoints would not be required to have
>> additional state related to AEAD. Endpoints already have the mapping
>> between connection IDs and their sequence numbers, all they need to do is
>> pass that sequence number as part of the AEAD nonce.
>>
>> But since QUIC-TLS has been in the last-call period, would it be able to
>>> add this modification into QUIC-TLS?
>>>
>>
>> I do not think we have to, especially if we embed the sequence number of
>> the connection ID into the AEAD nonce.
>>
>>
>>>
>>>
>>> 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
>>>>
>>>>
>>
>> --
>> Kazuho Oku
>>
>

-- 
Kazuho Oku