netfilter buglog - Mar 2016 - [Bug 1057] New: Allow for multiple protocols to be specified in a rule

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

            Bug ID: 1057
           Summary: Allow for multiple protocols to be specified in a rule
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: karol at babioch.de

Since DNS is allowed over both UDP as well as TCP, I have to specify two rules
each time I want to allow DNS traffic. This looks something like this:

    oif eth0 udp dport domain accept
    oif eth0 tcp dport domain accept

In an example found online [1] someone showed the following example:

    {udp, tcp} sport domain ip daddr 127.0.0.1 accept

Apparently this was never tested. At least it doesn't work for me. For the
example above it would look something like this:

    oif eth0 {udp, tcp} dport domain accept

This would make rulesets easier to read, which is why I want to suggest this as
future enhancement.

[1]: https://home.regit.org/2014/01/why-you-will-love-nftables/

-- 
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/20160308/6f8aa647/attachment.html>

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

--- Comment #1 from Karol Babioch <karol at babioch.de> ---
I'm not too familiar with the internals of nft, but implementation might be
as
"easy" as translating such rules (with multiple protocols) into two
(or
multiple) rules. It might be more complicated to get it merged into a single
rule when using the list ruleset functionality, but this should also be
possible.

-- 
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/20160308/99ecab4b/attachment.html>

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>

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

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kfm at plushkava.net

--- Comment #3 from kfm at plushkava.net ---
This bug can be closed, because it is now possible to write:

    oif eth0 meta l4proto { tcp, udp } @th,16,16 dport domain accept

And, since version 0.9.2:

    oif eth0 meta l4proto { tcp, udp } th dport domain accept

-- 
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/20200205/fec8fa77/attachment.html>

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

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at strlen.de
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

-- 
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/20200908/b8e980d7/attachment.html>