cyclomies
commented
4 years ago How about limiting messages forwarded or rebroadcast, from a particular node, with a increasing time between messages (after a certain threshold)? The same way we do limit brute-forcing our passwords: you can try the first times without a delay, but eventually the delay is increased by doubling the delay.
This way, the nodes would not be limited/fixed to a certain time intervals, and could forward packets as soon as possible. If all nodes would respect the same rules, defining maximum amount of packets sent within a certain time frame thresholds, this shouldn't cause any constrictions on the network.
Actually, duty cycles are already in place, with a fixed maximum airtime. Therefore, it might be rather easy to add a node specific increasing time buffer for outgoing packets.
samuk
If I wanted to disrupt a Disaster radio network I'd set up a node that broadcasts a message every 200ms to all other nodes in the network. This would probably cause the network to grind to a halt and drop loads of messages.
If each node was limited to sending one message every 20 seconds I'd have to buy loads more devices to achieve the same.
As I understand it the Mac address is derived from the Semtech on-chip UUID and not that trivial to spoof?
This could also be implemented on the client-side, so it's not a surprise to the user that the messages are dropped, but it would also need to be in the routing logic as the firmware can be re-written.
I realise I can still build my 200ms broadcast device, but at least the disruption is limited to nodes that can hear me, and not the rest of the network.