Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HIP 46: LoRaWAN NetID Routing #312

Closed
hiptron opened this issue Nov 13, 2021 · 8 comments
Closed

HIP 46: LoRaWAN NetID Routing #312

hiptron opened this issue Nov 13, 2021 · 8 comments
Labels

Comments

@hiptron
Copy link
Collaborator

hiptron commented Nov 13, 2021

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
Copy link

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
Copy link
Contributor

jamiew commented Feb 8, 2022

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
Copy link

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
Copy link
Contributor

lthiery commented Feb 20, 2022

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
Copy link

@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
Copy link
Contributor

lthiery commented Feb 21, 2022

@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
Copy link

@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
Copy link
Contributor

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants