Re: [dpdk-dev] 2.3 Roadmap

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Dec 01, 2015 at 02:49:46PM -0500, Matthew Hall wrote:
> 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.

Hi Matthew,

thanks for the info, but I'm not sure I understand it correctly. It seems to
me that you are mostly referring to the depths/sizes of the tables being used,
rather than to the "data-size" being stored in each entry, which was actually
what I was asking about. Is that correct? If so, it seems that - looking initially
at IPv4 LPM only - you are more looking for an increase in the number of tbl8's
for lookup, rather than necessarily an increase the 8-bit user data being stored
with each entry. [And assuming similar interest for v6] Am I right in 
thinking this?

Thanks,
/Bruce