On Thu, Dec 21, 2017 at 02:06:00AM +0900, Lorenzo Colitti wrote: > When using IPsec tunnel mode, VTIs provide many benefits compared > to direct configuration of xfrm policies / states. However, one > limitation is that there can only be one VTI between a given pair > of IP addresses. This does not allow configuring multiple IPsec > tunnels to the same security gateway. This is required by some > deployments, for example I-WLAN [3GPP TS 24.327]. > > This patchset introduces a new VTI_KEYED flag that allows > configuration of multiple VTIs between the same IP address > pairs. The semantics are as follows: > > - The output path is the same as current VTI behaviour, where a > routing lookup selects a VTI interface, and the VTI's okey > specifies the mark to use in the XFRM lookup. > - The input and ICMP error paths instead work by first looking up > an SA with a loose match that ignores the mark. That mark is > then used to find the tunnel by ikey (for input packets) or > okey (for ICMP errors). > > In order for ICMP errors to work, flags are added to the common > IP lookup functions to ignore the tunnel ikey and to look up > tunnels by okey instead of ikey. > > On the same IP address pair, keyed VTIs can coexist with each > other (as long as the ikeys are different), but cannot coexist > with keyless VTIs. This is because the existing keyless VTI > behaviour (which this series does not change) is to always accept > packets matching an input policy, regardless of whether there is > any matching XFRM state. Thus, the keyless VTI would accept the > traffic for the keyed tunnel and drop it because it would not > match the keyed tunnel's state.
I think this is not the way we should go. Instead of creating some new sort of VTI interfaces that have incompatibilities with the old ones, we should create something new. The fact that you need new keyed VTIs looks a bit like a workaround of the design limitations the VTI interfaces have. Unfortunately this is not the only limitation of VTI and I think we don't get what we really want by changing VTI without breaking existing userspace. The problem is that VTI interfaces are IP tunnels, and this is not the thing we need. The tunnel is already implemented in the generic xfrm code. All we need is some interface we can route through. In particular we need something that can work with transport mode too. I showed already some ideas on creating xfrm interfaces at the IPsec workshop in Seoul and my plan is to discuss this at the upcomming IPsec workshop, so that we get something everybody is happy with. In particular I want to have feedback from the userspace IPsec IKE developers before we change/create something.
