Rate-limit the packets accepted by the BPF filter?

[bengal]

Currently, the BPF filter accepts all packets with the right IP/MAC, and those packets are passed to user space. Someone could cause a Denial of Service on the program using the library by sending a flood of ARP packets on the local network. This will keep the program busy and unable to do anything else.

Would it make sense to add a rate-limiting mechanism to the BPF program? It could be e.g. token bucket or even something simpler like storing the timestamp for each IP in a map, and dropping packets for the same IP if they are too close to the last timestamp.

[dvdhrm]

Isn't this inherent to link-local connections? Either you have a clever switch that blocks ARP-spoofing, flooding, etc., or you are screwed and link-local can just mess with you, anyway?

I mean, why would someone try to cause a DoS via arp-flooding, if they could just cause an address-conflict instead?

[bengal]

That's a good point. Perhaps the difference is that with flooding an attacker can bring the program to a complete halt and this can affect other interfaces, or other programs in the system that depend on it. While by just causing an address conflict, an attacker can just prevent the use of the address on that specific interface. I don't know if this is a reason strong enough to add some kind of filtering, though, it's fine for me to close this issue otherwise.

I am reporting this because we faced a scenario in which NetworkManager was stuck due to ARP flooding on a secondary interface, and the flooding was caused by a wrong switch configuration. From the logs we could only see that NM was stuck for several minutes. In that specific case, the problem would have been prevented if NM had eBPF enabled. However, this made us realize that if the ARP packets are crafted with the right IP and MACs, they would all match the eBPF filter and they would be passed to userspace anyway, causing a DoS.

[dvdhrm]

I was going at this from a security perspective, but if we just consider keeping systems accessible / reactive under load, there is definitely room for improvement. I wonder, though, whether n-acd is the right place to do this.

Wouldn't an I/O scheduler combined with a CPU scheduler be much better? You use the I/O scheduler to ensure all interfaces get the same throughput, even if one is flooded. And then you use a CPU scheduler, to ensure NetworkManager (or similar) does not block the system if the network is flooded?

It seems like whack-a-mole trying to add rate-limiting to n-acd. And even if we did, what is a reasonable rate-limit, anyway?

I haven't thought too much about this. But I kinda feel like this is just inherent to link-local networking and rather needs some coordinated efforts. And if those efforts are: ensure every link-local protocol has a rate-limit, well yeah, then we can surely do this.

Thoughts?

[bengal]

Wouldn't an I/O scheduler combined with a CPU scheduler be much better? You use the I/O scheduler to ensure all interfaces get the same throughput, even if one is flooded. And then you us
e a CPU scheduler, to ensure NetworkManager (or similar) does not block the system if the network is flooded?

I am not familiar with I/O and CPU schedulers, but I assume they require that each ACD instance runs in a separate process or thread, is that correct? I didn't find reference they can be used in the same process on different sockets. This seems an important limitation, because this means that the program using n-acd must be heavily reworked to use different process/threads.

It seems like whack-a-mole trying to add rate-limiting to n-acd. And even if we did, what is a reasonable rate-limit, anyway?

During the probing phase, any packet that matches the ebpf filter causes an immediate failure of the probe for that address. Then the address get removed, the map gets updated and any subsequent ARP packet for the same address is dropped by the ebpf filter.

The problem is during the announcing phase when the client is configured to always defend the address. In case of an ARP flooding, the client keeps parsing those packets; it only generates a defend ARP message every 10 seconds. However, the parsing keeps the program busy.

From this considerations, it seems that the ACD protocol doesn't need a high rate of packets per second, and so the limit could be in the order of 10^1 or maybe 10^2 pps?

But I kinda feel like this is just inherent to link-local networking and rather needs some coordinated efforts. And if those efforts are: ensure every link-local protocol has a rate-limit, well yeah, then we can surely do this.

That's a good point. A DHCP server or a LLDP client would also need something like this. Maybe even a DHCP client, because in some states it could be possible to flood it.

For this reason, perhaps this should be something done at system level, maybe by systemd?