DPDK patches and discussions
 help / color / mirror / Atom feed
From: Matthew Hall <mhall@mhcomputing.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] 2.3 Roadmap
Date: Tue, 1 Dec 2015 14:49:46 -0500	[thread overview]
Message-ID: <20151201194946.GC28164@mhcomputing.net> (raw)
In-Reply-To: <20151201135739.GA31804@bricha3-MOBL3>

On Tue, Dec 01, 2015 at 01:57:39PM +0000, Bruce Richardson wrote:
> Hi Matthew,
> 
> Couple of follow-up questions on this:
> * do you need the exact same number of bits in both implementations? If we support
> 21 bits of data in IPv6 and 24 in IPv4 is that an issue compared to supporting
> 21 bits just in both for compatibility.
> * related to this - how much data are you looking to store in the tables?
> 
> Thanks,
> /Bruce

Let me provide some more detailed high level examples of some security use 
cases so we could consider what makes sense.

1) Spamhaus provides a list of approximately 800 CIDR blocks which are so 
bad that they recommend null-routing them as widely as possible:

https://www.spamhaus.org/drop/
https://www.spamhaus.org/drop/drop.txt
https://www.spamhaus.org/drop/edrop.txt

In the old implementation I couldn't even fit all of those, and doing 
something like this seems to be a must-have feature for security.

2) Team Cymru provides lists of Bogons for IPv4 and IPv6. In IPv4, there are 
3600 bogon CIDR blocks because many things are in-use. But the IPv6 table has 
65000 CIDR blocks, because it is larger, newer, and more sparse.

http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt
http://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt

Being able to monitor these would be another must-have for security and is 
quite popular for core routing from what I have heard.

3) At any given time, through various methods, I am aware of around 350,000 to 
2.5 million recent bad IP addresses. Technically single entries could be 
matched using rte_hash. But it is quite common in the security world, to look 
at the number of bad IPs in a class C, and then flag the entire subnet as 
suspect if more than a few bad IPs are present there.

Some support for some level of this is a must-have for security and firewall 
use cases.

4) Of course, it goes without saying that fitting the contents of the entire 
Internet BGP prefix list for IPv4 and IPv6 is a must-have for core routing 
although less needed for security. I am not an expert in this. Some very basic 
statistics I located with a quick search suggest one needs about 600,000 
prefixes (presumably for IPv4). It would help if some router experts could 
clarify it and help me know what the story is for IPv6.

http://www.cidr-report.org/as2.0/#General_Status

5) Considering all of the above, it seems like 22 or 23 unsigned lookup bits 
are required (4194304 or 8388608 entries) if you want comprehensive bad IP 
detection. And probably 21 unsigned bits for basic security support. But that 
would not necessarily leave a whole lot of headroom depending on the details.

Matthew.

  reply	other threads:[~2015-12-01 19:49 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-30 20:50 O'Driscoll, Tim
2015-11-30 21:50 ` Thomas Monjalon
2015-11-30 22:19 ` Dave Neary
2015-12-01 11:57   ` O'Driscoll, Tim
2015-11-30 22:30 ` Hobywan Kenoby
2015-12-01 11:52   ` O'Driscoll, Tim
2015-11-30 22:53 ` Kyle Larose
2015-12-01  1:16   ` Stephen Hemminger
2015-12-01 10:03     ` Bruce Richardson
2015-12-01 11:26       ` Yoshinobu Inoue
2015-12-01 11:58         ` Bruce Richardson
2015-12-01 13:42           ` Matthew Hall
2015-12-01 14:45             ` Kyle Larose
2015-12-01 19:28               ` Matthew Hall
2015-12-02  0:53           ` Yoshinobu Inoue
2015-12-01 14:27       ` Panu Matilainen
2015-12-01 14:48         ` Vincent JARDIN
2015-12-01 14:58           ` Panu Matilainen
2015-12-01 15:16             ` Christian Ehrhardt
2015-12-01 15:19             ` Bruce Richardson
2015-12-01 15:31               ` Aaron Conole
2015-12-01 15:54                 ` Richardson, Bruce
2015-12-02  1:38                   ` Wiles, Keith
2015-12-02  2:42                     ` Matthew Hall
2015-12-01 19:32                 ` Matthew Hall
2015-12-02 11:24           ` Neil Horman
2015-12-01 12:59 ` Matthew Hall
2015-12-01 13:16   ` O'Driscoll, Tim
2015-12-01 13:44     ` Matthew Hall
2015-12-01 13:57       ` Bruce Richardson
2015-12-01 19:49         ` Matthew Hall [this message]
2015-12-02 12:35           ` Bruce Richardson
2015-12-02 15:47             ` Matthew Hall

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=20151201194946.GC28164@mhcomputing.net \
    --to=mhall@mhcomputing.net \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.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).