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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160805024301.H56585>