RE: hardware offload (was: Packet number encryption)

[Praveen Balasubramanian <[e-mail]>]

We have precedence in Windows with IPsec task offload which is symmetric crypto offload. The goal is to not have to make separate API calls to process crypto. The main advantage of crypto offload results from being able to make it a inline step in the NIC packet processing engine as part of the data path. This allows you to offload more mundane packet processing tasks going forward like we do with TCP. Some programmable NICs might be able to do a second pass but I am not a hardware expert to say if all NICs will be able to. There is precedence of some form of hardware crypto offload for TCP/TLS both as a side function and inline in network card. Some links from a quick web search:
https://www.chelsio.com/crypto-offload/
https://aws.amazon.com/documentation/cloudhsm/
https://netdevconf.org/1.2/session.html?boris-pismenny
I cannot comment on whether requiring an extra pass will render existing hardware inapplicable for QUIC. I have been trying hard to see if we can avoid an extra step regardless of crypto offload.

From: Ian Swett [mailto:[e-mail]]
Sent: Friday, February 9, 2018 1:46 PM
To: huitema <[e-mail]>
Cc: Salz, Rich <[e-mail]>; Praveen Balasubramanian <[e-mail]>; Eric Rescorla <[e-mail]>; [e-mail]
Subject: Re: hardware offload (was: Packet number encryption)

I should say that I don't have a specific API, implementation, or NIC in mind, so hopefully someone(Praveen?) can provide some context about what is possible with existing APIs or what is relatively easy to add to them.

The API I had in mind was of the "encrypt this byte string" form, but in the NIC.  ie: When I write a sequence of packets I supply crypto info, as well as a minimum release time(or pacing rate).  The goal is to do the bulk crypto as the network stack is packetizing and copying into the NIC memory.  Ideally this can avoid an extra memcpy and avoids touching the data to be sent until the last possible moment.

Hardware acceleration of AES in modern CPUs is extremely good, so another approach is to do the above in a userspace networking stack or the kernel and use the CPU's AES acceleration.  If the networking code that was writing into NIC memory had a deep understanding of QUIC, possibly it could do the packet number encryption as a second pass?

On Fri, Feb 9, 2018 at 3:17 PM, Christian Huitema <[e-mail]<mailto:[e-mail]>> wrote:
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