Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Aug 2016 02:44:16 +1000 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        "Dr. Rolf Jansen" <rj@obsigna.com>
Cc:        ipfw mailing list <ipfw@freebsd.org>, Julian Elischer <julian@freebsd.org>
Subject:   Re: your thoughts on a particualar ipfw action.
Message-ID:  <20160805024301.H56585@sola.nimnet.asn.au>

Next in thread | Raw E-Mail | Index | Archive | Help
On Wed, 3 Aug 2016 18:53:38 -0300, Dr. Rolf Jansen wrote:
 > > Am 03.08.2016 um 11:13 schrieb Julian Elischer <julian@freebsd.org>:
> 
> On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote:
>>> Am 02.08.2016 um 05:08 schrieb Julian Elischer <julian@freebsd.org>:

'scuse savage reformatting, but I had to wrap it to read it .. and pine 
has completely mangled the quoting levels too, dunno why.

>>> looking for thoughts from people who know the new IPFW features well..

That's not me, but I'm having fun reading 11.0-RELEASE ipfw(8) ..

>>> 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?).

Julian, have you looked into Andrey's LINEAR_SKIPTO ?  How does it work?  
Are there any disadvantages?  And if not, why isn't it the default? :)

Also, There's a particularly useful example in new ipfw(8), showing how 
to set and use multiple tablearg values - the example uses skipto,fib 
with a setfib tablearg followed by a skipto tablearg both from the same 
table entry, and you can use, among others - some fully documented, some 
yet to catch up - dscp values (0..63) setting or testing, and notably 
tags 1..65534, set or test, which goes some way towards 'variables' you 
were hoping for, no? :)  Also some netgraph stuff I won't understand ..

>> 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 :-)

RJ> Yes, you're right, I was taken away by the wave of enthusiasm, 
RJ> before thinking about the subject up to the end.

> 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..

RJ> I understand the reasons, however, any complicated encoding will 
defeat the idea of the value can be sort of numeric mnemonic for the 
country code  well, so it is. I elaborated on your idea and came-up 
with the following formula:  val = (C1-60)*1000 + C2*10 + offset. The 
offset can be given as the parameter to the -x flag.

$ geoip -t "DE:BR:US" -4 -x 30000
...
table 0 add 93.157.48.0/21 38690
table 0 add 93.158.236.0/22 36820
table 0 add 93.159.96.0/19 38690
table 0 add 93.159.248.0/21 38690
table 0 add 93.180.72.0/21 38690
table 0 add 93.180.152.0/21 38690
table 0 add 93.181.0.0/18 38690
table 0 add 93.183.0.0/18 55830
...

The limits (without offset) are:
AA = 5650  -- actually AD = 5680
ZZ = 30900

RJ> With this formula, the offset must be less than 34735. Although, 
this wastes a considerable amount of rule number space, the advantage is 
that the numbers are still accessible by mental arithmetic, and the 
other constraint of having a step > 1 is fulfilled as well. Anyway, this 
one is not graved in stone, we can agree on another one.

Sorry, but that encoding takes up way too much (perhaps precious) rule 
space for one function, and I really can't see any mnemonic value in 
those numbers anyway; let's let the computers do the counting ..

I'd go a but further than Julian here.  Given the alpha country codes 
can only be AA .. ZZ, then using the same notation:

> ((name[0]-'A') * 26) + (name[1]-'A') multiplied by some 'step' (maybe 
> 10 by default) and offset by a given offset.

Which has a munimum value of 0 (AA) and maximum of 25 * 26 + 25 = 675, 
so at a spacing of 10 (less would do, but room for at least a couple in 
between for patching) is a much smaller range of 0 .. 6750, plus offset,
potentially less if step size were also optional.

> 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.

RJ> Agreed, too much dependencies, let's forget the numeric iso codes.

On the other hand a) you have to keep this data up to date anyway, as 
allocations are farmed out and shifted around among countries (including 
new ones, which happen pretty rarely) and b) probably most of the larger 
countries have ISO numbers that tend to be lower, eg US is 1, DE is 44?, 
GB is 41, AU is 61 - or am I mixing these up with the phone codes?

Anyway, then we really could have useful mnemonics, ie:
 country 1	<offset digit> <001> <0> say 10010
 ..
 country 256	<offset digit> <256> <0> say 12560

RJ> BTW: The ipdb tools are now IPv6 aware.

cool!

Just some thoughts, FWIW,

Ian



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20160805024301.H56585>