Re: Re: What to do about multipath in QUIC
"Ma, Yunfei" <yunfei.ma@alibaba-inc.com> Mon, 16 November 2020 07:24 UTC
Return-Path: <yunfei.ma@alibaba-inc.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5918C3A14ED for <quic@ietfa.amsl.com>; Sun, 15 Nov 2020 23:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULUS0OBb8xQ4 for <quic@ietfa.amsl.com>; Sun, 15 Nov 2020 23:24:35 -0800 (PST)
Received: from out0-152.mail.aliyun.com (out0-152.mail.aliyun.com [140.205.0.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C35D3A14E7 for <quic@ietf.org>; Sun, 15 Nov 2020 23:24:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1605511471; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=qYVHfj6P+8/fl6iiA1D3mw+c1Gzifx/3q85ZUx/LU8U=; b=XMKQbxwEzvPUAKcKdbH3sYbSKntIbXMyVfcMHatoNZHG7cHU9fhctnr1LC2Azc6jr/9v6KIt/A00iswkyxn6QfxIVU+a2pBSV7LlNVTHNa/2BTjBUSbidPEqKjgt3R6tS8fytLWiyKSVhvR+5GPGx4b5zLNupciIQuSL8fg7Yf4=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R791e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047204; MF=yunfei.ma@alibaba-inc.com; NM=1; PH=DW; RN=8; SR=0; TI=alimail_yun_mac.COREAPI09a52967bd574a86bd73e7070cdfece6;
Received: from WS-web (yunfei.ma@alibaba-inc.com[alimail_yun_mac.COREAPI09a52967bd574a86bd73e7070cdfece6]) by ay29a011140100061.et135 at Mon, 16 Nov 2020 15:24:27 +0800
Date: Mon, 16 Nov 2020 15:24:27 +0800
From: "Ma, Yunfei" <yunfei.ma@alibaba-inc.com>
To: Kazuho Oku <kazuhooku@gmail.com>, Yanmei Liu <healing4d@gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, Hongqiang Liu <hongqiang.liu@alibaba-inc.com>, Yanmei Liu <miaoji.lym@alibaba-inc.com>, "Mikkel Fahnøe Jørgensen" <mikkelfj@gmail.com>, quic <quic@ietf.org>, Qing An <anqing.aq@alibaba-inc.com>
Message-ID: <7272a3ee-6765-45af-a0a0-b83d31788bcb.yunfei.ma@alibaba-inc.com>
Subject: Re: Re: What to do about multipath in QUIC
X-Priority: 3
X-Mailer: [Alimail-Mailagent]
MIME-Version: 1.0
In-Reply-To: <CANatvzyEfkRqgCArC8sXaS1-1DckxjspBLqLyLNdHx-RDKjT_Q@mail.gmail.com>
References: <538215d1-3b9e-4784-920d-03be4c3a503a.miaoji.lym@alibaba-inc.com> <CAN1APddB4JDo281L0USsU7FSiQxRNi-LaB8ZS0a9kLAgeNJwrw@mail.gmail.com> <54510017-fa91-555f-0219-0859d6686b74@huitema.net> <CAMDWRAaSeC9Yd1DqzM9o5_CS5Kct0aNS_LUzty5YPO_5fBf4qw@mail.gmail.com>, <CANatvzyEfkRqgCArC8sXaS1-1DckxjspBLqLyLNdHx-RDKjT_Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_93993_7f8d8678c700_5fb2292b_139bea8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/xmoq-zrFOG-LMc9CPsIMpDlpwto>
X-Mailman-Approved-At: Sun, 15 Nov 2020 23:25:49 -0800
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 07:24:37 -0000
Dear Kazuho, Thanks for providing this alternative solution. I think it is great, but please correct me if I am wrong. In the quic-tls-32 draft 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 as you pointed out, don't we need to incoporate this method (or a sentence) into the section 5.3.? Thanks, Yunfei from Alimail macOS ------------------Original Mail ------------------ Sender:Kazuho Oku <kazuhooku@gmail.com> Send Date:Sun Nov 15 21:19:39 2020 Recipients:Yanmei Liu <healing4d@gmail.com> CC:Christian Huitema <huitema@huitema.net>, Ma, Yunfei <yunfei.ma@alibaba-inc.com>, Hongqiang Liu <hongqiang.liu@alibaba-inc.com>, Yanmei Liu <miaoji.lym@alibaba-inc.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, quic <quic@ietf.org>, Qing An <anqing.aq@alibaba-inc.com> Subject:Re: What to do about multipath in QUIC 2020年11月16日(月) 8:25 Yanmei Liu <healing4d@gmail.com>: 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 <huitema@huitema.net> 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
- What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Martin Duke
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Jana Iyengar
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Behcet Sarikaya
- Re: What to do about multipath in QUIC Lucas Pardue
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Lucas Pardue
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Christian Huitema
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Behcet Sarikaya
- Re: What to do about multipath in QUIC Lucas Pardue
- Re: What to do about multipath in QUIC Behcet Sarikaya
- Re: What to do about multipath in QUIC Olivier Bonaventure
- Re: What to do about multipath in QUIC Behcet Sarikaya
- Re: What to do about multipath in QUIC Lucas Pardue
- Re: What to do about multipath in QUIC Behcet Sarikaya
- Re: What to do about multipath in QUIC Roberto Peon
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Kazuho Oku
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Lars Eggert
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Lars Eggert
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Roberto Peon
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Martin Thomson
- Re: What to do about multipath in QUIC Yanmei Liu
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Terminology for multipath QUIC (was Re: What to d… Lucas Pardue
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: Terminology for multipath QUIC (was Re: What … Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Christian Huitema
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Mirja Kuehlewind
- Re: What to do about multipath in QUIC Mirja Kuehlewind
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Re: What to do about multipath in QUIC Yanmei Liu
- Re: What to do about multipath in QUIC Behcet Sarikaya
- Re: What to do about multipath in QUIC Yanmei Liu
- Re: What to do about multipath in QUIC Kazuho Oku
- Re: Re: What to do about multipath in QUIC Ma, Yunfei
- Re: What to do about multipath in QUIC Yunfei Ma
- Re: What to do about multipath in QUIC Kazuho Oku
- Re: What to do about multipath in QUIC Florentin Rochet
- Re: What to do about multipath in QUIC Christian Huitema
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Christian Huitema
- Re: What to do about multipath in QUIC Mikkel Fahnøe Jørgensen
- Re: What to do about multipath in QUIC Kazuho Oku
- Re: What to do about multipath in QUIC Christian Huitema
- Re: What to do about multipath in QUIC Kazuho Oku
- Re: What to do about multipath in QUIC Christian Huitema
- Re: What to do about multipath in QUIC Kazuho Oku
- Re: What to do about multipath in QUIC Christian Huitema
- Re: What to do about multipath in QUIC Kazuho Oku
- Re: What to do about multipath in QUIC Christian Huitema
- Re: What to do about multipath in QUIC Spencer Dawkins at IETF
- Packet number spaces in multipath (was Re: What t… Jana Iyengar
- RE: Packet number spaces in multipath (was Re: Wh… Markus.Amend
- Re: Packet number spaces in multipath (was Re: Wh… Christian Huitema
- RE: Packet number spaces in multipath (was Re: Wh… Markus.Amend
- RE: Packet number spaces in multipath (was Re: Wh… Mikkel Fahnøe Jørgensen
- RE: Packet number spaces in multipath (was Re: Wh… Mikkel Fahnøe Jørgensen
- Re: Packet number spaces in multipath (was Re: Wh… Roberto Peon
- RE: Packet number spaces in multipath (was Re: Wh… Markus.Amend
- Re: Packet number spaces in multipath (was Re: Wh… Mirja Kuehlewind
- Re: Packet number spaces in multipath (was Re: Wh… Jana Iyengar
- Re: Packet number spaces in multipath (was Re: Wh… Quentin De Coninck
- Re: Packet number spaces in multipath (was Re: Wh… Mikkel Fahnøe Jørgensen
- Re: Packet number spaces in multipath (was Re: Wh… Kazuho Oku
- Re: Packet number spaces in multipath (was Re: Wh… Quentin De Coninck
- Re: Packet number spaces in multipath (was Re: Wh… Martin Thomson
- Re: Packet number spaces in multipath (was Re: Wh… Kazuho Oku
- RE: Packet number spaces in multipath (was Re: Wh… Mike Bishop