> 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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to