RFC - Mesh LoRa Anonymity

Abstract

Users desire anonymous communication

• whistleblowers - expose practices that negatively impact the world
• overcome censorship - allow free exchange of information

Mesh LoRa presents an opportunity to design for anonymity - exceeding the anonymity provided by use of other communication channels (phone, internet, etc.).

As LoRa is an RF protocol. Identifying the location of the transmission should require RF triangulation - This document provides guidance on ensuring that Mesh LoRa communications don't allow communications to be traced back to the transmission location via the routing protocols.

Users can enhance anonymity by tunneling. Tunneling only increases anonymity if there is lots of traffic on the tunnel endpoints - for example, if you are the only one transmitting on a tunnel endpoint, correlating traffic back to your location is simply deduced.

By combining Mesh LoRa with the internet, tunneling algorithms can take advantage of the increased anonymity of Mesh LoRa anonymity. This allows anonymous protocols (Onion, Garlic) to gather anonymous routing information via an anonymous Mesh LoRa - increasing the timeliness of acquiring anonymous routes by eliminating the need to anonymize the exchange.

Mesh LoRa requires repeating LoRa transmissions which enhances the anonymity of the communication as the repeated transmissions should obfuscate the original location. This guidance identifies specific LoRa transmission data that if openly published on a Mesh LoRa would threaten anonymity.

Status of This Memo

This is an Internet Standards Track document.

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Motivation

We live in a surveillance economy - making it economically valuable to de-anonymize users (by both governments and marketers).

Users seek to communicate without interference. To mitigate the interference of the surveillance economy, users must be able to communicate anonymously.

Mesh LoRa Anonymity

1. Introduction

Mesh LoRa implementations will evolve toward the needs of the users. Mesh LoRa implementations that use this guidance are able to provide a higher level of anonymity. As users become more aware of the surveillance economy, they will seek out anonymous connectivity. Mesh LoRa implementations can provide higher anonymity by leveraging distributed communication over RF.

2. Terminology

• Anonymity Strength - metric for difficulty of deducing the user's physical location by usage of a protocol
• Surveillance Economy - Anonymity Strength can be quantified by the cost necessary to de-anonymize communications. Increasing the cost of de-anonymizing communications, increases the Anonymity Strength.

3. Overview

This guidance is provided to enhance Anonymity Strength by identifying the properties of LoRa communication that if published by the Mesh LoRa implementation would reduce Anonymity Strength.

As new threats to Mesh LoRa Anonymity Strength are found, this RFC will be updated - providing general architecture guidance to mitigate the threat. Where threats require specific mitigation, new RFCs will be created references.

4. Architecture

4.1. LoRa communication properties that reduce Anonymity Strength

Mesh LoRa implementations should only publish this information as necessary to support the network - but must never expose users.

• signal-strength - allows observers to concentrate upon a smaller geographical area, decreasing the effort/cost of locating the sender.
• path (hops across Mesh LoRa) - allows observers to concentrate upon a smaller geographical area, decreasing the effort/cost of locating the sender.
• timestamps - allows observers to deduce senders by identifying patterns of when the sender uses Mesh LoRa.
  • while patterns of usage by a sender will always be observable at the Mesh LoRa protocol level, providing public timestamps reduces the effort/cost to deduce the sender.

4.2. Secrets Privacy

To mitigate against man-in-the-middle attacks due to exposure of private keys, Mesh Lora designs must never unnecessarily expose private keys. Only the sender and receiver should have the private keys.

• Mesh LoRa implementations should never send private keys to an intermediate device
  • malicious actors could recover these private keys from the intermediate device either by physical access or software exploit.

4.3. Anonymizing Public Communications

The growth of Mesh LoRa is largely due to the ability to openly communicate with others. Anonymity Strength of public communications can be enhanced by protocols that provide deniable authentication.

Security Considerations

Raising the effort/cost of de-anonymizing Mesh LoRa participants enhances security by leveraging Anonymity Strength as a quality enhancement of secure communications.

IANA Considerations

• RFC on Anonymity
  • Motivation
    • Anonymity is a recent concern. Users have embraced the internet as means to communicate across the world.
    • Users didn't anticipate a surveillance economy that creates
      • censorship - ability of some other authority to dictate what can and can not be discussed
      • monetization of their communications
        • a third party that de-anonymizes their communications to allow marketers to focus directly upon users

References

Appendix

Acknowledgements

Contributors

Authors Contact Information