From nobody Mon Nov 16 17:41:24 2020 Return-Path: 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 487C53A1840 for ; Mon, 16 Nov 2020 17:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xs9K47DLpvIM for ; Mon, 16 Nov 2020 17:41:20 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850CF3A0D48 for ; Mon, 16 Nov 2020 17:41:19 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id a15so20780277edy.1 for ; Mon, 16 Nov 2020 17:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pyrjrJSRM9dzSPXetek0DYGu13rXEQZyVpL3VLrSlYU=; b=a8mxZ1BoXd4ZiIKFhGQ3x8JYScnCGeRvnSMqZRM1+cpO1eMuznxchpZUdEyJC16FYA KO5WPgtiMQXBlUbdo09mtDpbQ07SKvsmSZzJIN41cuY6OeI5ToAT8NXblAAU1RchOPzv YVYZAoTxi2QtVBYghiO3LcOmxoyKBh+smU+z9AX/P1zA9PR0UO2UBxpSb7ahIF4DeMcP WTZ+SLGoxDuT4YXmi3qWTiNDtzBQpFiUv8T7bDQT1URO4mEpckin7rbzt+yEZdI4XH71 jX1V6wcZl3d8hgSgkiOAFviTtcibbw3RS1Ow/2nIxGFsOcl3R40nuQpyDK2EEtaqLG/2 TWjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pyrjrJSRM9dzSPXetek0DYGu13rXEQZyVpL3VLrSlYU=; b=YcuMeSBsmk/cXTGkUuNCEq758ZTQpdFNgsNvfjwKBZbu4Fpfwei0yFnbgxlrgE3S+E vSfzU/xiQ2oPLbYfJpnJY//MKqfHLcX360O3vAodzPNf3KU6tsJIQKbNYVxnD5Ywb9ix FDVhOAKUK4vZ1leFWYRoJanYgEE6okQD+30KElJYNygwOCJz1KXxcCH6HS0mbbZdgCDC VNn8nSJP2T05feqHUzUvdStRQmWBpTMGxQfHWYhf+hIs54dc/t+eGErwlPWfRRfvgy8k yV+QSny/s7m3C2UmTAyL8kyHC/Kw8ndfPgcW9RHa7JxaqRx9qrGz91yfyenbcD8rumKA CyMQ== X-Gm-Message-State: AOAM532ZNlCY6nWo8XbfJ7g+a8ml/F3kOEghS3FR7splnOcpbxMCtHrp spUcJwrQ4DgK6aKbf3wHlXvOGX2Eu5kRDoiBIM/DpBn7 X-Google-Smtp-Source: ABdhPJz6wcMA5Jk7jJ8tEQ4KekVBtgtp4Dc/wrNw17IVww8hHoUl4zDwVys/QPpK6uB7DWAc8TH4xAjIZzaNR6VZWlQ= X-Received: by 2002:a50:a40c:: with SMTP id u12mr5605877edb.337.1605577278092; Mon, 16 Nov 2020 17:41:18 -0800 (PST) MIME-Version: 1.0 References: <538215d1-3b9e-4784-920d-03be4c3a503a.miaoji.lym@alibaba-inc.com> <54510017-fa91-555f-0219-0859d6686b74@huitema.net> <062fe812-8afb-d946-8336-1f4dc5ebeaaf@uclouvain.be> <7540ef46-9948-c76c-3617-5755be3cdf37@huitema.net> <3bb7f359-ebe5-7a54-0224-bb1f5f1754af@huitema.net> <651e0ae1-0a5e-89e9-55c0-c33439599da6@huitema.net> In-Reply-To: <651e0ae1-0a5e-89e9-55c0-c33439599da6@huitema.net> From: Kazuho Oku Date: Tue, 17 Nov 2020 10:41:06 +0900 Message-ID: Subject: Re: What to do about multipath in QUIC To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000051fc8205b4439747" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 01:41:22 -0000 --00000000000051fc8205b4439747 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2020=E5=B9=B411=E6=9C=8817=E6=97=A5(=E7=81=AB) 9:26 Christian Huitema : > > On 11/16/2020 3:33 PM, Kazuho Oku wrote: > > > > 2020=E5=B9=B411=E6=9C=8817=E6=97=A5(=E7=81=AB) 8:12 Christian Huitema : > >> >> On 11/16/2020 2:05 PM, Kazuho Oku wrote: >> >> >> >> 2020=E5=B9=B411=E6=9C=8817=E6=97=A5(=E7=81=AB) 3:11 Christian Huitema : >> >>> 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 encode= d >>> 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 on= ly >> 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 =3D 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 wh= ich >> 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 th= e >> 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 significan= tly >> more heavy weight than it is today -- the peer that creates a new CID wo= uld >> 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 th= e > incoming path-ID based on four-tuple and CID, and then finding whether th= e > number space associated with the path. That leaves the issue of the initi= al > 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 no= t > 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. > 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 pat= h > specific number space". That, or trial decryption. > > 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 p= eer >> will be in the same number space. That may well be just fine if that pee= r >> 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, an= d > therefore cannot sustain through intentional migration [1]. > > That's incorrect. If the server supports non-zero CID, then the client ca= n > 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. 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 > > > -- Christian huitema > --=20 Kazuho Oku --00000000000051fc8205b4439747 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
2020=E5=B9=B411=E6=9C=8817=E6=97=A5(= =E7=81=AB) 9:26 Christian Huitema <huitema@huitema.net>:
=20 =20 =20


On 11/16/2020 3:33 PM, Kazuho Oku wrote:
=20


2020=E5=B9=B411=E6=9C=8817= =E6=97=A5(=E7=81=AB) 8:12 Christian Huitema <huitema@huitema.net>:


On 11/16/2020 2:05 PM, Kazuho Oku wrote:


2020=E5=B9=B411=E6= =9C=8817=E6=97=A5(=E7=81=AB) 3:11 Christian Huitema <huitema@huitema.net>:
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 enc= oding the "packet number" of QUIC, has more space t= han 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.=C2=A0 The values of N_MAX a= nd N_MIN MAY be equal.=C2=A0 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 =3D 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 t= he 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 re= ason to tie CID sequence number to packet numbers, if we are going to have "path identifiers" as a separate concep= t. 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 intern= al N:1 mapping between CIDs and the paths. A receiver can decode packets us= ing the CID and PN, retain ACK queue for each active CID, then send ACKs fo= r each CID identified by the sequence number.
=C2=A0

Maybe what we need is just one bit in the header to distinguish between "this packet uses the default number space" and &qu= ot;this packet uses the path specific number space". That, or trial decryption.

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.

<= div>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 inste= ad use CID sequence numbers for identifying the paths, as stated above. But= that does prohibit clients using zero-length CIDs.

Personally I am fine with eliminating this asymmetry in the specification= that allows only clients to use zero-length CIDs, but maybe others have di= fferent opinions.

Then there is the issue of key rotation. In this "pat= h sequence" scheme, we have only one key, so I assume th= at it will rotate simultaneously for all CID.

Agreed.


-- Christian huitema



--
Kazuho Oku
--00000000000051fc8205b4439747--