netdev - Re: [Patch net-next] net: make neigh tables per netns

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:	Thu, 26 Jun 2014 05:10:13 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Michal Kubecek <mkubecek@...e.cz>
Cc:	Cong Wang <xiyou.wangcong@...il.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>,
	stephen hemminger <stephen@...workplumber.org>,
	Cong Wang <cwang@...pensource.com>
Subject: Re: [Patch net-next] net: make neigh tables per netns

Michal Kubecek <mkubecek@...e.cz> writes:

> On Wed, Jun 25, 2014 at 06:17:08PM -0700, Eric W. Biederman wrote:
>> Cong Wang <xiyou.wangcong@...il.com> writes:
>> 
>> > On Wed, Jun 25, 2014 at 5:04 PM, Eric W. Biederman
>> > <ebiederm@...ssion.com> wrote:
>> 
>> >> The only thing I see that you can gain by this work is getting around
>> >> global limits on neighbor table size.  Something that I think is most
>> >> unwise.
>> >
>> > Yes, this is one the benefits.
>> 
>> I disagree that removing a global DOS prevention check is a benefit.
>
> Network namespaces are often used for e.g. LXC containers. In such case,
> it would IMHO make sense if reaching the limits in one container didn't
> affect other containers or the host system.

I agree it would be good if one network namespace could not DOS
another.   It has even happened once or twice.  Probably the most
siginificant ways is when people create lots of network namespaces
(think 100s) and with just one or two neighbour tables per network
namespace exhaust the global neighbour limit.

However even in that case we don't want to remove the global limit and
allow ways to DOS the host that are not possible today.

I think there is some real potential in improving the neighbour cache.
We can DOS a system that is plugged into two networks by having an arp
flood of say 10,000 hosts on one interface that makes the other
interface useless.

Anyone who cares about ipv6 probably also wants to take a good hard look
at the neighbour table.  One documented attack on an ipv6 router is to
try to talk to each host in a /64 in turn.  To avoid that class of
problem ipv4 subnets are typically kept small, and that isn't a
realistic option in ipv6 for anyting except point to point links.

Which means there is a lot of room too improve how the neighbour table
behaves in a meaningful way.  I would be very happy to review patches
that make the neighbour cache better for everyone.  Figuring out how
to cleanly remove a lock sounds like one way.  Figuring out how to shape
the data structures and the limits so that a system stays performant and
is resistant to DOS attacks when a machine is connected to lots of
networks is another way.

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