netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: bcook@breakingpoint.com
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org
Subject: Re: Possible DoS with 6RD border relay
Date: Thu, 05 Jan 2012 14:20:54 -0500 (EST)	[thread overview]
Message-ID: <20120105.142054.318495253662798509.davem@davemloft.net> (raw)
In-Reply-To: <201201042222.53147.bcook@breakingpoint.com>

From: Brent Cook <bcook@breakingpoint.com>
Date: Wed, 4 Jan 2012 22:22:52 -0600

> Is this expected behavior? All of the peers in this case are really the same 
> 6RD client - it's really simulating a customer edge router with a few thousand 
> hosts behind it. I suspect that adding a static route entry for the CE's 
> prefix via 'sit' will also make the problem go away.

Any route which refers to more than one exact host as the destination must
be cloned or COW'd.

This is so that we can provide unique metrics for the destination, as
well as a unique neighbour for the nexthop.

In your case, the keys used to lookup the nexthop for all of these
routes must be different, otherwise you wouldn't hit the neighbour
table limits.  Since if they were all the same we'd find an existing
neighbour entry and just bump it's reference count.

Longer term I intend to make the ipv4 and ipv6 routes not take a
reference to the neighbour entries.  The neighbour entries will be
"refcount-less", and only we'll just use the neighbour entry at packet
output time using a low latency fast lookup inside of a tight RCU
protected code sequence.

So all of this "neighbour table overflow" crap will just disappear.

  reply	other threads:[~2012-01-05 19:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-04 16:48 Possible DoS with 6RD border relay Brent Cook
2012-01-04 17:02 ` Brent Cook
2012-01-04 17:25   ` Eric Dumazet
2012-01-04 17:35     ` Brent Cook
2012-01-04 17:53       ` Eric Dumazet
2012-01-04 19:26         ` Brent Cook
2012-01-05  4:22           ` Brent Cook
2012-01-05 19:20             ` David Miller [this message]
2012-01-04 17:02 ` Eric Dumazet

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=20120105.142054.318495253662798509.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=bcook@breakingpoint.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).