Date: Mon, 1 Aug 2016 04:38:44 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "Dr. Rolf Jansen" <rj@obsigna.com> Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw divert filter for IPv4 geo-blocking Message-ID: <20160801030317.P29054@sola.nimnet.asn.au> In-Reply-To: <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <CAHu1Y739PvFqqEKE74BjzgLa7NNG6Kh55NPnU5MaA-8HsrjkFw@mail.gmail.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <c2cd797d-66db-8673-af4e-552dfa916a76@freebsd.org> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <C0CC7001-16FE-40BF-A96A-1FA51A0AFBA7@obsigna.com> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <CAFPNf59w6BHgDjLNHW=rQckZAFG4gqPHL49vLXiDmMAxVPOcKg@mail.gmail.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <c62fa048-63c8-aef6-5bad-b0a6719f6acb@freebsd.org> <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160801030317.P29054>