Re: hardware offload (was: Packet number encryption)

[Ian Swett <[e-mail]>]

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]>
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
>
>
>
>