[RFC|Accepted] IP banning to use 'longest prefix matching'

Note: We are moving the topics of this forum and it will be deleted at some point

Publish your own request for comments/change or patches for the next version of phpBB. Discuss the contributions and proposals of others. Upcoming releases are 3.2/Rhea and 3.3.
User avatar
bantu
3.0 Release Manager
3.0 Release Manager
Posts: 557
Joined: Thu Sep 07, 2006 11:22 am
Location: Karlsruhe, Germany
Contact:

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by bantu » Tue May 01, 2012 10:50 am

AmigoJack wrote:I discourage storing CIDR notation - that'd be human readable, but comparing IPs would always end up in string operations for the DBMS.
You can store the network address as a 32 bit integer and the prefix as a 5 bit integer for IPv4 without requiring any string operations. The question I raised is only about whether users should be able to ban arbitrary ranges or only "CIDR ranges".

User avatar
AmigoJack
Registered User
Posts: 103
Joined: Wed May 04, 2011 7:47 pm
Location: グリーン ヒル ゾーン
Contact:

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by AmigoJack » Tue May 01, 2012 4:07 pm

They should be able to do both. At least boards being used in intranets only might have their reasons to ban ranges which can't be expressed in a subnet mask (or would then be forced to use multiple entries). Not to mention that I expect only a fraction of users to know/handle a CIDR notation.

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by brunoais » Tue May 01, 2012 5:10 pm

I like AmigoJack's proposal.
We just need to separate an IP by its dot decimal having numbers form 0 to 255 for IPv4 and have ":" hexadecimal for IPv6. Using hexadecimal isn't that hard.
For a number like 'ff' we just need to prepend "0x" forming "0xff" and then ask php to parse it as a integer. In order to be platform independent we must work with 32 bit integers and there is no doubt that 0xffff fits in an integer. So we can have an array of integer with all the parts of the IPv6.
Something like:

Code: Select all

$ipv6_parts = explode(':', $ipv6);
foreach($ipv6_parts AS $part => $ip)
{
    $ipv6_parts[$part] = (int) '0x' . $ip;
}
 
We could then use something like AmigoJack made to search in the DB and seems like quite straight forward.
I'd also mark the from1, from2, from3, from4, from5, from6, from7, from8 as unique, same for the from. With that both would be indexed and some constraining would be automatically added to prevent duplicates in the from as they are unnecessary.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by Oleg » Tue May 01, 2012 11:10 pm

The issue is not so much string operations as the fact that we store a lot more data than we have to. For each banned range (arbitrary range) we should convert endpoints to something that can be compared via less-than. For ipv4 we can use 32-bit integers, for ipv6 we'll have to encode into strings for compatibility most likely. But regardless we'll have one row per banned entry and we could have an index on the lower bound that would be used for querying.

I am not a fan of requiring banned blocks to be /xx subnets.

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by brunoais » Wed May 02, 2012 6:12 am

Oleg wrote:For ipv4 we can use 32-bit integers, for ipv6 we'll have to encode into strings for compatibility most likely.
Not needed. Any database has an integer.
E.g. MySQL has the BIGINT that goes form -9223372036854775807 to 9223372036854775807. If it is unsigned it is even bigger.
The problem is with PHP. PHP's int only guarantees from -2147483647 to 2147483647, going out of that is not platform independent. That is not enough to store a complete IPv6 address even though it has space to store each of the 8 fractions of an IPv6 address (each part between the ":").

(Edit: improved english)

User avatar
AmigoJack
Registered User
Posts: 103
Joined: Wed May 04, 2011 7:47 pm
Location: グリーン ヒル ゾーン
Contact:

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by AmigoJack » Wed May 02, 2012 2:59 pm

brunoais wrote:The problem is with PHP
Why? Where is there any need to use an Integer in PHP? That's the most important advantage of my approach: the database query is always a string and only the database itself uses Integers. No PHP limitations, no beyond-32bit-requirements for the DBMS.

Of course: if you want to query all IP ranges once and then cache them in PHP code it's another story.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by Oleg » Wed May 02, 2012 4:30 pm

ipv6 addresses, being 128 bits long, do not fit into bigints.

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by brunoais » Thu May 03, 2012 7:36 am

Oleg wrote:ipv6 addresses, being 128 bits long, do not fit into bigints.
Yes. That's why I think we should split IPv6 addresses by its parts (by each ":"). Each of those fit into a php's integer.
We just need to be careful with IP's that usually use "::" like: ::1 or ffff:ff00::gfser:weqe (both are completely valid IPv6 IP's)

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by Oleg » Thu May 03, 2012 5:07 pm

I am getting the impression that you do not understand the problem being discussed. Please reread the first post and my earlier post here. The issue, again, primarily is with how the banned ips are stored in the database.

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC|Accepted] IP banning to use 'longest prefix matchin

Post by brunoais » Fri May 04, 2012 9:06 am

^
I still think they should be stored as 8 integers. They are easy to work with and easy to search (if we use indexes, of course). Also, the IPv6 address representaion are already separated into multipart integers (seperated by a ":").

Post Reply