From owner-freebsd-ipfw@freebsd.org Thu Aug 4 18:22:16 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B692CBAE5F7 for ; Thu, 4 Aug 2016 18:22:16 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9B02B1A2D for ; Thu, 4 Aug 2016 18:22:16 +0000 (UTC) (envelope-from rj@obsigna.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9A4B2BAE5F6; Thu, 4 Aug 2016 18:22:16 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99E67BAE5F5 for ; Thu, 4 Aug 2016 18:22:16 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 151FE1A2A; Thu, 4 Aug 2016 18:22:15 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470334933; l=8484; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=4HI1zuKyXMXQ/kXXNCIY82HPjo2c/voZTsw9w3N1OYw=; b=C/8jH7siRAXGIKs9+d4lDckDERKpuamHuXOYvespCie4bTOlLQex3MD3FpfJVXDPjA2 KskYiahLzw1cnwatVrlk4NKuxnIIhnnJce2OpiPw8um12YYM80OsLR+Q+FmH2WPyFeWya PluKkgkM11FhC0FgnSORt7fy3F6LQDeOPJo= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU2B+3KSGnPFnK/TBWBCBcA X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bfb6bf8a.virtua.com.br [191.182.191.138]) by smtp.strato.de (RZmta 38.13 DYNA|AUTH) with ESMTPSA id j07edes74IM7xHs (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 4 Aug 2016 20:22:07 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 73C27229861E; Thu, 4 Aug 2016 15:22:03 -0300 (BRT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: your thoughts on a particualar ipfw action. From: "Dr. Rolf Jansen" In-Reply-To: <20160805024301.H56585@sola.nimnet.asn.au> Date: Thu, 4 Aug 2016 15:22:01 -0300 Cc: Julian Elischer , Ian Smith Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160805024301.H56585@sola.nimnet.asn.au> To: ipfw mailing list X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 18:22:16 -0000 > Am 04.08.2016 um 13:44 schrieb Ian Smith : >> On Wed, 3 Aug 2016 18:53:38 -0300, Dr. Rolf Jansen wrote: >>>> Am 03.08.2016 um 11:13 schrieb Julian Elischer = : >=20 > 'scuse savage reformatting, but I had to wrap it to read it .. and = pine=20 > has completely mangled the quoting levels too, dunno why. >=20 >>>>> looking for thoughts from people who know the new IPFW features = well.. >=20 > That's not me, but I'm having fun reading 11.0-RELEASE ipfw(8) .. >=20 >>>>> A recent addition to our armory is the geoip program that, given = an=20 >>>>> address can tell you what country it is in and given a country = code,=20 >>>>> can give an ipfw table that describes all the ip addresses in that=20= >>>>> country. >>>>>=20 >>>>> SO I was thinking how to use this, and the obvious way would be to=20= >>>>> have a set of rules for each country, and use the "skipto = tablearg"=20 >>>>> 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=20= >>>>> hard thing to set up with a set of rules for each country (how = many=20 >>>>> countries are there in the internet allocation system?). >=20 > Julian, have you looked into Andrey's LINEAR_SKIPTO ? How does it = work? =20 > Are there any disadvantages? And if not, why isn't it the default? :) >=20 > Also, There's a particularly useful example in new ipfw(8), showing = how=20 > to set and use multiple tablearg values - the example uses skipto,fib=20= > with a setfib tablearg followed by a skipto tablearg both from the = same=20 > table entry, and you can use, among others - some fully documented, = some=20 > yet to catch up - dscp values (0..63) setting or testing, and notably=20= > tags 1..65534, set or test, which goes some way towards 'variables' = you=20 > were hoping for, no? :) Also some netgraph stuff I won't understand = .. >=20 >>>> As of today a total of 236 country codes are in use for IPv4=20 >>>> delegations. If this helps for anything, a command line switch to = the=20 >>>> geoip tool could be added for letting it output the country code = (as the=20 >>>> hex encoded CC taken as a plain decimal integer) as the value for = the=20 >>>> given table entry. In the moment you can give one value for all = entries=20 >>>> generated by geoip, with this switch set, the output of geoip could = look=20 >>>> like: >>>>=20 >>>> $ 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 >>>> ... >>>>=20 >>>> Given that ... >>>> 0x4445 =3D 'DE' >>>> 0x4252 =3D 'BR' >>>> 0x5553 =3D 'US' >>>=20 >>> well it would have to be the decimal value so DE would be 6869, as=20= >>> while 4445 works 444F is a problem :-) >>=20 >> Yes, you're right, I was taken away by the wave of enthusiasm,=20 >> before thinking about the subject up to the end. >>=20 >>> 0x444F would work but we waste even more address space. You'd have = to=20 >>> multiply the numbers by some scaler, because adjacent numbers would = not=20 >>> be enough for one rule to do something and another rule to skip on = to=20 >>> somewhere else. (well, you could have multiple rules at the same = number=20 >>> but that has its limitations. > The idea would certainly work. it = would=20 >>> mean setting aside all the rules between 6565 and 9090 however. > A = more=20 >>> compact encoding could be something like >>>=20 >>> ((name[0]-'A') * 32)+(name[1]-'A')) multiplied by some 'step' (maybe=20= >>> 10 by default) and offset by a given offset. >>>=20 >>> so AF (Afghanistan) would be the first 0*32+5 * 10 would give an=20 >>> offset of 50.. plus a user supplied offset turns it into say, = 15050.. >>=20 >> I understand the reasons, however, any complicated encoding will=20 >> defeat the idea of the value can be sort of numeric mnemonic for the=20= >> country code =FF=FF well, so it is. I elaborated on your idea and = came-up=20 >> with the following formula: val =3D (C1-60)*1000 + C2*10 + offset. = The=20 >> offset can be given as the parameter to the -x flag. >>=20 >> $ 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 >> ... >>=20 >> The limits (without offset) are: >> AA =3D 5650 -- actually AD =3D 5680 >> ZZ =3D 30900 >>=20 >> With this formula, the offset must be less than 34735. Although,=20 >> this wastes a considerable amount of rule number space, the advantage = is=20 >> that the numbers are still accessible by mental arithmetic, and the=20= >> other constraint of having a step > 1 is fulfilled as well. Anyway, = this=20 >> one is not graved in stone, we can agree on another one. >=20 > Sorry, but that encoding takes up way too much (perhaps precious) rule=20= > space for one function, and I really can't see any mnemonic value in=20= > 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=3D50000:RU=3D50010:US=3D50020:BR=3D50030 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. =20 =20 > I'd go a but further than Julian here. Given the alpha country codes=20= > can only be AA .. ZZ, then using the same notation: >=20 >>> ((name[0]-'A') * 26) + (name[1]-'A') multiplied by some 'step' = (maybe=20 >>> 10 by default) and offset by a given offset. >=20 > Which has a munimum value of 0 (AA) and maximum of 25 * 26 + 25 =3D = 675,=20 > so at a spacing of 10 (less would do, but room for at least a couple = in=20 > 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=20 >>> Afghanistan is 004, but then you have the worry of keeping the data = up=20 >>> to date as they add new country codes, which in my opinion makes it = a=20 >>> bad solution. >>=20 >> Agreed, too much dependencies, let's forget the numeric iso codes. >=20 > On the other hand a) you have to keep this data up to date anyway, as=20= > allocations are farmed out and shifted around among countries = (including=20 > new ones, which happen pretty rarely) and b) probably most of the = larger=20 > countries have ISO numbers that tend to be lower, eg US is 1, DE is = 44?,=20 > 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 <001> <0> say 10010 > .. > country 256 <256> <0> say 12560 >=20 >> BTW: The ipdb tools are now IPv6 aware. >=20 > cool! >=20 > Just some thoughts, FWIW, >=20 > Ian