From owner-freebsd-ipfw@freebsd.org Wed Aug 3 14:13:31 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11C1DBAD75D for ; Wed, 3 Aug 2016 14:13:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id F118C1FCB for ; Wed, 3 Aug 2016 14:13:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id ECE44BAD75C; Wed, 3 Aug 2016 14:13:30 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC8E8BAD75B for ; Wed, 3 Aug 2016 14:13:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D457B1FC1 for ; Wed, 3 Aug 2016 14:13:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u73EDOlv032209 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2016 07:13:27 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: your thoughts on a particualar ipfw action. To: "Dr. Rolf Jansen" , ipfw mailing list References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> From: Julian Elischer Message-ID: <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org> Date: Wed, 3 Aug 2016 22:13:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 14:13:31 -0000 On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: >> Am 02.08.2016 um 05:08 schrieb Julian Elischer : >> >> looking for thoughts from people who know the new IPFW features well.. >> >> >> A recent addition to our armory is the geoip program that, given an address can tell you what country it is in and given a country code, can give an ipfw table that describes all the ip addresses in that country. >> >> SO I was thinking how to use this, and the obvious way would be to have a set of rules for each country, and use the "skipto tablearg" facility to skip to the right rules for each country. But the trouble is that a tablearg skipto is very inefficient. It's also a hard thing to set up with a set of rules for each country (how many countries are there in the internet allocation system?). > As of today a total of 236 country codes are in use for IPv4 delegations. If this helps for anything, a command line switch to the geoip tool could be added for letting it output the country code (as the hex encoded CC taken as a plain decimal integer) as the value for the given table entry. In the moment you can give one value for all entries generated by geoip, with this switch set, the output of geoip could look like: > > $ geoip -t "DE:BR:US" -x > ... > table 0 add 93.157.48.0/21 4445 > table 0 add 93.158.236.0/22 4252 > table 0 add 93.159.96.0/19 4445 > table 0 add 93.159.248.0/21 4445 > table 0 add 93.180.72.0/21 4445 > table 0 add 93.180.152.0/21 4445 > table 0 add 93.181.0.0/18 4445 > table 0 add 93.183.0.0/18 5553 > ... > > Given that ... > 0x4445 = 'DE' > 0x4252 = 'BR' > 0x5553 = 'US' well it would have to be the decimal value so DE would be 6869, as while 4445 works 444F is a problem :-) 0x444F would work but we waste even more address space. You'd have to multiply the numbers by some scaler, because adjacent numbers would not be enough for one rule to do something and another rule to skip on to somewhere else. (well, you could have multiple rules at the same number but that has its limitations. The idea would certainly work. it would mean setting aside all the rules between 6565 and 9090 however. A more compact encoding could be something like ((name[0]-'A') * 32)+(name[1]-'A')) multiplied by some 'step' (maybe 10 by default) and offset by a given offset. so AF (Afghanistan) would be the first 0*32+5 * 10 would give an offset of 50.. plus a user supplied offset turns it into say, 15050.. or there could be a translation into iso3166 numeric codes where Afghanistan is 004, but then you have the worry of keeping the data up to date as they add new country codes, which in my opinion makes it a bad solution. > > ..., IT people who know by heart the low ASCII table like chemists (are supposed to) know the periodic table of the elements, this should be not too hard to remember. true > >> Another way would be to just put 'action numbers' in the tablearg field and have a few actions, shared by countries, but the trouble comes when you want to change the action for a country, you need to rewrite potentially thousands of entries (USA has over 15800 allocations). > Two or more geoip commands can be used for populating ipfw tables for different utilization in ipfw directives: > > # Europe > geoip -t "FR:IT:DE:NL:BE:GB:..." -n 1 -x | ipfw -q > /dev/stdin > > # North America > geoip -t "US:CA" -n 2 -x | ipfw -q > /dev/stdin > > # South America > geoip -t "AR:BR:UR:CL:PY:BO:PE..." -n 3 -x | ipfw -q > /dev/stdin > > ... > >> A second way woudl be to somehow map the tablearg of the country, into a table of actions. effectively doing two levels of lookup. >> >> The first table converting IP addresses to a country number and a second lookup converting that to an action. >> >> the only trouble is that I don't know of a way to do that. If the new changes allow that, and anyone knows how, please let me know :-). > Looking-up a given IP in the totally balanced binary search tree takes on a decent system on average about 10-20 nanoseconds. So in theory 50 to 100 million packets per second could be filtered by this algorithm. In order to come more close to this performance in reality, it might be an option to move the search algorithm into ipfw. > > Best regards > > Rolf > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >