This set of patches entire resolves issues Android was having with VTIs, specifically that we need multiple IPsec tunnels with the same source/destination endpoints.
These tests pass the following regression tests (https://android-review.googlesource.com/c/kernel/tests/+/588259/24): - Outbound encapsulation - Inbound decapsulation - Rekey - ICMP error path - Netfilter rejections of outbound paths. -- Benedict Wong On Tue, Jun 12, 2018 at 12:56 AM Steffen Klassert <steffen.klass...@secunet.com> wrote: > > This patchset introduces new virtual xfrm interfaces. > The design of virtual xfrm interfaces interfaces was > discussed at the Linux IPsec workshop 2018. This patchset > implements these interfaces as the IPsec userspace and > kernel developers agreed. The purpose of these interfaces > is to overcome the design limitations that the existing > VTI devices have. > > The main limitations that we see with the current VTI are the > following: > > - VTI interfaces are L3 tunnels with configurable endpoints. > For xfrm, the tunnel endpoint are already determined by the SA. > So the VTI tunnel endpoints must be either the same as on the > SA or wildcards. In case VTI tunnel endpoints are same as on > the SA, we get a one to one correlation between the SA and > the tunnel. So each SA needs its own tunnel interface. > > On the other hand, we can have only one VTI tunnel with > wildcard src/dst tunnel endpoints in the system because the > lookup is based on the tunnel endpoints. The existing tunnel > lookup won't work with multiple tunnels with wildcard > tunnel endpoints. Some usecases require more than on > VTI tunnel of this type, for example if somebody has multiple > namespaces and every namespace requires such a VTI. > > - VTI needs separate interfaces for IPv4 and IPv6 tunnels. > So when routing to a VTI, we have to know to which address > family this traffic class is going to be encapsulated. > This is a lmitation because it makes routing more complex > and it is not always possible to know what happens behind the > VTI, e.g. when the VTI is move to some namespace. > > - VTI works just with tunnel mode SAs. We need generic interfaces > that ensures transfomation, regardless of the xfrm mode and > the encapsulated address family. > > - VTI is configured with a combination GRE keys and xfrm marks. > With this we have to deal with some extra cases in the generic > tunnel lookup because the GRE keys on the VTI are actually > not GRE keys, the GRE keys were just reused for something else. > All extensions to the VTI interfaces would require to add > even more complexity to the generic tunnel lookup. > > To overcome this, we started with the following design goal: > > - It should be possible to tunnel IPv4 and IPv6 through the same > interface. > > - No limitation on xfrm mode (tunnel, transport and beet). > > - Should be a generic virtual interface that ensures IPsec > transformation, no need to know what happens behind the > interface. > > - Interfaces should be configured with a new key that must match a > new policy/SA lookup key. > > - The lookup logic should stay in the xfrm codebase, no need to > change or extend generic routing and tunnel lookups. > > - Should be possible to use IPsec hardware offloads of the underlying > interface. > > Changes from v1: > > - Document the limitations of VTI interfaces and the design of > the new xfrm interfaces more explicit in the commit messages. > > - No code changes.
