proto: add pseudo th protocol to match d/sport in generic way

Problem: Its not possible to easily match both udp and tcp in a single
rule.

... input ip protocol { tcp,udp } dport 53

will not work, as bison expects "tcp dport" or "sctp dport", or any
other transport protocol name.

Its possible to match the sport and dport via raw payload expressions,
e.g.:
... input ip protocol { tcp,udp } @th,16,16 53

but its not very readable.
Furthermore, its not possible to use this for set definitions:

table inet filter {
        set myset {
                type ipv4_addr . inet_proto . inet_service
        }

        chain forward {
                type filter hook forward priority filter; policy accept;
                ip daddr . ip protocol . @th,0,16 @myset
        }
}
 # nft -f test
 test:7:26-35: Error: can not use variable sized data types (integer) in concat expressions

During the netfilter workshop Pablo suggested to add an alias to do raw
sport/dport matching more readable, and make it use the inet_service
type automatically.

So, this change makes @th,0,16 work for the set definition case by
setting the data type to inet_service.

A new "th s|dport" syntax is provided as readable alternative:

ip protocol { tcp, udp } th dport 53

As "th" is an alias for the raw expression, no dependency is
generated -- its the users responsibility to add a suitable test to
select the l4 header types that should be matched.

Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>

1 files changed, 9 insertions, 0 deletions

diff --git a/doc/payload-expression.txt b/doc/payload-expression.txt
index b98a6077..dba42fd5 100644
--- a/doc/payload-expression.txt
+++ b/doc/payload-expression.txt
@@ -498,6 +498,15 @@ Transport Header, for example TCP
 ----------------------------------------------
 inet filter input meta l4proto {tcp, udp} @th,16,16 { 53, 80 }
 -----------------------------------------------------------------
+The above can also be written as
+-----------------------------------------------------------------
+inet filter input meta l4proto {tcp, udp} th dport { 53, 80 }
+-----------------------------------------------------------------
+it is more convenient, but like the raw expression notation no
+dependencies are created or checked. It is the users responsibility
+to restrict matching to those header types that have a notion of ports.
+Otherwise, rules using raw expressions will errnously match unrelated
+packets, e.g. mis-interpreting ESP packets SPI field as a port.
 
 .Rewrite arp packet target hardware address if target protocol address matches a given address
 ----------------------------------------------------------------------------------------------