[Swan-dev] IPSec offload API

[Ilan Tayari]

Paul,

> >> You say these drivers have a limit to the number of concurrent SA's
> >> the can support - as opposed to a limit to the number of packets they
> >> can process? Where does that limit come from? Does the private IPsec
> >> SA key get pushed into the card?
> >
> > Yes.
> >
> >> If so, then we also have FIPS
> >> issues to deal with - that is either those drivers need to come
> >> inside the crypto boundary or we have to disable offload in FIPS mode.
> >
> > I'm not so familiar when FIPS mode allows, but be probably have to
> > disable offloading in FIPS mode.
> 
> Interesting. So that does mean we have to ensure we are not running in
> FIPS mode before we send the XFRM offload commands.

I believe not only the driver, but also the HW part that does the crypto
needs to be added to the boundary.
Until that happens and is certified (not impossible, but complicated), you
will not want to use the offload in FIPS mode.
There's no reason to block this future development, though.


> >>> Second, the user should be aware what happens. The systems behaviour
> >>> changes, a user won't see IPsec packets in the stack anymore.
> >>
> >> The behaviour I was expecting was IPsec processing always works. But
> >> it either gets offloaded or not.
> >
> > IPsec processing works always, but you don't have encrypted IPsec
> > packets in the stack anymore because the NIC does this, before the
> > packet enters the stack on receive and after the packets leaves the
> > stack on transmit.
> 
> Are you saying that the user won't see ESP packets when using tcpdump?
> Even when using VTI? That would be confusing and would have to be
> documented in the man page for such an option.

You will see ESP packets properly encapsulated. But if you use 
tcpdump -x (or -w, etc.) you will see plaintext payload inside them.


> >>> Third, you might not trust all NICs that can do ESP offload.
> >>
> >> It seems like an unlikely corner case that you would trust some NICs
> >> in your machine but not some others.
> >
> > This is a valid case in high security environments. The NIC has the
> > key and can do whatever it want with it. So somebody might just trust
> > the NIC if he knows the crypto code that is running on the NIC.
> 
> Okay.

Another example related to the above, you may have one offload-capable NIC
which is FIPS-certified, and another which isn't. You will want to have 
control over whether each one is doing offload or not.


> >>>> Does it only apply to nic cards? What if someone has some dedicated
> >>>> non-NIC PCI offloading card like the Intel QuickAssist?
> >>>
> >>> This is something completely different. Intel QuickAssist does pure
> >>> crypto offload. It is (as far as I know) already supported in the
> >>> crypto layer.
> >>
> >> It is. I am just wondering how these different methods will interact,
> >> or at least not interfere with each other.
> >
> > If we do crypto offload to the NIC, we don't use the crypto layer.
> > We do the ESP encapsulation in the stack and defer the crypto
> > operations to the NIC by just not calling the crypto layer.
> 
> Does this mean any related options have no more effect either? Such as
> replay-window size and replay protection and UDP encapsulation? Does the
> nic support all of those? Do we need to separately configure those or are
> they going to be part of the XFRM command set? I guess what you are saying
> is that you are completely bypassing esp4.c/esp6.c from the kernel? Would
> we still get ACQUIRE's when max packet count or max life is reached?

Replay protection and UDP encapsulation are both features of the XFRM stack
and not the crypto layer. They behave with offload just like without offload.
You configure them the same way too, and I believe AQUIRE works the same way
as well.

Only the crypto is offloaded to the NIC. Not the whole IPSec stack.
Although we did talk about offloading the replay protection as well, so that
RSS can work on the inner packets. This was not implemented yet.

esp4/6.c have lots of changes in these patches. Yes.
The new mechanisms are highly integrated into this logic.


> Interesting. I guess these cards are not cheap of-the-shelves cards that I
> can get to play with? :)

The product name is Mellanox Innova IPSec, you can find more details online,
or write to me in private.


Ilan.