On (05/02/17 11:33), Paul Wouters wrote: > > >If I used OE, I would *never* get a per-5-tuple SPI, right? > >(I can give this a try later today but the rfc definition of OE is > >not what I have in mind- I really want PFP, not OE). > > Right. > > 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.. 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 (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. Even for tunnel mode, I think there is a way to say that different inner IP addresses should use different SAs, and I think the same applies to port numbers including for transport mode. For the same entropy reason. > > I don't know of any userland implementing it. Which is why I suspect > the use case is weak :) I dont think so. See above. --Sowmini _______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan