From owner-freebsd-ipfw@freebsd.org Fri Aug 5 04:15:17 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 832A9BAE5EB for ; Fri, 5 Aug 2016 04:15:17 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7741449 for ; Fri, 5 Aug 2016 04:15:17 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5ECA6BAE5EA; Fri, 5 Aug 2016 04:15:17 +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 5E66EBAE5E9 for ; Fri, 5 Aug 2016 04:15:17 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 169F61447 for ; Fri, 5 Aug 2016 04:15:17 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qt0-x229.google.com with SMTP id u25so168549740qtb.1 for ; Thu, 04 Aug 2016 21:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=egYWsYQ5N+0U0hxsp4BnwVjfkF/mrsX6g3D/NUb1+Vo=; b=HqABoxxPVdmH4Zc7iRWMe6GKeDZsADlrODOF+BOWv4h7AqM6N35copzWXqL5tVZJXC x/RDms0TMHQ9s4VHAwTugL7BI+fJ0pvc1jCbiZuOCYYUuMVVQv//irWBTshCAYOwoom9 i/OXT55/HqEjWcKO52IY9OknSizXp8L8dYjsELIe89V32kd/O3T4zbQD1tEO73x0K9jO sWfBB2VkN0nhrG+0m5BxWn7rR0CxpPBjYPPXoAprevzLmalcS5OUr4lNk6eRwlCTttWK g2845Rv/UtbQ+rxTN799hxeFEO/woeKQu3XBs1HSqtjwwSSwlI22SM/0lOfbkoeRdvEj JwYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=egYWsYQ5N+0U0hxsp4BnwVjfkF/mrsX6g3D/NUb1+Vo=; b=UJeOOof8RN1ybynyYkMr6qs9Mj9jrcZHolrUMJNUa4QeUnL0eoOpK2b4IEQ/hEPwee 5IRV7oFx6EUGueTbACAa3W728uceQaeALJyyoXpm8yA1t4HImWnKsBYYWZFVPQXhrUN6 Xn01BGNE+tsyqw+Y20nFA/aTdenFbpmgGrhQENQ79rQDsHb8hQG8YbAx0KIZ+D15BbDN 2wjnbR3Jj41PBtCwfjuTaEqUmDJwA+NoINlwSG0aAbqMLyMqpQ/ydLmPeHfRfGvUDbiB EbPXxFlMM2mktittYgZffm5u8qIL5HJ5WXwg4+A2tQ/RN8m1LsYDXEW6LieRe/HXtBnC vsQA== X-Gm-Message-State: AEkoouvQuTv/aFB6LjslbowSIWMoU4ygNqIDKv6yjIDot/REQsG0hIqS6wt2fSgycYflUowvKgJnSnzaFgtogwh/ X-Received: by 10.200.35.44 with SMTP id a41mr10380668qta.25.1470370516086; Thu, 04 Aug 2016 21:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.249 with HTTP; Thu, 4 Aug 2016 21:15:15 -0700 (PDT) In-Reply-To: References: <20160805024301.H56585@sola.nimnet.asn.au> From: Michael Sierchio Date: Thu, 4 Aug 2016 21:15:15 -0700 Message-ID: Subject: Re: your thoughts on a particualar ipfw action. To: Julian Elischer Cc: Ian Smith , "Dr. Rolf Jansen" , ipfw mailing list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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: Fri, 05 Aug 2016 04:15:17 -0000 Wouldn't it make sense to use the ISO Numeric Code / UN M49 Numerical Code? On Thu, Aug 4, 2016 at 9:00 PM, Julian Elischer wrote: > 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 > >: >> >>> On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: >>> >>>> Am 02.08.2016 um 05:08 schrieb Julian Elischer : >>>>> >>>> 'scuse savage reformatting, but I had to wrap it to read it .. and pin= e >> 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 wor= k? >> 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 =3D 'DE' >>>> 0x4252 =3D 'BR' >>>> 0x5553 =3D '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 =C3=BF=C3=BF 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 >> >> 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 i= t > 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 =3D 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 <001> <0> say 10010 >> .. >> country 256 <256> <0> say 12560 >> >> RJ> BTW: The ipdb tools are now IPv6 aware. >> >> cool! >> >> Just some thoughts, FWIW, >> >> Ian >> >> > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > --=20 "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent man requires only two thousand five hundred." - The Mah=C4=81bh=C4=81rata