mirror of https://github.com/vacp2p/rfc.git
New RFC: 46/GOSSIPSUB-TOR-PUSH and 47/WAKU2-TOR-PUSH (#554)
This commit is contained in:
kaiserd
GitHub
parent
9645e72011
commit
27ad4582b0
|
|
@ -0,0 +1,188 @@
|
|||
---
|
||||
slug: 46
|
||||
title: 46/GOSSIPSUB-TOR-PUSH
|
||||
name: Gossipsub Tor Push
|
||||
status: raw
|
||||
category: Standards Track
|
||||
tags:
|
||||
editor: Daniel Kaiser <danielkaiser@status.im>
|
||||
contributors:
|
||||
---
|
||||
|
||||
# Abstract
|
||||
|
||||
This document extends the [libp2p gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
|
||||
specifying gossipsub Tor Push,
|
||||
a gossipsub-internal way of pushing messages into a gossipsub network via Tor.
|
||||
Tor Push adds sender identity protection to gossipsub.
|
||||
|
||||
**Protocol identifier**: /meshsub/1.1.0
|
||||
|
||||
Note: Gossipsub Tor Push does not have a dedicated protocol identifier.
|
||||
It uses the same identifier as gossipsub and works with all [pubsub](https://github.com/libp2p/specs/tree/master/pubsub) based protocols.
|
||||
This allows nodes that are oblivious to Tor Push to process messages received via Tor Push.
|
||||
|
||||
# Background
|
||||
|
||||
Without extensions, [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
|
||||
does not protect sender identities.
|
||||
|
||||
A possible design of an anonymity extension to gossipsub is pushing messages through an anonymization network before they enter the gossipsub network.
|
||||
[Tor](https://www.torproject.org/) is currently the largest anonymization network.
|
||||
It is well researched and works reliably.
|
||||
Basing our solution on Tor both inherits existing security research, as well as allows for a quick deployment.
|
||||
|
||||
Using the anonymization network approach, even the first gossipsub node that relays a given message cannot link the message to its sender (within a relatively strong adversarial model).
|
||||
Taking the low bandwidth overhead and the low latency overhead into consideration, Tor offers very good anonymity properties.
|
||||
|
||||
# Functional Operation
|
||||
|
||||
Tor Push allows nodes to push messages over Tor into the gossipsub network.
|
||||
The approach specified in this document is fully backwards compatible.
|
||||
Gossipsub nodes that do not support Tor Push can receive and relay Tor Push messages,
|
||||
because Tor Push uses the same Protocol ID as gossipsub.
|
||||
|
||||
Messages are sent over Tor via [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928).
|
||||
Tor Push uses a dedicated libp2p context to prevent information leakage.
|
||||
To significantly increase resilience and mitigate circuit failures,
|
||||
Tor Push establishes several connections, each to a different randomly selected gossipsub node.
|
||||
|
||||
# Specification
|
||||
|
||||
This section specifies the format of Tor Push messages, as well as how Tor Push messages are received and sent, respectively.
|
||||
|
||||
## Wire Format
|
||||
|
||||
The wire format of a Tor Push message corresponds verbatim to a typical [libp2p pubsub message](https://github.com/libp2p/specs/tree/master/pubsub#the-message).
|
||||
|
||||
```
|
||||
message Message {
|
||||
optional string from = 1;
|
||||
optional bytes data = 2;
|
||||
optional bytes seqno = 3;
|
||||
required string topic = 4;
|
||||
optional bytes signature = 5;
|
||||
optional bytes key = 6;
|
||||
}
|
||||
```
|
||||
|
||||
## Receiving Tor Push Messages
|
||||
|
||||
Any node supporting a protocol with ID `/meshsub/1.1.0` (e.g. gossipsub), can receive Tor Push messages.
|
||||
Receiving nodes are oblivious to Tor Push and will process incoming messages according to the respective `meshsub/1.1.0` specification.
|
||||
|
||||
## Sending Tor Push Messages
|
||||
|
||||
In the following, we refer to nodes sending Tor Push messages as Tp-nodes (Tor Push nodes).
|
||||
|
||||
Tp-nodes MUST setup a separate libp2p context, i.e. [libp2p switch](https://docs.libp2p.io/concepts/multiplex/switch/),
|
||||
which MUST NOT be used for any purpose other than Tor Push.
|
||||
We refer to this context as Tp-context.
|
||||
The Tp-context MUST NOT share any data, e.g. peer lists, with the default context.
|
||||
|
||||
Tp-peers are peers a Tp-node plans to send Tp-messages to.
|
||||
Tp-peers MUST support `/meshsub/1.1.0`.
|
||||
For retrieving Tp-peers, Tp-nodes SHOULD use an ambient peer discovery method that retrieves a random peer sample (from the set of all peers), e.g. [33/WAKU2-DISCV5](/spec/33/).
|
||||
|
||||
Tp-nodes MUST establish a connection as described in sub-section [Tor Push Connection Establishment](#connection-establishment) to at least one Tp-peer.
|
||||
To significantly increase resilience, Tp-nodes SHOULD establish Tp-connections to `D` peers,
|
||||
where `D` is the [desired gossipsub out-degree](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#parameters),
|
||||
with a default value of `8`.
|
||||
|
||||
Each Tp-message MUST be sent via the Tp-context over at least one Tp-connection.
|
||||
To increase resilience, Tp-messages SHOULD be sent via the Tp-context over all available Tp-connections.
|
||||
|
||||
Control messages of any kind, e.g. gossipsub graft, MUST NOT be sent via Tor Push.
|
||||
|
||||
### Connection Establishment
|
||||
|
||||
Tp-nodes establish a `/meshsub/1.1.0` connection to tp-peers via [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928) over [Tor](https://www.torproject.org/).
|
||||
|
||||
Establishing connections, which in turn establishes the respective Tor circuits, can be done ahead of time.
|
||||
|
||||
### Epochs
|
||||
|
||||
Tor Push introduces epochs.
|
||||
The default epoch duration is 10 minutes.
|
||||
(We might adjust this default value based on experiments and evaluation in future versions of this document.
|
||||
It seems a good trade-off between traceablity and circuit building overhead.)
|
||||
|
||||
For each epoch, the Tp-context SHOULD be refreshed, which includes
|
||||
|
||||
* libp2p peer-ID
|
||||
* Tp-peer list
|
||||
* connections to Tp-peers
|
||||
|
||||
Both Tp-peer selection for the next epoch and establishing connections to the newly selected peers SHOULD be done during the current epoch
|
||||
and be completed before the new epoch starts.
|
||||
This avoids adding latency to message transmission.
|
||||
|
||||
# Security/Privacy Considerations
|
||||
|
||||
## Fingerprinting Attacks
|
||||
|
||||
Protocols that feature distinct patterns are prone to fingerprinting attacks when using them over Tor Push.
|
||||
Both malicious guards and exit nodes could detect these patterns
|
||||
and link the sender and receiver, respectively, to transmitted traffic.
|
||||
As a mitigation, such protocols can introduce dummy messages and/or padding to hide patterns.
|
||||
|
||||
## DoS
|
||||
|
||||
### General DoS against Tor
|
||||
|
||||
Using untargeted DoS to prevent Tor Push messages from entering the gossipsub network would cost vast resources,
|
||||
because Tor Push transmits messages over several circuits and the Tor network is well established.
|
||||
|
||||
### Targeting the Guard
|
||||
|
||||
Denying the service of a specific guard node blocks Tp-nodes using the respective guard.
|
||||
Tor guard selection will replace this guard [TODO elaborate].
|
||||
Still, messages might be delayed during this window which might be critical to certain applications.
|
||||
|
||||
### Targeting the Gossipsub Network
|
||||
|
||||
Without sophisticated rate limiting (for example using [17/WAKU2-RLN-RELAY](/spec/17)),
|
||||
attackers can spam the gossipsub network.
|
||||
It is not enough to just block peers that send too many messages,
|
||||
because these messages might actually come from a Tor exit node that many honest Tp-nodes use.
|
||||
Without Tor Push, protocols on top of gossipsub could block peers if they exceed a certain message rate.
|
||||
With Tor Push, this would allow the reputation-based DoS attack described in
|
||||
[Bitcoin over Tor isn't a Good Idea](https://ieeexplore.ieee.org/abstract/document/7163022).
|
||||
|
||||
### Peer Discovery
|
||||
|
||||
The discovery mechanism could be abused to link requesting nodes to their Tor connections to discovered nodes.
|
||||
An attacker that controls both the node that responds to a discovery query,
|
||||
and the node who’s ENR the response contains,
|
||||
can link the requester to a Tor connection that is expected to be opened to the node represented by the returned ENR soon after.
|
||||
|
||||
Further, the discovery mechanism (e.g. discv5) could be abused to distribute disproportionately many malicious nodes.
|
||||
For instance if p% of the nodes in the network are malicious,
|
||||
an attacker could manipulate the discovery to return malicious nodes with 2p% probability.
|
||||
The discovery mechanism needs to be resilient against this attack.
|
||||
|
||||
## Roll-out Phase
|
||||
|
||||
During the roll-out phase of Tor Push, during which only a few nodes use Tor Push,
|
||||
attackers can narrow down the senders of Tor messages to the set of gossipsub nodes that do not originate messages.
|
||||
Nodes who want anonymity guarantees even during the roll-out phase can use separate network interfaces for their default context and Tp-context, respectively.
|
||||
For the best protection, these contexts should run on separate physical machines.
|
||||
|
||||
# Copyright
|
||||
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
||||
# References
|
||||
|
||||
* [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
|
||||
* [libp2p pubsub](https://github.com/libp2p/specs/tree/master/pubsub)
|
||||
* [libp2p pubsub message](https://github.com/libp2p/specs/tree/master/pubsub#the-message)
|
||||
* [libp2p switch](https://docs.libp2p.io/concepts/multiplex/switch)
|
||||
* [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928)
|
||||
* [Tor](https://www.torproject.org/)
|
||||
* [33/WAKU2-DISCV5](/spec/33/)
|
||||
* [Bitcoin over Tor isn't a Good Idea](https://ieeexplore.ieee.org/abstract/document/7163022)
|
||||
* [17/WAKU2-RLN-RELAY](/spec/17)
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
slug: 47
|
||||
title: 47/WAKU2-TOR-PUSH
|
||||
name: Waku v2 Tor Push
|
||||
status: raw
|
||||
category: Best Current Practice
|
||||
tags:
|
||||
editor: Daniel Kaiser <danielkaiser@status.im>
|
||||
contributors:
|
||||
---
|
||||
|
||||
|
||||
# Abstract
|
||||
|
||||
This document extends the [11/WAKU2-RELAY](/spec/11/), specifying Waku Tor Push,
|
||||
which allows nodes to push messages via Tor into the Waku relay network.
|
||||
|
||||
Waku Tor Push builds on [46/GOSSIPSUB-TOR-PUSH](/spec/46).
|
||||
|
||||
**Protocol identifier**: /vac/waku/relay/2.0.0
|
||||
|
||||
Note: Waku Tor Push does not have a dedicated protocol identifier.
|
||||
It uses the same identifier as Waku relay.
|
||||
This allows Waku relay nodes that are oblivious to Tor Push to process messages received via Tor Push.
|
||||
|
||||
|
||||
# Functional Operation
|
||||
|
||||
In its current version, Waku Tor Push corresponds to [46/GOSSIPSUB-TOR-PUSH](/spec/46)
|
||||
applied to [11/WAKU2-RELAY](/spec/11/),
|
||||
instead of [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
|
||||
|
||||
# Security/Privacy Considerations
|
||||
|
||||
see [46/GOSSIPSUB-TOR-PUSH](/spec/46)
|
||||
|
||||
# Copyright
|
||||
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
||||
# References
|
||||
|
||||
* [11/WAKU2-RELAY](/spec/11/)
|
||||
* [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
|
||||
* [46/GOSSIPSUB-TOR-PUSH](/spec/46)
|
||||
* [Tor](https://www.torproject.org/)
|
||||
|
||||
|
||||
|
||||
|
|
@ -15,6 +15,8 @@ bookMenuLevels: 1
|
|||
- [43/WAKU2-NOISE-PAIRING]({{< relref "/docs/rfcs/43/README.md" >}})
|
||||
- [44/WAKU2-DANDELION]({{< relref "/docs/rfcs/44/README.md" >}})
|
||||
- [45/WAKU2-ADVERSARIAL-MODELS]({{< relref "/docs/rfcs/45/README.md" >}})
|
||||
- [46/GOSSIPSUB-TOR-PUSH]({{< relref "/docs/rfcs/46/README.md" >}})
|
||||
- [47/WAKU2-TOR-PUSH]({{< relref "/docs/rfcs/47/README.md" >}})
|
||||
- Draft
|
||||
- [1/COSS]({{< relref "/docs/rfcs/1/README.md" >}})
|
||||
- [3/REMOTE-LOG]({{< relref "/docs/rfcs/3/README.md" >}})
|
||||
|
|
|
|||
Loading…
Reference in New Issue