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] [day] [month] [year] [list]
Message-ID: <9b245c1e-997a-4224-a819-3a3f1aee8b3f@avm.de>
Date: Thu, 12 Sep 2024 13:33:39 +0200
From: tmartitz-oss <tmartitz-oss@....de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Roopa Prabhu <roopa@...dia.com>, Nikolay Aleksandrov
 <razor@...ckwall.org>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, jnixdorf-oss@....de,
 bridge@...ts.linux.dev, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] net: bridge: drop packets with a local source

Hello Andrew,

Am 11.09.24 um 18:33 schrieb Andrew Lunn:
> On Wed, Sep 11, 2024 at 02:58:17PM +0200, Thomas Martitz wrote:
>> Currently, there is only a warning if a packet enters the bridge
>> that has the bridge's or one port's MAC address as source.
>>
>> Clearly this indicates a network loop (or even spoofing) so we
>> generally do not want to process the packet. Therefore, move the check
>> already done for 802.1x scenarios up and do it unconditionally.
> Does 802.1d say anything about this?
>
> Quoting the standard gives you a strong case for getting the patch
> merged.

I have 802.1q, the successor to 802.1d, at hand. It's a large document 
and I haven't read
all the details yet. From a coarse reading I get the impression that a 
bridge entity could
chose to filter such frames (based on "Filter Database" information 
which translates to our
BR_FDB_LOCAL flag), or forward to potential ports.

If we say we still want to forward these frames, that would probably be 
OK. The main
purpose of the patch is to avoid local processing of IGMP and other 
stuff. So at a minimum
we must avoid passing the frame up the stack and IGMP/MLD snooping code 
in addition
to the current handling (which is limited to avoiding to update the FDB).

However, I have a hard time to imagine legitimate cases of forwarding a 
frame again
that we obviously send out earlier. This is not helpful to our overall 
goal to stop storms when
customers manage to make loops in their networks (remember that we build 
routers
for end-user homes and loops are a constant source of problem reports).

Dropping on ingress is, in my opinion, also the better response to MAC 
spoofers on the network.

Best regards.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ