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]
Date:	Wed, 08 Jul 2015 10:43:34 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Lorenzo Colitti <lorenzo@...gle.com>
Cc:	Erik Kline <ek@...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

On Wed, 2015-07-08 at 17:19 +0900, Lorenzo Colitti wrote:
> On Wed, Jul 8, 2015 at 5:09 PM, Hannes Frederic Sowa
> <hannes@...essinduktion.org> wrote:
> > I wonder a little bit, because addresses which match the outgoing
> > interface should get a higher score in saddr_eval, thus be 
> > automatically
> > preferred. Is this check not strong enough?
> 
> It isn't strong enough because the "prefer outgoing interface" rule is
> lower priority than other rules such as "prefer deprecated addresses"
> and "prefer matching scope".
> 
> For example, consider the case where you have an IPv6 default route
> but not an IPv6 address on one interface (e.g., wifi), and a working
> configuration (IPv6 default route and IPv6 address) on another
> interface (e.g., cellular data). In this situation, the host will send
> the packet out on the wifi interface using the source address from the
> the cellular interface to try to talk to wifi. This will not work
> because the wifi network will almost certainly drop the packet due to
> BCP-38 ingress filtering.

So in this case we report errors to user space instead of picking an
address from another interface. If we turn on this knob unconditionally
we cannot leave the set of possible source addresses empty, this will
change application behavior and admin habits too much, I fear.

> > I really wonder if we can improve source address selection and make 
> > this
> > behavior a default without introducing a new sysctl.
> 
> Another option I see is to change the behaviour to follow the RFC
> recommendation, and thus always use the matching interface. Is that a
> better option?
> 
> At the moment, we're going against the explicit recommendation of the
> RFC, and I don't see a good reason for that.

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.

Thanks,
Hannes

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ