In early August Nova Labsposted a change in how the denylistis operated. This change has resulted in several positive effects on the network in terms of thenumber of hotspots that were improved and cleared from the denylist, as well as clusters ofmisbehaving hotspots getting turned off, clearing innocent hotspots that were swept up in theanalysis.
The ongoing challenge with the current approach is that innocent hotspots are still being swept upby the classifiers if they have especially good antenna setups since they are attractive targets forbeacon replay.
Nova Labs will be deploying a refinement to the denylist that instead of denying hotspots forexhibiting improbable RF behavior denying witness events, also known as edges or connections,that are improbable. This would allow hotspots to continue to operate and earn PoC rewards for RFbehavior that benefits the network overall even if they have improbable RF links.
We expect this new approach to be deployed before the end of September.
The rest of this post explains the introduction in more detail.
The IOT denylist is currently implemented as a list of hotspot addresses that are denied PoCrewards. This list is generated weekly based on the previous two weeks of PoC data. There arecurrently three metrics by which hotspots are added to the denylist:
- Terrain Intersection Margin: A hotspot is added to the deny list when greater than 50 percentof its witnesses pass through significant terrain obstructions asdescribed here.
- Witness Reciprocity: A hotspot is added to the deny list when the reciprocity (ratio of thecount of incoming to outgoing witnesses) is zero. This indicates that a hotspot is eitherexclusively receiving or transmitting beacons, which is a strong indication of either spoofingactivity or a hardware/software malfunction of the hotspot.
- Distance Insensitivity: A hotspot is added to the deny list when the distance insensitivity isabove 50 percent, asdescribed here.
The above metrics were designed based on a statistical analysis of hotspot behavior on the network.Abnormal behavior for each metric is identified at the 90 percent confidence level by comparisonwith the network average. This approach has two problems:
- Exceptional Actors: Some rare hotspots are installed on telecom towers or mountaintops, andmay have properties that are abnormal but not fraudulent.
- Blame by Association: Some legitimate hotspots are surrounded by large numbers of bad actors.This makes the good actor appear to be part of the surrounding gaming activities and may result inthem being wrongly added to the deny list.
A significant amount of research has gone into identifying how to identify good actors in the casewhere the majority of surrounding hotspots are participating in spoofing activities.
Attempts at applying label-propagation and PageRank-based classifiers have yielded some positiveresults, but it is currently not clear how to choose an appropriate threshold to assign blame to anindividual hotspot using these techniques. No good solution to this problem likely exists based oncurrently available data.
Since hotspots can unknowingly participate in fraudulent proof-of-coverage activities, there isalways a potential for false positives (i.e. deny-listed).
This problem may be avoided by denying PoC rewards based on the network edge (connection) betweentwo hotspots rather than the hotspots themselves (nodes).
Using some of the same criteria as are currently used to classify nodes (terrain intersection marginand distance insensitivity), edges may be classified as either good or bad. Bad edges, such as thosethat go through significant terrain, may then be denied rewards by the network oracles in the sameway as hotspots are on the current deny list.
This has the following effects:
Reduced Collateral Damage: Good actors will not be blocked from receiving legitimateproof-of-coverage rewards from legitimate edges. False positives can happen on edges but willnot affect the whole hotspot.
Reduced Risk of Packet Replay Attacks: A known current attack is where a LoRaWAN gateway,which is not necessarily a node on the IOT network, is programmed to re-broadcast anyproof-of-coverage packets it receives. This results in hotspots appearing to receive packets overimprobable or impossible paths and may result in them being added to the deny list. In theedge-based methodology, these packets would simply not be rewarded, and would therefore result inno damage to the network.
More Precise Denying: The various classifiers can be tuned more aggressively for edge eventsinstead of tagging a whole node for partially incorrect behavior. The effects of a bad classifierare less extreme than the current version.
Handling Transient and Sporadic Events: Some rare events, such as tropospheric ducting,reflection of water, and scatter around obstacles, may occasionally allow proof of coveragepackets to travel beyond the visual line of sight between the transmitter and receiver. Theseeffects are difficult to model and are currently accounted for by relaxing the detection thresholdfor the terrain intersection and distance insensitivity metrics.
By not rewarding proof of coverage packets that propagate beyond the line of sight, the risk ofadding hotspots to the deny list based on transient events is minimized. Further, these events arenot useful to the network and do not accurately represent the sensor coverage being provided byhotspots, which needs to be consistent.
Examples
Here are two examples of how an edge-based deny list can help hotspot owners and users of thenetwork.
Consider a hotspot (represented in blue) that is located near several bad actors (red). The badactors receive proof of coverage beacons over RF, and then forward them to distant hotspots via anInternet link.
Since the distant hotspots are obstructed by terrain, no radio signals from the beaconing hotspotcan reach them. All the LoRa beacons are compared against a terrain map, and signal paths that aresignificantly obstructed are prevented from receiving rewards.
This denies rewards to the hotspots forwarding and receiving illegitimate beacons while protectingthe good actor from their traffic.
Hotspots may also occasionally receive beacons that are beyond the visual line of sight.
This can sometimes happen due to reflections off of water, or radio scatter due to atmosphericeffects. Devices that use the network require consistent coverage. By preventing these sporadiclinks from being rewarded, good coverage for sensor deployments is incentivized. This is illustratedbelow.
The engineering work required to implement an edge-based deny list is minimal. The edge-baseddeny-list will exist alongside the existing node-based deny-list.
The following need to be completed for an edge-based deny list implementation:
Oracles will need to check the denylist xor filter for a lexicographically sorted hotspot-hotspotedge pair. This is accomplished in this PR
The edge-based denylist needs to be generated with the node deny list weekly and adjusted whennecessary to make it as effective as possible. This is accomplished inthis PR
A way to visualize/explain the denied edges. The initial approach will be to generate reportcards for hotspots that have more than 50% of their edges denied.
