IETF Logo Mail Archive

Re: hardware offload (was: Packet number encryption)

Christian Huitema <huitema@huitema.net> Sat, 10 February 2018 05:17 UTC

Return-Path: <huitema@huitema.net>
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 5A25A1241F8 for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 21:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 nx7dNsA0qJi7 for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 21:17:38 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 CD343126D85 for <quic@ietf.org>; Fri, 9 Feb 2018 21:17:37 -0800 (PST)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ekF8S-0005F7-8K for quic@ietf.org; Fri, 09 Feb 2018 21:19:04 +0100
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ekF8Q-00083Y-Hm for quic@ietf.org; Fri, 09 Feb 2018 15:19:03 -0500
Received: (qmail 12169 invoked from network); 9 Feb 2018 20:17:53 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 9 Feb 2018 20:17:53 -0000
To: Ian Swett <ianswett@google.com>, "Salz, Rich" <rsalz@akamai.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>, Eric Rescorla <ekr@rtfm.com>, "quic@ietf.org" <quic@ietf.org>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <bdf88936-8edc-d56e-ee59-c9d597058edd@huitema.net> <CY4PR21MB01337C8A700E58B49D90B712B6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <CAOYVs2pi8-NVuS+crNMfjsP-n5upK3=5tPeQ8OSGpOvL6RTrjA@mail.gmail.com> <CY4PR21MB0133A1117B2733BBCF049C5FB6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <MWHPR08MB24327A7BB5AE1AE70FE5CDB1DAF30@MWHPR08MB2432.namprd08.prod.outlook.com> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> <MWHPR21MB0144C68102972A668611E1FCB6F20@MWHPR21MB0144.namprd21.prod.outlook.com> <CY4PR21MB01332141C3563ABBA240C566B6F20@CY4PR21MB0133.namprd21.prod.outlook.com> <CABcZeBNeTT79nd+d7h-KFPpFYxpr5wt1KgwPY=M0_UQpCkKq1w@mail.gmail.com> <CY4PR21MB01337A5E81D8A8A1D7518D97B6F20@CY4PR21MB0133.namprd21.prod.outlook.com> <D3800B30-E1F5-4955-8F85-6FEF36AD2E23@akamai.com> <CAKcm_gO-2zejQnLCCzHvvG=gP70o9EAUQz8v2oYUiK=nFjyUCw@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <b8b848ba-e811-4ac0-5406-8d56fe7f7bae@huitema.net>
Date: Fri, 09 Feb 2018 10:17:52 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAKcm_gO-2zejQnLCCzHvvG=gP70o9EAUQz8v2oYUiK=nFjyUCw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: hardware offload (was: Packet number encryption)
X-Originating-IP: 168.144.250.215
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.24)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5naFvUnYQ8IAcp/fhsd9wscXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fv4i5bWdaOOh35Q+kHQgHYIB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXsyb8kPdw8E5fjseDcUSkOjZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XSWizyN/9VXiZ4elFzVDIjrsNHLD5iuK9LgA8bTWyd hYAA0yJvEM53nPrTZ5aF1kRZ0VwEd+iNUj65ezw/iijHw95cPWLsHiU6tFs2fFlaJuRMyksc0Dx4 iQa9AzGuG3nTPpuFqUUQz+mM8JAD4ECW5KgQQDk8tyKC/NeBLLoliqf4b0gaZx7Nq9QqOn1O3qTO G/srEDYAbd+JkBf9HkwTR4B44azPcrply6nBgbVn7CG7X+t1TW39Ja77LGPpOwDCYR4kEX6t994C WVS20AAh62+cNv80wh1h7LzKSJ1PRVAxXqQU4SUCmX1X8Fu4HDGTJ7q4QftjYVRI4vivMj6DQk2H BukllN/eBZD4GGbFsCT/dtMIs/LqOU9hZ/v31oRzg7QgpumQxgT4IcKeAlfy/bB/laLK9WZp+I7d gzC3lLdvK/cKOEqlCIPGIfYQDNKLLI6rY1d8Qdsix0hWyXbo
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/JXBvatPNqZ8j6rpPDN6uytHXThs>
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: Sat, 10 Feb 2018 05:17:40 -0000

On 2/9/2018 8:20 AM, Ian Swett wrote:

> One issue with the current encryption proposal is you can't use
> hardware crypto offload for the bulk encryption because the packet
> number has to be encrypted after the bulk data.
>
> Any suggestions on how to fix that?

Ian, could you be a bit more explicit about the type of hardware offload
that you have in mind?

I can think of two extreme types. One is embedding crypto offload in the
NIC, and is generally tied to TCP/TLS/TLO. That one type has no hope
whatsoever of working with UDP/QUIC. The other type is simply providing
an "encrypt this byte string" API, and can be trivially used with QUIC
-- much like we can use Intel's AES extended instructions today. So
obviously you have something else in mind, and maybe you should explain it.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email