-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
work in progress draft of waku mix spec
- Loading branch information
1 parent
1e9d9b6
commit 2e52e22
Showing
1 changed file
with
119 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,119 @@ | ||
| --- | ||
| title: WAKU-MIX | ||
| name: Waku Mix | ||
| editor: Prem Chaitanya Prathi <[email protected]> | ||
| contributors: | ||
| - Akshaya Mani <[email protected]> | ||
| - Hanno Cornelius <[email protected]> | ||
| --- | ||
|
|
||
| # Abstract | ||
| This document explains how [libp2p mix](https://rfc.vac.dev/vac/raw/mix/) protocol will be integrated into waku. This would provide higher anonymity for users publishing or querying for messages to/from the Waku network. | ||
|
|
||
| This document covers integration of mix with [lightpush](https://rfc.vac.dev/waku/standards/core/19/lightpush) and [store](https://rfc.vac.dev/waku/standards/core/13/store) protocols. It also covers the aspect of relay nodes acting as mix nodes. | ||
| Both of these are request response based protocols that follow a service-user and service-provider model. | ||
|
|
||
| Integration of gossipsub with mix is not covered in this document. | ||
|
|
||
| ## Background / Rationale / Motivation | ||
|
|
||
| Waku protocols have weak sender/originator anonymity as explained in [Waku Privacy and Anonymity Analysis](https://vac.dev/rlog/wakuv2-relay-anon/). | ||
| As of today, it is easy to analyze the network traffic and determine originator of messages published into the network or determine the topic interests by analyzing store queries requested by a user. Similar analysis is possible for topic subscriptions via [Filter](https://rfc.vac.dev/waku/standards/core/12/filter) protocol as well. | ||
|
|
||
| By using the libp2p mix protocol, we can improve the anonymity for publishers and store query users in the waku network. | ||
| Anonymity of Filter users will not be addressed by this and will have to be addressed separately. | ||
|
|
||
|
|
||
| # Specification | ||
|
|
||
| Mix protocol integration with waku would end up creating a separate mix network of all the waku nodes that also support the mix protocol. All mix packets would be routed via this mix network before reaching their intended destination. | ||
| Nodes shall advertise that they support mix protocol via their [ENR](#ENR updates). | ||
| Nodes that would like to use mix service shall discover enough mix nodes so that there is always a healthy pool of mix nodes available for selection. The pool size of mix nodes should be in multiples of 100 for the mixing to be effective. | ||
| Nodes that want higher anonymity while publishing a message or performing a store query would use the mix protocol to route their messages to their destination. | ||
| A response/reply to a protocol request sent using Mix can be implemented using `Single Use reply blocks` as the service node will not be aware of the originator of the request. | ||
| In order to have better reliability, any node that wish to send message using mix shall use 2 redundant paths. | ||
|
|
||
| ## Terminology | ||
| The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, | ||
| “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt). | ||
|
|
||
| ## Node Roles | ||
|
|
||
| Mix protocol defines 3 roles for the nodes in the mix network - `entry`, `exit`, `intermediary`. Each node in the network can have all 3 roles or can act as just an entry/exit node as well. | ||
|
|
||
| - An `entry` node is the originator node of a message, i.e a node that wishes to publish/query messages to/from the waku network. | ||
| - An `exit` node is responsible for delivery messages to destination peer in the network. | ||
| - An `intermediary` node is responsible for just forwarding mix packet to the next mix node in the path. | ||
|
|
||
| All the relay nodes would by default act as mix `intermediary` and `exit` nodes in the network. Any node that wishes to publish/query messages from the waku network would act as an entry node. The implementation can provide a configuration to disable a node from acting as an `intermediary` node. | ||
|
|
||
| Light/Edge nodes will only be acting as `entry` nodes. | ||
|
|
||
| ## Flow | ||
|
|
||
| TBD | ||
|
|
||
| ## ENR updates | ||
|
|
||
| Each waku node that supports mix shall include the same in its ENR as per [Waku ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md). | ||
| The `bit 5` in the [waku2 ENR key](https://github.com/waku-org/specs/blob/master/standards/core/enr.md#waku2-enr-key) shall be used to indicate a node's support for mix protocol. | ||
|
|
||
| Each mix node shall also include its `ed25519 public key` that is used for sphinx encryption as a separate field `mix-key` in the [Waku ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md). | ||
|
|
||
|
|
||
| ### Discovery | ||
|
|
||
| Mix protocol provides better anonymity when an originator node has a large pool of mix nodes to choose randomly from. This moves the problem into discover domain and requires the following from discovery mechanisms: | ||
| 1. it is important for nodes to be able to discover as many nodes as possible quickly. This becomes especially important for edge nodes that come online just to publish/query messages for a short period of time. | ||
| 2. it is important to have the most recent online status of the nodes so that broken mix paths are not selected leading to reliability issues. | ||
|
|
||
| Point-2 above can be mitigated partially by choosing redundant mix paths for the same message by the originator but this may not be effective. | ||
|
|
||
| Combining existing discovery mechanisms of [WAKU DISCV5](https://rfc.vac.dev/waku/standards/core/33/discv5), [WAKU PEER-EXCHANGE](https://rfc.vac.dev/waku/standards/core/34/peer-exchange) and [WAKU RENDEZVOUS](https://github.com/waku-org/specs/blob/master/standards/core/rendezvous.md) should help address this problem till a certain extent, but not completely. | ||
|
|
||
| As Waku rendezvous proposes to use a 10 second registration interval and a 1 minute expiry for all nodes to a rendezvous point, this should help nodes maintain up-to-date online status of other mix nodes in the network. | ||
|
|
||
| Edge nodes will have to use rendezvous discovery in order to discover a larger and available set of mix nodes quickly. | ||
|
|
||
| Having following improvements in discovery would further improve the efficacy of mix protocol: | ||
| - quicker discovery of most of the mix nodes | ||
| - to be aware of online status of the mix nodes. | ||
|
|
||
| ## Spam Protection | ||
|
|
||
| Mix protocol in waku network would require rate-limiting/spam protection in following scenarios: | ||
|
|
||
| 1. any node can generate a mix packet and publish into the mix network and there needs to be some validation as to who is allowed to publish and whether the user is within allowed rate-limits. | ||
| 2. any node can generate paths which are broken intentionally and generate messages into the network. | ||
| 3. prevent a single attacker from spawning a huge number of mix nodes so that the user can observe and determine traffic patterns in order to deanonymize users. | ||
|
|
||
| The current [WAKU RLN](https://rfc.vac.dev/waku/standards/core/17/rln-relay) would not be enough to handle scenarios 1 and 2 explained above. RLN can address scenario-3 by making it restrictive for users to be able to spawn a lot of nodes in the network. | ||
|
|
||
| We need to look at either customizing RLN or some alternative mechanism in order go enforce rate-limits or spam protect the mix network. | ||
|
|
||
| ## Potential problems (Need better name for the section) | ||
|
|
||
| The following could be an impact of using a mixing network for publishing and querying messages. The impact needs to be analyzed to take further decisions as to whether using mix would be a default behaviour for using waku protocols such as relay etc. | ||
|
|
||
| - Each mix nodes adds a delay while forwarding the message to the next hop. With a path length of 3 and avg delay of 3 msecs and including packet processing and connection established delay between mix nodes, the overall delay could be significant. | ||
| - Effectiveness of a mixing network depends on how many nodes in the network support mix and what is the set of nodes an originating node considers to select a random subset of nodes to form a path. ????? | ||
|
|
||
| # Implementation | ||
|
|
||
|
|
||
| ## Parameters | ||
|
|
||
|
|
||
| ## Attack Vectors | ||
| TBD | ||
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via | ||
| [CC0](https://creativecommons.org/publicdomain/zero/1.0/). | ||
|
|
||
| ## References | ||
| - [libp2p mix](https://rfc.vac.dev/vac/raw/mix/) | ||
| - [waku lightpush](https://rfc.vac.dev/waku/standards/core/19/lightpush) | ||
| - [waku relay](https://rfc.vac.dev/waku/standards/core/11/relay) | ||
| - [Single Use Reply Blocks]() |