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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAKD1Yr3nfOp1LNfvVuTGZyThwu8Z+gaSN-DVaa11ZJYR+tMemg@mail.gmail.com>
Date:   Wed, 11 Jan 2017 02:47:55 +0900
From:   Lorenzo Colitti <lorenzo@...gle.com>
To:     "Andrey Jr. Melnikov" <temnota.am@...il.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: ipv6: put autoconf routes into
 per-interface tables

On Tue, Jan 10, 2017 at 10:21 PM, Andrey Jr. Melnikov
<temnota.am@...il.com> wrote:
>
> > >>> I have no firsthand experience of this myself, but if the problems
> > >>> that Andrey reports above in this thread are real, then those would
> > >>> indicate that the code is not well-supported. Being unable to accept
> > >>> DAD is a pretty serious issue. Andrey, what version of the kernel did
> > >>> you see this on?
>
> Good catch. I'm running 4.8 without this patch. Current 4.10-rc works. Sorry
> for noise.

Ack. As I said before, I haven't seen this myself. Shouldn't have made
assertions without firsthand evidence.

That said, I think this patch is useful even though autoconf on VRFs
works the same way. One reason is the example I provided above: it
works even for interfaces that don't exist yet, whereas a VRF has to
be created ahead of time, which means that the interface cannot
immediately come up and receive an RA or its configuration will be
incorrect.

I also think that from a configuration perspective it's not
necessarily useful to have one VRF for every interface, but that sort
of depends on your point of view. Perhaps it's fine on a client system
to have both vrf-wlan0 and wlan0, and vrf-eth0 and eth0. That might be
confusing to users but maybe users don't really care?

More in general I think that using a VRFs is buying into a bigger set
of assumptions/restrictions than this patch does. For example, if I'm
reading ipv6_dev_get_saddr correctly, once you put an interface in a
VRF you can't really use the weak host model any more, because the
stack won't pick a source address from outside the VRF if the route
lookup returned a route in the VRF. Turning on the functionality in
patch is a more minimal change that only affects autoconf.