netdev - Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 12 Jan 2017 01:46:34 +0900
From:   Lorenzo Colitti <lorenzo@...gle.com>
To:     David Miller <davem@...emloft.net>
Cc:     "Andrey Jr. Melnikov" <temnota.am@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: ipv6: put autoconf routes into
 per-interface tables

On Wed, Jan 11, 2017 at 11:11 PM, David Miller <davem@...emloft.net> wrote:
> I understand what you're saying, but if you look at how apps can be
> put into hierarchical control groups, and automatically bind to VRF's
> based upon where they are in that cgroup hierarchy, it matches your
> use case precisely.

I think whether an app is in bound to a certain VRF or not is not
directly related to this patch. What this patch does is provide a way
to ensure that routes learned via autoconf go into a specific routing
table, so that policy routing rules can select them.

Without this patch, and without VRFs, the routes for all networks and
all interfaces all go into the same routing table (main). That doesn't
work well on a multinetwork device. As David A. points out, with VRFs
this can be done - since each VRF has its own routing table, the
routes are isolated and ip rules can be applied to determine which
ones are used. However, I'm not convinced that VRFs are a great
solution to this problem. A couple of problems I see here are:

1. When an interface is created on the fly, the system must guarantee
that a VRF for it exists, and the interface is put into it, before it
comes up and receives an RA. This is not insurmountable - for example,
you can set net.conf.default.disable_ipv6 to 1, and set it to 0 on the
interface once it's in a VRF. Not sure this is feasible on a
mainstream distribution, but it could be done on something like
Android that's more tightly integrated.

2. I'm not sure it's possible to use routing policy to select between
interfaces in the same VRF. For example, if you have a carrier that
provides the user with the same IP address and similar connectivity on
both cellular data and a carrier-operated wifi network, and you put
those two in the same VRF, I don't see a way to say via routing policy
"prefer wifi over cellular", because the routes for both are in the
same table and AIUI the only discriminator between the two - the oif -
has to be set to the VRF ifindex. I suppose it might be possible to
alter the metrics of routes that were previously created by autoconf
but that sounds desperately hacky.

I suppose both of these could also be resolved by ensuring that each
interface is its own VRF at creation time. But if every VRF only
contains exactly one interface, the VRF construct doesn't really seem
useful.

That said, we've maintained this patch out of tree for a few years now
and we can continue to do so for a while longer. When the VRF code
rolls into enough SoC kernels we can make an attempt to use it and see
what issues we find.