Hi Neale, It's maybe worth pointing this out: using policy based IPsec continues to work fine for me. What I had and lost is route based IPsec, i.e., a destination interface that directs traffic to an SA *without trying to "partially-implement" the tunnel mode SA functionality*.
The new code is making the assumption that a tunnel mode SA's encap function can be 1-1 replaced by an upstream IPIP encapsulating function. This assumption is what is breaking me b/c my ESP payload is not a simple single IP packet. Each of my ESP payloads is an aggregate of IP packets sometimes padded sometimes fractional. These payloads are emitted on a fixed timed interval (which determines if there is padding or not) and encapsulated only upon being emitted. *Specifically* this cannot be driven by the users (inner) traffic or we've failed -- all of this is the function the IPTFS SA implements. All of this is coded and working for policy directed tunnel mode SAs. Having to somehow replicate this functionality in two places (one place for policy based, and then in some new tightly coupled encapsulating custom interface type) to support the vpp post 19.08 optimization couldn't be seen as being "cleaner" by any subjective measure I hope. So, in order to make things work post 19.08 I'm going to have to (re-)introduce a new "iptfs" interface type to VPP, so that I can have traffic directed to my SA w/o any encapsulation being done beforehand. If the goal was to avoid requiring per-use case interface types I don't think it worked for me. Basically I'm going to have to put back what was removed, maybe with a few refinements since I'm there already. Will that be acceptable when I eventually try and upstream the code? There's also the distinct possibility that we can't get this extra work funded in which case it would then only be available externally based on 19.08 which would be a shame as this work is based on the what is being done in ipsecme WG of the IETF. I would guess this would be seen as a poor outcome by others too. FWIW the GRE use-case was, and remains, a transport mode use of IPsec, so no extra assumptions are being made for that use case. The new code probably is an improvement for GRE with transport mode IPsec, but for the purpose of discussing IPsec tunnel mode functionality it's a bit distracting. Thanks, Chris. > On Jun 23, 2020, at 8:51 AM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > > > 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 (#16793): https://lists.fd.io/g/vpp-dev/message/16793 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] -=-=-=-=-=-=-=-=-=-=-=-
