Re: Extensions for ICMP[6] with sport, dport

[Rick van Rein <rick@openfortress.nl>]

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