Re: [PATCH] netfilter: nft_paylaod: add base type NFT_PAYLOAD_LL_HEADER_NO_TAG

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

On Tue, Jun 18, 2019 at 12:42:32AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > Subject: Change bridge l3 dependency to meta protocol
> > > 
> > > This examines skb->protocol instead of ethernet header type, which
> > > might be different when vlan is involved.
> > >  
> > > +	if (ctx->pctx.family == NFPROTO_BRIDGE && desc == &proto_eth) {
> > > +		if (expr->payload.desc == &proto_ip ||
> > > +		    expr->payload.desc == &proto_ip6)
> > > +			desc = &proto_metaeth;
> > > +	}i
> > 
> > Is this sufficient to restrict the matching? Is this still buggy from
> > ingress?
> 
> This is what netdev family uses as well (skb->protocol i mean).
> I'm not sure it will work for output however (haven't checked).

You mean for locally generated traffic?

> > I wonder if an explicit NFT_PAYLOAD_CHECK_VLAN flag would be useful in
> > the kernel, if so we could rename NFTA_PAYLOAD_CSUM_FLAGS to
> > NFTA_PAYLOAD_FLAGS and place it there. Just an idea.
> 
> What would NFT_PAYLOAD_CHECK_VLAN do?

Similar to the checksum approach, it provides a hint to the kernel to
say that "I want to look at the vlan header" from the link layer.

> You mean disable/enable the 'vlan is there' illusion that nft_payload
> provides?  That would work as well of course, but I would prefer to
> switch to meta dependencies where possible so we don't rely on
> particular layout of a different header class (e.g. meta l4proto doesn't
> depend on ip version, and meta protocol won't depend on particular
> ethernet frame).

If we can fix all cases from userspace, that's fine.

> What might be useful is an nft switch to turn off dependeny
> insertion, this would also avoid the problem (if users restrict the
> matching properly...).

Hm. How does this toggle would look like?

> Another unresolved issue is presence of multiple vlan tags, so we might
> have to add yet another meta key to retrieve the l3 protocol in use
> 
> (the problem at hand was 'ip protocol icmp' not matching traffic inside
>  a vlan).

Could you describe this problem a bit more? Small example rule plus
scenario.

> The other issue is lack of vlan awareness in some bridge/netdev
> expressions, e.g. reject.

This needs to be fixed for bridge. There is no support for netdev yet,
IIRC.

> I think we could apply this patch to nft after making sure it works
> for output as thats probably the only solution that won't need
> changes in the kernel.

That's fine with me.

> If it doesn't, we will need to find a different solution in any case.

OK.