From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170]) by dpdk.org (Postfix) with ESMTP id 10D41E62 for ; Tue, 1 Dec 2015 20:49:47 +0100 (CET) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id 8E5391BB; Tue, 1 Dec 2015 14:49:46 -0500 (EST) Date: Tue, 1 Dec 2015 14:49:46 -0500 From: Matthew Hall To: Bruce Richardson Message-ID: <20151201194946.GC28164@mhcomputing.net> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA674705F1@IRSMSX108.ger.corp.intel.com> <20151201125935.GA20658@mhcomputing.net> <26FA93C7ED1EAA44AB77D62FBE1D27BA67470C36@IRSMSX108.ger.corp.intel.com> <20151201134457.GB21396@mhcomputing.net> <20151201135739.GA31804@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151201135739.GA31804@bricha3-MOBL3> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] 2.3 Roadmap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 19:49:47 -0000 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.