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
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
