Skip to content

Changes

Page history
Expand introduction, add notes on simultaneous BT connections. authored by akwizgran's avatar akwizgran
Show whitespace changes
Inline Side-by-side
Public-Mesh-Research-Report.md
View page @ feee4bf8
[[_TOC_]]
# Motivation
# Introduction
Over the lifetime of the Briar project, the Briar messaging app, and its underlying data synchronization protocol, Bramble, has operated using a "one-hop social mesh" data propagation protocol.
All private messages in the current implementation of Briar, are only delivered directly to the intended recipient.
This design choice allows Briar to hide peer discovery from anyone who is not existing Briar contacts with the user.
Non-contacts, in theory, are unable to prove that the target user is even running the Briar application by sniffing the target's Bluetooth, LAN, or Tor traffic.
This protocol design offers strong privacy and security benefits, however it removes the opportunity for messages to "hop" across mutual Briar contacts, or to other nearby entrusted Briar users.
For transports with short effective range like Bluetooth, a one-hop social mesh propagation strategy is potentially harmful to the message delivery rate.
To potentially improve connectivity in internet shutdown scenarios, the Briar team is conducting research on using "social mesh" and "public mesh" propagation strategies for messages.
This research covers the Briar team's findings for public mesh propagation.
## Motivation
The Briar messaging app and its underlying protocol stack, Bramble, operate using a "one-hop social mesh" data propagation strategy: each device only connects to contacts chosen by the user, and only exchanges data with each contact that the user has chosen to share with that contact.
In particular, private messages are only delivered directly to the intended recipient.
This strategy was chosen to maximise privacy.
Connecting only to contacts makes it difficult for non-contacts to discover that the user is running Briar, while giving the user control over which data is exchanged with each contact limits the exposure of metadata about which data the user subscribes to and the identities of the user's other contacts.
However, this one-hop social mesh strategy does not maximise connectivity, particularly when devices are online at different times or are operating entirely offline (eg during an internet shutdown).
Connectivity could potentially be improved by removing one or both of the key restrictions of the one-hop social mesh strategy.
Data could be allowed to propagate for multiple hops ("multi-hop" rather than "one-hop"), and/or devices could be allowed to discover and connect to nearby devices without being contacts ("public mesh" rather than "social mesh").
The Briar team is researching the pros and cons of "multi-hop social mesh" and "multi-hop public mesh" data propagation strategies.
This report describes the team's findings so far for the multi-hop public mesh strategy.
## Research Goals
Before designing protocols to achieve high-level goals such as multi-hop propagation of data across the mesh, we need to understand the various transport layers that could be used for making connections between devices.
The properties of these transport layers will impose constraints on the higher layers of the protocol stack, and will also affect the mental models that users need to build (with the help of the user interface) in order to use the mesh effectively.
The bulk of this research is therefore concerned with understanding and evaluating the available transport layers. We aim to identify a transport, or set of transports, that can be used for making connections between a wide range of devices.
# Transport Layers
The base layer of any mesh networking protocol is the individual direct connections between peer devices. In this section we explore a set of possible transport layers for discovering, and connecting to peer devices. The target for this research is primarily mobile-friendly protocols, however support for other computing devices is also worth considering.
The base layer of any mesh networking protocol is the individual direct connections between peer devices. In this section we explore a set of possible transport layers for discovering and connecting to peer devices.
Some of the transport layers covered by this research are already used in the Briar messaging app, but by removing the constraint that devices only connect to contacts, we change the ways in which familiar transports can be used, so we need to look at them again with the public mesh strategy in mind.
## Prologue
......@@ -25,15 +41,18 @@ If infrastructure is needed, it must be of a kind that is already widely deploye
Suitable transport layers must be supported by a wide range of smartphones of different models and manufacturers, and must not require root access, which is only available to technically skilled users and only on certain phone models.
For each transport layer, we aim to understand how it can be used in theory, what APIs are available for using it on Android, how it performs on a variety of real devices, and how it might affect the user experience of a mesh application (for example, by requiring user confirmation for certain actions).
Although we have evaluated the various transport layers on Android, we are also interested in whether they can interoperate with other platforms, include iOS, Windows, Linux and macOS.
### Test Devices
The following devices were used for testing one or more transport layers:
The following Android devices were used for testing one or more transport layers:
| Device Name | Android Version | API level |
|-------------|-----------------|-----------|
| Alcatel A3 XL (TCL 9008X) | 7.0 | 24 |
| Google Pixel 2 | 11 | 30 |
| Google Pixel 3A | 12 (CalyxOS) | 31 |
| Honor 8A (JAT-L29) | 9 (EMUI 9.1.0) | 28 |
| Huawei P8 Lite 2015 (ALE-L21) | 5.0.1 (EMUI 3.1) | 21 |
......@@ -45,6 +64,7 @@ The following devices were used for testing one or more transport layers:
| Motorola Moto G 4G (XT1039) | 5.1 | 22 |
| Motorola Moto G10 | 11 | 30 |
| Nokia 1.3 | 11 (Android Go) | 30 |
| Nokia 3.1 | 10 | 29 |
| OnePlus 5T (A5010) | 10 | 29 |
| Redmi Note 7 | 10 (MIUI 12.5.1) | 29 |
| Redmi Note 10 5G | 11 (MIUI 12) | 30 |
......@@ -55,7 +75,7 @@ The following devices were used for testing one or more transport layers:
### Source Code
All of the source code for this project can be found in the [Public Mesh Testbed project](https://code.briarproject.org/briar/public-mesh-testbed) on Briar Project's gitlab. As a way of managing the many different transport layers we are testing for in this project, we use different git branches to represent different transport layer properties.
All of the source code for this project can be found in the [Public Mesh Testbed project](https://code.briarproject.org/briar/public-mesh-testbed) on Briar Project's GitLab. As a way of managing the many different transport layers we are testing in this project, we use different git branches for different transport layer investigations.
### Automation Suite
......@@ -115,6 +135,14 @@ Beyond that point, an application receiving an RFCOMM connection can still acces
This does not allow a group of devices to bootstrap connectivity entirely without user interaction, as would have been possible on earlier API levels: at least one device must be made discoverable in order to receive the first RFCOMM connection. But this technique can be used to reduce the amount of user interaction needed.
#### Simultaneous connections
In previous research we found that some devices (eg LGE Nexus 5X) are capable of keeping up to seven RFCOMM connections open at a time. Other devices (eg Motorola Moto E3) can only keep a single connection open: if a second connection is opened, both connections fail.
The number of connected devices may also be relevant. For example, the Google Pixel 2, Nokia 3.1, LGE Nexus 5X and Huawei P8 Lite 2017 can all keep stable connections to each other (six connections in total), but adding the Huawei P8 Lite 2015 to the group destabilises the connections between the other devices.
There are even some indications that certain devices (eg Motorola Moto E3) may behave in a way that causes the Bluetooth stacks of other devices (Nokia 3.1) to crash, requiring Bluetooth to be turned off and on again.
### Bluetooth Low Energy (BLE)
Bluetooth Low Energy is a separate protocol from Bluetooth classic that is designed to use less energy without greatly impacting functional range.
......@@ -244,7 +272,7 @@ When a central device discovers a peripheral that's advertising the app's servic
##### L2CAP CoC
With L2CAP CoC, there is less of a conceptual divide between "central" and "peripheral" devices than there is with GATT. Instead of advertising a set of services consisting of characteristics, a peripheral using L2CAP CoC can just advertise a "PSM" value, which is similar to a port number, and open a Bluetooth server socket running on that PSM value. On our `blessed` branch, we advertise the PSM if the device supports L2CAP CoC:
With L2CAP CoC, there is less of a conceptual divide between "central" and "peripheral" devices than there is with GATT. Instead of advertising a set of services consisting of characteristics, a peripheral using L2CAP CoC can just advertise a "PSM" value, which is similar to a port number, and open a Bluetooth server socket running on that PSM value. On our `blessed-gatt` branch, we advertise the PSM if the device supports L2CAP CoC:
```Java
if (USE_L2CAP && SDK_INT >= 29 && serverSocket == null) openServerSocket();
......@@ -262,13 +290,12 @@ if (USE_L2CAP && SDK_INT >= 29) {
}
```
Then, whenever we discover an L2CAP-compatible device, we can connect to it using a method like the `connectViaSocket()` method on the `blessed` branch:
Then, whenever we discover an L2CAP-compatible device, we can connect to it using a method like the `connectViaSocket()` method on the `blessed-gatt` branch:
<https://code.briarproject.org/briar/public-mesh-testbed/-/blob/blessed-gatt/app/src/main/java/org/briarproject/publicmesh/bt/BtServiceImpl.java#L416>
#### Notes
- Some devices (eg Samsung J5 2016) receive the advertising packet but not the scan record, so if we want to provide extra information in the scan record we also need to make this information available via GATT
- BLESSED doesn't provide a wrapper for the new advertising set API, which supports new Bluetooth 5 advertising features such as periodic advertising, extended advertising and coded PHY, so if we want to use those features we'll need to use the Android API directly
- If we use any Bluetooth 5 advertising features then we also need to use the Android API for scanning (or submit a pull request upstream to allow legacy mode to be turned off for scanning)
- We can, however, use BLESSED to request coded PHY for GATT connections
......@@ -276,7 +303,6 @@ Then, whenever we discover an L2CAP-compatible device, we can connect to it usin
- Some devices allow connections to multiple peripherals when acting as a central
- Some devices also support connections from multiple centrals when acting as a peripheral, but since GATT doesn't provide a way to send data to a specific central we'd need to do some creative thinking to make use of this
- L2CAP connection-oriented channels (CoC) seem to work as advertised. The server socket provides a PSM (something like a dynamic port number) that needs to be communicated to the client somehow (eg via BLE advertising). We can use L2CAP when the central and peripheral both support it and fall back to GATT when they don't
- The P8 Lite doesn't support advertising (`BluetoothAdapter#getBluetoothLeAdvertiser()` returns `null`)
- The Moto G never receives the result of starting advertising (no callback to `onAdvertisingStarted()` or `onAdvertiseFailure()`)
- The Moto G and P8 Lite can discover the J5, but it can't discover them and they can't discover each other
- The P8 Lite can connect to the J5 via GATT and exchange pings and pongs
......@@ -285,7 +311,7 @@ Then, whenever we discover an L2CAP-compatible device, we can connect to it usin
### BLE Allocator Characteristic
The `blessed` testbed branch exemplifies how individual connections can be made using BLE. However, the one of the core features for a performative ad-hoc mesh system is the ability to make simultaneous p2p connections between 3+ devices. In order to support multi-device scenarios, we developed the "allocator characteristic" system which guides incoming central devices to the correct read characteristic, in order to read arbitrary amounts of data from the advertising peripheral device.
The `blessed-gatt` testbed branch exemplifies how individual connections can be made using BLE. However, the one of the core features for a performative ad-hoc mesh system is the ability to make simultaneous p2p connections between 3+ devices. In order to support multi-device scenarios, we developed the "allocator characteristic" system which guides incoming central devices to the correct read characteristic, in order to read arbitrary amounts of data from the advertising peripheral device.
The high level structure of the allocator characteristic system is built using two main characteristics:
- Read Characteristic
......