Date: Fri, 5 Aug 2016 12:00:52 +0800 From: Julian Elischer <julian@freebsd.org> To: Ian Smith <smithi@nimnet.asn.au>, "Dr. Rolf Jansen" <rj@obsigna.com> Cc: ipfw mailing list <ipfw@freebsd.org> Subject: Re: your thoughts on a particualar ipfw action. Message-ID: <b4eb71be-9490-5c22-d22b-f6a1612e38d3@freebsd.org> In-Reply-To: <20160805024301.H56585@sola.nimnet.asn.au> References: <20160805024301.H56585@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/08/2016 12:44 AM, Ian Smith wrote: > 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? :) no, until he mentioned i I was unaware of it.. I will be looking at it as soon as 1 have time. > > 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 .. tags "almost" do variables but they stick on the packet after it leaves ipfw and may cause misinterpretation if the packet enters ipfw a second time. It's a question of scope. > >>> 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 applaud the attempt to forward computer science memorisation of ascii but I don't think that most people will see the value in those numbers. (though I admit it is cute).. For me the simplest thing would be if geoip had a option to "only do the mapping" so you could say ipfw add `geoip -m DE -x 15000` drop tcp .... or for a reverse lookup.. "eh what country was THAT again?" # geoip -r -x 15000 15123 AF # geoip -r -x 15000 15124 AF+1 because I know I'm going to be looking it up all the time. Many programs do this sort of thing, for example tcpdump dumps packets, but it can also give you the opcodes it decided to generate. > > 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 minimum 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? yes you are mixing them up.. GB is eight hundred and something. Aus is 36.. for phones, Hungary is 36.. go figure.. You'd have to import the numeric data from a different source and keeping them in sync would be a nightmare. The RIR information only has the two letter 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?b4eb71be-9490-5c22-d22b-f6a1612e38d3>