On Tue, Jun 18, 2019 at 12:42:32AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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.
