netdev - Re: [PATCH net-next] net: bridge: do not send arp replies if src and target hw addr is the same

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: <bdb86076-d4ce-49b3-8ceb-742f61f05559@nbd.name>
Date: Tue, 9 Jan 2024 13:41:47 +0100
From: Felix Fietkau <nbd@....name>
To: Nikolay Aleksandrov <razor@...ckwall.org>, Paolo Abeni
 <pabeni@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: bridge: do not send arp replies if src and
 target hw addr is the same

On 09.01.24 13:02, Nikolay Aleksandrov wrote:
> On 09/01/2024 13:58, Felix Fietkau wrote:
>> On 09.01.24 12:36, Paolo Abeni wrote:
>>> On Thu, 2024-01-04 at 15:25 +0100, Felix Fietkau wrote:
>>>> There are broken devices in the wild that handle duplicate IP address
>>>> detection by sending out ARP requests for the IP that they received from a
>>>> DHCP server and refuse the address if they get a reply.
>>>> When proxyarp is enabled, they would go into a loop of requesting an address
>>>> and then NAKing it again.
>>>
>>> Can you instead provide the same functionality with some nft/tc
>>> ingress/ebpf filter?
>>>
>>> I feel uneasy to hard code this kind of policy, even if it looks
>>> sensible. I suspect it could break some other currently working weird
>>> device behavior.
>>>
>>> Otherwise it could be nice provide some arpfilter flag to
>>> enable/disable this kind filtering.
>> 
>> I don't see how it could break anything, because it wouldn't suppress non-proxied responses. nft/arpfilter is just too expensive, and I don't think it makes sense to force the use of tc filters to suppress nonsensical responses generated by the bridge layer.
>> 
>> - Felix
>> 
> 
> I also share Paolo's concerns, and I don't think such specific policy
> should be hardcoded in the bridge. It can already be achieved via tc/nft/ebpf
> as mentioned. Also please CC bridge maintainers for bridge patches, I saw this
> one because of Paolo's earlier reply.

Why is this 'specific policy'? I'm not changing the bridge to filter 
quirky ARP responses generated elsewhere. I'm simply changing the bridge 
code to avoid generating nonsensical ARP responses by itself.

Also, I can't replicate the exact behavior with a nft/tc filter, because 
a filter can't differentiate between forwarded ARP responses and bogus 
fake responses generated by the bridge code itself.

The concern regarding breaking existing devices also makes no sense to 
me at all. From my perspective, proxyarp is an optimization that you 
should be able to turn on without breaking breaking existing devices.
The fact that the current code violates that expectation is something 
I'm trying to fix.

- Felix