From: ebiederm@xmission•com (Eric W. Biederman)
To: Michal Kubecek <mkubecek@suse•cz>
Cc: Cong Wang <xiyou.wangcong@gmail•com>,
Linux Kernel Network Developers <netdev@vger•kernel.org>,
"David S. Miller" <davem@davemloft•net>,
Patrick McHardy <kaber@trash•net>,
stephen hemminger <stephen@networkplumber•org>,
Cong Wang <cwang@twopensource•com>
Subject: Re: [Patch net-next] net: make neigh tables per netns
Date: Thu, 26 Jun 2014 05:10:13 -0700 [thread overview]
Message-ID: <87k383lvmi.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20140626061438.GA2889@unicorn.suse.cz> (Michal Kubecek's message of "Thu, 26 Jun 2014 08:14:39 +0200")
Michal Kubecek <mkubecek@suse•cz> writes:
> On Wed, Jun 25, 2014 at 06:17:08PM -0700, Eric W. Biederman wrote:
>> Cong Wang <xiyou.wangcong@gmail•com> writes:
>>
>> > On Wed, Jun 25, 2014 at 5:04 PM, Eric W. Biederman
>> > <ebiederm@xmission•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
next prev parent reply other threads:[~2014-06-26 12:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-23 22:09 [Patch net-next] net: make neigh tables per netns Cong Wang
2014-06-25 23:33 ` David Miller
2014-06-26 0:04 ` Eric W. Biederman
2014-06-26 0:22 ` Cong Wang
2014-06-26 1:17 ` Eric W. Biederman
2014-06-26 6:14 ` Michal Kubecek
2014-06-26 12:10 ` Eric W. Biederman [this message]
2014-06-26 20:43 ` David Miller
[not found] ` <87egybibh5.fsf@x220.int.ebiederm.org>
2014-06-26 22:44 ` David Miller
2014-06-28 0:09 ` Cong Wang
2014-06-28 5:12 ` Eric W. Biederman
2014-06-30 18:15 ` Jesper Dangaard Brouer
2014-06-30 18:54 ` Hannes Frederic Sowa
2014-11-04 15:49 ` Stéphane Graber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k383lvmi.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission$(echo .)com \
--cc=cwang@twopensource$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=kaber@trash$(echo .)net \
--cc=mkubecek@suse$(echo .)cz \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stephen@networkplumber$(echo .)org \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox