Re: [ANNOUNCE] ipset-5.0 released

[Mr Dash Four <mr.dash.four@googlemail.com>]

>> You are expanding the command line port ranges (80-82 in your example above)
>> to add the underlying elements. Could you not do a similar arrangement for the
>> protocol as well?
>>     
> That won't go: tcp and udp are not the possible protocols alone, so by any 
> reasonable syntax, '*' or 'all' should have to mean all protocols from 
> /etc/protocols.
>   
Whatever the appropriate place holder is - 'all', '*', '@', '$$$$$$' 
etc. etc - as long as it does the job at the end it won't matter.

>> It is not a perfect solution by any stretch, but at least it will save me the
>> hassle, as with the introduction of the port ranges, of executing the
>> statement twice each time I want to include net and port ranges without being
>> interested in the protocol match.
>>     
>
> What I could come up as something similar in effect is to make possible to 
> use a copy of /etc/services maintained by the administrator of the given 
> ipset installation and whatever protocols and ports a service name is
> resolved to from that file, use those.
>   
I wasn't aware that there are more than 2 (tcp and udp) protocols on 
which I could define/use ports!

> However such a feature won't be added tomorrow. Nor this year (:-) or the 
> very near future.
>   
What are your plans?

> For the "net" (sub)type of sets the different prefixes in the set is 
> recorded. When testing (adding/deleting) entries, the IP part of the entry 
> is masked with the prefixes one by one and looked up until a match is 
> found or the list is exhausted - that's why the speed is linearly slows 
> down with the different number of prefixes added to the set. An example:
>
> # ipset create test hash:net
> # ipset add test 192.168.0.0/30
> # ipset add test 192.168.1.0/24
>
> There are two different prefixes in the set, 30, 24. So when the command 
> is issued
>
> # ipset test test 192.168.0.1
>
> the address 192.168.0.1 is masked with /30 and the result is looked up 
> and the match is reported:
>   
So, in other words 'internally' you store something like (using your 
example above) 192.168.0.0 (the IP part), 30 (the prefix), tcp, 80 in 
the structure, is that right?
Do you then use the mask of each member of that set (30 and 24 in your 
example above) until you get a match? In other words, you 'walk through' 
every internally stored element and try their mask and then lookup for a 
match, is that how you do it?


>> Is this slowdown more than when I use iptreemap set for example? How does the
>> new set (hash) performance compares against the 'old' iptreemap/treemap sets
>> used in 4.x?
>>     
>
> I never measured the speed difference between the two types. A good guess 
> is that iptreemap is faster.
Thought so!

> However, the problem with iptree(map) is that 
> it's susceptible when used as a container to block attackers dynamically 
> by the SET target: it's trivial to mount an attack by which the worst tree 
> structure is forced to be created.
Could you expand on that bit please? What do you mean?