your thoughts on a particualar ipfw action.

Thu Aug 4 18:22:16 UTC 2016

> Am 04.08.2016 um 13:44 schrieb Ian Smith <smithi at nimnet.asn.au>:
>> On Wed, 3 Aug 2016 18:53:38 -0300, Dr. Rolf Jansen wrote:
>>>> Am 03.08.2016 um 11:13 schrieb Julian Elischer <julian at 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 :-)
>> 
>> Yes, you're right, I was taken away by the wave of enthusiasm, 
>> 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..
>> 
>> 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
>> 
>> 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 am completely free of passions on this CC encoding thingy. I won't use this feature anyway. Please, may I suggest that the experts of the ipfw community come to an agreement, and I then I will change the implementation accordingly.

Another possibility could be to attach the desired rule numbers directly to the country codes in the argument of the -t option, How about:

   geoip -t AU=50000:RU=50010:US=50020:BR=50030

The present behaviour would be kept without attached numbers. Please let me know your choices. Furthermore, if the new ipfw allows for more sophisticated table construction directives, that could be beneficial for country code based table processing, please advice.  

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

I will be ready to change the encoding scheme to anything on which the community will have been agreed upon.

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

The present incarnation of the ipdb tools makes no assumption on country codes. The user of the tools need to know what's the official codes of the countries to be selected, i.e. those that the RIR's happen to use in their delegation statistics files. So, no ipdb does not keep any CC data updated, and also the source for possibly updating CC data would not be one of the current RIR mirrors.

This would be another download from another source. However, if the community agrees on this, then I can look into this as well.

> 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
> 
>> BTW: The ipdb tools are now IPv6 aware.
> 
> cool!
> 
> Just some thoughts, FWIW,
> 
> Ian