netdev - Re: [PATCH] flowi: add concept of "not

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: <CAHmME9rF83ir0Hf9wsAoyu2aYPffu+WmOonc0nC6ZQqO8R_SyA@mail.gmail.com>
Date:	Fri, 5 Feb 2016 19:38:05 +0100
From:	"Jason A. Donenfeld" <Jason@...c4.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Julian Anastasov <ja@....bg>, Netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	David Ahern <dsa@...ulusnetworks.com>
Subject: Re: [PATCH] flowi: add concept of "not_oif"

On Thu, Feb 4, 2016 at 4:44 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Wed, 2016-02-03 at 22:02 +0100, Jason A. Donenfeld wrote:
>
>>
>> >         I don't know about the particular problems with
>> > tunnels but the scripts can use the route metric to order
>> > the routes in a table.
>>
>> This unfortunately does not cut it with tunnels.
>
> ip rule show
>
> ip route show table 10
>
> I am pretty sure that you could select/change skb mark when packets
> traverse the tunnel : The second route lookup can then select a
> completely different table.

This doesn't work. Not to mention the fact that ip-rules aren't
cleaned up when the interface is removed and the issues with having
multiple routing tables, the following only works for very narrow
cases:

(212.47.239.81 is the IP of a VPN endpoint, for example below)

$ ip rule add to 212.47.239.81 lookup main pref 30
$ ip rule add to all lookup 80 pref 40
$ ip route add default dev tun0 table 80

The problem is -- what happens when you have particular routes that
you'd like specifically to go over your original network connection,
not the tunnel? I am now not able to do this:

$ ip route add 1.2.3.4/32 dev eth0

Because it will examine the second rule. Moving everything to the
second routing table obviously isn't a solution either for all the
reasons listed in my first email. Everything is complicated, partially
broken, and all together unrobust this way.

Sorry, but the current routing facilities of Linux are woefully
insufficient for extremely common place modern day tunneling. The
solution I've offered here is extremely simple, easy, and
non-intrusive to implement. You will be the best friend of many
network administrators and ordinary daily users alike.

Just imagine if authors of userspace tunneling utilities could write
things like:

    setsockopt(fd, SO_NOTOIF, tun0_idx);

Or kernel tunneling utilities being able to write:

   .flowi4_not_oif = geneve0_idx;

And then never have to worry about routing loops or bizarre
situations? And have everything nicely cleaned up when the interface
goes away? And be able to continue using all the same old routing
tools and schemes as before, with no need for enormous
reimplementations and daemons and endless bloat?

This is a simple feature that will go a very long way. There is no
current solution that comes anywhere close to solving the real
problem. Please consider it.

Thanks,
Jason