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. Changes from RFC series: - Processing of ICMP errors now works when ikey != okey. - Series now contains changes to the common tunnel lookup functions to match tunnels by okey and to ignore ikey when matching. - Fixed missing EXPORT_SYMBOL for xfrm_state_lookup_loose. - Made vti6_lookup static as it should have been.