netdev - Re: [PATCH ipsec-next 0/7]: Support multiple VTIs with the same src+dst pair

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180103121012.y5l6exoygb4gwapa@gauss3.secunet.de>
Date:   Wed, 3 Jan 2018 13:10:12 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Lorenzo Colitti <lorenzo@...gle.com>
CC:     <netdev@...r.kernel.org>, <subashab@...eaurora.org>,
        <nharold@...gle.com>, <davem@...emloft.net>
Subject: Re: [PATCH ipsec-next 0/7]: Support multiple VTIs with the same
 src+dst pair

On Thu, Dec 21, 2017 at 02:06:00AM +0900, Lorenzo Colitti wrote:
> 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.

I think this is not the way we should go. Instead of creating some
new sort of VTI interfaces that have incompatibilities with the old
ones, we should create something new.

The fact that you need new keyed VTIs looks a bit like a workaround
of the design limitations the VTI interfaces have. Unfortunately
this is not the only limitation of VTI and I think we don't get what
we really want by changing VTI without breaking existing userspace.

The problem is that VTI interfaces are IP tunnels, and this is
not the thing we need. The tunnel is already implemented in the
generic xfrm code. All we need is some interface we can route
through. In particular we need something that can work with
transport mode too.

I showed already some ideas on creating xfrm interfaces at the
IPsec workshop in Seoul and my plan is to discuss this at the
upcomming IPsec workshop, so that we get something everybody is
happy with. In particular I want to have feedback from the
userspace IPsec IKE developers before we change/create something.