Exploring HIP 35: Safe RF Meta-Data Side Channel
The Helium project has a community-driven proposal system that can be found on GitHub. When a rough consensus has been achieved in the review committee, a Helium Improvement Proposal (HIP) will be marked as “approved,” and then the code can be merged and deployed.
For those interested in learning more about Helium before they make investments or become more involved in the community, exploring all of the HIPs can be a fruitful exercise.
What is HIP 35?
HIP 35 is a proposal for Helium software to provide RF (Radio frequency) Metadata (data concerning underlying system data) in a secure, standardized way. This is a brand new proposal that formally passed review and became an official, numbered HIP on July 28th, 2021.
A desire to analyze Helium RF Metadata is borne out of a need to ensure that systems are running properly and optimally. Especially in ways that aren’t binary, and using insights that may be more useful in aggregate or in summary. While a few data points associated with Helium hotspots (earnings, challenges, location, sync) are obvious, this information is not metadata, and, specifically, it is not RF Metadata. RF Metadata concerns information related to the sending and receiving of packets.
A detailed description of exactly what information is communicated can be found on the Semtech LoRa® packet forwarder’s protocol document. It even includes ASCII diagrams. A summary of some of the more useful pieces of data can be found in the HIP:
- RF Quality
- RF Channel and Frequency
- RF Modulation and encoding information
- The packet data payload
- GPS Timestamp (where applicable)
- [Summary] Number of packets sent/received
- [Summary] Number of packets rejected or received with bad CRC (Cyclic redundancy check)
- [Summary] Percentage of upstream datagrams that were acknowledged
How is This Metadata Currently Obtained?
This metadata (as is the case with most metadata) already exists, it just isn’t exposed to the end user. The reason is likely for simplicity and security reasons. Exposing new data via a side channel always opens the opportunities for some vulnerability and, of course, there can be some performance impact. Not to mention complexity.
Those with experience working with RF and other networking hardware may be familiar with ways to collect this data. It involves setting up a tap and altering the stream of packets. This carries some risk of damaging hardware while also being inaccessible to the inexperienced user. If there was a widely available third-party solution, that might be viewed as wasteful. The information is already there, it just can’t be accessed.
As you can imagine, the main stakeholders in this proposal will be hosts with large hotspot footprints and those who may be delivering their own IoT solutions. However, even for the user with one hotspot, it can be very difficult to analyze performance issues, and without this information being exposed there is a heavy dependence on 3rd-party tools.
How Would HIP 35 Be Implemented?
The proposal specifies that the implementation would be simple in that this data could be exposed via a side channel. This channel would exist within a man-in-the-middle UDP forwarder that would only expose the stream of analytics data. This would not require any hardware changes.
Are There Any Downsides to This Proposal?
There are very few tradeoffs in HIP 35. The main sticking point will be the amount of work required to verify that the code changes are safe and that there are indeed no discernible changes to the handling of privileged data or performance of hotspots. Also, as time goes on, will the existence of the side-channel cause extra work to implement new features or metrics?
What is Likely to Happen with HIP 35?
Being an improvement mainly desired by large operators, it is likely that it will take some time for the proposal to be prioritized and consensus to be reached. It may be hard to build meaningful community support while the use cases for single-hotspot owners are likely uninteresting and not useful to casual Helium participants.
