Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Aug 2016 15:22:01 -0300
From:      "Dr. Rolf Jansen" <rj@obsigna.com>
To:        ipfw mailing list <ipfw@freebsd.org>
Cc:        Julian Elischer <julian@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
Subject:   Re: your thoughts on a particualar ipfw action.
Message-ID:  <B26AAEC0-593A-46D9-A22F-F6B4B78E7E8E@obsigna.com>
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
> Am 04.08.2016 um 13:44 schrieb Ian Smith <smithi@nimnet.asn.au>:
>> 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>:
>=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	<offset digit> <001> <0> say 10010
> ..
> country 256	<offset digit> <256> <0> say 12560
>=20
>> BTW: The ipdb tools are now IPv6 aware.
>=20
> cool!
>=20
> Just some thoughts, FWIW,
>=20
> Ian




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?B26AAEC0-593A-46D9-A22F-F6B4B78E7E8E>