Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Aug 2016 18:53:38 -0300
From:      "Dr. Rolf Jansen" <rj@obsigna.com>
To:        ipfw mailing list <ipfw@freebsd.org>
Cc:        Julian Elischer <julian@freebsd.org>
Subject:   Re: your thoughts on a particualar ipfw action.
Message-ID:  <DA5D1FAE-79D9-4A19-8EFB-951C926265A0@obsigna.com>
In-Reply-To: <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org>
References:  <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> <AE91DE1F-82B5-413C-826C-085231906C5F@obsigna.com> <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> Am 03.08.2016 um 11:13 schrieb Julian Elischer <julian@freebsd.org>:
>=20
> On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote:
>>> Am 02.08.2016 um 05:08 schrieb Julian Elischer <julian@freebsd.org>:
>>>=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




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?DA5D1FAE-79D9-4A19-8EFB-951C926265A0>