ipfw divert filter for IPv4 geo-blocking

[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 
 > 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