netdev - Re: [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] [day] [month] [year] [list]

Message-ID: <20180105143250.6egaljl4y6quy63r@AntonyAntony.local>
Date:   Fri, 5 Jan 2018 15:32:50 +0100
From:   Antony Antony <antony@...nome.org>
To:     Lorenzo Colitti <lorenzo@...gle.com>
Cc:     netdev@...r.kernel.org, steffen.klassert@...unet.com,
        subashab@...eaurora.org, nharold@...gle.com, davem@...emloft.net
Subject: Re: [ipsec-next,0/7] : Support multiple VTIs with the same src+dst
 pair

Hi Lorenzo,
I agree vti is very limiting! I am glad to hear about xfrmi.

I saw two tunnels between gateways send traffic using VTI. So I am curious 
what is different in your case. Or are you dealing with something else?

Here are a couple of outputs from libreswan testing 

this is the verbose output.
https://swantest.libreswan.fi/results/blackswan/2018-01-05-swantest-3.22-596-g6bac0de35-master/netkey-vti-09/OUTPUT/west.console.verbose.txt

[root@...t netkey-vti-09]# ip xfrm state
src 192.1.2.23 dst 192.1.2.45
	proto esp spi 0x0eb97a56 reqid 16393 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 
0xcf25becdc6c196ff04b9e893d2caa387ed63bc96cf66ab7c1e5c74d32b9eeb801f06fbf3 
128
src 192.1.2.45 dst 192.1.2.23
	proto esp spi 0x507929e8 reqid 16393 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 
0x8b5f8143cb6f361e57b0096bc1a444a65e244f97ba76e8779b968bcae54b78cea7c17d38 
128
src 192.1.2.23 dst 192.1.2.45
	proto esp spi 0x73eab5cf reqid 16389 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 
0xb00cc4d0da414cba35c9a41e176fdafb92af0a7912d633c1c3f4623bee2d090173e3fca3 
128
src 192.1.2.45 dst 192.1.2.23
	proto esp spi 0x52581beb reqid 16389 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 
0x01b906499806ec2436ffe125f54ce297c3a3a14bb19fcbf51f16888c6927a20cd0dc5e67 
128

a santized output 
https://swantest.libreswan.fi/results/blackswan/2018-01-05-swantest-3.22-596-g6bac0de35-master/netkey-vti-09/OUTPUT/west.console.txt

Also from an older test:
https://swantest.libreswan.fi/results/blackswan/2018-01-04-swantest-3.22-596-g6bac0de35-master/netkey-vti-02/OUTPUT/west.console.txt

regards,
-antony

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.
> 
> Changes from RFC series:
> - Processing of ICMP errors now works when ikey != okey.
> - Series now contains changes to the common tunnel lookup
>   functions to match tunnels by okey and to ignore ikey when
>   matching.
> - Fixed missing EXPORT_SYMBOL for xfrm_state_lookup_loose.
> - Made vti6_lookup static as it should have been.