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: <CAAedzxqvEx+dMCmM5YLbnmd9REpcWFi=+nZ4s0EaBe8mxSKKgQ@mail.gmail.com>
Date:	Wed, 8 Jul 2015 21:41:58 +0900
From:	Erik Kline <ek@...gle.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Lorenzo Colitti <lorenzo@...gle.com>,
	吉藤英明 <hideaki.yoshifuji@...aclelinux.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v2] ipv6: sysctl to restrict candidate source addresses

> 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.
--
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