[Swan-dev] [PATCH libreswan] Add support for IPSec HW-offload on the NIC

[Antony Antony]

On Wed, Jun 28, 2017 at 05:53:17AM +0000, Ilan Tayari wrote:
> Hi Antony,
> (Sorry for confusing you with Paul in previous email)

no problem.

> > 1. how to detect which esp algorithms are supported by this card?
> There is no kernel API for that :/
> Currently the user is supposed to be aware which algos and modes his offload-capable NIC supports.
>
It would be nice to have such listing function. 

I advise better logging when pluto see EINVAL with offload.  The bellow link 
suggest very limited ESP algorithm support.  Just one AES GCM.  Which is ok 
to start with.  However, if there is a mismatch, it would be hard to debug.  
A clear log message would help.  Pluto detect EINVAL way late in the 
connection negotiation.  Just at the final step.
Also if one end has such an offload and the other end do not, it will be 
hard to debug. Especially if the initiator has a offload card.
In this responder would happily install the SA and send ESP traffic which 
will get discarded now. Even the IKE dpd/liveness could go through?

May be the phase 2 pending timer will kick in after two minutes on the 
initiator and restart.

> > 2. how does it deal with add_sa for a unsupported algorithm?
> If you attempt to install an SA with unsupported offload properties, it fails with -EINVAL.
> User may get more info in the logs, but the daemon will get just this generic indication.
> 
> > 3. does the card support AH SA?
> Our card does not currently. It is in the plans for future.
> See the driver cover letter for more info:
> https://patchwork.ozlabs.org/patch/781230/

I guess AH config would fail hard. Could you try and see what pluto would 
log if any?

> > 4. does it support xfrm acquire, block and pass polices too?
> The card currently offloads only the SADB, and not the SPD.
> So all policy-related checks are still in the xfrm stack.
> Acquires are not offloaded, only SAs that are supposed to have traffic on them are offloaded.
> 
> Offloading the SPD is planned for the future. 

It sounds this could work. However, it would be nice to test it. You need a 
"conn" with auto=ondemand on both ends, initiate a ping. The connection 
should come up and

"ipsec whack --trafficstatus" should show the SA.

conn myconn
	auto=ondemand 

if you run into issues may be look at "ip xfrm monitor"

> > 5. Any limits on number of SA supported? and would it return something
> > like
> > can't add any more message or silently fail.
> The card currently supports 1 million SAs maximum.
> You may not reach that limit, though, due to hash collisions.
> If offloaded SA cannot be added to the hardware due to that, the add_sa will fail.

sounds good enough for now.

> > 6. does a "ipsec restart" clear the SAs properly if pluto crash?
> > _stackmanger try to do that when pluto crash.
> 
> Deleting the SA in xfrm deletes it in the NIC as well.
> Flushing SAs in xfrm flushes them in the NIC as well. 

Then I guess if pluto get killed and it restart things should work!

> The conclusion from all the above, is that on failure to add_sa with 
> offload, we may retry add_sa without offload.
> But then again some users may want to engineer their systems to only add supported SAs. They will not want to tolerate fallback to non-offload.
> Maybe this could be another configuration option?

not sure what would be a good solution. In some sense less knobs the beter!  
My intention is to make sure there is clear logging when add_sa failis.
So the user know what failed.

> In any case maybe these things can be developed as incremental 
> improvements to libreswan?

agree!

regards,
-antony