On Mon, Jun 04, 2018 at 08:58:22AM -0400, David Miller wrote: > From: Steffen Klassert <steffen.klass...@secunet.com> > Date: Mon, 4 Jun 2018 08:09:07 +0200 > > > 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. > > > > We had two presentations about xfrm interfaces at > > the workshop. Slides with further informations > > can be found at the workshop homepage: > > > > https://workshop.linux-ipsec.org/2018/ > > First off, you will have to describe in detail what the VTI > limitations are and how these new devices overcome them in this commit > message.
Ok, no problem. Sorry for not doing this in the initial mail. 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. So 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. > > You can't just say "we discussed this over there, go take a look". > > The place people "take a look" is your text here. > > Second, since you didn't explain things, I have to ask. Why is a new > special ID even necessary? It makes the flowi bigger, and adds all of > this new logic. > > All netdevs have an ifindex and you should be able to find a way to > use the ifindex of these new devices in the key somehow. The ifindex is already part of the xfrm selector and used as a key to enforce the output device after the transformation in the policy/state lookup. So we need some other identifier as the ifindex is already in use for xfrm lookups. We tried to keep the lookup logic in xfrm as much as possible, the only thing that we currently need is a field in the flowi for this to pass the information down to the lookups.
