Re: [ANNOUNCE] ipset-5.0 released

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




The algorithm does not allow to ignore the protocol part. That's the reason why double lookup would be needed if such syntactic sugar as 'tcpudp' were introduced. Lets assume we store in the artifical set above two elements:

192.168.0.1,tcpudp:53
192.168.0.1,tcp:80

Now, assuming that first 'tcpudp' is looked up, to match the first element, we need one lookup. To check the existence of the second element, we have to use two lookups: first with '192.168.0.1,tcpudp:80' (nomatch), then with '192.168.0.1,tcp:80'. And to check the existence of any non-matching element (say 192.168.0.1,udp:123) needs again two lookups.
Then your matching algorithm is wrong!

Using your example above, I'd add the following change: the protocol specifier could be converted (internally) to a number: 1 - tcp (1 in binary form), 2 - udp (10 in binary form), 3 - 'tcp and udp' (11 in binary form). When you need to match against a real protocol (which, if I am not mistaken, can only be either tcp or udp), then you can use binary 'and' operation (&) with one simple statement to determine whether there is a match. Using your example above, we will have the following (internal) representation:

192.168.0.1,3,53
192.168.0.1,1,80

Thus, to check for 192.168.0.1:53 (tcp) - there will be a match as when you apply 1) ip match; and 2) protocol match - i.e. 1 & 3 (1 & 11) you will get >0, therefore protocol matches; and 3) port match, there is a match on all 3 elements, hence return a complete match. Just one lookup needed.

When you have 192.168.0.1:53 (udp) the situation is exactly the same as far as the protocol goes - 2 & 3 (10 & 11) you will get > 0, hence there is a match again. Just one lookup needed.

When you have 192.168.0.1:80 (tcp) - you will have a match on the ip and protocol, bit mismatch on the port, so no match - you also need one lookup.

You have exactly the same scenario with 192.168.0.1:123 (udp) - match on the ip and protocol part, but mismatch on the port, so no match!

Such a hack thus would penalize the normal cases.
There is no need for a 'hack' just sensible and efficient programming, that's all.

I am not sure I understand you.

If you need to match the same port both with TCP and UDP, then add it to the set twice, with the proper protocols.
I've already dealt with this - I do not see the need to add 2x as many elements to a set when, in reality, I am not interested in matching the protocol part.

There is a problem with this - the 'bond' which exists with (the imaginary and
working) hash:ip,all,port (i.e. the implicit link between the element's ip
address/subnet and the port or port range)  is not there if two separate sets
are used!

[...]

Yes, therfore my assumption was that the ports are uniform, identical for all elements.
An isolated case and one which does not apply to a common scenario.

You already mentioned DNS, I'd add DHCP to that list as well as VPN, IPSec and Kerberos traffic, which could be either tcp or udp on the same port numbers.

DHCP uses UDP only.
You are mistaken - DHCPv6 (client as well as server configurations) uses both TCP and UDP protocols on the same port numbers.


VPN (e.g OpenVPN) can be configured to use UDP or TCP, but not both at the same time.
You are assuming that I will have a single machine on which VPN is running, which, again, is an isolated case. When I have a central hub, which controls multiple subnets VPN packets can originate from (or be destined to) the same port numbers using TCP as well as UDP protocols.

For ipset point of view, IPSec is an independent (actually, two, AH and ESP) protocol. Kerberos uses a couple of TCP and UDP ports, but not both with the same port number (except for changing password under Windows, if you have to support both the old and new interfaces).
Again, not true and you are assuming I am running a single machine - that is not the case at all.

Kerberos remote login, change password (except klogin which uses tcp only), administration and kreg can all be ran using either tcp or udp on the same port numbers. As for IPSec - the situation is exactly the same - port 1293 with either tcp or udp utilised.

VOIP (including STUN, RTP and SIP) is another example - not only the port numbers vary wildly within (usually) pre-defined group, but could utilise tcp as well as the udp protocol on these ports. IRC

STUN uses a single port over TCP and UDP.
Yep, that's right - both protocols could be used on the same port.

RTP may run over TCP but the majority of the applications uses UDP only.
Again, utilising TCP is not as uncommon as you might think - TCP gives you better line quality when you have good (optical for example) network and it is also the preferred option when you utilise encrypted data streams. Same goes for SIP.

SIP is complex... IRC uses TCP only.
IRC on Port 194, protocols could be either TCP or UDP, again, depending on the configuration. AOL instant messenger also utilises both tcp and udp protocols on the same port (531).


or even LDAP. Various databases (MySQL, PostgreSQL and Oracle to name a few) also utilise both protocols on the same port numbers.

LDAP and *SQL use TCP only.
Wrong again! Check the documentation for the databases I mentioned properly and you will see that MySQL could use 3306 utilising both tcp and udp protocols, PostgreSQL can also utilise both protocols on its common port (5432) and with the case of Oracle - although the commonly used Oracle port is 1521 it also utilises ports 2483 (for insecure) and 2484 (for secure) client connections replacing the 'old' 1521 port for insecure client connections.

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux