MeshCore currently allows several flood packet types to be forwarded without any sender signature. That creates a structural DoS weakness: an attacker can inject forged flood traffic with arbitrary routes, saturate the mesh, and leave repeaters with no stable identity to rate-limit, deprioritize, or block.
The first fix should be protocol-level: require all flood packets to carry a verifiable sender identity and signature. This does not prevent abuse by itself, but it changes the problem from anonymous packet spam to cert reputation and rate control.
The airtime cost is a concern. A 32-byte cert plus 64-byte Ed25519 signature adds roughly 96 bytes, which is painful for group messages. However, #2481 and #2509 both point at ways to regain useful payload capacity: compression and relaxing the static MAX_PACKET_PAYLOAD split so short-path packets can use more of the actual PHY budget.
After signed flood packets exist, repeaters can implement decentralized trust heuristics. Cert generation is cheap, so the practical lever is cert age and observed behavior. A repeater could track when a cert was first seen (bloom filters can do this with minimal memory use), assign higher priority to older/stable certs, delay forwarding from new certs, and maintain a bounded priority queue that drops low-trust traffic first during congestion.
Is going down this route something which the Meshcore maintainers would remotely consider? I'd be happy to write a spec proposal and implementation but given the crickets on my last proposal I'm hesitant to spend more time with contributions.
MeshCore currently allows several flood packet types to be forwarded without any sender signature. That creates a structural DoS weakness: an attacker can inject forged flood traffic with arbitrary routes, saturate the mesh, and leave repeaters with no stable identity to rate-limit, deprioritize, or block.
The first fix should be protocol-level: require all flood packets to carry a verifiable sender identity and signature. This does not prevent abuse by itself, but it changes the problem from anonymous packet spam to cert reputation and rate control.
The airtime cost is a concern. A 32-byte cert plus 64-byte Ed25519 signature adds roughly 96 bytes, which is painful for group messages. However, #2481 and #2509 both point at ways to regain useful payload capacity: compression and relaxing the static MAX_PACKET_PAYLOAD split so short-path packets can use more of the actual PHY budget.
After signed flood packets exist, repeaters can implement decentralized trust heuristics. Cert generation is cheap, so the practical lever is cert age and observed behavior. A repeater could track when a cert was first seen (bloom filters can do this with minimal memory use), assign higher priority to older/stable certs, delay forwarding from new certs, and maintain a bounded priority queue that drops low-trust traffic first during congestion.
Is going down this route something which the Meshcore maintainers would remotely consider? I'd be happy to write a spec proposal and implementation but given the crickets on my last proposal I'm hesitant to spend more time with contributions.