Use Case:
Reduce the DoS impact of a malicious actor by causing a public key to "mean something", allowing implementation of QoS and/or rate limiting by id to reduce the impact of broadcasting large-hop messages.
Issues to overcome:
- Malicious actor with LoRa hardware or SDR (complicated case) can flood the network with large hop broadcasts.
- Packets don't have enough reliable source or destination information to differentiate users
- Creating a new Ed25519 key to do it again is trivial, even if it was required
Implementation:
- Include source fidelity of ~24b in packets to have a very unlikely birthday-paradox [581 devices to reach 1%], Adjust bits based on birthday-paradox metric if lower is required
- Create a rule where a node cannot broadcast unless they first broadcast a Proof of Work based on their public key
- The effort should be seconds per key of GPU effort
- Effort can be saved for that key to be resent for future broadcasts, and be able to be calculated on a web page and input easily into a client application / repeater
- PoW needs to be extremely asymmetric
- If a user doesn't hear their message repeated, they provide their challenge via broadcast and then resend the broadcast
The Fix:
- If a PoW fails to calculate, block the key for Q hours
- If a key broadcasts more then N times a minute, QoS/bock them for M minutes
- If a node's ring buffer of "blocks" fills, sleep that node for J minutes, disabling it as it's under an attack
- All malicious actors are now DoSing a region but not destroying the network, requiring many systems to be purchased and placed to disable a network
- Could implement fingerprinting a LoRa device with CFO and packet timing jitter for suspected nodes to block them at a hardware based level if under an attack, as it will likely block good nodes too sometimes and can be defeated by an SDR, but now the actor needs to do a lot and spend a lot and we have to do just a little which is the point.
The new problem:
Broadcasts may fail for ducting or other things. This may require a "auth failure" type response, but that adds even more messages which we're trying to remove the amplification-attack. Implicit trust would just have a user fake a broadcast path and random TTL.
You could also implement this for direct but that would be much worse, but perhaps a "you're sending a lot of messages" challenge based on hop count and path is the fix, implementing the above. It cannot be based on "first in path" though so it would have to be a scale based on how far into the TTL you are and where you are in the list. Sanity checking, such as TTL63 but you're node 3 is obviously a flood and offer a challenge, but this type of checking is probably just too much and too easy to avoid.
Use Case:
Reduce the DoS impact of a malicious actor by causing a public key to "mean something", allowing implementation of QoS and/or rate limiting by id to reduce the impact of broadcasting large-hop messages.
Issues to overcome:
Implementation:
The Fix:
The new problem:
Broadcasts may fail for ducting or other things. This may require a "auth failure" type response, but that adds even more messages which we're trying to remove the amplification-attack. Implicit trust would just have a user fake a broadcast path and random TTL.
You could also implement this for direct but that would be much worse, but perhaps a "you're sending a lot of messages" challenge based on hop count and path is the fix, implementing the above. It cannot be based on "first in path" though so it would have to be a scale based on how far into the TTL you are and where you are in the list. Sanity checking, such as TTL63 but you're node 3 is obviously a flood and offer a challenge, but this type of checking is probably just too much and too easy to avoid.