RFC ‐ Mesh LoRa - redengin/enmesh GitHub Wiki

Mesh LoRa Overview [Informational]

Abstract

The use of LoRa has expanded as RFC-8376 predicted. Mesh LoRa implementations allow users to communicate with others beyond the reach of their LoRa radio. Mesh LoRa implementations are now struggling to provide transmit availability as the density of nodes increases.

Status of this memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the enmesh crowd.

The current status, any errata, and feedback can be obtained at https://github.com/redengin/enmesh/wiki/RFC

Memo

Introduction

The growth of Mesh LoRa is largely due to providing forums for users to chat with others.

The exponential increase in Mesh LoRa nodes demonstrates a need for communication, but the qualities of communication haven't been well-defined.

This memo provides definitive qualities of a Mesh LoRa implementation that have led to the rapid adoption.

Mesh LoRa designers should leverage the IETF to design toward best-of-practice.

Mesh LoRa Qualities (aka - why do users desire to use LoRa vs the internet)

  • Availability (Access to both transmit and receive)

    • Mesh LoRa provides communication when internet access is unavailable.
    • Mesh LoRa should be robust to jamming (e.g. a malicious node constantly transmitting - attempting to deny transmit access to others)

  • Privacy

    • users expect Mesh LoRa to meet or exceed the privacy provided by internet protocols

  • Anonymity (usage does not expose the location of the sender nor receiver)

    • RFC-6973 Anonymity
      'anonymity' is not considered as a primary trait of communication. Instead, RFC-6973 defines the characteristics of a design that can provide anonymity.
      • Mesh LoRa designs should embrace RFC designs for anonymity
        • As users are expecting anonymity, there should be an RFC specifically about the traits of anonymity
          • the traits of anonymity should be universal, not focused on the usage of LoRa

Gap Analysis

Current Mesh LoRa Implementations

Availability (Access to both transmit and receive)

LoRa nodes broadcast communications over RF. Current Mesh LoRa implementations are struggling to provide availability as density of participating LoRa nodes increases.

Current Mesh LoRa implementations use a single LoRa channel. This only allows one transmitter at a time. As the density of users increases, the access to transmit is inhibited. Additionally, malicious nodes can create a denial-of-service attack by constantly transmitting on the LoRa channel - denying transmit access to nearby users.

Privacy

Current Mesh LoRa implementations are leveraging encryption for privacy. Unfortunately, current implementations have poor controls for private keys

  • placing private keys onto physically uncontrolled nodes
    • private keys could be exposed by a malicious actor taking physical control of the node
  • no design for revoking exposed keys
    • allows malicious actor having the keys to continuously pose as the actual user
  • lack of design for end-to-end communication authentication

Evolution of functionality

Mesh LoRa forums are quickly evolving (similar to the internet)

  1. peer-to-peer - communicate directly
  2. peer-to-others - communicate on a forum
    this is essentially a re-implementation of the internet

Anonymity

Current Mesh LoRa implementations aren't designed toward anonymity.

Under current implementations, the user's location can be traced back to a physical location by the routing protocols.

  • Coarse Location
    • the recorded hops in the packet can be used to locate the origin of the transmission
  • Fine Location - leverage multiple nodes reporting the received power (dB)
    • user's location can be triangulated by RF monitors near the user's location
      • the constant sending of data under the current implementations exposes the user's location

IANA Considerations

  • There should be an RFC on the traits of anonymity to inform designs of how the location of the user could be exposed.
    • most designers as well as users aren't aware of how usage of an implementation exposes the location of the user.

Informative References

Acknowledgements

Contributors