[dpdk-dev] 2.3 Roadmap
Bruce Richardson
bruce.richardson at intel.com
Wed Dec 2 13:35:16 CET 2015
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
More information about the dev
mailing list