IETF Logo Mail Archive

Re: Getting to consensus on packet number encryption

"Brian Trammell (IETF)" <ietf@trammell.ch> Thu, 05 April 2018 06:53 UTC

Return-Path: <ietf@trammell.ch>
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 BB391126579 for <quic@ietfa.amsl.com>; Wed, 4 Apr 2018 23:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 T1c6btyAGW0x for <quic@ietfa.amsl.com>; Wed, 4 Apr 2018 23:53:35 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52984120725 for <quic@ietf.org>; Wed, 4 Apr 2018 23:53:35 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E49E4340E75; Thu, 5 Apr 2018 08:53:33 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.8388); Thu, 5 Apr 2018 08:53:33 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 5 Apr 2018 08:53:33 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50680374; Thu, 05 Apr 2018 08:53:33 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <3E5BCB0F-DEDE-4EBA-80DF-31E49764C0FE@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_E6AF5EFA-1AD8-4D46-B79C-5BDEEF9813E9"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: Getting to consensus on packet number encryption
Date: Thu, 05 Apr 2018 08:53:31 +0200
In-Reply-To: <CABkgnnV8ya_YdhU1VE+BuiMvuuZOO1-j-2=YHAGbmdE3OMk7Gg@mail.gmail.com>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Lars Eggert <lars@eggert.org>, Mark Nottingham <mnot@mnot.net>, IETF QUIC WG <quic@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>
To: Martin Thomson <martin.thomson@gmail.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <F9FCC213-62B9-437C-ADF9-1277E6090317@gmail.com> <CABcZeBM3PfPkqVxPMcWM-Noyk=M2eCFWZw2Eq-XytbHM=0T9Uw@mail.gmail.com> <CAN1APdfjuvd1eBWCYedsbpi1mx9_+Xa6VvZ3aq_Bhhc+HN67ug@mail.gmail.com> <CABcZeBMtQBwsAF85i=xHmWN3PuGRkJEci+_PjS3LDXi7NgHyYg@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <CABcZeBNfPsJtLErBn1=iGKuLjJMo=jEB5OLxDuU7FxjJv=+b=A@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <BBB8D1DE-25F8-4F3D-B274-C317848DE872@akamai.com> <CAN1APdd=47b2eXkvMg+Q_+P254xo4vo-Tu-YQu6XoUGMByO_eQ@mail.gmail.com> <CAKcm_gMpz4MpdmrHLtC8MvTf5uO9LjD915jM-i2LfpKY384O2w@mail.gmail.com> <HE1PR0702MB3611A67E764EE1C7D1644FAD84AD0@HE1PR0702MB3611.eurprd07.prod.outlook.com> <d8e35569-e939-4064-9ec4-2cccfba2f341@huitema.net> <CACpbDccqKoF-Y1poHMN2cLOK9GOuvtMTPsF-QEen3b30kUo9bg@mail.gmail.com> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <CAOdDvNo9QS=CX5YUWK8Lxs_SYX4nEM7OWv2+zB=VGhOX6J-BEw@mail.gmail.com> <CANatvzyo6xz7Kwh=EJ4GExBM35Dpw_=pLsAYiFA==vVBJwhCXw@mail.gmail.com> <CABkgnnV8ya_YdhU1VE+BuiMvuuZOO1-j-2=YHAGbmdE3OMk7Gg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/EUZVVqWuFy-QoqU3a9Wz7xvQp-o>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 05 Apr 2018 06:53:39 -0000


> On 5 Apr 2018, at 06:35, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
>> It is true that #1079 has issues with hardware crypto offload. I am
>> happy to support switching to a better encryption scheme (if we find
>> one) at any moment; e.g., during the standardization of QUICv1, or as
>> an extension to v1, or part of vX.
> 
> Until this came up, I hadn't considered the use of an
> extension/transport parameter to negotiate a new scheme, but it's
> obvious.  This fits best with my view of things.
> 
> If that means that we get the DC-QUIC option that turns the packet
> number encryption function into identity or some cheaper function,
> then I think that's an OK outcome.  We should stop pretending that one
> size fits all is achievable; it's not been the case for years already.

other than "please, please don't call it DC-QUIC", this approach (packet number encoding/encryption scheme as a transport parameter) sounds like a very good approach to me. There are details here, of course...

> FWIW, what I got from the info that Praveen and Ian have shared is
> that there are enough problems to solve with UDP that worrying about
> the performance hit from encryption is premature.

This was my intuition as well.

However, fixing kernel interface issues (as are at the root of UDP performance problems, as well as the lack of ECN signaling from userland) takes time, so those of us with hands on kernels should be working to fix those issues we *know* we will have should be working to fix them now. Fixing hardware issues -- let's face it, we'll probably never have full transport offload for QUIC, given the flexibility at the core of its design philosophy, but crypto offload is a good target -- takes longer, so anything we think we need for V2/V3, we need to start thinking about now.

IOW it's all premature, but the prematurity in this case is an externality, unless we think we know enough to decide that crypto offload isn't worth it for QUIC. (Obviously, I don't think we do)

Cheers,

Brian

v2.23.0 | Report a Bug | By Email