[Swan] IPsec PFP support on linux

[Paul Wouters]

On Tue, 2 May 2017, Sowmini Varadhan wrote:

>> Over the years I've received a number of requests for PFP, but I've
>> never seen people really followup with this. Of course, I also have
>> a hard time seeing the use case for per-port SPI's. It seems like a
>> dirty hack to do firewalling "per port" on IPsec SA's, instead of
>> just moving the firewall rules to the endnodes and apply them after
>> decryption, eg on a VTI device.
>
> I can easily give you the use cases for PFP! You need it for retaining
> the  entropy (equivalent to clear traffic). Entropy for RSS, entropy
> for ECMP in a CLOS..

I'm not familiar with those acronyms, and do not understand what
"retaining entropy" means.

> we are looking at using ipsec in transport mode for some of the
> kernel RDS-TCP sockets:
> http://www.netdevconf.org/1.1/proceedings/slides/varadhan-securing-tunneled-kenel-tcp-udp-sockets.pdf

Thanks for the link. So I think you are saying that different tenants
are using a single TCP stream so you need to have different IPsec SA's
for these? But what I don't understand is that if these are the same
endpoints, isn't the same IKE daemon used as a single trust point?
How does using different IPsec SA's per TCP stream get you anything?
The same kernels know the private keys, same code paths, just a
different SPI and different encr/integ keys?

> (I think there's some youtube somewhere online too). We need the
> per-socket entropy.  And similar issue for things like RoCEv2 tunnelled
> traffic (UDP in this case).
>
> For RoCE, the spec requires you to use a different udp sport per
> "qpair" (IB equivalent of socket) for entropy. In fact most udp
> tunneling protocols require this. IPsec reduces that entropy down.

Again, I don't understand entropy in this context.

Paul