Message-ID: <CANrj0bZOR0_r1VFE1-qJhDeWQQNfL9uFfzfomzG+izcWg=HWSw@mail.gmail.com>
Date:   Wed, 20 Jun 2018 14:39:16 -0700
From:   Benedict Wong <benedictwong@...gle.com>
To:     Steffen Klassert <steffen.klassert@...unet.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, eyal.birger@...il.com,
        antony@...nome.org, Lorenzo Colitti <lorenzo@...gle.com>,
        shannon.nelson@...cle.com
Subject: Re: [PATCH RFC v2 ipsec-next 0/3] Virtual xfrm interfaces

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.klassert@...unet.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.

Powered by blists - more mailing lists