Re: RFC: Ideas about possible solutions for nfbz#949

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi Phil,

I'm recovering this RFC that got lost in the pile.

On Wed, May 10, 2017 at 05:34:29PM +0200, Phil Sutter wrote:
> Hi,
> 
> Netfilter Bugzilla #949[1] complains about broken output when trying to
> match icmpv6 message fields. This is a problem in how payload match is
> implemented in nft: The given match (e.g. 'icmp6 id 2') is broken down
> to a simple match of header data at a specific offset. Sadly this does
> not work with ICMP(v6) since header structure depends on the packet's
> ICMP type and on return path there is no information about which type of
> message the user wanted to match against.

Right, this is a longstanding bug.

> My idea was to build something like the protocol dependencies we have
> for e.g. TCP header fields but with ICMP, a given header field might be
> present in multiple message types (e.g. icmp6_id is present in echo
> request as well as reply).

You mean adding more instructions when generating bytecode? This has
runtime overhead, just to provide context for just listing the
ruleset. I would prefer we skip this.

> I already considered inserting a match for icmp6 type against an
> anonymous set (like 'icmp6 type { echo-request, echo-reply }'), but
> having this as an implicit dependency and resolving with previous
> matches, etc. becomes pretty complex.
> 
> Do you think I should try following a different approach (via userdata
> e.g.)?

I think you should try adding some context structure to the
expr_print(), this context can be used to interpret this offset based
on the icmp type.

Someone (Elise?) send me a patch to add this context structure, just
to prepare introduction, but she got stuck in the context update
logic at some point. I can find such patch so you only have to figure
out how to annotate the information we need in this context structure.