Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Aug 2016 22:13:18 +0800
From:      Julian Elischer <julian@freebsd.org>
To:        "Dr. Rolf Jansen" <rj@obsigna.com>, ipfw mailing list <ipfw@freebsd.org>
Subject:   Re: your thoughts on a particualar ipfw action.
Message-ID:  <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org>
In-Reply-To: <AE91DE1F-82B5-413C-826C-085231906C5F@obsigna.com>
References:  <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> <AE91DE1F-82B5-413C-826C-085231906C5F@obsigna.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote:
>> Am 02.08.2016 um 05:08 schrieb Julian Elischer <julian@freebsd.org>:
>>
>> 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"
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9fb7a057-aa02-9743-db9f-d4eef6df16f0>