Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?20160801030317.P29054>