From owner-freebsd-ipfw@freebsd.org Wed Aug 3 21:53:49 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 4FA3FBAEF91 for ; Wed, 3 Aug 2016 21:53:49 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 316B81C63 for ; Wed, 3 Aug 2016 21:53:49 +0000 (UTC) (envelope-from rj@obsigna.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2D0F5BAEF90; Wed, 3 Aug 2016 21:53:49 +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 2CB52BAEF8F for ; Wed, 3 Aug 2016 21:53:49 +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::2]) (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 9C1F61C5E; Wed, 3 Aug 2016 21:53:48 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470261225; l=5321; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=UbOFNTJAGVAU6aGugS/PDygQITQkGbHn3QM4xy39F+c=; b=Gnp+Yd/6bmFI35+YdS0/pIpfg9doCUWB2l0p6ZN+iGCdXdScnEHr6D0UK9j+lrQJu6h RtaHKFXmc2UQTi/ssa1ReNbD1jXmIFKitWrUgwLn24kIm7KHYczUNbt8ItHtEP9lgPQiO 9ApBR6wNH51OjMrYuhnPwcI7Dg2bNy6Tnfw= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU2BqlKi/2sgPrFVr5Wz+A= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bd1d99a8.virtua.com.br [189.29.153.168]) by smtp.strato.de (RZmta 38.13 DYNA|AUTH) with ESMTPSA id i0b7f2s73LrhfAK (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); Wed, 3 Aug 2016 23:53:43 +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 9DB8B229861E; Wed, 3 Aug 2016 18:53:39 -0300 (BRT) Content-Type: text/plain; charset=utf-8 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: <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org> Date: Wed, 3 Aug 2016 18:53:38 -0300 Cc: Julian Elischer Content-Transfer-Encoding: quoted-printable Message-Id: References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org> 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: Wed, 03 Aug 2016 21:53:49 -0000 > Am 03.08.2016 um 11:13 schrieb Julian Elischer : >=20 > On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: >>> Am 02.08.2016 um 05:08 schrieb Julian Elischer : >>>=20 >>> looking for thoughts from people who know the new IPFW features = well.. >>>=20 >>>=20 >>> 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. >>>=20 >>> 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?). >>=20 >> 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: >>=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 = 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. >=20 > 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 =E2=80=93 well, so it is. I elaborated on your idea and came-up = with the following formula: val =3D (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 =3D 5650 -- actually AD =3D 5680 ZZ =3D 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. > 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. BTW: The ipdb tools are now IPv6 aware. $ geoip 2001:1900:2254:206a::50:5 2001:1900:2254:206a::50:5 in 2001:1900:0:0:0:0:0:0 - = 2001:1900:ffff:ffff:ffff:ffff:ffff:ffff in US $ geoip -t "DE:BR:US" -p ... ... 217.194.64.0/20 217.194.224.0/20 217.195.0.0/20 217.195.32.0/20 217.197.80.0/20 217.198.128.0/20 217.198.240.0/20 217.199.64.0/20 217.199.192.0/20 217.224.0.0/11 2001:400:0:0:0:0:0:0/32 2001:408:0:0:0:0:0:0/32 2001:418:0:0:0:0:0:0/32 2001:420:0:0:0:0:0:0/32 2001:428:0:0:0:0:0:0/32 2001:430:0:0:0:0:0:0/32 2001:438:0:0:0:0:0:0/32 ... ... $ geoip -t "" -p | wc -l 137097 For processing only IPv4 addresses, add the -4 switch (this reproduces = the old behaviour) $ geoip -4 -t "" -p | wc -l 106637 For processing only IPv6 addresses, add the -6 switch $ geoip -6 -t "" -p | wc -l 30460 106637+30460 =3D 137097 After running 'make install' of the new version, the IP database needs = to be updated using the ipdb-update.sh script. This will now generate = two binary database files (*.v4 and *.v6). Best regards Rolf