netdev - Re: [PATCH net-next v2] ipv6: sysctl to restrict candidate source addresses

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: <20150708.144108.1074660115445698837.davem@davemloft.net>
Date:	Wed, 08 Jul 2015 14:41:08 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ek@...gle.com
Cc:	hannes@...essinduktion.org, lorenzo@...gle.com,
	hideaki.yoshifuji@...aclelinux.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2] ipv6: sysctl to restrict candidate source
 addresses

From: Erik Kline <ek@...gle.com>
Date: Wed, 8 Jul 2015 21:41:58 +0900

>> I really would like to come up with a sane works-always behavior for
>> this, but besides doing a retry on the complete source address selection
>> algorithm I currently cannot come up with an idea.
>>
>> Maybe we can tweak saddr_eval a bit.
> 
> I think it all comes down to this: source address selection really
> doesn't know anything about routing that could help it make a better
> evaluation.
> 
> Reading the RFCs that seems to be by design, or at the very least
> there is a kind of "implied flat-ish routing table" at work, which the
> algorithm works around by having various "prefer same interface" type
> of rules. So, after the routing lookup to determine outgoing interface
> it's just looking at all the addresses on all the interfaces.  There
> is no checking of any of the multiple possible routing tables, in part
> because there just isn't all the right information available.
> 
> So, I figured the safe thing to do would be to not change existing
> default behaviour but just introduce a knob to at least make it
> possible to get the RFC recommended behaviour.
> 
> ---
> 
> Re: not having a source address or returning a link-local source for a
> global destination:  I think that's perfectly ok, if the knob is set.
> Frequently the source address will just be tossed into a salad bowl of
> (src, dst) pairs returned from DNS and 3484/6724 sorting will then
> help pick a more globally optimum (src, dst) to work with.

The fact is, if wireless APs are going to reject packets sent out in
the very circumstances this is claiming to help, our default behavior
is broken because communication is not possible.

So we should look at a way at making the new behavior the default, and
in fact that makes sense and we can even optimize this piece of saddr
selection code to not do an iteration over all devices in the system
for no reason at all.  It can just do a quick dev_get_by_index() and
work with that.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html