[Swan-dev] IPSec offload API

[Ilan Tayari]

Hi Paul,

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

Our card has proven so far that it definitely does.
We do have more work ahead of us, though.

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

The kernel stack supports anything the hardware would support.
Software-API-wise, the driver is responsible to filter out unsupported offloads.

Our hardware currently does AES-GCM.
AES-CBC with SHA is planned, but not available yet.

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

This relates to a similar discussion I had with strongswan developers.

The daemon explicitly configures the SA to offload on a device, so it
is aware of this "bind" (although the SA still works on other interfaces
Without the NIC offload)

Then, if a netlink route change notification affects this, the daemon
may re-configure the SA.

This functionality is very similar to MOBIKE. If you have code paths to
handle that, then theoretically you could re-use large parts of the
same logic.


Ilan.