Re: [ANNOUNCE] ipset-5.0 released

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

 





Wouldn't you agree that this is a better solution than registering twice as
many members in a particular set in order to get the match I need?

Given that ports are only meaningful in the context of a protocol I don't think that makes sense.
You are mistaken! I've never actually stated, nor implied, that protocols are 'meaningless' when ports are specified or used - I stated that I am not interested in *matching* the protocol as for me this part of the match is irrelevant - there are plenty of examples where a particular service can employ either tcp or udp protocol on the same port - see below for examples.

If I want to block traffic to "port 80" in order to prevent access to a web server then what I'm rally saying is that I want top block traffic to "tcp port 80". There is no point in blocking udp port 80 too.
True, but that is an isolated case when I want to block a traffic to 1) a particular well-known service (web/http), which uses 2) a well-defined port (80 in this case) and 3) a well-defined protocol (tcp in this case).

That, as I already mentioned is an isolated case and defining the protocol and port in the ipset makes perfect sense. I would like to be able to define a match which captures subnets and port numbers regardless of the protocol involved (udp or tcp) - I thought I made that perfectly clear.

While there are some servers out there that use connections on the same port on both udp and tcp (e.g. DNS) these are the exception and should still be handled explicitly by defining rules for both protocols separately.
I disagree! Why should I have to define 2x as many members in a particular set in order to cover tcp and udp protocols where, in reality, I have no interest whatsoever in matching the protocol element at all - all I need is a subnet match and a port number, the protocol part (whatever that is - udp or tcp) is completely irrelevant - I do not really care whether the protocol is tcp or udp.

Why would you want to match a port for all protocols? Do you have a specific example for that?
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. 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 and media streaming too, not to mention the (notoriously bad) Microsoft NetBIOS (ports 135, 137, 138 and 139), WINS or even LDAP. Various databases (MySQL, PostgreSQL and Oracle to name a few) also utilise both protocols on the same port numbers.

Using tcp as well as udp traffic on the same port numbers is not as uncommon as you might think, hence why I would like to have subnet and port matching regardless of what the protocol is.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux