lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc34e774-e264-492c-9ecb-20eaf7bd87e8@gmail.com>
Date: Tue, 8 Apr 2025 20:33:42 +0200
From: Eric Woudstra <ericwouds@...il.com>
To: Florian Westphal <fw@...len.de>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
 Jozsef Kadlecsik <kadlec@...filter.org>,
 Nikolay Aleksandrov <razor@...ckwall.org>, Ido Schimmel <idosch@...dia.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Simon Horman <horms@...nel.org>, netfilter-devel@...r.kernel.org,
 bridge@...ts.linux.dev, netdev@...r.kernel.org
Subject: Re: [PATCH v11 nf-next 1/2] netfilter: bridge: Add conntrack double
 vlan and pppoe



On 4/8/25 6:39 PM, Florian Westphal wrote:
> Eric Woudstra <ericwouds@...il.com> wrote:
>> This adds the capability to conntrack 802.1ad, QinQ, PPPoE and PPPoE-in-Q
>> packets that are passing a bridge.
> 
> Conntrack is l2 agnostic, so this either requires distinct
> ip addresses in the vlans/pppoe tunneled traffic or users
> need to configure connection tracking zones manually to
> ensure there are no collisions or traffic merges (i.e.,
> packet x from PPPoE won't be merged with frag from a vlan).
> 
> Actually reading  nf_ct_br_defrag4/6 it seems existing
> code already has this bug :/
> 
> I currently don't see a fix for this problem.
> Can't add L2 addresses to conntrack since those aren't
> unique accross vlans/tunnels and they can change anyway
> even mid-stream, we can't add ifindexes into the mix
> as we'd miss all reply traffic, can't use the vlan tag
> since it can be vlan-in-vlan etc.
> 
> So likely, we have to live with this.
> 
> Maybe refuse to track (i.e. ACCEPT) vlan/8021ad qinq, etc.
> traffic if the skb has no template with a zone attached to it?
> 
> This would at least push 'address collisions' into the
> 'incorrect ruleset configuration' domain.

Thanks for the input. I will look in to it and see if I can also add it
to the test script.

The thing is, single vlan (802.1Q) can be conntracked without setting up
a zone. I've only added Q-in-Q, AD and PPPoE-in-Q. Since single Q (L2)
can be conntracked, I thought the same will apply to other L2 tags.

So would single Q also need this restriction added in your opinion?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ