Hi Chris,
On 22/06/2020 13:09, "Christian Hopps" <cho...@chopps.org> wrote:
>
> - 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".
'cleaner' is a subjective term and subjective analysis is subject to bias; my
biases are clear. That's why I tried to frame this discussion with an objective
comparison of use case. First in what we can't do with ipip/gre then in what we
'can't' do with xfrms. More later..
> - 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.
More on this below...
- You can't do route based transport mode IPsec using ipip (my use case
doesn't require this).
That's true, but is that a use case? Route based VPNs apply to transit traffic,
as well as locally generated, and one shouldn't send transit traffic using a
transport mode SA, i.e. without encap that ensures it returns.
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.
VPP supports policy based VPNs using an SPD attached to an interface. Any
interface type could be used.
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).
I'm sure that had compelling reasons, but do they translate to VPP? Were they
for architectural reasons that don't apply. For example, was the choice of a
new interface type required to support HW offload? I'll try and find more info.
Perhaps you have good source you can share.
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.
... I don't follow your reasoning. Your feature runs in the ip4-output path of
an interface. It will therefore, per-buffer, get;
1) an ip4 packet, because that's what the 'contract' of the ip4-output feature
guarantees.
2) they will all be destined to the [single] peer that is reachable through the
interface, because that's what routing has decided is the fate of these
packets. Of course you are free to over-ride the routing decision if you wish,
but at the end of the feature arc the tunnel's adjacency will ship the packet
out the phy thru which the peer is reachable.
Now this applies regardless of the interface type. For example, if, and I'm not
suggesting you do this, but if, you were to protect the tunnel with a tunnel
mode SA, and in your feature vnet_buffer_advance'd away the first 20 bytes of
buffer data, then, what you receive, would be functionally equivalent to the
xfrm model, and what you transmit also the same; a packet to the peer. The
difference being that in the ipip/gre model your feature is expected to produce
a packet for the next node with those 20 bytes on the front. But in either case
the next feature on the arc is expecting an ipv4 packet, because it expects the
same guarantees your feature benefitted from. Which leads me to think that you
are not using the existing esp4-encrypt node unmodified? In your current
implementation, how do you communicate the change in packet type to the next
node?
You say 'IPTFS is a tunnel', perhaps this is where our view point differs. I
have a strong routing bias, and we're talking route based VPNs here __ the
tunnel is used for routing, it is through the tunnel that the routes are
advertised, and so the FIB chooses these tunnels to [load-balance] the traffic
to. The fact that they are secured, or have IPTFS, or ACLs, or NAT or whatever
else enabled on them is value add. The tunnel exists for routing, it is not
created by one those features.
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. :)
If there's one thing I hope I can assure you about, it's that these changes
weren't done just to make your life harder __ if it's any consolation, I have
no more changes planned, other than to finally removed the deprecated
ipsec_itf_create API, which currently maps onto call to ipip tunnels.
As a little back ground as to why the changes were made, here are a few other
use cases that VPP needs to support.
- GRE encap.
- L2 payload over GRE
- multipoint interfaces (DMVPN).
- specifying encap/decap behaviour (i.e. what IP header fields are copied from
overlay to underlay and vice versa, like DSCP,ECN, DF, etc.)
- double encap - when the tunnel IP endpoints are different (or the same) as
the crypto IP endpoint. A use case old VPP code supported.
With all but the last also required for tunnels without protection. So is it a
cleaner architecture to add another interface type just for ipsec tunnels and
move/replicate more types and functions of encap/decap into the SA - I'd argue
no. Should we introduce an xfrm like interface just for the popular
point-to-point IP encap case - again I'd argue no - we know how feature creep
works, we'd start with one use case and finish supporting them all. I'm hoping
you'll give me the killer reason __
Maybe the solution is to decouple the encap from the interface and we can share
a common encap-free interface type/template across ipip, gre, and maybe other
tunnels, then 'instantiate' that template with a protocol specific encap. Then
SAs could be similarly instantiated w/ or w/o an equivalent encap to share the
functionality. An xfrm interface would be an encap free interface instance. The
template would support the required modes; l2/l3, p2p/p2mp and mcast
destination address.
You probably saw that I'm taking a break for a few months, so not much code
from me in that time.
/neale
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 (#16790): https://lists.fd.io/g/vpp-dev/message/16790
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]
-=-=-=-=-=-=-=-=-=-=-=-
