From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 08494594B for ; Wed, 2 Dec 2015 13:35:20 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2015 04:35:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,373,1444719600"; d="scan'208";a="832627121" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.62]) by orsmga001.jf.intel.com with SMTP; 02 Dec 2015 04:35:17 -0800 Received: by (sSMTP sendmail emulation); Wed, 02 Dec 2015 12:35:16 +0025 Date: Wed, 2 Dec 2015 12:35:16 +0000 From: Bruce Richardson To: Matthew Hall Message-ID: <20151202123516.GA30204@bricha3-MOBL3> 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> <20151201194946.GC28164@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151201194946.GC28164@mhcomputing.net> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 02 Dec 2015 12:35:21 -0000 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