Message-ID: <20180625143440.ixo2aflwqzqfhqqj@gauss3.secunet.de>
Date:   Mon, 25 Jun 2018 16:34:40 +0200
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>
CC:     Eyal Birger <eyal.birger@...il.com>,
        Antony Antony <antony@...nome.org>,
        Benedict Wong <benedictwong@...gle.com>,
        Lorenzo Colitti <lorenzo@...gle.com>,
        Shannon Nelson <shannon.nelson@...cle.com>
Subject: Re: [PATCH RFC v2 ipsec-next 0/3] Virtual xfrm interfaces

On Tue, Jun 12, 2018 at 09:56:07AM +0200, Steffen Klassert 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.

I have not got any further comments, so applied to ipsec-next.

Powered by blists - more mailing lists