IOT Denylist Refinement | Helium Documentation

In early August Nova Labs
posted a change in how the denylist
is operated. This change has resulted in several positive effects on the network in terms of the
number of hotspots that were improved and cleared from the denylist, as well as clusters of
misbehaving hotspots getting turned off, clearing innocent hotspots that were swept up in the
analysis.

The ongoing challenge with the current approach is that innocent hotspots are still being swept up
by the classifiers if they have especially good antenna setups since they are attractive targets for
beacon replay.

Nova Labs will be deploying a refinement to the denylist that instead of denying hotspots for
exhibiting 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 RF
behavior 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 PoC
rewards. This list is generated weekly based on the previous two weeks of PoC data. There are
currently 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 percent
  of its witnesses pass through significant terrain obstructions as
  described here.
• Witness Reciprocity: A hotspot is added to the deny list when the reciprocity (ratio of the
  count of incoming to outgoing witnesses) is zero. This indicates that a hotspot is either
  exclusively receiving or transmitting beacons, which is a strong indication of either spoofing
  activity or a hardware/software malfunction of the hotspot.
• Distance Insensitivity: A hotspot is added to the deny list when the distance insensitivity is
  above 50 percent, as
  described 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 comparison
with the network average. This approach has two problems:

• Exceptional Actors: Some rare hotspots are installed on telecom towers or mountaintops, and
  may 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 in
  them being wrongly added to the deny list.

A significant amount of research has gone into identifying how to identify good actors in the case
where the majority of surrounding hotspots are participating in spoofing activities.

Attempts at applying label-propagation and PageRank-based classifiers have yielded some positive
results, but it is currently not clear how to choose an appropriate threshold to assign blame to an
individual hotspot using these techniques. No good solution to this problem likely exists based on
currently available data.

Since hotspots can unknowingly participate in fraudulent proof-of-coverage activities, there is
always a potential for false positives (i.e. deny-listed).

This problem may be avoided by denying PoC rewards based on the network edge (connection) between
two hotspots rather than the hotspots themselves (nodes).

Using some of the same criteria as are currently used to classify nodes (terrain intersection margin
and distance insensitivity), edges may be classified as either good or bad. Bad edges, such as those
that go through significant terrain, may then be denied rewards by the network oracles in the same
way as hotspots are on the current deny list.

This has the following effects:

• Reduced Collateral Damage: Good actors will not be blocked from receiving legitimate
  proof-of-coverage rewards from legitimate edges. False positives can happen on edges but will
  not 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 any
  proof-of-coverage packets it receives. This results in hotspots appearing to receive packets over
  improbable or impossible paths and may result in them being added to the deny list. In the
  edge-based methodology, these packets would simply not be rewarded, and would therefore result in
  no damage to the network.

• More Precise Denying: The various classifiers can be tuned more aggressively for edge events
  instead of tagging a whole node for partially incorrect behavior. The effects of a bad classifier
  are 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 coverage
  packets to travel beyond the visual line of sight between the transmitter and receiver. These
  effects are difficult to model and are currently accounted for by relaxing the detection threshold
  for the terrain intersection and distance insensitivity metrics.

  By not rewarding proof of coverage packets that propagate beyond the line of sight, the risk of
  adding hotspots to the deny list based on transient events is minimized. Further, these events are
  not useful to the network and do not accurately represent the sensor coverage being provided by
  hotspots, which needs to be consistent.

Examples​

Here are two examples of how an edge-based deny list can help hotspot owners and users of the
network.

Consider a hotspot (represented in blue) that is located near several bad actors (red). The bad
actors receive proof of coverage beacons over RF, and then forward them to distant hotspots via an
Internet link.

Since the distant hotspots are obstructed by terrain, no radio signals from the beaconing hotspot
can reach them. All the LoRa beacons are compared against a terrain map, and signal paths that are
significantly obstructed are prevented from receiving rewards.

This denies rewards to the hotspots forwarding and receiving illegitimate beacons while protecting
the 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 atmospheric
effects. Devices that use the network require consistent coverage. By preventing these sporadic
links from being rewarded, good coverage for sensor deployments is incentivized. This is illustrated
below.

The engineering work required to implement an edge-based deny list is minimal. The edge-based
deny-list will exist alongside the existing node-based deny-list.

The following need to be completed for an edge-based deny list implementation:

1. Oracles will need to check the denylist xor filter for a lexicographically sorted hotspot-hotspot
   edge pair. This is accomplished in this PR

2. The edge-based denylist needs to be generated with the node deny list weekly and adjusted when
   necessary to make it as effective as possible. This is accomplished in
   this PR

3. A way to visualize/explain the denied edges. The initial approach will be to generate report
   cards for hotspots that have more than 50% of their edges denied.