[Bug]: Inadvertent DDoS due to low battery

[gitbisector]

Category

Other

Hardware

Not Applicable

Firmware Version

2.5.18.89ebafc

Description

A node in a reboot loop (observed here due to low battery) reports its position every cycle with want_ack=true. In a well connected mesh that causes tons of nodes to reply back with their own position flooding the mesh as these replies are not rate limited as regular position reporting is.

Relevant log output

[RCGV1]

I think nodes should have a rate limit for responding to want_acks packets or even rate limit nodes that are sending packets way too often

[gitbisector]

How to go about this one? Seems somewhat wasteful to begin with. DMs get sent from every node in range every time you turn on your node. If we didn't move since last time we heard from a node why bother at all? And if we do decide to reply maybe broadcast so others can benefit too? A node getting turned on for the first time of course highly benefits from this information as it helps populate their nodedb. Gives you some clue who's out there. Especially since we've all turned down node_info broadcast rates to lower channel utilization.

[GUVWAF]

And if we do decide to reply maybe broadcast so others can benefit too?

Position packets are not sent via PKI and are "promiscuous", meaning we'll look at them even when they're not destined to us.

I think rate limiting specifically for position requests makes sense, just like we do for NodeInfo. I would not be in favor of rate limiting all want_responses as it's not intuitive that you can't request a position within x minutes after you did a traceroute. Furthermore, rate limiting specific nodes would also not suffice for a malicious actor that spoofs new NodeNums everytime.

[RCGV1]

I think the main thing is doing the rate limiting of other nodes packets and not just ours. So we will just ignore packets we are currently rate limiting.