HIP 46: LoRaWAN NetID Routing

[hiptron]

• Author(s): @lthiery
• Start Date: 2021-10-26
• Category: Technical
• Original HIP PR: HIP draft: NetID routing #300
• Tracking Issue: this
• Status: Approved

Summary and Motivation

Currently, packets that are not under the Helium NetID are dropped. They belong
to other networks, such as Actility or Senet. However, these other networks
have manifested interest in purchasing these packets and thus "roaming" on the
Helium Network. Ultimately, enabling this makes the existing infrastructure
more valuable as the same hotspots (LoRaWAN gateways) can provide coverage for
these existing LoRaWAN Networks.

We propose to create a new chain_var that maps NetID to OUI. This mapping
will be maintained by the DeWi LoRaWAN Committee who can receive requests from
NetID owners to route these frames to one or many OUIs.

Rendered view

https://github.com/helium/HIP/blob/master/0046-lorawan-netid-routing.md

[wolfenhawke]

I think this makes sense. LORA has been around for more than a decade. In that time there are sensors fielded that are only programmed with specific networks in mind. But the networks have been very limited in coverage before Helium. Doing this enables those providers to "sell" capability for wider coverage, and in turn allow their customers' sensors to be addressed by Helium providing a win-win-win.

[jamiew]

Like #311, There has been strong support for this proposal. The coredevs support it, the newly formed LoRaWAN committee supports it, it has 95%+ support in Discord straw polling, and there have no concerns raised either here or on the monthly community call. Additionally, it has been open for feedback for several months.

I believe this proposal has passed our standard for rough consensus, and an on-chain temperature check or vote is not required.

On behalf of the DeWi, the HIP Editors, and the wider Helium community, I am marking this proposal as approved, and request that the coredev team implement the necessary changes as soon as reasonably possible.

[pvolodin]

So if I create a device with fake DevAddr which has Senet prefix, put it close to my hotspot and force it to send the packets frequently enough, I'll be rewarded for these fake packets?

[lthiery]

So if I create a device with fake DevAddr which has Senet prefix, put it close to my hotspot and force it to send the packets frequently enough, I'll be rewarded for these fake packets?

Only if the OUI operating the Senet purchasing decides to buy them. Keeping track of allocated NetIDs and locations makes it easy to see spoofs. And if you get fooled, it's easy to tell after purchase and denylist the hotspot.

[pvolodin]

@lthiery

Only if the OUI operating the Senet purchasing decides to buy them.

If Helium roaming really works (or will work? :-) ) as described here: https://docs.helium.com/lorawan-on-helium/lorawan-roaming-on-helium/ or in a similar way, I don't think there's any possibility to reject the fake packets.

And if you get fooled, it's easy to tell after purchase and denylist the hotspot.

This is that I expected to hear. Shortly, all the hotspots around will be denylisted, right? Or I can take my device, go travelling, and piss in the pocket of any hotspot owner I meet on my way...

[lthiery]

@pvolodin I can assure you it works as I've personally worked on the integrations with Senet and Actility. You can see the codebase under helium/packet-purchaser and with the implementation of this HIP, anyone could run a roaming server.

The denylist logic is not implemented and could be problematic should it be implemented, as you point out. The payoff for a bad actor doing what you propose is very low though and the wasted cost on irrelevant packets is very low for operators - it's not a major problem yet.

We are currently working on proposals to the LoRaWAN specification that would resolve this. The LoRaWAN specification was not initially developed with this kind of trustless roaming in mind but I think with the relatively small changes we are proposing, it is easily adapted.

[pvolodin]

@lthiery

You can see the codebase under helium/packet-purchaser

Thanks a lot for pointing me to that repo, I'm not fully familiar with Helium codebase (yet).

The denylist logic is not implemented and could be problematic ... the wasted cost on irrelevant packets is very low for operators

And there's a lot of other philosophical questions, yeah... Thank you for confirming (from the techical perspective) my findings.

We are currently working on proposals to the LoRaWAN specification that would resolve this....

Do you mean the LoRaWAN spec itself? Or just one of TRs? Will surely check these proposals when they're available in the member area of LoRa Alliance portal.

[vincenzospaghetti]

This HIP has been approved for some time, and we are going to close it. Congrats on a successful HIP and for your contributions to the Helium community!