HIP00xx: Safe RF Meta-Data Side Channel

[wavesoft]

Author(s): @wavesoft, @dmamalis
Initial PR: #249
Start Date: 2021-07-28
Category: Technical

Rendered view:
https://github.com/helium/HIP/blob/9ce376f2d18d973fb26aac44360f072cb6d86512/00xx-safe-rf-metadata-side-channel.md

Summary:

The goals of these changes are to:

Introduce a new side-channel from which RF meta-data can be collected, in a way that no sensitive information
can be disclosed to third parties.

[jamiew]

Acknowledged and looks great based on my initial review. I'm out most of day but will number and merge ASAP

[mfalkvidd]

@wavesoft interesting proposal. Some thoughts (none of them critical, but might be useful)

• The feature is designed to be opt-in. Could you clarify who would opt in? My guess is the hotspot owner, but it would be good to clarify. Do you have any opinion/suggestions on how the hotspot owner would be informed of the possibility to opt-in?
• It seems to me that the only reason to not include the payload is due to PoC being "insecure". All normal LoRaWAN traffic has encrypted payload. Gateway owners on other LoRaWAN networks (at least the 2 other networks I have extensive experience with) can see the full (encrypted) payload. Have you considered other mitigations to protect the PoC payload? Maybe a simple delay of the report data would be sufficient, to prevent fake witnesses? If the statistics used the standard semtech format, existing tools could be used. If a new format is invented, existing tools would need to be adapted. For example, Chirpstack support is being added and it would be nice to not have to adapt Chirpstack to a Helium-specific format.

[wavesoft]

Hello @mfalkvidd !

• The feature is designed to be opt-in. Could you clarify who would opt in? My guess is the hotspot owner, but it would be good to clarify. [...]

You are correct. The hotspot owners are the main stakeholders here. I will check how I can emphasize this on the document 👍

[...] Do you have any opinion/suggestions on how the hotspot owner would be informed of the possibility to opt-in?

I am expecting this to be taken care partially by the hotspot manufacturers and through a helium mailing list notification. I don't think it makes much sense to add this anywhere on the UI because it might be unwanted noise for non-stakeholders.

You raise however an interesting point : if a network operator/controller wants to enforce this as a policy down to all hotspots that (s)he owns, how would this work? Personally I have a feeling that answering this in this HIP might over-bloat it's scope, but that's an interesting discussion to have on another HIP. What do you think?

It seems to me that the only reason to not include the payload is due to PoC being "insecure". All normal LoRaWAN traffic has encrypted payload. Gateway owners on other LoRaWAN networks (at least the 2 other networks I have extensive experience with) can see the full (encrypted) payload. Have you considered other mitigations to protect the PoC payload? Maybe a simple delay of the report data would be sufficient, to prevent fake witnesses?

That's actually a quite elegant solution. I like it, but there is an unfortunate side-effect: this requires that the hotspot client should maintain a queue of the messages and replay them with a given delay. If too many messages arrive at close intervals, then you are increasing the memory pressure, risking to loose messages, or to ran out of memory in compact hardware solutions.

If the statistics used the standard semtech format, existing tools could be used. If a new format is invented, existing tools would need to be adapted. For example, Chirpstack support is being added and it would be nice to not have to adapt Chirpstack to a Helium-specific format.

I absolutely agree on that, that's why I also mentioned that some discussion is needed to settle on the actual format. I am still undecided on weather it should be encoded with ProtoBuf, or with a Semtech UDP style JSON (for this compatibility).

You will also notice that I have kept almost all of the fields from the UDP protocol (even the data field now holds only the MAC header), and I have only added more fields for easier consumption. But I guess for compatibility's sake we could keep all the fields from Semtech's protocol AND only add more fields as we need (still capping the body to 8 bytes though).

[jamiew]

I'm having some pushing-to-remote-fork pains with gh so I'm goign to squash-merge here and then number the HIP in master Please excuse my dust

[jamiew]

This HIP draft has been reviewed, numbered, and merged for discussion! Please direct future feedback & questions to its central tracking issue: #250