From owner-freebsd-ipfw@freebsd.org Sun Jul 31 16:27:41 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 15267BAAA37 for ; Sun, 31 Jul 2016 16:27:41 +0000 (UTC) (envelope-from satyaday@phx2.hostbyte.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F232A1989 for ; Sun, 31 Jul 2016 16:27:40 +0000 (UTC) (envelope-from satyaday@phx2.hostbyte.net) Received: by mailman.ysv.freebsd.org (Postfix) id F186ABAAA36; Sun, 31 Jul 2016 16:27:40 +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 F1229BAAA35 for ; Sun, 31 Jul 2016 16:27:40 +0000 (UTC) (envelope-from satyaday@phx2.hostbyte.net) Received: from phx2.hostbyte.net (phx2.hostbyte.net [198.15.89.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DBB541988 for ; Sun, 31 Jul 2016 16:27:40 +0000 (UTC) (envelope-from satyaday@phx2.hostbyte.net) Received: from satyaday by phx2.hostbyte.net with local (Exim 4.87) (envelope-from ) id 1bTrbQ-00044n-NY for ipfw@freebsd.org; Sun, 31 Jul 2016 18:20:28 +0400 To: ipfw@freebsd.org Subject: Courier was unable to deliver the parcel, ID00000342272 X-PHP-Script: satyaday.com/post.php for 64.150.183.118 Date: Sun, 31 Jul 2016 14:20:28 +0000 From: "FedEx International Ground" Reply-To: "FedEx International Ground" Message-ID: <4ddbc0ad46a143897d90318a34ae5f7d@satyaday.com> X-Priority: 3 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx2.hostbyte.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [521 521] / [47 12] X-AntiAbuse: Sender Address Domain - phx2.hostbyte.net X-Get-Message-Sender-Via: phx2.hostbyte.net: authenticated_id: satyaday/from_h X-Authenticated-Sender: phx2.hostbyte.net: gilbert.krueger@satyaday.com Content-Type: text/plain; charset=us-ascii 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: Sun, 31 Jul 2016 16:27:41 -0000 Dear Customer, We could not deliver your item. Shipment Label is attached to email. Thank you for choosing FedEx, Gilbert Krueger, Delivery Agent. From owner-freebsd-ipfw@freebsd.org Sun Jul 31 18:38:56 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 C0EF2BAAEB4 for ; Sun, 31 Jul 2016 18:38:56 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 385F81EEF for ; Sun, 31 Jul 2016 18:38:55 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u6VIcivq009155; Mon, 1 Aug 2016 04:38:45 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Aug 2016 04:38:44 +1000 (EST) From: Ian Smith To: "Dr. Rolf Jansen" cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw divert filter for IPv4 geo-blocking In-Reply-To: <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> Message-ID: <20160801030317.P29054@sola.nimnet.asn.au> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Sun, 31 Jul 2016 18:38:56 -0000 On Sat, 30 Jul 2016 11:17:13 -0300, Dr. Rolf Jansen wrote: > I finished the work on CIDR conformity of the IP ranges tables > generated by the tool geoip. The main constraint is that the start > and end address of an IP block given by the delegation files MUST BE > PRESERVED during the transformation to a set of CIDR records. This > target is achieved by: > > 1. Finding the largest common netmask boundary of the start address utilizing > int(log2(addr_count)); then iteration like Euclid's algorithm in computing > a GCD. > > 2. Output the CIDR with the given start address and the masklen belonging > to the found netmask. > > 3. If the CIDR does not match the whole original IP range then set the start > address of the next CIDR block to the next boundary of the common netmask, > and loop over starting at 1. until the original range has been satisfied. > > I carefully tested the algorithm and a table that I pipe by the new > geoip tool into ipfw is 100 % identical to the output of the ipfw > command 'table N list'. Great. I suppose that caters for some of the odd delegations one sees, such as perhaps a /16 then a /15 (ie 3/4 of a /14) followed by maybe a /12, maybw with another /15 tacked on the end .. but I'm unsure if that applies to country allocations as much as it does within countries. > It is worth to note, that already the original RIR delegation files > contain 457 non CIDR conforming IPv4 ranges in a total of 165815 > original records. I guess that this number will increase in the > future because the RIR's ran empty on new IPv4 ranges and are urged > to subdivide returned old ranges for new delegations. The above > algorithm is ready for this. Yes, and just as well. I'm surprised it's as few as 457 .. I looked into it a bit back when 115.70/17 was first allocated to my ISP, after previously having been, as I recall, in China .. so of course we fell foul of a number of (probably perennially) out-of-date geoip blockers, for months in some cases .. malevolent beasts if not kept well fed :) > Generally, CIDR conforming tables are more than twice as large as > optimized (joined adjacencies) IP range tables. All said changes have > been pushed to GitHup already. So how many table entries does 'the world' come to, around 400,000? > I am still a little bit amazed how ipfw come to accept incorrect CIDR > ranges and arbitrarily moves the start/end addresses in order to > achieve CIDR conformity, and that without any further notice, and > that given that ipfw can be considered as being quite relevant to > system security. Or, may I assume that ipfw knows always better than > the user what should be allowed or denied. Otherwise, perhaps I am > the only one ever who input incorrect CIDR ranges for processing by > ipfw. You've lost me here, Rolf. Do you mean that ipfw adds incorrect table entries for a given IPv4 address and mask length? Or that it c/should itself accept IP ranges and generate the needed CIDR entries to match? If the former, how to reproduce for a bug report? If the latter, might you contemplate adding that functionality to ipfw - or is ipfw better off being driven to generate tables from the output of such as geoip? cheers, Ian From owner-freebsd-ipfw@freebsd.org Sun Jul 31 20:18:01 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 6D21ABA9F77 for ; Sun, 31 Jul 2016 20:18:01 +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::10]) (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 0520E1457 for ; Sun, 31 Jul 2016 20:18:00 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1469996277; l=7365; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=eWS4rQkxY2qpgP/NkpCUz9VQcmdxruPgHdkjXu/q6zA=; b=w8YoYlzgCGlIIY0BoyKzjbxXsAOVVv6LMeSvxp+/uXPlJz2G/SCgicD2LUxs0W138pR 7MmlKxA1FTBXY0RcJ91fY3uj808YdDZKcbKFzHoiDoeFmzHlWxHwnx4sdZ2N7UQkHNjGn su9G6MLfqYy7mzw+5tyx2Vei0bWdpbFjDKg= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU2B+3KSGnPFnK/TBWBAh4A X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bfb6bfbf.virtua.com.br [191.182.191.191]) by smtp.strato.de (RZmta 38.13 DYNA|AUTH) with ESMTPSA id 6057c4s6VKHo917 (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); Sun, 31 Jul 2016 22:17:50 +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 20C05229861E; Sun, 31 Jul 2016 17:17:46 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ipfw divert filter for IPv4 geo-blocking From: "Dr. Rolf Jansen" In-Reply-To: <20160801030317.P29054@sola.nimnet.asn.au> Date: Sun, 31 Jul 2016 17:17:44 -0300 Cc: Ian Smith Content-Transfer-Encoding: quoted-printable Message-Id: <166B5A24-8E5A-444D-BBF5-2B5883DE76A7@obsigna.com> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> <20160801030317.P29054@sola.nimnet.asn.au> To: freebsd-ipfw@freebsd.org 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: Sun, 31 Jul 2016 20:18:01 -0000 > Am 31.07.2016 um 15:38 schrieb Ian Smith : > On Sat, 30 Jul 2016 11:17:13 -0300, Dr. Rolf Jansen wrote: >> I finished the work on CIDR conformity of the IP ranges tables=20 >> generated by the tool geoip. The main constraint is that the start=20 >> and end address of an IP block given by the delegation files MUST BE=20= >> PRESERVED during the transformation to a set of CIDR records. This=20 >> target is achieved by: >>=20 >> 1. Finding the largest common netmask boundary of the start address = utilizing >> int(log2(addr_count)); then iteration like Euclid's algorithm in = computing >> a GCD. >>=20 >> 2. Output the CIDR with the given start address and the masklen = belonging >> to the found netmask. >>=20 >> 3. If the CIDR does not match the whole original IP range then set = the start >> address of the next CIDR block to the next boundary of the common = netmask, >> and loop over starting at 1. until the original range has been = satisfied. >>=20 >> I carefully tested the algorithm and a table that I pipe by the new=20= >> geoip tool into ipfw is 100 % identical to the output of the ipfw=20 >> command 'table N list'. >=20 > Great. I suppose that caters for some of the odd delegations one = sees,=20 > such as perhaps a /16 then a /15 (ie 3/4 of a /14) followed by maybe a=20= > /12, maybw with another /15 tacked on the end .. but I'm unsure if = that=20 > applies to country allocations as much as it does within countries. >=20 >> It is worth to note, that already the original RIR delegation files=20= >> contain 457 non CIDR conforming IPv4 ranges in a total of 165815=20 >> original records. I guess that this number will increase in the=20 >> future because the RIR's ran empty on new IPv4 ranges and are urged=20= >> to subdivide returned old ranges for new delegations. The above=20 >> algorithm is ready for this. >=20 > Yes, and just as well. I'm surprised it's as few as 457 .. I looked=20= > into it a bit back when 115.70/17 was first allocated to my ISP, after=20= > previously having been, as I recall, in China .. so of course we fell=20= > foul of a number of (probably perennially) out-of-date geoip blockers,=20= > for months in some cases .. malevolent beasts if not kept well fed :) >=20 >> Generally, CIDR conforming tables are more than twice as large as=20 >> optimized (joined adjacencies) IP range tables. All said changes have=20= >> been pushed to GitHup already. >=20 > So how many table entries does 'the world' come to, around 400,000? No, it is not that bad. The total number of original entries in the = delegation statistics files of all 5 RIR's is about 166000. The ipdb = tool which compiles these ranges into a consolidated sorted binary = table, that is suitable for loading it directly into a binary search = tree, reduces the number of entries to a bit more than one half, namely = ca. 83500. Consolidation primarily means, resolving of overlaps, because these = could not be handled in a meaningful way by a binary search tree. Only = as an additional benefit in the same go, that routine combines = adjacencies with the same country code, although, skipping the = combination is technically not a show stopper for the BST, this is only = to increase the performance. The geoip tool which generates the tables of CIDR ranges per country = code out of the consolidated tables would output a count of 167500 = entries for all countries. That is a little bit more than the original = count, however this table is still optimized, because original ranges = that when combined form a new valid CIDR are not broken down again, but = the combined CIDR is passed. >> I am still a little bit amazed how ipfw come to accept incorrect CIDR=20= >> ranges and arbitrarily moves the start/end addresses in order to=20 >> achieve CIDR conformity, and that without any further notice, and=20 >> that given that ipfw can be considered as being quite relevant to=20 >> system security. Or, may I assume that ipfw knows always better than=20= >> the user what should be allowed or denied. Otherwise, perhaps I am=20 >> the only one ever who input incorrect CIDR ranges for processing by=20= >> ipfw. >=20 > You've lost me here, Rolf. Do you mean that ipfw adds incorrect table=20= > entries for a given IPv4 address and mask length? Or that it c/should=20= > itself accept IP ranges and generate the needed CIDR entries to match? Perhaps an example may explain it better. Remember that the first = incarnation of geoip passed the incorrect range 201.222.20.0/20 to ipfw. = This is an incorrect CIDR because the start address does not match a = mask boundary defined by the given masklen. The point now is that this = error is caused by EITHER the masklen is incorrect OR the start address = is incorrect. ipfw can determine only that the CIDR is incorrect, and = does rectify it for further processing: # ipfw table 1 add 201.222.20.0/20 # ipfw table 1 list --> 201.222.16.0/20 0 So actually ipfw happily takes an incorrect CIDR and transforms this = into a correct one under the arbitrary assumption that the masklen is = the correct part and the start address is sort of variable. Technically = the addition by ipfw is a correct CIDR, but this is not necessarily the = range the user wanted to add. > If the former, how to reproduce for a bug report? If the latter, = might > you contemplate adding that functionality to ipfw Well, in the meantime, I saw that this kind of automatic rectification = of incorrect CIDR entries is within ipfw throughout. # ipfw add 50000 allow ip from 201.222.20.0/20 to any --> 50000 allow ip from 201.222.16.0/20 to any At least in this case the user is informed directly about the CIDR that = has been actually utilized, anyway, it is not exactly the range the user = has asked for, and the tiny difference can easily be overseen. Given that ipfw can't know what the user actually intended - did he = mistype the start address or obtained somehow a wrong masklen -, I = advocate that ipfw should accept the wrong CIDR and transform it to a = correct one exactly as above, but should output a warning, either to the = shell or to syslog in case no shell is connected. Ideally this warning = would give a useful explanation why the input CIDR is wrong and how it = could be made correct by either adjusting the masklen or the start = address. > - or is ipfw better=20 > off being driven to generate tables from the output of such as geoip? Of course, tools like geoip HAVE TO produce by 100 % valid CIDR, = otherwise the tool is buggy and the bug must be fixed as in the cse of = geoip. Of course, ipfw must not receive any so called "bug fix" that = immediately may break lots of firewall installations around the world, = given that it is so easy to inform invalid CIDR, and that ipfw happily = accepted these up to now. I don't want to look more catholic than the pope. My main concern is not = that ipfw does a choice for correcting invalid CIDR, my concern is that = the choice is sort of arbitrary. I advocate for logging a suitable = warning, but keep on processing invalid CIDR's by transforming it to = valid ones exactly as before. Best regards Rolf From owner-freebsd-ipfw@freebsd.org Mon Aug 1 05:22:28 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 AA5C5BABF61 for ; Mon, 1 Aug 2016 05:22:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8312713BB for ; Mon, 1 Aug 2016 05:22:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u715MN6W094317 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 31 Jul 2016 22:22:26 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: "Dr. Rolf Jansen" , freebsd-ipfw@freebsd.org References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> From: Julian Elischer Message-ID: Date: Mon, 1 Aug 2016 13:22:17 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 01 Aug 2016 05:22:28 -0000 On 30/07/2016 10:17 PM, Dr. Rolf Jansen wrote: > > I am still a little bit amazed how ipfw come to accept incorrect CIDR ranges and arbitrarily moves the start/end addresses in order to achieve CIDR conformity, and that without any further notice, and that given that ipfw can be considered as being quite relevant to system security. Or, may I assume that ipfw knows always better than the user what should be allowed or denied. Otherwise, perhaps I am the only one ever who input incorrect CIDR ranges for processing by ipfw. it's not so amazing when you think about it. The code comes from the routing table.. In this context a.b.c.d/N means "the range of addresses containing a.b.c.d, masked to a length of N". there is no specification that a.b.c.d is the first address of the range. I have relied upon this behaviour many times. > > Best regards > > Rolf > > _______________________________________________ > 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" > From owner-freebsd-ipfw@freebsd.org Mon Aug 1 06:17:55 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 6FF33BAC4B2 for ; Mon, 1 Aug 2016 06:17:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 37EAD16D2 for ; Mon, 1 Aug 2016 06:17:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u716HnNI094494 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 31 Jul 2016 23:17:52 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: "Dr. Rolf Jansen" , freebsd-ipfw@freebsd.org References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> From: Julian Elischer Message-ID: <3eedb126-ac78-ddad-27d3-132c742b2fdb@freebsd.org> Date: Mon, 1 Aug 2016 14:17:43 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 01 Aug 2016 06:17:55 -0000 On 30/07/2016 10:17 PM, Dr. Rolf Jansen wrote: >> Am 29.07.2016 um 10:23 schrieb Dr. Rolf Jansen : >>> Am 29.07.2016 um 06:50 schrieb Julian Elischer : >>> On 29/07/2016 5:22 PM, Julian Elischer wrote: >>>> On 29/07/2016 4:53 PM, Dr. Rolf Jansen wrote: >>>>>> Am 28.07.2016 um 23:48 schrieb Lee Brown : >>>>>> >>>>>> That makes sense to me. Your /20 range encompasses 201.222.16.0 - >>>>>> 201.222.31.255. >>>>>> If you want 201.222.20.0-201.222.31.255, you'll need 3 ranges: >>>>>> >>>>>> 201.222.20.0/22 (201.222.20.0-201.222.23.255) >>>>>> 201.222.24.0/22 (201.222.24.0-201.222.27.255) >>>>>> 201.222.28.0/22 (201.222.28.0-201.222.31.255) >>>>> Ian, Julian and Lee, >>>>> >>>>> Thank you vary much for your responses. In order not bloat the thread, I answer only to one message. >>>>> >>>>> I found the problem. As a matter of fact, the respective IP ranges in the LACNIC delegation statistics file are 3 adjacent blocks with 1024 addresses, i.e. those that you listed in your message above: >>>>> >>>>> $grep 201.222.2 /usr/local/etc/ipdb/IPRanges/lacnic.dat >>>>> lacnic|BR|ipv4|201.222.20.0|1024|20140710|allocated|164725 >>>>> lacnic|BR|ipv4|201.222.24.0|1024|20140630|allocated|138376 >>>>> lacnic|BR|ipv4|201.222.28.0|1024|20140701|allocated|129095 >>>>> >>>>> However, my database compilation combines adjacent blocks with the same country code, and the ranges above turn into one block of 3072 addresses, which obviously doesn't have a valid netmask - log(3072) = 11,5849625. >>>>> ... >>>>> ..., it is not sufficient to forget about optimization but I need to check also whether, the delegation files contain already some non-CIDR ranges, which need to be broken down. >>>> there is code to take ranges and produce cidr sets. >>>> >>>> We used to have exactly that code in the appletalk code before we took it out. Appletalk uses ranges. >>>> https://svnweb.freebsd.org/base/release/3.2.0/sys/netatalk/at_control.c?view=annotate#l703 >>> though htat uassumes input in the form af an appletak sockaddr.. >>> there is also this python module >>> https://pythonhosted.org/netaddr/tutorial_01.html#support-for-non-standard-address-ranges >>> >>>> maybe you can find other versions on the net. >>>> however if you fully populate the table, you will get the correct result because more specific entries will >>>> override less specific entries. To do that you would have to have a way to describe to your program what >>>> value each table entry should output. >>>> If you did what you do now, then you would specify the value for the required countries, and give a default falue for "all others". >>>> aggregation of adjacent ranges with same value would be an optimisation. >> Don't worry, breaking down an arbitrary IP-range into a CIDR conforming set of ranges, doesn't seem too difficult. ... >> ... >> Once I come to a conclusion, I will post it to this mailing list. > I finished the work on CIDR conformity of the IP ranges tables generated by the tool geoip. The main constraint is that the start and end address of an IP block given by the delegation files MUST BE PRESERVED during the transformation to a set of CIDR records. This target is achieved by: > > 1. Finding the largest common netmask boundary of the start address utilizing > int(log2(addr_count)); then iteration like Euclid's algorithm in computing > a GCD. > > 2. Output the CIDR with the given start address and the masklen belonging > to the found netmask. > > 3. If the CIDR does not match the whole original IP range then set the start > address of the next CIDR block to the next boundary of the common netmask, > and loop over starting at 1. until the original range has been satisfied. check out the appletalk code I pointed out to you.. I wrote that in 93 or so but I remember sweating blood over it to get it right. > > I carefully tested the algorithm and a table that I pipe by the new geoip tool into ipfw is 100 % identical to the output of the ipfw command 'table N list'. though that doesn't mean it is semantically identical to the original table due to 'most specific rule wins" behaviour. for example: if you type in ; 1.2.3.0/24 -> A and 1.2.3.0/26 -> B then both rules will be listed the same as what you put in but if you wanted to get all rules that point to A, without having rules that point to B, then you would have to export 1.2.3.64/26 -> A 1.2.3.128/25 -> A (i.e. TWO rules) you could also export 1.2.3.0/24 -> A 1.2.3.0/26 -> 0 (think of it as an "EXCEPT for these" rule) which is ALSO two rules but you would need to be sure that the receiver knows what to do with them. > > It is worth to note, that already the original RIR delegation files contain 457 non CIDR conforming IPv4 ranges in a total of 165815 original records. I guess that this number will increase in the future because the RIR's ran empty on new IPv4 ranges and are urged to subdivide returned old ranges for new delegations. The above algorithm is ready for this. > > Generally, CIDR conforming tables are more than twice as large as optimized (joined adjacencies) IP range tables. All said changes have been pushed to GitHup already. Unfortunately there is no way to specify (using cidr notation) a.b.1.x AND a.b.2.x without including a.b.[03].x. HOWEVER if you specified the FULL table you could use the "except" feature of routing table behaviour where a.b.0.x/22 -> A a.b.0.x/24 -> B a.b.3.x/24 -> B gives you the same thing because of the 'most specific rule wins" nature of routing table evaluation. I believe this is the case in the tables you imported. the trick is to be able to take an "optimised" table such as that above and produce, given a required subset, just the required part, while changing the rules as needed on the fly to "de-optimise" them enough to maintain correctness. > > I am still a little bit amazed how ipfw come to accept incorrect CIDR ranges and arbitrarily moves the start/end addresses in order to achieve CIDR conformity, and that without any further notice, and that given that ipfw can be considered as being quite relevant to system security. Or, may I assume that ipfw knows always better than the user what should be allowed or denied. Otherwise, perhaps I am the only one ever who input incorrect CIDR ranges for processing by ipfw. I answered this before but can't see the answer in my out box, plus I have added info.. The ipfw code is derived from the routing code. it is shorthand notation for a.b.c.d [netmask e.f.g.h ] there is nothing that says that a.b.c.d need be the first address in the range. (though some vendors may require that.) to quote wikipedia on the topic (yes, I know, not an authoritative source) ==== quote ==== The address may denote a single, distinct interface address or the beginning address of an entire network. The maximum size of the network is given by the number of addresses that are possible with the remaining, least-significant bits below the prefix. The aggregation of these bits is often called the /host identifier/. For example: * 192.168.100.14/24 represents the IPv4 address 192.168.100.14 and its associated routing prefix 192.168.100.0, or equivalently, its subnet mask 255.255.255.0, which has 24 leading 1-bits. I use this all the time when parsing information that contains a hostname, and I know the netmask width. It saves me from having to have complicated shell code to pull apart the address and zero out the host bits of the address. > Best regards > > Rolf > > _______________________________________________ > 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" > From owner-freebsd-ipfw@freebsd.org Mon Aug 1 09:28:39 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 83139BAA99A; Mon, 1 Aug 2016 09:28:39 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EFC5F198D; Mon, 1 Aug 2016 09:28:38 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u719SXvc041396; Mon, 1 Aug 2016 19:28:33 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Aug 2016 19:28:33 +1000 (EST) From: Ian Smith To: Kevin Oberman cc: FreeBSD-STABLE Mailing List , freebsd-ipfw@freebsd.org Subject: Re: Significant missing item in 11.0 release notes In-Reply-To: Message-ID: <20160801191550.J29054@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 01 Aug 2016 09:28:39 -0000 On Sun, 31 Jul 2016 12:28:06 -0700, Kevin Oberman wrote: > This morning I updated my min user system from 10.3-Stable to 11.0-BETA3. > In general, things went well, but I had two issues that prevented the > network from operating. the first is a lack of documentation in the Release > Notes and the second is a driver issue. Since they are in no way related, > I'll send the report of the driver issue later. > > I use ipfw(8) tables in my firewall configuration. Unfortunately, 11.0 has > introduced a totally re-worked tables structure. The new structure is > awesome and I read about it at the time the changes were being planned and > implemented, but had forgotten. As a result the very first line in my > configuration, "table 1 flush" was no longer valid and the remainder of the > file was ignored. > > I assumed that I had missed this in the release notes, but I can find no > reference to this significant change that simultaneously greatly enhanced > ipfw table functionality, but also broke my configuration. While the fix > was trivial, if the Release Notes had addressed this, I would not have had > the problem in the first place. I don't see this as a Release Notes issue - though I guess it will be if it cannot be quickly fixed before 11.0-RELEASE - but as a very serious and - as far as I know - unreported regression in ipfw(8). In 18 years I cannot recall any addition of features, or additional options for existing features, that caused any breakage of existing rulesets. What on earth could be invalid about "table 1 flush"? cc'ing ipfw@, which is most likely where this should be discussed .. cheers, Ian From owner-freebsd-ipfw@freebsd.org Mon Aug 1 11:16:24 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 4C3FDBABE5E for ; Mon, 1 Aug 2016 11:16:24 +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::3]) (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 B140B1585; Mon, 1 Aug 2016 11:16:23 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470050181; l=6869; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=UqW1JgKy3v6BRCYwxjCxZ77eWMxYz+sNwcvnQSe1MTA=; b=WwGbjhx3mV7+DgAbB7SFa3e9MswnMeGPWMoz/UYC4Ep7CyZZpwV/AA8uPtvhRwYFGc0 Zm70cLv2B+qj7QgNjqwLT3ji/88crFofJJ8wXWJmJ+reXJIcL3+DNfjL1m4UMrqwnIM9B Uk6Lw+lc4LjloePQ6Y9+iucGyM1B/HQe98c= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU2B+3KSGnPFnG2JO1U7V8= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bfb6c829.virtua.com.br [191.182.200.41]) by smtp.strato.de (RZmta 38.13 DYNA|AUTH) with ESMTPSA id K0ba00s71BGJFgu (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); Mon, 1 Aug 2016 13:16:19 +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 A660C229861E; Mon, 1 Aug 2016 08:16:15 -0300 (BRT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ipfw divert filter for IPv4 geo-blocking From: "Dr. Rolf Jansen" In-Reply-To: <3eedb126-ac78-ddad-27d3-132c742b2fdb@freebsd.org> Date: Mon, 1 Aug 2016 08:16:14 -0300 Cc: Julian Elischer Content-Transfer-Encoding: quoted-printable Message-Id: References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> <3eedb126-ac78-ddad-27d3-132c742b2fdb@freebsd.org> To: freebsd-ipfw@freebsd.org 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: Mon, 01 Aug 2016 11:16:24 -0000 > Am 01.08.2016 um 03:17 schrieb Julian Elischer : > On 30/07/2016 10:17 PM, Dr. Rolf Jansen wrote: >> I finished the work on CIDR conformity of the IP ranges tables = generated by the tool geoip. The main constraint is that the start and = end address of an IP block given by the delegation files MUST BE = PRESERVED during the transformation to a set of CIDR records. This = target is achieved by: >>=20 >> 1. Finding the largest common netmask boundary of the start address = utilizing >> int(log2(addr_count)); then iteration like Euclid's algorithm in = computing >> a GCD. >>=20 >> 2. Output the CIDR with the given start address and the masklen = belonging >> to the found netmask. >>=20 >> 3. If the CIDR does not match the whole original IP range then set = the start >> address of the next CIDR block to the next boundary of the common = netmask, >> and loop over starting at 1. until the original range has been = satisfied. >>=20 > check out the appletalk code I pointed out to you.. I wrote that in = 93 or so but I remember sweating blood > over it to get it right. I read the description of the code and the following sentence made me = suspicious that aa_dorangeroute() would guarantee the above mentioned = main constraint "start and end address of an IP block given by the = delegation files MUST BE PRESERVED" can be matched. Start/end address = are said to be anything (even undefined) but fixed in the description. ...=20 Split the range into two subranges such that the middle of the two ranges is the point where the highest bit of difference between the two addresses makes its transition. ... I do not want this. >> I carefully tested the algorithm and a table that I pipe by the new = geoip tool into ipfw is 100 % identical to the output of the ipfw = command 'table N list'. > though that doesn't mean it is semantically identical to the original = table due to 'most specific rule wins" behaviour. >=20 > for example: > if you type in ; >=20 > 1.2.3.0/24 -> A > and > 1.2.3.0/26 -> B > then both rules will be listed the same as what you put in > but if you wanted to get all rules that point to A, without having = rules that point to B, then you would have to export > 1.2.3.64/26 -> A > 1.2.3.128/25 -> A > (i.e. TWO rules) This is definitely not the usage case. The origin of the data to be = passed to ipfw tables are RIR delegation statistics files, which is = guaranteed to be consolidated, namely resolved overlaps and joined = adjacencies, long before any tables for ipfw are generated. Each range = entry got a well defined, i.e. fixed, i.e non-variable starting address, = and anything that changes the starting address of the ranges renders the = table useless. Every entry got a well defined range length, and that one = also must not be changed, or the table would be useless as well. In addition, we are talking about automatic generation of thousands of = entries, and I never ever won't rely on something like 'most specific = rule wins' behaviour, I want the behaviour as explicit as possible, and = for this reason I am happy with 'INPUT is 100 % identical to the = OUTPUT'. > you could also export > 1.2.3.0/24 -> A > 1.2.3.0/26 -> 0 (think of it as an "EXCEPT for these" rule) >=20 > which is ALSO two rules but you would need to be sure that the = receiver knows what to do with them. This is simply a ridiculous example in the given respect, this sounds = like you are suggesting fuzzying the input data in order to bring ipfw = to its limits. This makes life less boring, doesn't it? No thanks. >> It is worth to note, that already the original RIR delegation files = contain 457 non CIDR conforming IPv4 ranges in a total of 165815 = original records. I guess that this number will increase in the future = because the RIR's ran empty on new IPv4 ranges and are urged to = subdivide returned old ranges for new delegations. The above algorithm = is ready for this. >>=20 >> Generally, CIDR conforming tables are more than twice as large as = optimized (joined adjacencies) IP range tables. All said changes have = been pushed to GitHup already. >>=20 > Unfortunately there is no way to specify (using cidr notation) a.b.1.x = AND a.b.2.x without including a.b.[03].x. >=20 > HOWEVER > if you specified the FULL table you could use the "except" feature of = routing table behaviour where > a.b.0.x/22 -> A > a.b.0.x/24 -> B > a.b.3.x/24 -> B > gives you the same thing because of the 'most specific rule wins" = nature of routing table evaluation. > I believe this is the case in the tables you imported. > the trick is to be able to take an "optimised" table such as that = above and produce, given a required subset, just the required part, = while changing the rules as needed on the fly to "de-optimise" them = enough to maintain correctness. Again, this is not the usage case. >> I am still a little bit amazed how ipfw come to accept incorrect CIDR = ranges and arbitrarily moves the start/end addresses in order to achieve = CIDR conformity, and that without any further notice, and that given = that ipfw can be considered as being quite relevant to system security. = Or, may I assume that ipfw knows always better than the user what should = be allowed or denied. Otherwise, perhaps I am the only one ever who = input incorrect CIDR ranges for processing by ipfw. >=20 > I answered this before but can't see the answer in my out box, plus I = have added info.. >=20 > The ipfw code is derived from the routing code. it is shorthand = notation for a.b.c.d [netmask e.f.g.h ] > there is nothing that says that a.b.c.d need be the first address in = the range. (though some vendors may require that.) > to quote wikipedia on the topic (yes, I know, not an authoritative = source) >=20 > =3D=3D=3D=3D quote =3D=3D=3D=3D > The address may denote a single, distinct interface address or the = beginning address of an entire network. The maximum size of the network = is given by the number of addresses that are possible with the = remaining, least-significant bits below the prefix. The aggregation of = these bits is often called the host identifier. >=20 > For example: >=20 > =95 192.168.100.14/24 represents the IPv4 address 192.168.100.14 = and its associated routing prefix 192.168.100.0, or equivalently, its = subnet mask 255.255.255.0, which has 24 leading 1-bits. > I use this all the time when parsing information that contains a = hostname, and I know the netmask width. It saves me from having to have = complicated shell code to pull apart the address and zero out the host = bits of the address. I got it, anyway this is not an issue anymore for the new geoip table = generation. Best regards Rolf From owner-freebsd-ipfw@freebsd.org Mon Aug 1 15:00:53 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 9DDACBAAC16 for ; Mon, 1 Aug 2016 15:00:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DDE61282 for ; Mon, 1 Aug 2016 15:00:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u71F0kuF004137 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Aug 2016 08:00:49 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: "Dr. Rolf Jansen" , freebsd-ipfw@freebsd.org References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> <3eedb126-ac78-ddad-27d3-132c742b2fdb@freebsd.org> From: Julian Elischer Message-ID: <7ca15b3c-e0af-2759-6d43-96ecc9990d2b@freebsd.org> Date: Mon, 1 Aug 2016 23:00:40 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Mon, 01 Aug 2016 15:00:53 -0000 On 1/08/2016 7:16 PM, Dr. Rolf Jansen wrote: >> Am 01.08.2016 um 03:17 schrieb Julian Elischer : >> On 30/07/2016 10:17 PM, Dr. Rolf Jansen wrote: >>> I finished the work on CIDR conformity of the IP ranges tables generated by the tool geoip. The main constraint is that the start and end address of an IP block given by the delegation files MUST BE PRESERVED during the transformation to a set of CIDR records. This target is achieved by: >>> >>> 1. Finding the largest common netmask boundary of the start address utilizing >>> int(log2(addr_count)); then iteration like Euclid's algorithm in computing >>> a GCD. >>> >>> 2. Output the CIDR with the given start address and the masklen belonging >>> to the found netmask. >>> >>> 3. If the CIDR does not match the whole original IP range then set the start >>> address of the next CIDR block to the next boundary of the common netmask, >>> and loop over starting at 1. until the original range has been satisfied. >>> >> check out the appletalk code I pointed out to you.. I wrote that in 93 or so but I remember sweating blood >> over it to get it right. > I read the description of the code and the following sentence made me suspicious that aa_dorangeroute() would guarantee the above mentioned main constraint "start and end address of an IP block given by the delegation files MUST BE PRESERVED" can be matched. Start/end address are said to be anything (even undefined) but fixed in the description So you get your data as ranges (i.e. a start and an end address) > > ... > Split the range into two subranges such that the middle > of the two ranges is the point where the highest bit of difference > between the two addresses makes its transition. > ... > > I do not want this. I think I may explain it better by example.. Any range of addresses can conceptually be broken into an optimal range of binary chunks. for example, for the range 1..... 62 we have an optimal set of binary subranges: 1-1 2-3 4-7 8-15 16-31 (*) 32-47 48-55 56-59 60-61 and 62-62 there is always a point (*) where we separate the left hand side from the right hand side. You can also only merge the two items either side of the (*) point, and even then, only if they have the same width. Ranges not immediately adjacent to the (*) point can never be merged into any other range. In some ranges, there are no items to the right, and for some ranges there are no items to the left. There may also be skipped ranges. The above example is "worst case". All 10 subranges are present, and only 2 can be merged, leading to needing 9 binary subranges to correctly express the whole range. So the term "middle" is misleading. It however allows you to take an arbitrary range of addresses and generate the optimal set of cidr addresses. In this case if you had 10.0.1.0 through 10.0.62.255 you would need 9 cidr addresses to express the range correctly (the middle two can be joined). That is what the code referred to does. if you have exceptions as you do in routing tables, you can express it as 3 cidr addresses.. 0-64 MINUS 0 and MINUS 63. i.e 10.0.0.0/18 minus 10.0.0.0/24 minus 10.0.63.0/24. However this is probably not of interest to your use case. It however IS possible to do this in ipfw since it allows overlapping ranges of different widths. (you will note that the code pointed to does NOT do that. it would be an order of magnitude (or more) harder to do.) > >>> I carefully tested the algorithm and a table that I pipe by the new geoip tool into ipfw is 100 % identical to the output of the ipfw command 'table N list'. >> though that doesn't mean it is semantically identical to the original table due to 'most specific rule wins" behaviour. >> >> for example: >> if you type in ; >> >> 1.2.3.0/24 -> A >> and >> 1.2.3.0/26 -> B >> then both rules will be listed the same as what you put in >> but if you wanted to get all rules that point to A, without having rules that point to B, then you would have to export >> 1.2.3.64/26 -> A >> 1.2.3.128/25 -> A >> (i.e. TWO rules) > This is definitely not the usage case. The origin of the data to be passed to ipfw tables are RIR delegation statistics files, which is guaranteed to be consolidated, namely resolved overlaps and joined adjacencies, long before any tables for ipfw are generated. Each range entry got a well defined, i.e. fixed, i.e non-variable starting address, and anything that changes the starting address of the ranges renders the table useless. Every entry got a well defined range length, and that one also must not be changed, or the table would be useless as well. I think you are misunderstanding what I meant. > > In addition, we are talking about automatic generation of thousands of entries, and I never ever won't rely on something like 'most specific rule wins' behaviour, I want the behaviour as explicit as possible, and for this reason I am happy with 'INPUT is 100 % identical to the OUTPUT'. I agree. I was saying that getting the same rules out of ipfw as you put INTO ipfw does not guarantee that you have correctly converted the ranges given in the RIR databases into accurate CIDR ranges. It just means you have correctly normalised the data you are putting into the firewall table. > >> you could also export >> 1.2.3.0/24 -> A >> 1.2.3.0/26 -> 0 (think of it as an "EXCEPT for these" rule) >> >> which is ALSO two rules but you would need to be sure that the receiver knows what to do with them. > This is simply a ridiculous example in the given respect, this sounds like you are suggesting fuzzying the input data in order to bring ipfw to its limits. This makes life less boring, doesn't it? No thanks. noooooo I'm saying that in a different use case data can be (and sometimes is) given assuming that exceptions work. But that such use cases must always have the entire database to work from and you can not extract smaller parts of it without risking leaving out one of the exception clauses. (unless you specifically code for that). (I've been doing this for 30 years, you can assume I'm not taking about monte-carlo routing .. life is interesting enough thank you.. :-) > >>> It is worth to note, that already the original RIR delegation files contain 457 non CIDR conforming IPv4 ranges in a total of 165815 original records. I guess that this number will increase in the future because the RIR's ran empty on new IPv4 ranges and are urged to subdivide returned old ranges for new delegations. The above algorithm is ready for this. >>> >>> Generally, CIDR conforming tables are more than twice as large as optimized (joined adjacencies) IP range tables. All said changes have been pushed to GitHup already. >>> >> Unfortunately there is no way to specify (using cidr notation) a.b.1.x AND a.b.2.x without including a.b.[03].x. >> >> HOWEVER >> if you specified the FULL table you could use the "except" feature of routing table behaviour where >> a.b.0.x/22 -> A >> a.b.0.x/24 -> B >> a.b.3.x/24 -> B >> gives you the same thing because of the 'most specific rule wins" nature of routing table evaluation. >> I believe this is the case in the tables you imported. >> the trick is to be able to take an "optimised" table such as that above and produce, given a required subset, just the required part, while changing the rules as needed on the fly to "de-optimise" them enough to maintain correctness. > Again, this is not the usage case. that is pretty much the case that you showed with Argentina and Brazil. four /20 regions, where the last three were aggregated.. Did they come to you already joined together, or did you join them on receipt? in what form do you get and keep the data? you showed: $ geoip 201.222.20.1 --> 201.222.20.1 in 201.222.20.0-201.222.31.255 in BR $ geoip 201.222.16.1 --> 201.222.16.1 in 201.222.16.0-201.222.19.255 in AR do you keep it internally as a cidr address? or as a range? > >>> I am still a little bit amazed how ipfw come to accept incorrect CIDR ranges and arbitrarily moves the start/end addresses in order to achieve CIDR conformity, and that without any further notice, and that given that ipfw can be considered as being quite relevant to system security. Or, may I assume that ipfw knows always better than the user what should be allowed or denied. Otherwise, perhaps I am the only one ever who input incorrect CIDR ranges for processing by ipfw. >> I answered this before but can't see the answer in my out box, plus I have added info.. >> >> The ipfw code is derived from the routing code. it is shorthand notation for a.b.c.d [netmask e.f.g.h ] >> there is nothing that says that a.b.c.d need be the first address in the range. (though some vendors may require that.) >> to quote wikipedia on the topic (yes, I know, not an authoritative source) >> >> ==== quote ==== >> The address may denote a single, distinct interface address or the beginning address of an entire network. The maximum size of the network is given by the number of addresses that are possible with the remaining, least-significant bits below the prefix. The aggregation of these bits is often called the host identifier. >> >> For example: >> >> • 192.168.100.14/24 represents the IPv4 address 192.168.100.14 and its associated routing prefix 192.168.100.0, or equivalently, its subnet mask 255.255.255.0, which has 24 leading 1-bits. >> I use this all the time when parsing information that contains a hostname, and I know the netmask width. It saves me from having to have complicated shell code to pull apart the address and zero out the host bits of the address. > I got it, anyway this is not an issue anymore for the new geoip table generation. > > Best regards > > Rolf > > > From owner-freebsd-ipfw@freebsd.org Mon Aug 1 15:43:29 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 7B5EBBAB66D; Mon, 1 Aug 2016 15:43:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 034F71CDF; Mon, 1 Aug 2016 15:43:28 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u71FhMKT053932; Tue, 2 Aug 2016 01:43:22 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 2 Aug 2016 01:43:22 +1000 (EST) From: Ian Smith To: "Andrey V. Elsukov" cc: Kevin Oberman , freebsd-ipfw@freebsd.org, FreeBSD-STABLE Mailing List Subject: Re: Significant missing item in 11.0 release notes In-Reply-To: <3b44dbc7-95c9-b529-c1a4-47a4af0774cf@yandex.ru> Message-ID: <20160802012633.X29054@sola.nimnet.asn.au> References: <3b44dbc7-95c9-b529-c1a4-47a4af0774cf@yandex.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20160802012633.R29054@sola.nimnet.asn.au> 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: Mon, 01 Aug 2016 15:43:29 -0000 On Mon, 1 Aug 2016 16:39:45 +0300, Andrey V. Elsukov wrote: > On 31.07.16 22:28, Kevin Oberman wrote: > > I assumed that I had missed this in the release notes, but I can find no > > reference to this significant change that simultaneously greatly enhanced > > ipfw table functionality, but also broke my configuration. While the fix > > was trivial, if the Release Notes had addressed this, I would not have had > > the problem in the first place. > > I fixed this in r303615. Thanks for the report! Fast work Andrey, and sorry for rushing in. I ASSumed, after reading the new tables section in 11.0-R ipfw(8), that Kevin had run into: Tables require explicit creation via create before use. but diving - not too deeply - into the log of /head/sbin/ipfw/tables.c from your commit, I think that statement must be out of date, at least regarding existing ruleset table configuration? Is that right? cheers, Ian From owner-freebsd-ipfw@freebsd.org Mon Aug 1 15:49:22 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 775BCBAB85C; Mon, 1 Aug 2016 15:49:22 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4h.cmail.yandex.net (forward4h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01A8E1F86; Mon, 1 Aug 2016 15:49:21 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [IPv6:2a02:6b8:0:f05::115]) by forward4h.cmail.yandex.net (Yandex) with ESMTP id C5DEA206D2; Mon, 1 Aug 2016 18:49:18 +0300 (MSK) Received: from smtp1h.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id C3C378C0A04; Mon, 1 Aug 2016 18:49:18 +0300 (MSK) Received: by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id bGmwOvgOvn-nIJejALm; Mon, 01 Aug 2016 18:49:18 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1470066558; bh=kxPTHc0ECOSCNx7We9Qi5d5TUZdf/3gdFgPLO7aERRk=; h=Subject:To:References:Cc:From:Message-ID:Date:In-Reply-To; b=U9Y/YglLYDHhzL1G/K9D+0miPspei0qva91X7CHQl9QDrAGpfy/jIKIEGJRpLYW/2 0EGTD5MXREqS+uLRFZSt71LNGCU3mb8zYFaMlDBvq7sr+tG4kME+ElsvQBxUc+1FIp SdrDK0DkpfQ7sjlsS2wBzVLo94TyzsnLw2xP8oM8= Authentication-Results: smtp1h.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0,1 0 Subject: Re: Significant missing item in 11.0 release notes To: Ian Smith References: <3b44dbc7-95c9-b529-c1a4-47a4af0774cf@yandex.ru> <20160802012633.X29054@sola.nimnet.asn.au> Cc: Kevin Oberman , freebsd-ipfw@freebsd.org, FreeBSD-STABLE Mailing List From: "Andrey V. Elsukov" Message-ID: <921fa5a6-5cbf-a7d4-3306-090d16195491@yandex.ru> Date: Mon, 1 Aug 2016 18:47:37 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160802012633.X29054@sola.nimnet.asn.au> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xtG06LUTl0DcTBHGdpxCVKdklsSd091Ll" 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: Mon, 01 Aug 2016 15:49:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xtG06LUTl0DcTBHGdpxCVKdklsSd091Ll Content-Type: multipart/mixed; boundary="CEoSfN4NXWeaXeQFGVdO2SFd6x51Aoju5" From: "Andrey V. Elsukov" To: Ian Smith Cc: Kevin Oberman , freebsd-ipfw@freebsd.org, FreeBSD-STABLE Mailing List Message-ID: <921fa5a6-5cbf-a7d4-3306-090d16195491@yandex.ru> Subject: Re: Significant missing item in 11.0 release notes References: <3b44dbc7-95c9-b529-c1a4-47a4af0774cf@yandex.ru> <20160802012633.X29054@sola.nimnet.asn.au> In-Reply-To: <20160802012633.X29054@sola.nimnet.asn.au> --CEoSfN4NXWeaXeQFGVdO2SFd6x51Aoju5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01.08.16 18:43, Ian Smith wrote: > Fast work Andrey, and sorry for rushing in. I ASSumed, after reading=20 > the new tables section in 11.0-R ipfw(8), that Kevin had run into: >=20 > Tables require explicit creation via create before use. >=20 > but diving - not too deeply - into the log of /head/sbin/ipfw/tables.c = > from your commit, I think that statement must be out of date, at least = > regarding existing ruleset table configuration? Is that right? If you want to use some new specific feature you need to create table explicitly. But for old rules generic tables will be created automatically (with warning). --=20 WBR, Andrey V. Elsukov --CEoSfN4NXWeaXeQFGVdO2SFd6x51Aoju5-- --xtG06LUTl0DcTBHGdpxCVKdklsSd091Ll Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEvBAEBCAAZBQJXn28ZEhxidTdjaGVyQHlhbmRleC5ydQAKCRABxeoEEMiheucr CACXoYNSshvFGncrPuAEw3p52h5LuGhj7spOmrTIhmCnXnXmXsvvAIoqDbNDINzu NvsplJ7pL6ECRUc+9IyZs1ZFVY+BRkZPkCWsCd4ZD6EwOldmsYWHCcB/g/Dq6jqO 6zM5uVxu2/9LGT9qb+dYwOEDxDw4LrCH0vNFxRqWdSf1j3NnpQ8g+6iDFP91edNG 3SiYjVvMVF/HpuqH8RqBp+fY6M+AQnMJlCQc0La/SKcUGD9vS5sqrMYhps9s+0zn diAfa1gqfCcZhmziDJgEhv0fbzHTDUtEl2QFX1IKZyjpyCVYUWL/ppxh+gKzqOZ8 /aiaogGbY3z0amXdQIj5iRzn =2nFh -----END PGP SIGNATURE----- --xtG06LUTl0DcTBHGdpxCVKdklsSd091Ll-- From owner-freebsd-ipfw@freebsd.org Mon Aug 1 17:03:02 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 73926BAB348; Mon, 1 Aug 2016 17:03:02 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F08B8114C; Mon, 1 Aug 2016 17:03:01 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u71H2uGV056832; Tue, 2 Aug 2016 03:02:57 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 2 Aug 2016 03:02:56 +1000 (EST) From: Ian Smith To: "Andrey V. Elsukov" cc: Kevin Oberman , freebsd-ipfw@freebsd.org, FreeBSD-STABLE Mailing List Subject: Re: Significant missing item in 11.0 release notes In-Reply-To: <921fa5a6-5cbf-a7d4-3306-090d16195491@yandex.ru> Message-ID: <20160802023424.W29054@sola.nimnet.asn.au> References: <3b44dbc7-95c9-b529-c1a4-47a4af0774cf@yandex.ru> <20160802012633.X29054@sola.nimnet.asn.au> <921fa5a6-5cbf-a7d4-3306-090d16195491@yandex.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 01 Aug 2016 17:03:02 -0000 On Mon, 1 Aug 2016 18:47:37 +0300, Andrey V. Elsukov wrote: > On 01.08.16 18:43, Ian Smith wrote: > > Fast work Andrey, and sorry for rushing in. I ASSumed, after reading > > the new tables section in 11.0-R ipfw(8), that Kevin had run into: > > > > Tables require explicit creation via create before use. > > > > but diving - not too deeply - into the log of /head/sbin/ipfw/tables.c > > from your commit, I think that statement must be out of date, at least > > regarding existing ruleset table configuration? Is that right? > > If you want to use some new specific feature you need to create table > explicitly. But for old rules generic tables will be created > automatically (with warning). Exactly how I was hoped it would work, thankyou .. cheers, Ian From owner-freebsd-ipfw@freebsd.org Mon Aug 1 22:35:32 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 6FB1CBAC4DC; Mon, 1 Aug 2016 22:35:32 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 29D19158B; Mon, 1 Aug 2016 22:35:32 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-io0-x231.google.com with SMTP id q83so197091406iod.1; Mon, 01 Aug 2016 15:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XK3xBINndwR4YSNbEAa0zxG1M6LWB4WEa3wh+bSXYNA=; b=dEJOLffqIDWooPDlOCE6fsZ62GPmJNqjEGFTY7rwqngB+SG0lLUJC1w+CGA650ioBE MG+kTvswshtNC/rTCe5VAQmQh6enIUHSNM3xNjvVR0i+ALwVzJLCWkd9myQQ2ma2MNkG Q5kUJsZ9oeGokVL1MNwWSdwTuS/dOuRT/XQhY3ec6Z6aSDmeJbBAmkZo0Ke5wKF7AD+z oDKVP02xr/5ER58XkWUEqplEXUoSnIewkdrZboxLHizss2VbZZ1kccLf7CVml+4Dm7PU dfHTEw+jKGIpoHjzB37R6xE3Ks904SfjZR0eDWN9hl8zotYldZEdHOMSUSDi8nOHx3CK y4sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XK3xBINndwR4YSNbEAa0zxG1M6LWB4WEa3wh+bSXYNA=; b=JaO1JP9bB2qbqIXLiRruOmV5Su6JW4ZLoK5ZYHY8gGesV1UhgWgKqQwYHxcHM5StGg XiK1FDvQB0ixhlgLBaJiuksEeW1VucO+ceT6nPi29H2VU43In36edMKpFf/8XAnXU/B2 NfKsAtOvMjZLtNGuVKTwEo2nuhknuM61gbf8/InFIOZlBJgBPeLheKSA9GWI54wyKf+S Bt0y6FNCy/8N3wYlzUdIZ1iuZh1hPcx+J7CLt+/cSe5Yp4pG3dKsYoUlgy86QI+Ln6Jd H1Z3b00V7217ueMQqxam9BjXQ3lw8lfBNgFllH1LWFfN8btUsVlhnAgA3jv6MbdW3qm2 TNgA== X-Gm-Message-State: AEkoouuZnzo3SDUooZiC98rvE6FJjJs3Uq4NwZ0/ou8oeV7HQUNsNhtm5WIEgt8dg5r+dLjCpWcemo9g+uqGrw== X-Received: by 10.107.129.152 with SMTP id l24mr58503815ioi.179.1470090931591; Mon, 01 Aug 2016 15:35:31 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.79.119.144 with HTTP; Mon, 1 Aug 2016 15:35:31 -0700 (PDT) In-Reply-To: <20160802023424.W29054@sola.nimnet.asn.au> References: <3b44dbc7-95c9-b529-c1a4-47a4af0774cf@yandex.ru> <20160802012633.X29054@sola.nimnet.asn.au> <921fa5a6-5cbf-a7d4-3306-090d16195491@yandex.ru> <20160802023424.W29054@sola.nimnet.asn.au> From: Kevin Oberman Date: Mon, 1 Aug 2016 15:35:31 -0700 X-Google-Sender-Auth: wBOCoTi-BPdBca9WscNvVqnkWjM Message-ID: Subject: Re: Significant missing item in 11.0 release notes To: Ian Smith Cc: "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 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: Mon, 01 Aug 2016 22:35:32 -0000 Thanks for the quick fix, Andrey! Now that this is taken care of, time to start playing with the cool new features... especially naming tables. Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Mon, Aug 1, 2016 at 10:02 AM, Ian Smith wrote: > On Mon, 1 Aug 2016 18:47:37 +0300, Andrey V. Elsukov wrote: > > On 01.08.16 18:43, Ian Smith wrote: > > > Fast work Andrey, and sorry for rushing in. I ASSumed, after reading > > > the new tables section in 11.0-R ipfw(8), that Kevin had run into: > > > > > > Tables require explicit creation via create before use. > > > > > > but diving - not too deeply - into the log of /head/sbin/ipfw/tables.c > > > from your commit, I think that statement must be out of date, at least > > > regarding existing ruleset table configuration? Is that right? > > > > If you want to use some new specific feature you need to create table > > explicitly. But for old rules generic tables will be created > > automatically (with warning). > > Exactly how I was hoped it would work, thankyou .. > > cheers, Ian > From owner-freebsd-ipfw@freebsd.org Tue Aug 2 06:47:38 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 B2DD6BAA9BF for ; Tue, 2 Aug 2016 06:47:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 980721E00; Tue, 2 Aug 2016 06:47:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u726lUc7034552 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Aug 2016 23:47:33 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> Cc: "Andrey V. Elsukov" , lev@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: Julian Elischer Message-ID: <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> Date: Tue, 2 Aug 2016 14:47:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 02 Aug 2016 06:47:38 -0000 Do we have any movement on these improvements? even similar functionality by different names is ok. 1/ ability to use keep-state without an implicit check-state. <--- most important for me. (store-state)? 2/ ability to keep-state without actually doing it <---- less important for me. 3/ multiple state tables? this was discussed and I thought I saw patches but I haven't seen it going in, <-- super luxurious On 20/06/2016 9:59 PM, Julian Elischer wrote: > On 16/06/2016 12:11 AM, Ian Smith wrote: >> On Mon, 13 Jun 2016 23:18:24 +0800, Julian Elischer wrote: >> > On 10/06/2016 5:11 AM, Lev Serebryakov wrote: >> > > -----BEGIN PGP SIGNED MESSAGE----- >> > > Hash: SHA512 >> > > >> > > On 07.06.2016 00:53, Andrey V. Elsukov wrote: >> > > >> > > > looking at provided description and examples, seems the >> main task >> > > > you want to solve is problem with NAT. But from my point of >> view, >> > > > you are trying to solve it in a easy way wrongly using >> existing >> > > > methods. >> > > It is was initial driver for this patch, yes, but, please, >> read >> > > subject (? is mistype, of course, it is closing "). >> > > >> > > Current set of primitives, dealing with state, is terribly >> wrong, >> > > IMHO. "keep-state" which trigger (any!) state check alone is >> awuful, >> > > and complete "keep-state / check-state" pair is ugly hack. It >> is like >> > > CISC vs RISC, actually. >> > > >> > > New primitives are ORTHOGONAL. Each one solves one and >> only one >> > > well-defined task, state creation, state checking and command >> > > execution are well-separated. IMHO, "keep-state" in it >> current form >> > > should be killed with fire. Yes, I understand about backward >> > > compatibility and POLA, so I don't propose to really remove >> it, but, >> > > IMHO, new set is much, much better. >> >> Lev, is there any chance you and Andrey can work together here? At the >> moment we seem to have two 'competing' models. Can they be melded at >> all? Or can you live with adding new opcodes on top of Andrey's named >> states? (Feel free to tell me that this is none of my business ..) > yes, please.. >> > In writing complicated automatically generated firewalls, >> > I've wanted the following capacities: >> > 1/ one state table for one part of the flow and another for a >> different >> > part... e.g. a different table for "inside" nat to "outside" >> nat.. >> >> Isn't one table with distinct flow-or-whatever names for matching not >> sufficient for this purpose? Wouldn't that also be faster than having >> to consult multiple distinct tables? > if you name table entries then you effectively have different > tables, but yes I was mistaken in how it was being done. > I had assumed a separate table >> >> In the end those are details the user doesn't need to know about .. >> but >> ze does need to comprehend the terms conveying the ideas. >> >> > also a different table for the inside interface to the outside >> interface.. >> > just because you allow a flow at one interface doesn't mean you >> want it to be >> > allowed through a different one. >> >> Sure, so couldn't you have, say, 'inbound_outside', 'inbound_inside', >> 'outbound_outside' and 'outbound_inside', 'from_dmz' or whatever to >> distinguish multiple flows? >> >> Why doesn't 'flowname' sound right to describe what you call 'flows'? > multiple flows can end up in the same table/name > a flow to me is some set of packets that relate to each other in > source, > destination and sequence. you could almost say that each pair of > sockets defines a flow. > Others probably have different definitions.. One could even say that > in the context of > ipfw, any set of packets that can be discriminated by a set of rules > can be a flow. >> >> > 2/ The ability to specifically add a flow's state rule to a >> table, without >> > EVERY OTHER FLOW hitting a 'check-state' at that point. If I >> select s >> > particular flow , then I do not want other flows affected. just >> that flow >> > should be affected. >> >> Isn't that the case with Andrey's code at the moment, if you specify a >> name on that keep-state rule, only that - erm - flow would be checked >> and not other flows (including 'default' where added by unnamed >> rules)? > no. but it is the case with Lev's patch (and Andrey's matching effort) >> >> Can I assume that if this is the first keep-state|limit for one >> flowname >> then an implicit check-state would check that flow only, finding none? > I don't know. currently the selector part of the rule doesn't > distinguish who does a check-state. > I'm guessing he finds the label and uses it but I don't know. > >> >> Similarly, if I'm grokking this at all right, then only a check-state >> (or another keep-state or limit encountered) with that same name will >> match existing states having that same name? Issue 2/ solved or not? > > Issue 2 is mostly solved for many cases. >> >> I hope you can see my concern that this be easily described in ipfw(8) >> so people without high level of expertise can easily see how it works. >> >> I'll have some more suggestions re description along the way, but >> after >> seeing clear agreement that the proposed model/s cover the usage cases >> described (somewhat), and where not, what more needs doing to make it >> acceptable as a next step, if not entirely ideal for every case .. >> >> To that end, I'll leave wishes 3/ and 4/ well alone .. as usual, FWIW >> >> cheers, Ian >> >> > 3/ the ability to select a completley different firewall for a >> differnent >> > interface.. this can be simulated at the moment. but it'd be >> nice to be able >> > to specify a entry pont into the table or a separate table per >> interface.. >> > ipfw interface xn0 in enter 5000 or something. >> > or maybe ipfw interface firewall 3 >> > 4/ the ability to have variables and set and test them. We >> ALMOST have that >> > with tags . >> > i] variables would hav eone of several scopes: >> > a) a single transit.. you might set some flag at rule 40 and >> branch on it >> > at rule 4000, but a separate packet would ahv ea different >> instance. >> > b) per flow.. assigned at creation of the dynamic rule and >> avaliable at >> > any time after a packet has been associated with that flow. >> > c) global >> > ii] branching on values is possible. >> > there are others I've wanted (and forgotten) but that's the >> wish-list I have >> > at the moment. >> _______________________________________________ >> 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" >> > > _______________________________________________ > 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" > From owner-freebsd-ipfw@freebsd.org Tue Aug 2 08:08: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 ACB49BACD26 for ; Tue, 2 Aug 2016 08:08:17 +0000 (UTC) (envelope-from julian@freebsd.org) 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 9A1A3113D for ; Tue, 2 Aug 2016 08:08:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 99639BACD25; Tue, 2 Aug 2016 08:08: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 99113BACD24 for ; Tue, 2 Aug 2016 08:08:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 79C04113C for ; Tue, 2 Aug 2016 08:08:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u7288CLM088871 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 2 Aug 2016 01:08:15 -0700 (PDT) (envelope-from julian@freebsd.org) To: ipfw mailing list From: Julian Elischer Subject: your thoughts on a particualar ipfw action. Message-ID: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> Date: Tue, 2 Aug 2016 16:08:06 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 02 Aug 2016 08:08:17 -0000 looking for thoughts from people who know the new IPFW features well.. 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?). Another way would be to just put 'action numbers' in the tablearg field and have a few actions, shared by countries, but the trouble comes when you want to change the action for a country, you need to rewrite potentially thousands of entries (USA has over 15800 allocations). A second way woudl be to somehow map the tablearg of the country, into a table of actions. effectively doing two levels of lookup. The first table converting IP addresses to a country number and a second lookup converting that to an action. the only trouble is that I don't know of a way to do that. If the new changes allow that, and anyone knows how, please let me know :-). From owner-freebsd-ipfw@freebsd.org Tue Aug 2 12:37:45 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 562ABBACFFD for ; Tue, 2 Aug 2016 12:37:45 +0000 (UTC) (envelope-from bu7cher@yandex.ru) 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 34F181E58 for ; Tue, 2 Aug 2016 12:37:45 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 34616BACFFC; Tue, 2 Aug 2016 12:37:45 +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 340FEBACFFB for ; Tue, 2 Aug 2016 12:37:45 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5j.cmail.yandex.net (forward5j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD09F1E57; Tue, 2 Aug 2016 12:37:44 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::26]) by forward5j.cmail.yandex.net (Yandex) with ESMTP id F252220CA4; Tue, 2 Aug 2016 15:37:40 +0300 (MSK) Received: from smtp2o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp2o.mail.yandex.net (Yandex) with ESMTP id EB48D5080C22; Tue, 2 Aug 2016 15:37:40 +0300 (MSK) Received: by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id mKNHdnuU7R-beG4haG7; Tue, 02 Aug 2016 15:37:40 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1470141460; bh=wePHwjzuiDjy3J1ixoVNuNoxYwp8IgQfIy5gM4pIoNo=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=uYCWJwBA6JsMOpwnXMhU9ts5wJxATDS6q6JDsjx1w+IAx/mfAzfHiKsiEOO5tJJvj CzsdWBTrYRwceJku8jEiloTOw8q3M9oQKczXCjULu0MeaY0uLhtVCMmUeU2wgMLAka Xxvl0Cpnt1XJ09HYWkIQG13BmJJCRUBW7BCTOTjQ= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: your thoughts on a particualar ipfw action. To: Julian Elischer , ipfw mailing list References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> From: "Andrey V. Elsukov" Message-ID: <8e3d54b1-2315-decb-158a-bf06443cdb04@yandex.ru> Date: Tue, 2 Aug 2016 15:36:01 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fJlKg99VUlmfiJG6POrui4wTdsIEXK7SI" 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: Tue, 02 Aug 2016 12:37:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fJlKg99VUlmfiJG6POrui4wTdsIEXK7SI Content-Type: multipart/mixed; boundary="VEbSdbsp9kDP50xOmfe9ewcLoUlVlDE2v" From: "Andrey V. Elsukov" To: Julian Elischer , ipfw mailing list Message-ID: <8e3d54b1-2315-decb-158a-bf06443cdb04@yandex.ru> Subject: Re: your thoughts on a particualar ipfw action. References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> In-Reply-To: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> --VEbSdbsp9kDP50xOmfe9ewcLoUlVlDE2v Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02.08.16 11:08, Julian Elischer wrote: > 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?). You can build ipfw with enabled LINEAR_SKIPTO and use the same rules for most countries. --=20 WBR, Andrey V. Elsukov --VEbSdbsp9kDP50xOmfe9ewcLoUlVlDE2v-- --fJlKg99VUlmfiJG6POrui4wTdsIEXK7SI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEvBAEBCAAZBQJXoJOxEhxidTdjaGVyQHlhbmRleC5ydQAKCRABxeoEEMiheizZ B/4nttVFWHcrZOJkCCdwGpYe43FOImjuxL8IQG7aUi9VDKAbHSCHjAfcvNdy/izY Gozwe4sSjVrZtwqRQdV+qnL4fCj2Bdb9577rRFz+PO6T+fwSiZHHekHlJyz6xG9u +dDXq4Zm3J/1s1mWEYLc810GNfDKePlR9ZQ9+jai1ZbnCZ17l/iydvVG22fKXIrK k7DYioYUxzHQcZJAsdt4jJQzZe6G1dmT0TZE0ARS3Nuypf49mlTmoEcUItVfbAOL wMnCoQ7ia+rRUv6lV6Rbj0ZZXhDNGOjSwxGSwe9Xw6UorpWB1jmAgZRs9LP/EzvD z6jFG+uVmnoJHfhFDdr1UV9O =zn+m -----END PGP SIGNATURE----- --fJlKg99VUlmfiJG6POrui4wTdsIEXK7SI-- From owner-freebsd-ipfw@freebsd.org Tue Aug 2 12:51:01 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 831D7BAC470 for ; Tue, 2 Aug 2016 12:51:01 +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 685DE17D1 for ; Tue, 2 Aug 2016 12:51:01 +0000 (UTC) (envelope-from rj@obsigna.com) Received: by mailman.ysv.freebsd.org (Postfix) id 67B8DBAC46F; Tue, 2 Aug 2016 12:51:01 +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 675ADBAC46E for ; Tue, 2 Aug 2016 12:51:01 +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::5]) (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 D33B617D0; Tue, 2 Aug 2016 12:51:00 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470142257; l=3224; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=yOoeA+aicni22KY1PVJDpATxDEc65rjsKiQj5zDkQwA=; b=vq1xSGZNNiMLkoPaIGwktQdaUYjBkScS8WakAPogdj2kRzKZ2bOGBnNwiV9eUzlvUb/ RePwf2NO1qsc56mNwN3eMLz2Wb30U/xoZzHiJFVOw0xbna6syNGt1tQzFeq4cytzpi4xr sU7r3eKvLca/YbLDJ8BsYZADqGEkslwIhts= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU2BqlKi/2sgPrEGJh3cdM= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bd1d98a1.virtua.com.br [189.29.152.161]) by smtp.strato.de (RZmta 38.13 DYNA|AUTH) with ESMTPSA id K03e26s72CovaQo (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); Tue, 2 Aug 2016 14:50:57 +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 37AFC229861E; Tue, 2 Aug 2016 09:50:54 -0300 (BRT) Content-Type: text/plain; charset=us-ascii 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: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> Date: Tue, 2 Aug 2016 09:50:53 -0300 Cc: Julian Elischer Content-Transfer-Encoding: quoted-printable Message-Id: References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@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: Tue, 02 Aug 2016 12:51:01 -0000 > 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?). 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' ..., IT people who know by heart the low ASCII table like chemists (are = supposed to) know the periodic table of the elements, this should be not = too hard to remember. > Another way would be to just put 'action numbers' in the tablearg = field and have a few actions, shared by countries, but the trouble comes = when you want to change the action for a country, you need to rewrite = potentially thousands of entries (USA has over 15800 allocations). Two or more geoip commands can be used for populating ipfw tables for = different utilization in ipfw directives: # Europe geoip -t "FR:IT:DE:NL:BE:GB:..." -n 1 -x | ipfw -q > /dev/stdin # North America geoip -t "US:CA" -n 2 -x | ipfw -q > /dev/stdin # South America geoip -t "AR:BR:UR:CL:PY:BO:PE..." -n 3 -x | ipfw -q > /dev/stdin ... > A second way woudl be to somehow map the tablearg of the country, into = a table of actions. effectively doing two levels of lookup. >=20 > The first table converting IP addresses to a country number and a = second lookup converting that to an action. >=20 > the only trouble is that I don't know of a way to do that. If the new = changes allow that, and anyone knows how, please let me know :-). Looking-up a given IP in the totally balanced binary search tree takes = on a decent system on average about 10-20 nanoseconds. So in theory 50 = to 100 million packets per second could be filtered by this algorithm. = In order to come more close to this performance in reality, it might be = an option to move the search algorithm into ipfw. Best regards Rolf From owner-freebsd-ipfw@freebsd.org Tue Aug 2 13:14:51 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 A4CC5BACE2A for ; Tue, 2 Aug 2016 13:14:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (gtw.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 692191C82; Tue, 2 Aug 2016 13:14:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 31A4724475; Tue, 2 Aug 2016 15:14:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7reZPTiaeSE; Tue, 2 Aug 2016 15:14:46 +0200 (CEST) Received: from [192.168.101.139] (vpn.ecoracks.nl [176.74.240.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 674CD24474; Tue, 2 Aug 2016 15:14:46 +0200 (CEST) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: Julian Elischer , "Dr. Rolf Jansen" , freebsd-ipfw@freebsd.org References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> From: Willem Jan Withagen Message-ID: <2e7d84c7-e962-e131-b788-81a6489b9f95@digiware.nl> Date: Tue, 2 Aug 2016 15:14:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Tue, 02 Aug 2016 13:14:51 -0000 On 1-8-2016 07:22, Julian Elischer wrote: > On 30/07/2016 10:17 PM, Dr. Rolf Jansen wrote: >> >> I am still a little bit amazed how ipfw come to accept incorrect CIDR >> ranges and arbitrarily moves the start/end addresses in order to >> achieve CIDR conformity, and that without any further notice, and that >> given that ipfw can be considered as being quite relevant to system >> security. Or, may I assume that ipfw knows always better than the user >> what should be allowed or denied. Otherwise, perhaps I am the only one >> ever who input incorrect CIDR ranges for processing by ipfw. > it's not so amazing when you think about it. The code comes from the > routing table.. > > In this context a.b.c.d/N means "the range of addresses containing > a.b.c.d, masked to a length of N". there is no specification that > a.b.c.d is the first address of the range. I have relied upon this > behaviour many times. I happily agree with Julian.... Rarely have I given the exact address of a router and it's net much thought. And apply happily a.b.c.27/26 in ipfw, assuming that ipfw would figure out what the actual network part of the address was. --WjW From owner-freebsd-ipfw@freebsd.org Tue Aug 2 15:02:46 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 31C88BAC1FB for ; Tue, 2 Aug 2016 15:02:46 +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 10FDA1234 for ; Tue, 2 Aug 2016 15:02:46 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1042ABAC1FA; Tue, 2 Aug 2016 15:02:46 +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 0DAA2BAC1F9 for ; Tue, 2 Aug 2016 15:02:46 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 C2FEC1232 for ; Tue, 2 Aug 2016 15:02:45 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qk0-x22f.google.com with SMTP id s63so177356780qkb.2 for ; Tue, 02 Aug 2016 08:02:45 -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; bh=Ap+d9PO/xS/Ozi6Kk8Ty5is1MnKNC4HfYW9h6XGvcqE=; b=OXR51sZMo9CuMrFI/8OFuu7WXp4Bq1OPh/AyNI7BIUF3QAq7BvMk2Cn0mrnLiJNCwa /NwCSF6cMYgclf+zw8eKdFEAI68Gc0tS199/Nva+xZZJim/4LAmaLT2HTJNZ/riVYKIg fxX81djrjOYWHwsLneOh5HjFAoLQBmy0JcJMBpYq+zmtRXufezblDbUs60Vo1EIGAzTM vGpxNxTyg/y7QXrmZxO6BzJi/HV+b2G2uGSGkuEe4SKiy2abE3KVAMpAQ8FVY/0S0V0r JCiq/E/Xmi05WoGND65H2FjFyKqufiX0lF9gb5iB3FyRKyT7F1tbnVMEwL9UxD/6t3lS Ep6A== 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; bh=Ap+d9PO/xS/Ozi6Kk8Ty5is1MnKNC4HfYW9h6XGvcqE=; b=iigIIPm4ohSlQ7W15o+shslhhUPs3Jomuudz3QC7j/pJB5ZMBAg7nGbtdSUigtQW0i pdgsVEVcSsmAouXrh5IORsb/T85nfMb4J3bxTlFO91YXCa7HoF1e0nOyC69pTEKOZvpw a/u/nPXf14nhEJzhYwoKoZJ9AoAbUiNvfFtMQF9doRiCD+68XsVPia5DLKt380qC9rKD 4LQf+FpEGWrFUyqtKDQhHs5+oGnfNBjQWRwSBab+JZLPg9TkAHFaLK9HfcZ5TrCcFsIS qajlJiLQfESjSrUMKUZH7F+InQP9dtMFrfYegNnamoQvVJUJs3DQ5qjVSIvkbTehn8Uv aWEQ== X-Gm-Message-State: AEkoouvjXoR+DCWBm391edY6Oil1a0M8/YgkuoFaYQBBX+V8Q2Sn7FOfacP5E6vJKABwYlHN/wB9eKM94DRf63Kd X-Received: by 10.55.4.133 with SMTP id 127mr78082907qke.207.1470150164873; Tue, 02 Aug 2016 08:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.249 with HTTP; Tue, 2 Aug 2016 08:02:44 -0700 (PDT) In-Reply-To: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> From: Michael Sierchio Date: Tue, 2 Aug 2016 08:02:44 -0700 Message-ID: Subject: Re: your thoughts on a particualar ipfw action. To: Julian Elischer , 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: Tue, 02 Aug 2016 15:02:46 -0000 On Tue, Aug 2, 2016 at 1:08 AM, Julian Elischer wrote: > > 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. > > I look forward to getting acquainted with the new features, but I have an observation - a database of networks by country is not invariably a geographic database. If you were to look at IP allocations in the Caribbean, or other overseas territories of the Netherlands, France, etc. you'd see what I mean. There's even a bit of FR in North America, Saint-Pierre & Miquelon. It works pretty well for excluding North Korea, Afghanistan, Yemen, Somalia, etc. but can sometimes be confusing. --=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 From owner-freebsd-ipfw@freebsd.org Tue Aug 2 21:01:11 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 93287BAD76F for ; Tue, 2 Aug 2016 21:01:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82AD31410 for ; Tue, 2 Aug 2016 21:01:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u72L1B8Y072168 for ; Tue, 2 Aug 2016 21:01:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 211256] ipfw nat tablearg regression in FreeBSD 11 Date: Tue, 02 Aug 2016 21:01:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-BETA1 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Tue, 02 Aug 2016 21:01:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211256 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Assignee|freebsd-standards@FreeBSD.o |freebsd-ipfw@FreeBSD.org |rg | Summary|FreeBSD 11 ipfw nat |ipfw nat tablearg |tablearg |regression in FreeBSD 11 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Wed Aug 3 14:13:31 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 11C1DBAD75D for ; Wed, 3 Aug 2016 14:13:31 +0000 (UTC) (envelope-from julian@freebsd.org) 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 F118C1FCB for ; Wed, 3 Aug 2016 14:13:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id ECE44BAD75C; Wed, 3 Aug 2016 14:13:30 +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 EC8E8BAD75B for ; Wed, 3 Aug 2016 14:13:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D457B1FC1 for ; Wed, 3 Aug 2016 14:13:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u73EDOlv032209 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2016 07:13:27 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: your thoughts on a particualar ipfw action. To: "Dr. Rolf Jansen" , ipfw mailing list References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> From: Julian Elischer Message-ID: <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org> Date: Wed, 3 Aug 2016 22:13:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 14:13:31 -0000 On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: >> Am 02.08.2016 um 05:08 schrieb Julian Elischer : >> >> looking for thoughts from people who know the new IPFW features well.. >> >> >> 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?). > 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 = 'DE' > 0x4252 = 'BR' > 0x5553 = 'US' well it would have to be the decimal value so DE would be 6869, as while 4445 works 444F is a problem :-) 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.. 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. > > ..., IT people who know by heart the low ASCII table like chemists (are supposed to) know the periodic table of the elements, this should be not too hard to remember. true > >> Another way would be to just put 'action numbers' in the tablearg field and have a few actions, shared by countries, but the trouble comes when you want to change the action for a country, you need to rewrite potentially thousands of entries (USA has over 15800 allocations). > Two or more geoip commands can be used for populating ipfw tables for different utilization in ipfw directives: > > # Europe > geoip -t "FR:IT:DE:NL:BE:GB:..." -n 1 -x | ipfw -q > /dev/stdin > > # North America > geoip -t "US:CA" -n 2 -x | ipfw -q > /dev/stdin > > # South America > geoip -t "AR:BR:UR:CL:PY:BO:PE..." -n 3 -x | ipfw -q > /dev/stdin > > ... > >> A second way woudl be to somehow map the tablearg of the country, into a table of actions. effectively doing two levels of lookup. >> >> The first table converting IP addresses to a country number and a second lookup converting that to an action. >> >> the only trouble is that I don't know of a way to do that. If the new changes allow that, and anyone knows how, please let me know :-). > Looking-up a given IP in the totally balanced binary search tree takes on a decent system on average about 10-20 nanoseconds. So in theory 50 to 100 million packets per second could be filtered by this algorithm. In order to come more close to this performance in reality, it might be an option to move the search algorithm into ipfw. > > Best regards > > Rolf > > _______________________________________________ > 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" > From owner-freebsd-ipfw@freebsd.org Wed Aug 3 16:44:30 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 F1AB9BAE5AE for ; Wed, 3 Aug 2016 16:44:30 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 88FFE15A9; Wed, 3 Aug 2016 16:44:30 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 9636F1D4E; Wed, 3 Aug 2016 19:44:19 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> To: Julian Elischer , Ian Smith Cc: "Andrey V. Elsukov" , "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: Date: Wed, 3 Aug 2016 19:44:12 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dDQ7C5dOGSF2WwJi8k0cv6HuqHviJhoA7" 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 16:44:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dDQ7C5dOGSF2WwJi8k0cv6HuqHviJhoA7 Content-Type: multipart/mixed; boundary="HCtWPnVge54Jp3DB4cPRMoP2iW3wcAx2K" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Julian Elischer , Ian Smith Cc: "Andrey V. Elsukov" , "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Message-ID: Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> In-Reply-To: <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> --HCtWPnVge54Jp3DB4cPRMoP2iW3wcAx2K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02.08.2016 09:47, Julian Elischer wrote: I don't have rights to commit my changes, and looks like I can not persuade others that my changes are Ok as-is, with all changes, made on requests from reviewers. Personally, I think, that (1) + (2) is orthogonal to (3) and it should be different change sets, reviews, etc. And, yes, (3) is great feature by itself. > Do we have any movement on these improvements? > even similar functionality by different names is ok. >=20 > 1/ ability to use keep-state without an implicit check-state. <--- most= > important for me. (store-state)? > 2/ ability to keep-state without actually doing it <---- less important= > for me. > 3/ multiple state tables? this was discussed and I thought I saw patche= s > but I haven't seen it going in, <-- super luxurious --=20 // Lev Serebryakov --HCtWPnVge54Jp3DB4cPRMoP2iW3wcAx2K-- --dDQ7C5dOGSF2WwJi8k0cv6HuqHviJhoA7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXoh9hXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP134QAKfx53Oq4a4qMVHaENAf0Q6H VfNbQEMAki4D8jgOjS4DXqnuqBWiwyPUi+5Q8Qgz/ukVhT64Zbz303g3dHhp8ejS vTX0E9q9X5a5HTdWA1L+IgITycI6uszJx+84lO6cGe6IgzwSTHygMpahLk2tPuzr tk8suynUuv7bEIZ7cpK94q0+41QZNnSD9gmbIjACuiYnZcSqYqUePYFqTtx8xQUU 0hFmvO+DAJWxXVO7FVJRgHySzjUroUVxMXNANqSwIESU0bqoqX+bkD4pa19MKxmv gsc7pZ2ENpKsXF0bh4GveDKZ/pBezP4NzHBCJ3HZ4CAnP8DXXCQUP84Zl/row7pc fmOhxdEfymlpnRpGxVJJnSsxQ3NHV3ZQoqtIL/+VlUeXRW9KN05F1/geRtPsWHON Aov8zK6KRyQtFSenqwfWHwrqcAr2hBgePyx+xbIOu93fvd12O+L2PRJjo54659Lt o1RmUI7qg5Ufi8qzpRb/Y1VpjNDJ6a8LgYzU2TcDCHg9vEGmu2f6ygqt6MRoCJuE nUR/iWDF89y8p0dmIDfB9ABPxKiTa2SBMW4zBy7lE7puZcvL7zN9i5tAepXsOojh jvKczxU8WMsbHVMATRDTRUaus8EC3AYOwIi38XYk68DL5vVGrnzOXh1gpDjCcO/g L9oAu0TBnUk4px9cCqoW =ZcPb -----END PGP SIGNATURE----- --dDQ7C5dOGSF2WwJi8k0cv6HuqHviJhoA7-- From owner-freebsd-ipfw@freebsd.org Wed Aug 3 18:05:42 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 0F6FABADF59 for ; Wed, 3 Aug 2016 18:05:42 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E559E16EA; Wed, 3 Aug 2016 18:05:41 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id E117A71805; Wed, 3 Aug 2016 18:05:39 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Julian Elischer , Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> Cc: lev@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: "Andrey V. Elsukov" Message-ID: <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> Date: Wed, 3 Aug 2016 21:03:50 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pSiLNJdf6wFEA8TNOA1npFEEVgxaV3ou0" 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 18:05:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pSiLNJdf6wFEA8TNOA1npFEEVgxaV3ou0 Content-Type: multipart/mixed; boundary="WPtlGaJ4pVrUeE4ufWDl39GR8Nr8ux2EL" From: "Andrey V. Elsukov" To: Julian Elischer , Ian Smith Cc: lev@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Message-ID: <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> In-Reply-To: <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> --WPtlGaJ4pVrUeE4ufWDl39GR8Nr8ux2EL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02.08.16 09:47, Julian Elischer wrote: > Do we have any movement on these improvements? > even similar functionality by different names is ok. >=20 > 1/ ability to use keep-state without an implicit check-state. <--- most= > important for me. (store-state)? > 2/ ability to keep-state without actually doing it <---- less important= > for me. So, if there are nobody against, I plan to commit this part in a several days. > 3/ multiple state tables? this was discussed and I thought I saw patche= s > but I haven't seen it going in, <-- super luxurious AFAIR, this was a part of "per-interface firewall" patch from eri@ and I think it is mostly outdated now, because in head/ we did very complex changes in ipfw. --=20 WBR, Andrey V. Elsukov --WPtlGaJ4pVrUeE4ufWDl39GR8Nr8ux2EL-- --pSiLNJdf6wFEA8TNOA1npFEEVgxaV3ou0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEsBAEBCAAWBQJXojIHDxxhZUBmcmVlYnNkLm9yZwAKCRABxeoEEMihei60B/9T ABGo4jcYrIZvwEnZCJye+Loa831xxVTQOBfzsjypShw6Hu3EdaurWEiI86FrEl1W 0XSbHkNaDSz8IplDSkpYDpUDCj55FZvYefimyzr38dB05Rlr5X3xQmdoT/yBkagx /7jpNXuv+NLANL/4FFTy0tjgNnMg37Vr+YUcuJ/6DT0y6xBzpQ6cyR29dA7o8H09 P19+MmYI00Y1gZrQJC8nRgxEsCmSwCy6FJ5CujWnGw46qhUA8T4LCECzi46lCGqD gHBmrXrlH6kSb6DAkuIW8FuOdaxa5BbCgtCIHIuy1isTzsoDWXEEs/qeXtmEpGmc Bz0YF203mbKfnJe7JvgY =n5sT -----END PGP SIGNATURE----- --pSiLNJdf6wFEA8TNOA1npFEEVgxaV3ou0-- From owner-freebsd-ipfw@freebsd.org Wed Aug 3 19:07:58 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 14FDDBAEF31 for ; Wed, 3 Aug 2016 19:07:58 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id A04C61CA7; Wed, 3 Aug 2016 19:07:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id E10161D89; Wed, 3 Aug 2016 22:07:54 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> To: "Andrey V. Elsukov" , Julian Elischer , Ian Smith Cc: "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> Date: Wed, 3 Aug 2016 22:07:48 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1vE69PTuddsF6K2aBLKHBXRWmR8MWOr01" 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 19:07:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1vE69PTuddsF6K2aBLKHBXRWmR8MWOr01 Content-Type: multipart/mixed; boundary="UpTP060a5eFlaxGPseC2BTsTFfVxeNk0F" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: "Andrey V. Elsukov" , Julian Elischer , Ian Smith Cc: "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Message-ID: <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> In-Reply-To: <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> --UpTP060a5eFlaxGPseC2BTsTFfVxeNk0F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03.08.2016 21:03, Andrey V. Elsukov wrote: >> 1/ ability to use keep-state without an implicit check-state. <--- mos= t >> important for me. (store-state)? >> 2/ ability to keep-state without actually doing it <---- less importan= t >> for me. > So, if there are nobody against, I plan to commit this part in a severa= l > days. Which implementation? Just curious, I could live with any, really. --=20 // Lev Serebryakov --UpTP060a5eFlaxGPseC2BTsTFfVxeNk0F-- --1vE69PTuddsF6K2aBLKHBXRWmR8MWOr01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXokEJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTdkP/2N8eIsNrSHPKz+f37lrCx+k S53c8c/AJwgtxyoo5YA62tmMBU6YhG5axWolfdI2Ii+5Z93wzL2njVVEhDBX1FUY aIzqrbTV3/gJ1p620W7tVG/WnH9alyKSs7PlXWHTDH0lsAeeqA0yWQP4mWo+VbVD RL7Acmid29nOhcP3F2Ga2FypQlGkTBuFVP4E+0cebUHMOJRhAXpTt3tfFhABUjYq M9AaQRDr5rkzl9EEEG6V5Mz8UIpLwJRRyK3jJSuHDGsnVPeOVwpnYdnclITnn86+ t06blvgtlpnRscMcCcZ4lBxn0taoTFFQHYMckTTtq+xrSCQm7i2iBAl8yD1icB9U kDSFTV7h+E1CFWIokLMX5xDJsvckzbZhIqwGPZQVzDo/hzoiyFllDwYx+LIEasub gzxLRUrAVffVCBtIjjlM3CP1pOWD6n5LaQjFnc0CbIBbpQc3d/OtWo5NgvK49+0A L0MHCfHIS43bq8aRSo1FNx+n0lSvSAb2pq41kmOvsClcOdHAq1iu9PMKyUT2pcYK 70aDkGXDXhkLMUxVDP1NroDrhehXwXdUU3quRLdEmFx1VYYk18DYPU2YbDR40QhH vd+8lbkE5mz55SaeN4z8cRmkKUtXMRLYHUFYJzGeVkBDFfrLItaxA9KfLArLfGdr ud+bHnBQXPnQqtjZJcW7 =LZ5z -----END PGP SIGNATURE----- --1vE69PTuddsF6K2aBLKHBXRWmR8MWOr01-- From owner-freebsd-ipfw@freebsd.org Wed Aug 3 19:10: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 76A71BAEFE4 for ; Wed, 3 Aug 2016 19:10:49 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AD141D98; Wed, 3 Aug 2016 19:10:49 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 302B679342; Wed, 3 Aug 2016 19:10:46 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: lev@FreeBSD.org, Julian Elischer , Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> Cc: "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: "Andrey V. Elsukov" Message-ID: Date: Wed, 3 Aug 2016 22:08:59 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UGKoLmUajKWthBrcgnt4opFJmdxf2rN1a" 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 19:10:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UGKoLmUajKWthBrcgnt4opFJmdxf2rN1a Content-Type: multipart/mixed; boundary="VNvXmvXE7E6u12EIfunCCiIsDHOQL0wje" From: "Andrey V. Elsukov" To: lev@FreeBSD.org, Julian Elischer , Ian Smith Cc: "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Message-ID: Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> In-Reply-To: <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> --VNvXmvXE7E6u12EIfunCCiIsDHOQL0wje Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03.08.16 22:07, Lev Serebryakov wrote: > On 03.08.2016 21:03, Andrey V. Elsukov wrote: >=20 >>> 1/ ability to use keep-state without an implicit check-state. <--- mo= st >>> important for me. (store-state)? >>> 2/ ability to keep-state without actually doing it <---- less importa= nt >>> for me. >> So, if there are nobody against, I plan to commit this part in a sever= al >> days. > Which implementation? Just curious, I could live with any, really. This one https://people.freebsd.org/~ae/ipfw.diff but with separate opcodes, I have come to the opinion, that this will be more readable. --=20 WBR, Andrey V. Elsukov --VNvXmvXE7E6u12EIfunCCiIsDHOQL0wje-- --UGKoLmUajKWthBrcgnt4opFJmdxf2rN1a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEsBAEBCAAWBQJXokFLDxxhZUBmcmVlYnNkLm9yZwAKCRABxeoEEMihepldB/wJ UZVuTP/TSdpYsYbcxEi2j6oMYl2muRYNvcHF+iYy6xSs368NP1UgNl41L/qS7h24 BlEPQciXgZnOTD8biZCOLoNchJFN7RZJNT4cOzPg/XV46Vt9mykrapyuS8ELe29l icsKQUGYmiJZEWK6H4XdFpNqZ+ohRId6NzLMFqRTNdaPs9mNE9hS6jsNWPd3iKam tShEcS/BjspHov7Dm7r6uu01fQ8OZKJ1uN/NBu7uE1lwFTug7E9pzlKvTFt89bP4 pA4AQCB9xhluuVS//hVPg3CjbOUbADS+38FILH+31KoXudWuDVm3t0i3Vti0HcJH fs0T8YTWgmQBNoTX6pZ2 =wykh -----END PGP SIGNATURE----- --UGKoLmUajKWthBrcgnt4opFJmdxf2rN1a-- From owner-freebsd-ipfw@freebsd.org Wed Aug 3 19:23:32 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 2899DBAE7A0 for ; Wed, 3 Aug 2016 19:23:32 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 90CAC1DD2; Wed, 3 Aug 2016 19:23:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 28EFA1D95; Wed, 3 Aug 2016 22:23:29 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> To: "Andrey V. Elsukov" , Julian Elischer , Ian Smith Cc: "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <3e505c15-02fa-c927-9892-f74d3ba058b7@FreeBSD.org> Date: Wed, 3 Aug 2016 22:23:29 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="phFeb19pvXdPa7dPxjV3gPsFCtDGEhBed" 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 19:23:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --phFeb19pvXdPa7dPxjV3gPsFCtDGEhBed Content-Type: multipart/mixed; boundary="6dJ7uKPQQr95XeppnnR24690KRHVBEGhh" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: "Andrey V. Elsukov" , Julian Elischer , Ian Smith Cc: "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Message-ID: <3e505c15-02fa-c927-9892-f74d3ba058b7@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> In-Reply-To: --6dJ7uKPQQr95XeppnnR24690KRHVBEGhh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03.08.2016 22:08, Andrey V. Elsukov wrote: >>>> 1/ ability to use keep-state without an implicit check-state. <--- m= ost >>>> important for me. (store-state)? >>>> 2/ ability to keep-state without actually doing it <---- less import= ant >>>> for me. >>> So, if there are nobody against, I plan to commit this part in a seve= ral >>> days. >> Which implementation? Just curious, I could live with any, really. >=20 > This one > https://people.freebsd.org/~ae/ipfw.diff >=20 > but with separate opcodes, I have come to the opinion, that this will > be more readable. How will it differ from my implementation, with separate opcode? --=20 // Lev Serebryakov --6dJ7uKPQQr95XeppnnR24690KRHVBEGhh-- --phFeb19pvXdPa7dPxjV3gPsFCtDGEhBed Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXokSxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePXvkP/R2eUF0AY3FOG0fVSjgf/Kkn uBz96vHPy55Kgov23Mr9vEpZbAesaDcw6limUOIt3xFTpI11w4zePGoXldqjDthD qtikhcJe9HfQM8nNPaJHAhYuL6gKUaLT0xHVvy5jAoUQx42POSGnKbS1vvlpdj0r PJV0oRM/Q/QsZLC46lKhNjrV8XjqmZvR4uG5dtj1WoywI2PeKtRcl0ZOFCDwa9cy J5ZjzvYibXKR1t6ZNvDJoolwEDitYYDP2lhWp/lLDpSYImq/EPTGEG1aojYYov47 Nv91Qvb6xz6/vl4jSRGqRAzUnVjaWgWUF7X29GyMoAwKVplI9OmeN4UJSmd2yjiN TMY/Ekwq1PWQMln0IiVEOj13ofD4oyGo4TJDoETv0vtXZESjk/O9yhMrZcHJBQEN Po2AD/zlQrek/F3OGwyTsyMekVZnbHkRLrR3LUzvIg4TYu2SWPFw0wYv4nHbKefL w0R+Kjizf/8X07zPiVGaqTDWm4yIFiEks4XEiAAlM6C386WrcwD2bBXjx4+fSRGj AD/QRfvnmG6z7lE94SzpZC3PvBktNVuA+1c2qZ4d/RUyQC3fD+P6ClaAnogN85vw UGzH4bFr4HPL/S06iFpv6xJsHREF5Pm8T5yQ7e4eHz/M5HY2Jhzf10HpyApZ+GRP ovp97uqBYCymhvNJT/Kk =fWh6 -----END PGP SIGNATURE----- --phFeb19pvXdPa7dPxjV3gPsFCtDGEhBed-- 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 From owner-freebsd-ipfw@freebsd.org Thu Aug 4 02:29:42 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 158A3BADB4A for ; Thu, 4 Aug 2016 02:29:42 +0000 (UTC) (envelope-from julian@freebsd.org) 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 F3D841578 for ; Thu, 4 Aug 2016 02:29:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id EF86ABADB47; Thu, 4 Aug 2016 02:29:41 +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 EF2B3BADB45 for ; Thu, 4 Aug 2016 02:29:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C2F3A1577 for ; Thu, 4 Aug 2016 02:29:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u742TZex038906 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2016 19:29:38 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: your thoughts on a particualar ipfw action. To: "Dr. Rolf Jansen" , ipfw mailing list References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org> From: Julian Elischer Message-ID: <6253540c-9692-7869-825f-5453505d7e2b@freebsd.org> Date: Thu, 4 Aug 2016 10:29:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 02:29:42 -0000 Wow, this is getting to be a very useful tool. thanks for all the work. I look forward to the port.. On 4/08/2016 5:53 AM, 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 : >>>> >>>> looking for thoughts from people who know the new IPFW features well.. >>>> >>>> >>>> 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?). >>> 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 = 'DE' >>> 0x4252 = 'BR' >>> 0x5553 = 'US' >> 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. >> >> 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 – well, so it is. I elaborated on your idea and came-up with the following formula: val = (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 = 5650 -- actually AD = 5680 > ZZ = 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 = 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 > > From owner-freebsd-ipfw@freebsd.org Thu Aug 4 02:41:45 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 0794ABADF8A for ; Thu, 4 Aug 2016 02:41:45 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D71171E85; Thu, 4 Aug 2016 02:41:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u742fbOI038968 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2016 19:41:40 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: lev@FreeBSD.org, Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> Cc: "Andrey V. Elsukov" , "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: Julian Elischer Message-ID: Date: Thu, 4 Aug 2016 10:41:31 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 02:41:45 -0000 On 4/08/2016 12:44 AM, Lev Serebryakov wrote: > On 02.08.2016 09:47, Julian Elischer wrote: > > I don't have rights to commit my changes, and looks like I can not > persuade others that my changes are Ok as-is, with all changes, made on > requests from reviewers. > > Personally, I think, that (1) + (2) is orthogonal to (3) and it should > be different change sets, reviews, etc. And, yes, (3) is great feature > by itself. I think 1 on its own would have good chance.. I'd probably commit it myself :-) save-state as a new keyword, that doesn't do a check-state. 2 is more esoteric. and sort of orthogonal to 1. > >> Do we have any movement on these improvements? >> even similar functionality by different names is ok. >> >> 1/ ability to use keep-state without an implicit check-state. <--- most >> important for me. (store-state)? >> 2/ ability to keep-state without actually doing it <---- less important >> for me. >> 3/ multiple state tables? this was discussed and I thought I saw patches >> but I haven't seen it going in, <-- super luxurious just noticed this IS in... From owner-freebsd-ipfw@freebsd.org Thu Aug 4 03:42:59 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 05F37BAC0CE for ; Thu, 4 Aug 2016 03:42:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D3BE5139D; Thu, 4 Aug 2016 03:42:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u743goEA039133 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2016 20:42:53 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: "Andrey V. Elsukov" , lev@FreeBSD.org, Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> Cc: "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: Julian Elischer Message-ID: Date: Thu, 4 Aug 2016 11:42:45 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 03:42:59 -0000 On 4/08/2016 3:08 AM, Andrey V. Elsukov wrote: > On 03.08.16 22:07, Lev Serebryakov wrote: >> On 03.08.2016 21:03, Andrey V. Elsukov wrote: >> >>>> 1/ ability to use keep-state without an implicit check-state. <--- most >>>> important for me. (store-state)? >>>> 2/ ability to keep-state without actually doing it <---- less important >>>> for me. >>> So, if there are nobody against, I plan to commit this part in a several >>> days. >> Which implementation? Just curious, I could live with any, really. > This one > https://people.freebsd.org/~ae/ipfw.diff > > but with separate opcodes, I have come to the opinion, that this will > be more readable. > so, reading it. it appears that teh record-state saves a rule as a target but doesn't actually perform the rule, right? that needs to be made more clear in the man page you say " Instead, the firewall creates a dynamic rule and the search continues with the next rule." so it's a combination of #1 and #2 in my list. I think I originally thought of having just #1. A combination is less useful for me as you need to do: 20 skipto 400 tcp from table(2) to me setup record-state 21 skipto 400 tcp from table(2) to me setup to make the entire session do the same thing. From owner-freebsd-ipfw@freebsd.org Thu Aug 4 03:58:28 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 524E6BAC46D for ; Thu, 4 Aug 2016 03:58:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 24FD81CB1; Thu, 4 Aug 2016 03:58:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u743wLvP048391 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2016 20:58:25 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: "Andrey V. Elsukov" , lev@FreeBSD.org, Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" From: Julian Elischer Message-ID: Date: Thu, 4 Aug 2016 11:58:16 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 03:58:28 -0000 So while thinking about states etc, it occured to me, what does THIS do on subsequent packets in the session? 10 skipto tablearg tcp from table(3) to me keep-state On 4/08/2016 11:42 AM, Julian Elischer wrote: > On 4/08/2016 3:08 AM, Andrey V. Elsukov wrote: >> On 03.08.16 22:07, Lev Serebryakov wrote: >>> On 03.08.2016 21:03, Andrey V. Elsukov wrote: >>> >>>>> 1/ ability to use keep-state without an implicit check-state. >>>>> <--- most >>>>> important for me. (store-state)? >>>>> 2/ ability to keep-state without actually doing it <---- less >>>>> important >>>>> for me. >>>> So, if there are nobody against, I plan to commit this part in a >>>> several >>>> days. >>> Which implementation? Just curious, I could live with any, really. >> This one >> https://people.freebsd.org/~ae/ipfw.diff >> >> but with separate opcodes, I have come to the opinion, that this will >> be more readable. >> > so, reading it. it appears that teh record-state saves a rule as a > target but doesn't actually perform the rule, right? > > that needs to be made more clear in the man page > > you say " Instead, the firewall creates a dynamic rule and the > search continues with the next rule." > > so it's a combination of #1 and #2 in my list. I think I originally > thought of having just #1. > > A combination is less useful for me as you need to do: > > 20 skipto 400 tcp from table(2) to me setup record-state > > 21 skipto 400 tcp from table(2) to me setup > > to make the entire session do the same thing. > > > > > > _______________________________________________ > 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" > From owner-freebsd-ipfw@freebsd.org Thu Aug 4 10:27:44 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 B63FBBAED07 for ; Thu, 4 Aug 2016 10:27:44 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 77A99182A; Thu, 4 Aug 2016 10:27:44 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e0f4:994:662:862]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id C6A971ED6; Thu, 4 Aug 2016 13:27:41 +0300 (MSK) Date: Thu, 4 Aug 2016 13:27:43 +0300 From: Lev Serebryakov Reply-To: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <428538212.20160804132737@serebryakov.spb.ru> To: Julian Elischer , "Andrey V. Elsukov" , Ian Smith CC: "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Subject: Re: IPFW: more "orthogonal? state operations, push into 11? In-Reply-To: References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="----------0200831B53747B6C7" 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 10:27:44 -0000 ------------0200831B53747B6C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 SGVsbG8gSnVsaWFuLA0KDQpUaHVyc2RheSwgQXVndXN0IDQsIDIwMTYsIDY6NDI6NDUgQU0s IHlvdSB3cm90ZToNCg0KPiBBIGNvbWJpbmF0aW9uIGlzIGxlc3MgdXNlZnVsIGZvciBtZSBh cyB5b3UgbmVlZCB0byBkbzoNCiAgSSdtIGFnYWluc3QgdGhpcyB0b28sIGFzIEkgcmVhbGx5 IGxvdmUgb3J0aG9nb25hbGl0eSwgYXMgZXZlcnlib2R5IGtub3cNCiBhbHJlYWR5LCBhbmQg eW91ciBleGFtcGxlIGlzIGdvb2QgZXhhbXBsZSB3aHkuDQoNCj4gMjAgc2tpcHRvIDQwMCB0 Y3AgZnJvbSB0YWJsZSgyKSB0byBtZSBzZXR1cCByZWNvcmQtc3RhdGUNCj4gMjEgc2tpcHRv IDQwMCB0Y3AgZnJvbSB0YWJsZSgyKSB0byBtZSBzZXR1cA0KDQo+IHRvIG1ha2UgdGhlIGVu dGlyZSBzZXNzaW9uIGRvIHRoZSBzYW1lIHRoaW5nLg0KIFNvbWV0aW1lcyBpdCBjb3VsZCBi ZQ0KDQoyMCBza2lwdG8gNDAwIHRjcCBmcm9tIHRhYmxlKDIpIHRvIG1lIHNldHVwIHJlY29y ZC1zdGF0ZQ0KMjEgY2hlY2stc3RhdGUNCg0KIEJ1dCBvbmx5IHNvbWV0aW1lcy4NCg0KLS0g DQpCZXN0IHJlZ2FyZHMsDQogTGV2ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1haWx0 bzpsZXZARnJlZUJTRC5vcmc= ------------0200831B53747B6C7 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJXoxifXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePg6sP/0CntUL4Cyxm1cOySynjy/p+ f07gssCeUYjQzGKPoAcMEpG6rYGxjsqTdC0EhtUtfV18Z4C2sNnpr9E6hi6ggviv DM9XeCJsYopk09Lnhxi0lIgX0UBLRnXK4SyXzXSqvwsQTEyDpLZfkxWu0f+ccNqx aNdGWCHIMr2s7Zmv7+NYkYusf5lkCGj51o3jprIywbxPIjBaLnXuB0g61/w1LxwF 5uh+MZxbh5yQNaUmlXea44p1ilRpKsWA89YpmVY5DgoaQUvMrE7ndpoPanPFPF+A eqT8RN9JXuaq1TOVFmFD19pmB7+kD0jPOPtCKC+HAyWBMYhGap4MK9B2oiclnDMO LYb/5eUr5A0gCpJuNcmZjKYMYjF6k7HVg2PI50v2pFwscCHBhJpUkG2CEmDcp89j 0/0d5B24ieegqJxHG008M752UtAggKLpqzlxPS5S6Ou1gNuAeeo1A033oS0Ktq72 AGtaivyPJ/1byDNQa8aI/fY0CG0AszMy9xjQd1U3Rq8FWIpZdp25duEeyko8X159 ndghfnIenLc8odabcQwNnxCuY90etEYWGQIHewIFB5mHNOFcUS2lQ5dKmL3IsVUN 9lxI4NF7KVY7mD+waJljENQtIrBCPhSQVvBMhjuwVbKLbDru6SRddSormkNLrxc1 OhJIJJDKqqehBfVp7zQo =WX+J -----END PGP MESSAGE----- ------------0200831B53747B6C7-- From owner-freebsd-ipfw@freebsd.org Thu Aug 4 10:52:38 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 1E7DDBAE493 for ; Thu, 4 Aug 2016 10:52:38 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 002BE15B0; Thu, 4 Aug 2016 10:52:38 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 2947F65EF4; Thu, 4 Aug 2016 10:52:35 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Julian Elischer , lev@FreeBSD.org, Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" From: "Andrey V. Elsukov" Message-ID: <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> Date: Thu, 4 Aug 2016 13:50:49 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eiWttdhA9Lk9CaDLN7jSqawr9TTpsxS2O" 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 10:52:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eiWttdhA9Lk9CaDLN7jSqawr9TTpsxS2O Content-Type: multipart/mixed; boundary="NMWkI1KptlCxn04x6N5duDRX3iUxQe2Lh" From: "Andrey V. Elsukov" To: Julian Elischer , lev@FreeBSD.org, Ian Smith Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" Message-ID: <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> In-Reply-To: --NMWkI1KptlCxn04x6N5duDRX3iUxQe2Lh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04.08.16 06:42, Julian Elischer wrote: > so it's a combination of #1 and #2 in my list. I think I originally > thought of having just #1. >=20 > A combination is less useful for me as you need to do: >=20 > 20 skipto 400 tcp from table(2) to me setup record-state > 21 skipto 400 tcp from table(2) to me setup > to make the entire session do the same thing. So, in your example what wrong with just using keep-state? "record-state without immediate action" =3D=3D "keep-state without implic= it check-state" needed to solve issues with NAT or something similar, that was described by Lev. --=20 WBR, Andrey V. Elsukov --NMWkI1KptlCxn04x6N5duDRX3iUxQe2Lh-- --eiWttdhA9Lk9CaDLN7jSqawr9TTpsxS2O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEsBAEBCAAWBQJXox4KDxxhZUBmcmVlYnNkLm9yZwAKCRABxeoEEMihejaMCACK gbKjFVfrtM2bNAX8lrtvoS1srTHLy86+aNYyBu6WgLGwVErthgJpfM/0lwO0M8CL 1vB9SjHUJnHj60fN6gNhTNrY4KFkSpy59idSFY5qK4H8BSt9eWZ7S7S6ZeJK2lCP bF+R1AFwa6fiRa2u0nVK5QmjrlJ4nhVPwN8+L3oA9Z23pRx6a+XLCOPBqNYLEAu4 pASrS/s6i8dSwHNDPgND+Mqsh2+wKhyAfN91JcgpYRLAtfTFdqg0ettdXepnt5vV OTAZXvsGENoJbJwY8fjmlXZApYUj8Mzm5hv6AD62kBJ+URYfvFnnTBNWFrFX7NJ5 mRe15GzDkLMJohkfpTt/ =8qi9 -----END PGP SIGNATURE----- --eiWttdhA9Lk9CaDLN7jSqawr9TTpsxS2O-- From owner-freebsd-ipfw@freebsd.org Thu Aug 4 11:22:46 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 D535BBAEFAC for ; Thu, 4 Aug 2016 11:22:46 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5CC31917; Thu, 4 Aug 2016 11:22:46 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id D81E266341; Thu, 4 Aug 2016 11:22:44 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Julian Elischer , lev@FreeBSD.org, Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" From: "Andrey V. Elsukov" Message-ID: Date: Thu, 4 Aug 2016 14:20:58 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JwTCJKoSsrVfu2lfSqdhdUudDGEl1nGlq" 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 11:22:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JwTCJKoSsrVfu2lfSqdhdUudDGEl1nGlq Content-Type: multipart/mixed; boundary="nVxKXOVGB2qDvcCQValPRbn7AJRomegji" From: "Andrey V. Elsukov" To: Julian Elischer , lev@FreeBSD.org, Ian Smith Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" Message-ID: Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> In-Reply-To: --nVxKXOVGB2qDvcCQValPRbn7AJRomegji Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04.08.16 06:58, Julian Elischer wrote: > o while thinking about states etc, it occured to me, what does THIS do > on subsequent packets in the session? >=20 >=20 > 10 skipto tablearg tcp from table(3) to me keep-state I think it will not work like you expected when you have created this rule :) --=20 WBR, Andrey V. Elsukov --nVxKXOVGB2qDvcCQValPRbn7AJRomegji-- --JwTCJKoSsrVfu2lfSqdhdUudDGEl1nGlq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEsBAEBCAAWBQJXoyUaDxxhZUBmcmVlYnNkLm9yZwAKCRABxeoEEMiheiKFB/4z G8aXtWkBgH3QKOFHxsHDh/AEN1Y1fACniN+CtRAKacQGNO7BBipilVFeJd3BZj2r JQvZZ5+U0B/zmKZcK++QsFFcTd8BDUijLa1jgASlXiSMgmrEHFqwB7X71lhJjuAd tpBBfRVPIOFio1gFGO10q5YcNwksGnVwJz1bhyK/GapBwFUvUu6R3NpgFN+WyczC 6g1kMnGFUJSOXjyiz4BWOhMT2GmBzdU1Yphods8/7F429Qy8mIG60WpNfGIriMl8 GjIig7tru0NPkTeVozPVhrlgyCF/2BL8RAfuTwHEttj+srMfPewm38KOhqQWnuDX W3aUZMzc5LFa6u8MMM+M =2AXl -----END PGP SIGNATURE----- --JwTCJKoSsrVfu2lfSqdhdUudDGEl1nGlq-- From owner-freebsd-ipfw@freebsd.org Thu Aug 4 16:08:50 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 3A05EBAFCAB for ; Thu, 4 Aug 2016 16:08:50 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 12CC6155F; Thu, 4 Aug 2016 16:08:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u74G8bv7001875 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2016 09:08:40 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: "Andrey V. Elsukov" , lev@FreeBSD.org, Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" From: Julian Elischer Message-ID: <713a45fd-70a1-e0ed-a3b9-bf057cec12a9@freebsd.org> Date: Fri, 5 Aug 2016 00:08:31 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 16:08:50 -0000 On 4/08/2016 7:20 PM, Andrey V. Elsukov wrote: > On 04.08.16 06:58, Julian Elischer wrote: >> o while thinking about states etc, it occured to me, what does THIS do >> on subsequent packets in the session? >> >> >> 10 skipto tablearg tcp from table(3) to me keep-state > I think it will not work like you expected when you have created this > rule :) > yes that's what I was thinking.. I'm guessing that the table is not evaluated due to the dynamic match and thus the skipto fails, either doing nothing, or dropping the packet (not sure which) From owner-freebsd-ipfw@freebsd.org Thu Aug 4 16:12: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 3D32BBAFDDF for ; Thu, 4 Aug 2016 16:12:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 113BF186E; Thu, 4 Aug 2016 16:12:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u74GCh05001899 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2016 09:12:46 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: "Andrey V. Elsukov" , lev@FreeBSD.org, Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" From: Julian Elischer Message-ID: <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> Date: Fri, 5 Aug 2016 00:12:37 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 16:12:49 -0000 On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: > On 04.08.16 06:42, Julian Elischer wrote: >> so it's a combination of #1 and #2 in my list. I think I originally >> thought of having just #1. >> >> A combination is less useful for me as you need to do: >> >> 20 skipto 400 tcp from table(2) to me setup record-state >> 21 skipto 400 tcp from table(2) to me setup >> to make the entire session do the same thing. > So, in your example what wrong with just using keep-state? > "record-state without immediate action" == "keep-state without implicit > check-state" needed to solve issues with NAT or something similar, that > was described by Lev. > because keep-state is a check-state for ALL packets going past, regardless of whether they match the pattern. at least that's what I have observed. From owner-freebsd-ipfw@freebsd.org Thu Aug 4 16:14:37 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 AC329BAFE36 for ; Thu, 4 Aug 2016 16:14:37 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8560E18F8; Thu, 4 Aug 2016 16:14:37 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u74GEVTR001907 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2016 09:14:34 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Lev Serebryakov , "Andrey V. Elsukov" , Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> <428538212.20160804132737@serebryakov.spb.ru> Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" From: Julian Elischer Message-ID: Date: Fri, 5 Aug 2016 00:14:26 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <428538212.20160804132737@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 16:14:37 -0000 On 4/08/2016 6:27 PM, Lev Serebryakov wrote: > Hello Julian, > > Thursday, August 4, 2016, 6:42:45 AM, you wrote: > >> A combination is less useful for me as you need to do: > I'm against this too, as I really love orthogonality, as everybody know > already, and your example is good example why. > >> 20 skipto 400 tcp from table(2) to me setup record-state >> 21 skipto 400 tcp from table(2) to me setup >> to make the entire session do the same thing. > Sometimes it could be > > 20 skipto 400 tcp from table(2) to me setup record-state > 21 check-state > > But only sometimes. exactly.. I don't want OTHER packets coming past here to hit a check-state yet.. I still have unfinished business with them. > From owner-freebsd-ipfw@freebsd.org Thu Aug 4 16:33:54 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 EEA14BAF42F for ; Thu, 4 Aug 2016 16:33:54 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B36C917B1 for ; Thu, 4 Aug 2016 16:33:54 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from vader9.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 7710E2342 for ; Thu, 4 Aug 2016 18:33:44 +0200 (CEST) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: freebsd-ipfw@freebsd.org References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> From: Jan Bramkamp Message-ID: <458591fc-8118-a3a4-071b-4f581687ee53@rlwinm.de> Date: Thu, 4 Aug 2016 18:33:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 16:33:55 -0000 On 04/08/16 18:12, Julian Elischer wrote: > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: >> On 04.08.16 06:42, Julian Elischer wrote: >>> so it's a combination of #1 and #2 in my list. I think I originally >>> thought of having just #1. >>> >>> A combination is less useful for me as you need to do: >>> >>> 20 skipto 400 tcp from table(2) to me setup record-state >>> 21 skipto 400 tcp from table(2) to me setup >>> to make the entire session do the same thing. >> So, in your example what wrong with just using keep-state? >> "record-state without immediate action" == "keep-state without implicit >> check-state" needed to solve issues with NAT or something similar, that >> was described by Lev. >> > because keep-state is a check-state for ALL packets going past, > regardless of whether they match the pattern. > > at least that's what I have observed. According to the documentation and my experience it is. As a workaround i use skipto $stateful + record-state. That way each stateful match continues processing at $stateful. Whilte it works it's hard to understand when combined with in-kernel NAT, because you end up with asymmetric paths through the ruleset for incoming and outgoing packets. From owner-freebsd-ipfw@freebsd.org Thu Aug 4 16:44:23 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 78CF8BAF6DC for ; Thu, 4 Aug 2016 16:44:23 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) 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 687931DDA for ; Thu, 4 Aug 2016 16:44:23 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: by mailman.ysv.freebsd.org (Postfix) id 642CEBAF6DA; Thu, 4 Aug 2016 16:44:23 +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 63C9CBAF6D9 for ; Thu, 4 Aug 2016 16:44:23 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78A131DD8; Thu, 4 Aug 2016 16:44:22 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u74GiGOn004720; Fri, 5 Aug 2016 02:44:17 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 5 Aug 2016 02:44:16 +1000 (EST) From: Ian Smith To: "Dr. Rolf Jansen" cc: ipfw mailing list , Julian Elischer Subject: Re: your thoughts on a particualar ipfw action. Message-ID: <20160805024301.H56585@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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 16:44:23 -0000 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 pine 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 work? Are there any disadvantages? And if not, why isn't it the default? :) 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 .. >> 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 = 'DE' >> 0x4252 = 'BR' >> 0x5553 = '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 ÿÿ well, so it is. I elaborated on your idea and came-up with the following formula: val = (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 = 5650 -- actually AD = 5680 ZZ = 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'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 munimum value of 0 (AA) and maximum of 25 * 26 + 25 = 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? 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 From owner-freebsd-ipfw@freebsd.org Thu Aug 4 17:07:45 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 89BEBBAFAC4 for ; Thu, 4 Aug 2016 17:07:45 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) 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 775A01970 for ; Thu, 4 Aug 2016 17:07:45 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: by mailman.ysv.freebsd.org (Postfix) id 76BAEBAFAC3; Thu, 4 Aug 2016 17:07:45 +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 766BBBAFAC2 for ; Thu, 4 Aug 2016 17:07:45 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89383196F; Thu, 4 Aug 2016 17:07:43 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u74Fcjpu002288; Fri, 5 Aug 2016 01:38:46 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 5 Aug 2016 01:38:45 +1000 (EST) From: Ian Smith To: "Dr. Rolf Jansen" cc: ipfw mailing list , Julian Elischer Subject: Re: your thoughts on a particualar ipfw action. In-Reply-To: Message-ID: <20160805002459.N56585@sola.nimnet.asn.au> References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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 17:07:45 -0000 <<< No Message Collected >>> From owner-freebsd-ipfw@freebsd.org Thu Aug 4 17:14:39 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 927BBBAFC70 for ; Thu, 4 Aug 2016 17:14:39 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 806A31CF2 for ; Thu, 4 Aug 2016 17:14:39 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: by mailman.ysv.freebsd.org (Postfix) id 7FC73BAFC6F; Thu, 4 Aug 2016 17:14:39 +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 7F7B9BAFC6E for ; Thu, 4 Aug 2016 17:14:39 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA81E1CF1; Thu, 4 Aug 2016 17:14:37 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u74HEX9a006125; Fri, 5 Aug 2016 03:14:33 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 5 Aug 2016 03:14:32 +1000 (EST) From: Ian Smith To: "Dr. Rolf Jansen" cc: ipfw mailing list , Julian Elischer Subject: Re: your thoughts on a particualar ipfw action. In-Reply-To: <20160805002459.N56585@sola.nimnet.asn.au> Message-ID: <20160805030930.R56585@sola.nimnet.asn.au> References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org> <20160805002459.N56585@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 17:14:39 -0000 On Fri, 5 Aug 2016 01:38:45 +1000, Ian Smith wrote: > <<< No Message Collected >>> Yeah, sorry about that .. this got stuck in mailq somehow in 'locked' EHLO state .. never seen that before in many years; had to kill and resend it from sent-mail as a fwd, losing 'References:'. Weird. Ian From owner-freebsd-ipfw@freebsd.org Thu Aug 4 18:14:13 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 2B734BAE2B7 for ; Thu, 4 Aug 2016 18:14:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 776A713D9; Thu, 4 Aug 2016 18:14:11 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u74IE5ve008153; Fri, 5 Aug 2016 04:14:06 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 5 Aug 2016 04:14:05 +1000 (EST) From: Ian Smith To: Julian Elischer cc: "Andrey V. Elsukov" , lev@freebsd.org, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" Subject: Re: IPFW: more "orthogonal? state operations, push into 11? In-Reply-To: <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> Message-ID: <20160805034606.K56585@sola.nimnet.asn.au> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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:14:13 -0000 On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote: > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: > > On 04.08.16 06:42, Julian Elischer wrote: > > > so it's a combination of #1 and #2 in my list. I think I originally > > > thought of having just #1. > > > > > > A combination is less useful for me as you need to do: > > > > > > 20 skipto 400 tcp from table(2) to me setup record-state > > > 21 skipto 400 tcp from table(2) to me setup > > > to make the entire session do the same thing. > > So, in your example what wrong with just using keep-state? > > "record-state without immediate action" == "keep-state without implicit > > check-state" needed to solve issues with NAT or something similar, that > > was described by Lev. > > > because keep-state is a check-state for ALL packets going past, regardless of > whether they match the pattern. > > at least that's what I have observed. Except now(?) with named states/flows/whatever, isn't it the case that check-state [flowname] only affects packets with same state/flowname? So you can clearly separate, say, packets on different interfaces, packets coming or going on any interface, and such? If I'm understanding that right - quite possibly not! - then only those packets will match, and others with other names (including 'default') won't match states with that name. I'm not sure I'm expressing this at all well, because I'm only just starting to get any sort of grip, but I'm liking the idea and wondering if it's sufficient for starters. To me, orthogonality implies the least number of commands/instructions that will accomplish the desired functionality. First, let's find out what can and cannot be accomplished with named states/flows .. I'm yet to understand what record-state-without-action can accomplish apart from that .. it could work only for the first packet I suppose, since once state is established, further packets will match and follow state, no? Again, I find concrete examples - like the use of valtype skipto,fib mentioned above - really helpful, essential really, for bears of such little brain as I .. cheers, Ian 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 From owner-freebsd-ipfw@freebsd.org Fri Aug 5 04:01:07 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 16346BAE15F for ; Fri, 5 Aug 2016 04:01:07 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 01F221CD4 for ; Fri, 5 Aug 2016 04:01:07 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id F1AD5BAE15E; Fri, 5 Aug 2016 04:01:06 +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 F155DBAE15B for ; Fri, 5 Aug 2016 04:01:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C358C1CD1 for ; Fri, 5 Aug 2016 04:01:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u7540v0f004258 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2016 21:01:00 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: your thoughts on a particualar ipfw action. To: Ian Smith , "Dr. Rolf Jansen" References: <20160805024301.H56585@sola.nimnet.asn.au> Cc: ipfw mailing list From: Julian Elischer Message-ID: Date: Fri, 5 Aug 2016 12:00:52 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160805024301.H56585@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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:01:07 -0000 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 pine > 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 work? > 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 = 'DE' >>> 0x4252 = 'BR' >>> 0x5553 = '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 ÿÿ well, so it is. I elaborated on your idea and came-up > with the following formula: val = (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 = 5650 -- actually AD = 5680 > ZZ = 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 it 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 = 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 > 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 From owner-freebsd-ipfw@freebsd.org Fri Aug 5 04:37:08 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 589D5BAE95E for ; Fri, 5 Aug 2016 04:37:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 197D81BE1; Fri, 5 Aug 2016 04:37:07 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u754b1vo004416 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2016 21:37:04 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> <20160805034606.K56585@sola.nimnet.asn.au> Cc: "Andrey V. Elsukov" , lev@freebsd.org, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" From: Julian Elischer Message-ID: <24bf65d1-1b4f-07a0-5a3c-93fd906f5705@freebsd.org> Date: Fri, 5 Aug 2016 12:36:56 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160805034606.K56585@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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:37:08 -0000 On 5/08/2016 2:14 AM, Ian Smith wrote: > On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote: > > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: > > > On 04.08.16 06:42, Julian Elischer wrote: > > > > so it's a combination of #1 and #2 in my list. I think I originally > > > > thought of having just #1. > > > > > > > > A combination is less useful for me as you need to do: > > > > > > > > 20 skipto 400 tcp from table(2) to me setup record-state > > > > 21 skipto 400 tcp from table(2) to me setup > > > > to make the entire session do the same thing. > > > > So, in your example what wrong with just using keep-state? > > > "record-state without immediate action" == "keep-state without implicit > > > check-state" needed to solve issues with NAT or something similar, that > > > was described by Lev. > > > > > > because keep-state is a check-state for ALL packets going past, regardless of > > whether they match the pattern. > > > > at least that's what I have observed. > > Except now(?) with named states/flows/whatever, isn't it the case that > check-state [flowname] only affects packets with same state/flowname? So > you can clearly separate, say, packets on different interfaces, packets > coming or going on any interface, and such? > > If I'm understanding that right - quite possibly not! - then only those > packets will match, and others with other names (including 'default') > won't match states with that name. I'm not sure I'm expressing this at > all well, because I'm only just starting to get any sort of grip, but > I'm liking the idea and wondering if it's sufficient for starters. wellll not quite.. Only the given state table will be looked at, but all packets will still be matched with it. > > To me, orthogonality implies the least number of commands/instructions > that will accomplish the desired functionality. First, let's find out > what can and cannot be accomplished with named states/flows .. I'm yet > to understand what record-state-without-action can accomplish apart from > that .. it could work only for the first packet I suppose, since once > state is established, further packets will match and follow state, no? > > Again, I find concrete examples - like the use of valtype skipto,fib > mentioned above - really helpful, essential really, for bears of such > little brain as I .. ok, so sometimes I like to do some processing on a packet (e.g. divert it somewhere for munging) after I've set up a state for it. so I don't want to necessarily Act on the state immediately. but the packet may get changed in the munging, so I need to set the state before hand., or I can't match it. here's a real example that I couldn't do because I couldn't store a state without actually doing it. I wanted all packets from a process on the local machine (identified because it has a unique group, used for just this purpose) to be forwarded to a particular other machine for "vetting', however the machine I am doing this has outgoing NAT using a modified natd that also does some added "stuff". After the NAT I can no longer recognise the packets that came from that process as they moved out of the kernel to userland and back, yet I still need these ackets to go through the natd. So I need to identify them first, before the nat in order to set a state entry for them. Since they are local packets NAT will not have changed their addresses, so AFTER the NAT I could have done the associated check-state which triggers the stored action (forwarding to another location). I ended up having to do this via an ugly use of skiptos where packets I wanted to forward, were identified early and then sent to a duplicate set of rules which also did the divert, but then did the forward. I think there were about 25 rules duplicated. Having said that, "store without do" is the least important of the features. Store (do or not) without a prior checkstate is more important to me. state name are a wonderful addition that I have yet to use in all my scripts I just haven't had time yet. > > cheers, Ian > From owner-freebsd-ipfw@freebsd.org Fri Aug 5 05:23:00 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 4071EBAD3E1 for ; Fri, 5 Aug 2016 05:23:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EFC31EEF for ; Fri, 5 Aug 2016 05:22:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u755MtkM004596 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 4 Aug 2016 22:22:58 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: your thoughts on a particualar ipfw action. To: freebsd-ipfw@freebsd.org References: <20160805024301.H56585@sola.nimnet.asn.au> From: Julian Elischer Message-ID: <5ca6bec5-0cff-b9f0-8d1e-abc858e32703@freebsd.org> Date: Fri, 5 Aug 2016 13:22:50 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 05:23:00 -0000 On 5/08/2016 12:15 PM, Michael Sierchio wrote: > Wouldn't it make sense to use the ISO Numeric Code / UN M49 Numerical Code? actually it doesn't make sense. the source of data doesn't have that information in it so it would require a whole layer of mapping, including downloads. and it would have to cope with unexpected ambiguities and mismatches. From owner-freebsd-ipfw@freebsd.org Fri Aug 5 05:33:32 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 F336FBAD57A for ; Fri, 5 Aug 2016 05:33:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D01B1336; Fri, 5 Aug 2016 05:33:31 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u755XQZ0030960; Fri, 5 Aug 2016 15:33:27 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 5 Aug 2016 15:33:26 +1000 (EST) From: Ian Smith To: Julian Elischer cc: freebsd-ipfw@freebsd.org Subject: Re: your thoughts on a particualar ipfw action. In-Reply-To: <5ca6bec5-0cff-b9f0-8d1e-abc858e32703@freebsd.org> Message-ID: <20160805152657.O56585@sola.nimnet.asn.au> References: <20160805024301.H56585@sola.nimnet.asn.au> <5ca6bec5-0cff-b9f0-8d1e-abc858e32703@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 05:33:33 -0000 On Fri, 5 Aug 2016 13:22:50 +0800, Julian Elischer wrote: > On 5/08/2016 12:15 PM, Michael Sierchio wrote: > > Wouldn't it make sense to use the ISO Numeric Code / UN M49 Numerical Code? > actually it doesn't make sense. the source of data doesn't have that > information in it so it would require a whole layer of mapping, > including downloads. and it would have to cope with unexpected > ambiguities and mismatches. Yeah, no .. to address this point first, I misunderstood mention of it to indicate that data was also available in what geoip is using. Given that it's not, agreed it'd be way too much hassle to synchronise .. cheers, Ian From owner-freebsd-ipfw@freebsd.org Fri Aug 5 05:44:12 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 E1C99BAD745 for ; Fri, 5 Aug 2016 05:44:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C08231689 for ; Fri, 5 Aug 2016 05:44:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u755i6lK004677 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 4 Aug 2016 22:44:09 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: your thoughts on a particualar ipfw action. To: freebsd-ipfw@freebsd.org References: <20160805024301.H56585@sola.nimnet.asn.au> From: Julian Elischer Message-ID: <7486c7ce-49db-b6b9-a6bb-13f04b4ce6d6@freebsd.org> Date: Fri, 5 Aug 2016 13:44:01 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 05:44:13 -0000 On 5/08/2016 2:22 AM, Dr. Rolf Jansen wrote: > 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=50000:RU=50010:US=50020:BR=50030 > > 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. > I can hear the exasperation in your writing :-) I've lost track.. Was the present behaviour just a single value? or a generated number with -x offset? (not sure if you actually added that or just described it). your "US=50020" idea is nice but a lot of work I think for you. I guess you would do it with script geoip -t US=${LINE_US} |ipfw -q /dev/stdin ipfw add ${LINE_US} drop all tcp from any to any 80 ipfw add $((${LINE_US} + 1)) skipto ${FINISH_UP} probably in a shell function it would also allow you to put 'action numbers' rather than line numbers as it doesn't interpret the values, just passes them through. On the other hand the same thing can be achieved by embedding geoip in a loop in a script. I think we should just let you get on with your life and be happy with what you have given us. mapping a set of country codes to a number. I can always make more complicated setups using that and 15 minutes of shell script. From owner-freebsd-ipfw@freebsd.org Fri Aug 5 06:15:53 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 4B8F4BADE16 for ; Fri, 5 Aug 2016 06:15:53 +0000 (UTC) (envelope-from julian@freebsd.org) 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 36D171498 for ; Fri, 5 Aug 2016 06:15:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 363B5BADE15; Fri, 5 Aug 2016 06:15:53 +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 35EFABADE14 for ; Fri, 5 Aug 2016 06:15:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 14D611497 for ; Fri, 5 Aug 2016 06:15:52 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u756Fh0g004802 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2016 23:15:48 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: your thoughts on a particualar ipfw action. To: "Dr. Rolf Jansen" , ipfw mailing list References: <20160805024301.H56585@sola.nimnet.asn.au> Cc: Ian Smith From: Julian Elischer Message-ID: Date: Fri, 5 Aug 2016 14:15:37 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 06:15:53 -0000 On 5/08/2016 2:22 AM, Dr. Rolf Jansen wrote: > > 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=50000:RU=50010:US=50020:BR=50030 > > 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. > >> >> Which has a munimum value of 0 (AA) and maximum of 25 * 26 + 25 = 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. > I will be ready to change the encoding scheme to anything on which the community will have been agreed upon. > > I think you very first idea is best geoip -t AU:US:DE -n ${GEO_TABLE} -v ${ALLOW_VALUE} |ipfw -q /dev/stdin we can embed that into scripts any way we want. let's call this "done", drop it into a port and get onto more productive things.. thanks for all the work and I already have a use for this in my home network.. My "home" network spreads over 2 continents with VPNs etc and I sometimes want to make sure that reaching certain sites only happens from the exit point near the destination, due to geo blocking. I think using geo-ip to sidestep geo blocking will be a perfect use. From owner-freebsd-ipfw@freebsd.org Fri Aug 5 08:03:27 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 66327BAF9E7 for ; Fri, 5 Aug 2016 08:03:27 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24F761B45 for ; Fri, 5 Aug 2016 08:03:27 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from vader9.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 602B12415 for ; Fri, 5 Aug 2016 10:03:24 +0200 (CEST) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: freebsd-ipfw@freebsd.org References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> <20160805034606.K56585@sola.nimnet.asn.au> <24bf65d1-1b4f-07a0-5a3c-93fd906f5705@freebsd.org> From: Jan Bramkamp Message-ID: <033c79d5-2a66-1000-7d2b-c81fdb287690@rlwinm.de> Date: Fri, 5 Aug 2016 10:03:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <24bf65d1-1b4f-07a0-5a3c-93fd906f5705@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 08:03:27 -0000 On 05/08/16 06:36, Julian Elischer wrote: > I ended up having to do this via an ugly use of skiptos where packets > I wanted to forward, were identified early and then sent to a duplicate > set of > rules which also did the divert, but then did the forward. I think > there were > about 25 rules duplicated. You could deduplicate this with a call/return pair but good luck ever debugging it if something goes wrong because the call/return stack is tied to the mbuf "allowing" you to call during igress and return during egress for maximal confusion. From owner-freebsd-ipfw@freebsd.org Fri Aug 5 12:10:29 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 DF004BB034B for ; Fri, 5 Aug 2016 12:10:29 +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::5]) (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 7FB691190 for ; Fri, 5 Aug 2016 12:10:29 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470399027; l=4270; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=5NVqRtQ9SP5bG+5CflfKiea6cwWLUbxKN/aiMj2yd14=; b=uxB0fj6BPhp6sEePzczWGJ6DJaqHDc0O/Vxg7wpj2UWz6s4AlOEtITi8Ot5AZJavheB of3QVPeny10RgyedQZmoPVwEKeSzrcS25WOIdq9IqDF4MclLnfYKWne/UwEuUqUms2i65 pnOkY6reNejTrwl6vaU3ikZ5w3qlynfEAtU= 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 Y09437s75CAQsSP (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) for ; Fri, 5 Aug 2016 14:10:26 +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 E9955229861E for ; Fri, 5 Aug 2016 09:10:23 -0300 (BRT) Content-Type: text/plain; charset=us-ascii 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: <7486c7ce-49db-b6b9-a6bb-13f04b4ce6d6@freebsd.org> Date: Fri, 5 Aug 2016 09:10:23 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160805024301.H56585@sola.nimnet.asn.au> <7486c7ce-49db-b6b9-a6bb-13f04b4ce6d6@freebsd.org> To: freebsd-ipfw@freebsd.org 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: Fri, 05 Aug 2016 12:10:30 -0000 > Am 05.08.2016 um 02:44 schrieb Julian Elischer : > On 5/08/2016 2:22 AM, Dr. Rolf Jansen wrote: >> 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. >>=20 >> Another possibility could be to attach the desired rule numbers = directly to the country codes in the argument of the -t option, How = about: >>=20 >> geoip -t AU=3D50000:RU=3D50010:US=3D50020:BR=3D50030 >>=20 >> 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 > I can hear the exasperation in your writing :-) Not exactly 'exasperation'. Moving targets are always kind of unpleasant = - at least for me, perhaps I am not a sufficiently patient hunter :-) > I've lost track.. > Was the present behaviour just a single value? or a generated number = with -x offset? (not sure if you actually added that or just described = it). I meant, geoip would continue allowing a -t option argument without = numbers, for example -t AU:RU:US:BR, and in that case it would continue = with its present behaviour (mutually exclusive either -v XOR -x): -v # default 0 -x # in val =3D (C1-60)*1000 + C2*10 + offset The -v and -x options as above are already on GitHub, the x-formula can = be changed quickly.=20 > your "US=3D50020" idea is nice but a lot of work I think for you. Not that much work. I like this one as well, because this is the most = explicit way, that I can imagine, of associating a rule/action number = with a country code. I figure, that any kind of x-formula let people shoot themselves in the = foot at one day or the other. Imagine you set up your sophisticated rule = set in 2016 and in 2017 a colleague is asked by the boss to add another = country code. The trouble may start by she/he forgets to add an action = rule for the implicitly generated table argument, and it does not end = with a possible violation of the implicitly reserved rule number range. > I guess you would do it with script > geoip -t US=3D${LINE_US} |ipfw -q /dev/stdin > ipfw add ${LINE_US} drop all tcp from any to any 80 > ipfw add $((${LINE_US} + 1)) skipto ${FINISH_UP} Yes, why not? The nice thing of the "CC=3Dnnnnn:..." feature is, that it = is already useful as is, and that it is open for any further = sophistication with shell script magics. =20 > probably in a shell function > it would also allow you to put 'action numbers' rather than line = numbers as it doesn't interpret the values, just passes them through. >=20 > On the other hand the same thing can be achieved by embedding geoip in = a loop in a script. > I think we should just let you get on with your life and be happy with = what you have given us. mapping a set of country codes to a number. I = can always make more complicated setups using that and 15 minutes of = shell script. Yes, for us this is not a big deal. However, once this stuff is in the = ports, I have to take into account the work of answering questions from = the non-enlightened folks, on how to achieve the mapping between rule = numbers and country codes. Perhaps, it is less hassle to simply add the = "CC=3Dnnnnn:..." feature and move on. BTW: In the course of preparing the packet for the ports, I am working now on = a man file for the geoip db utilities (geoip, ipdb and ipdb-update.sh). = I want to put it to section 1 - General Commands, OK? Shall I remove the geod ipfw divert filter daemon from the distribution = for the ports? My initial incentive was Geo-blocking. However, I learned from your VPN = usage example (in your other message), that these utilities may quite = well serve for other objectives. Now, I am looking for a package title = that does suggest a wider range of applications. How about: "Utilities for IP based Geo-blocking/routing with IPFW" Best regards Rolf