netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dennis Jacobfeuerborn <dennisml@conversis.de>
To: Mr Dash Four <mr.dash.four@googlemail.com>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
	netfilter-devel@vger.kernel.org, netfilter@vger.kernel.org
Subject: Re: [ANNOUNCE] ipset-5.0 released
Date: Sun, 19 Dec 2010 16:20:05 +0100	[thread overview]
Message-ID: <4D0E22A5.8090808@conversis.de> (raw)
In-Reply-To: <4D0E0E2A.3090604@googlemail.com>

On 12/19/2010 02:52 PM, Mr Dash Four wrote:
>
>>> By 'something' I mean either omission of the protocol, or 'all' to be
>>> specified instead of the protocol to mean no matching on protocol would be
>>> made (in other words the protocol to be disregarded). This will be
>>> especially
>>> useful for sets with quite a few number of members and will avoid
>>> unnecessary
>>> duplication - as things stand I have to add the same number of members for
>>> both tcp and udp protocols when I don't need any protocol matching -
>>> just the
>>> subnets and port numbers I specified. Is this doable?
>>
>> Use set types without port sub-part, like hash:net or hash:ip, etc.
>> I don't really see why you would want to use a type with port and then
>> ignore it.
> I don't want to ignore the port - that stays (I need it to do the
> matching). I want to ignore the protocol, but keep the subnet and port
> number matches.
>
> As I already mentioned, I see the need to register 2x as many members to a
> particular set just to get the match required (i.e. ignore the protocol)
> unnecessary when the alternative is to a) do not use protocol definition;
> or b) use another word (I suggested 'all') to ignore the protocol match and
> just use the subnet and port number(s) instead.
>
> 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. 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. 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.
Why would you want to match a port for all protocols? Do you have a 
specific example for that?

Regards,
   Dennis

  reply	other threads:[~2010-12-19 15:20 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-17 22:26 [ANNOUNCE] ipset-5.0 released Jozsef Kadlecsik
2010-12-17 23:32 ` Jan Engelhardt
2010-12-18 10:40   ` Jozsef Kadlecsik
2010-12-18  7:29 ` Rob Sterenborg (lists)
2010-12-18 11:13   ` Jozsef Kadlecsik
2010-12-18 15:43     ` Jan Engelhardt
2010-12-18 19:50       ` Jozsef Kadlecsik
2010-12-18 21:49         ` Jan Engelhardt
2010-12-19  0:05           ` Jozsef Kadlecsik
2010-12-19  0:28             ` Jan Engelhardt
2010-12-19  5:56           ` Jan Engelhardt
2010-12-19 18:23     ` Rob Sterenborg (lists)
2010-12-21 11:14     ` Rob Sterenborg (lists)
2010-12-21 14:03       ` Jozsef Kadlecsik
2010-12-18 14:22 ` Mr Dash Four
2010-12-18 20:23   ` Jozsef Kadlecsik
2010-12-18 21:51     ` Mr Dash Four
2010-12-18 22:10       ` Jan Engelhardt
2010-12-18 22:23         ` Mr Dash Four
2010-12-19  0:34       ` Jozsef Kadlecsik
2010-12-19 13:52         ` Mr Dash Four
2010-12-19 15:20           ` Dennis Jacobfeuerborn [this message]
2010-12-19 17:04             ` Mr Dash Four
2010-12-22 10:59               ` Jozsef Kadlecsik
2010-12-22 12:48                 ` Mr Dash Four
2010-12-23 15:39                   ` Jozsef Kadlecsik
2010-12-23 17:50                     ` Mr Dash Four
2010-12-23 17:55                       ` David Miller
2010-12-23 18:00                         ` Mr Dash Four
2010-12-23 18:06                           ` David Miller
2010-12-23 18:10                             ` Mr Dash Four
2010-12-23 19:35                       ` Jozsef Kadlecsik
2010-12-23 22:23                         ` Mr Dash Four
2010-12-23 22:46                           ` Jozsef Kadlecsik
2010-12-23 22:56                             ` Jozsef Kadlecsik
2010-12-23 23:06                               ` Mr Dash Four
2010-12-26 10:30                                 ` Jozsef Kadlecsik
2010-12-26 13:47                                   ` Mr Dash Four
2010-12-26 20:09                                     ` Jozsef Kadlecsik
2010-12-26 21:44                                       ` Mr Dash Four
2010-12-27 14:49                                         ` Jozsef Kadlecsik
2010-12-27 16:23                                           ` Mr Dash Four
2010-12-27 18:20                                             ` Jozsef Kadlecsik
2010-12-27 18:52                                               ` Mr Dash Four
2010-12-28 19:26                                                 ` Jozsef Kadlecsik
2010-12-23 23:03                             ` Mr Dash Four
2010-12-26 10:32                               ` Jozsef Kadlecsik
2010-12-23 21:51                       ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D0E22A5.8090808@conversis.de \
    --to=dennisml@conversis.de \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=mr.dash.four@googlemail.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).