> On Jun 22, 2020, at 4:11 AM, Neale Ranns via lists.fd.io > <nranns=cisco....@lists.fd.io> wrote: > > > > From: <vpp-dev@lists.fd.io> on behalf of Christian Hopps <cho...@chopps.org> > Date: Thursday 18 June 2020 at 18:20 > To: vpp-dev <vpp-dev@lists.fd.io> > Cc: Christian Hopps <cho...@chopps.org> > Subject: [vpp-dev] ipsec interface revisted. > > Hi, > > So to revisit this topic from a different angle. I believe VPP needs > something like the xfrm linux interface [1]. If I understand things correctly > this actually provides what was useful (but more-so) with old ipsec interface > functionality that has been lost. It is also a much cleaner/more powerful > abstraction than the current "ipip tunnel with transport mode SA" trick that > replaced the old ipsec interface functionality. > > As you say, replaced by ipip/gre tunnel interface, which shows the > functionality has not been lost. Route based VPNs are still supported. > > > The idea is to have an interface that one can use as a result of a FIB > lookup. SAs can be attached to this interface. The replacement for the old > ipsec interface functionality that was removed after 19.08, is that you > attach a simple *tunnel mode* SA with "accept all" policy to the xfrm > interface. You can also attach more complex policies if you care to, but the > common and highly efficient case will be "accept all". > > The win here is that: > > - FIB Fast: You get an interface that can be the result of the forwarding > lookup > . highly efficient especially with common zero cost match all policy > . compare to adding complex ip policy directly to all your ingress > interfaces (expensive). > - You have one interface for both IPv4 and IPv6 > > All of which are available with the ipip/gre tunnel model.
Yes. > > - It operates directly with the IPsec tunnel mode and transport mode SAs > without needing to mangle the internal definition of SA tunnel into transport > mode. Do you have any comments on this point? This is what I was talking about when I said a "cleaner abstraction". > - CRITICAL: Its use does not impose any encapsulation on the traffic itself. > > Critical implies that without this some use cases are impossible. What is it > that cannot be done with the tunnel model? - You can't tunnel non-singular IP traffic with IPIP (my use case requires this) IOW "ipip-only" model assumes the ESP payload is a single IP packet that will be wrapped with an outer IP packet. - You can't do route based transport mode IPsec using ipip (my use case doesn't require this). Both of these speak to the "more powerful abstraction" point. - The xfrm interface allows for route-based selection, but also allows for additional policy restrictions. This might be possible with IPIP model, but again it doesn't seem as clean/obvious. There's a reason that linux went with this approach as their improvement on the VTI interface, rather than just re-using IPIP tunnel after re-interpreting tunnel mode SAs into transport mode SAs like the new VPP code does. The latter makes assumptions about the IPsec tunnel mode payload and generally feels like a restricted "works for me/good enough" solution, rather than a clean abstraction one can build new use cases on (as I am trying to do). In my case I want to insert myself into a place in the graph that appears to no longer exist. IPTFS is a tunnel that carriers multiple or fractional inner IP packets per outer IP packet -- this simply does not map to an IPIP interface, where it would easily map to an XFRM style interface. So it definitely is a loss of functionality. Additionally I'm worried there may be even newer changes being made in VPP that are making further assumptions (restrictions) based on the new "ipip-only" model (something to do with rewrites/adjacencies maybe? -- my understanding here is minimal). It's been hard to justify, time-wise, tracking changes in code that seems engineered to not work for me. :) Thanks, Chris. > > /neale > > > Thoughts? > > Thanks, > Chris. > > [1] - > https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#XFRM-Interfaces-on-Linux >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16780): https://lists.fd.io/g/vpp-dev/message/16780 Mute This Topic: https://lists.fd.io/mt/74962223/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
