netdev - Question: Why only 1 VTI per src/dest-pair allowed

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

Message-ID: <8884c89f-81f9-509b-4cde-2c6ca1dfb76a@riverbed.com>
Date:   Wed, 26 Oct 2016 15:45:51 +0200
From:   Dario Ernst <Dario.Ernst@...erbed.com>
To:     netdev@...r.kernel.org
Subject: Question: Why only 1 VTI per src/dest-pair allowed

Hi,

I’m currently running into a limitation where I’d like to have multiple 
VTI interfaces with the same source / destination address. It seems like 
that this is not possible by default.

To elaborate a bit on my use-case: I’m trying to set up multiple tunnels 
(SAs) between two endpoints, be it for load-balancing and fail-over, or 
for complex routing in software-defined networking scenarios — or simply 
multiple different peers behind a NAT. I would like to retain the 
flexibility (and debuggability) that having a VTI provides.

I’ve been digging the ip_vti.c and ip_tunnel.c sources a bit — and 
please excuse my kernel-illiteracy, I’m a complete kernel-newbie. I’m 
creating a 2nd VTI through the IOCTL (as »iproute2« does), with the same 
src/dst as an existing VTI, but with a different ikey and okey. The 
condition that seems to break and throw -EEXIST is ip_tunnel_key_match. 
This checks whether TUNNEL_KEY (0x04) is set, however, from what I’ve 
seen only GRE_KEY (0x2000) is set — by vti_tunnel_ioctl. Also, in 
iproute2, I’ve not found that TUNNEL_KEY gets set.

So from what I *think* I’ve read it’s deliberate that the check doesn’t 
actually compare the keys — and thus forbids creating tunnel devices 
with same src/same dst/different key.

Now, my final questions on this is: What is the design decision behind 
this? Is there a finer point that I’m missing? And … is it actually 
sufficient to modify ip_tunnel_key_match to actually compare the keys, 
should they be set?

Thanks for all your great work, and thanks for reading this far :-).
Best Regards,
-Dario Ernst