[Swan-dev] IPSec offload API

[Paul Wouters]

On Wed, 30 Nov 2016, Ilan Tayari wrote:

> This way IPSec benefits from plenty of other NIC offloads, such as RX and
> TX check summing, GSO, and so on.
> The NIC hardware has a chance to do all of these on the plaintext payload
> just before encrypting it.
>
> If one uses crypto-offload not in the NIC, such as AES-NI or even Quick-
> Assist, then all these goodies can't happen.

Ahh, that is interesting. I had not expected that the nic could beat a
multi core cpu with this....

> In addition, dedicated crypto offload hardware requires that all the
> payload passes over the PCI bus 3 times:
> From RAM to crypto hardware, from crypto hardware back to RAM, and then
> from RAM to NIC (assuming all are doing DMA).
> Under high bandwidths (we are testing 40Gbps), this can put extra stress
> on the system. Eventually the CPU is able to do only a little with all
> the cycles it saved not doing crypto.

Cool! I have not seen 40gbps of ipsec traffic. Do these cards support
AES-GCM, or is this using AES-CBC with a SHA authentication?

>>> I would love to see support for all of this in libreswan as well.
>>
>> We'd be happy to support it, although the failure-then-retry API is
>> something I'm very reluctant about. I'd rather send a flag to the kernel
>> to tell it what to do on offload failure, so we keep our current API of
>> sending 1 XFRM message and getting 1 XFRM answer.
>
> This is the main reason I wrote to the list.
> We want to get your feedback and comments, and you probably want to
> understand and/or influence our decisions.

And again, thank you for reaching out to us. It would be great to add
support for this.

Another question I had is how you would handle nic changes? Let's say we
have an IPsec SA up and running over one nic, and the machine's default
route changes so it goes over another nic, what is (or should?) happen?
Currently, we do not "tie" our IPsec SA's to a specific nic.

Paul