[Swan] IPsec PFP support on linux

Paul Wouters paul at nohats.ca
Wed May 3 18:11:27 UTC 2017


On Wed, 3 May 2017, Sowmini Varadhan wrote:

> I am saying that if there are multiple TCP streams between the same
> pair of IP addresses, we want each stream to get a different SPI.
>
> For RDS-TCP, we have the concept of mprds:
> https://www.spinics.net/lists/netdev/msg381424.html
> where I pointed out that a single tcp stream can only give me
> 4 Gbps, but 8 streams (with 8 different client ports, single server port)
> can give me 32 Gbps.
>
> Today, without PFP, IPsec leaves me at single-stream throughput,
> even when I have 8 TCP connections going on.

Oh, so you are looking at just solving the problem of 1 IPsec SA only
being served by 1 CPU? Then look into pcrypt:

https://libreswan.org/wiki/OCF_Hardware_crypto_acceleration#The_pcrypt_kernel_module

but yes, reordering can then happen and you need to set a larger
replay-window= or disable replay detection completely.

>> How does using different IPsec SA's per TCP stream get you anything?
>
> See other mail about entropy. Everything that uses flow-based
> parallelism (RSS at the host, ECMP at the switches) needs to be able to
> spread flows across multiple paths, while making sure there is
> no packet reordering within the flow.
>
> having as much granularity in the flow-id as possible is the key
> to getting this to work well.

So you want to use the SPI's to spread the flows. Okay, I guess I
understand that now, and that it is not an entropy source or something.

It seems using IKE to artificially split up an IPsec SA into multiple
ones to address a kernel issue is not the proper solution though.

Paul


More information about the Swan mailing list