Hey Florian,
You are generalising ICMP matching to tunnel matching, and then conclude that it is quite complex.
Yes, there is some overlap, but ICMP is also quite different:
- Encapsulated traffic travels in reverse compared to a tunnel
- ICMP-contained content must be NAT-reversed, unlike tunnel content
- ICMP carries cut-off headers: IP header + 8 bytes of its payload
- In practice, the contents of interest would be ip|ip6 and th
- References "icmp ip" and "icmp th" are simple-yet-enough
- General tunnel logic may be less efficient?
I originally proposed to treat ICMP as a side-case to TCP et al, but that won't fly. There's also an embedded saddr/daddr pair to be treated. This also means that the silent reversal of sport/dport is not needed, which is a relief.
> I think instead of this specific use case it would be preferrable to
> tackle this in a more general way, via more generic "ip - in foo"
> matching.
Given the differences above, do you still think so?
I would argue that these provide (not 100% hard) reasons to treat ICMP differently from tunnels. Possibly syntaxes, in line with what "nft" does now, could say things like
ip protocol icmp
icmp protocol { tcp, udp, sctp, dccp }
icmp th daddr set
icmp th dport map @my-nat-map
This looks like an extension of the nft command, under my assumption that it computes fixed offsets. There may be more trouble with two-variable comparisons, which would cover paranoid checks like
icmp daddr = saddr
icmp saddr = daddr
icmp th dport = sport
icmp th sport = dport
If this ends up being kernel work, then I'm afraid I will have to let go.
Thanks,
-Rick
