[Bug 1057] Allow for multiple protocols to be specified in a rule

bugzilla-daemon at netfilter.org bugzilla-daemon at netfilter.org
Sat Mar 18 01:34:30 CET 2017


https://bugzilla.netfilter.org/show_bug.cgi?id=1057

Robert White <rwhite at pobox.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rwhite at pobox.com

--- Comment #2 from Robert White <rwhite at pobox.com> ---
I am not an authority here by any means, but I spotted this while checking
whether a different idea of mine would be a duplicate...

The problem I see is that your example conflates syntax and value.

So you asked for:
{udp, tcp} sport domain ip daddr 127.0.0.1 accept

Which you want to be equivalent to the working syntax
tcp sport domain ip daddr 127.0.0.1 accept
udp sport domain ip daddr 127.0.0.1 accept

But in this case the "udp" and "tcp" respectively introduce the syntax for
"sport" instead of being just a selector for the protocol numeric value. After
all, other ip protocols like "icmp" don't have any ports, source or
destination.

Note that you can select for multiple protocols by value using "meta protocol":
add rule example foo meta protocol { udp, tcp } ip daddr 127.0.0.1 accept

But the actual rule you asked for is problematic because other (think raw
numeric) protocols may generate packets that aren't even long enough for the
lookup of the memory that might hold "sport" to be present.

But what happens for
add rule example foo meta protocol { udp, tcp, 73 } sport domain ip daddr
127.0.0.1 accept

Does protocol 73 even have an sport value?

The necessary underlying code seems like it'd get back to being awfully twisty.

A unified header of some name that has all the common fields for tcp, udp, and
anything else that happens to line up (sctp? udplite?) (much like "inet"
unified "ip" and "ipv6") might be worthwhile eventually to get to dport and
sport entries, but it might get confusing or elaborate compared to the system
speed and focus targets for the project.

Something like u16 matching could do this explicity (is that even an thing in
iftables?) but that "optimization" would probably be slower than just having
two rules.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170318/6fb8f7be/attachment.html>


More information about the netfilter-buglog mailing list