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
