From ebf8b463aadbda9a390eb770e72ac886b3c15343 Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Tue, 11 Mar 2025 18:19:54 +0530 Subject: [PATCH 1/5] waku mix protocol integration spec --- standards/core/mix.md | 128 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 standards/core/mix.md diff --git a/standards/core/mix.md b/standards/core/mix.md new file mode 100644 index 0000000..8c9ec40 --- /dev/null +++ b/standards/core/mix.md @@ -0,0 +1,128 @@ +--- +title: WAKU-MIX +name: Waku Mix +editor: Prem Chaitanya Prathi +contributors: + - Akshaya Mani + - Hanno Cornelius +--- + +## Tags + +`waku/core-protocol` + +# Abstract +The document describes [libp2p mix](https://rfc.vac.dev/vac/raw/mix/) integration into waku. +This integration provides 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. +Both of these are `request-response` based protocols that follow a service-user and a service-provider model. +A node that initiates the request is a `service-user/client` whereas a node that replies to the request is the `service-provider/service-node`. + +This document also covers the aspect of relay nodes acting as mix nodes. +Integration of [waku relay](https://rfc.vac.dev/waku/standards/core/11/relay) 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/). +Without further anonymization, it is easy to analyze the network traffic and determine the originator of messages published into the network. +Topic interests of a user can be identified by analyzing [Store](https://rfc.vac.dev/waku/standards/core/13/store) query messages sent by a user. +Same applies for topic subscriptions via [Filter](https://rfc.vac.dev/waku/standards/core/12/filter) protocol. + +`Mix` protocol allows libp2p nodes to send messages without revealing the sender's identity (peer ID, IP address) to intermediary mix nodes or the recipient/destination. +Anonymity is achieved by using the [Sphinx packet format](#references), which encrypts and routes messages through a series of mix nodes before reaching the recipient. + +By integrating the `mix` protocol into the waku network, we can improve the anonymity for publishers and store query users. +Each waku relay node will be acting as a mix node that forms an `overlay mix network`. +This network of mix nodes SHALL relay mix messages anonymously to the recepient. + +Anonymity of [Filter](https://rfc.vac.dev/waku/standards/core/12/filter) users is not addressed by this document. + +## 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). + +## Theory / Semantics + +Waku Mix creates an `overlay network` of all the waku nodes that support the `mix` protocol. + +Nodes with `mix` protocol mounted SHOULD advertise that they support mix protocol via their their chosen discovery method. +They MAY do so by updating their [ENR](#enr-updates) and using one of the ENR based discovery methods. + +Nodes that want higher anonymity while publishing a message via [lightpush](https://rfc.vac.dev/waku/standards/core/19/lightpush) or performing a [store](https://rfc.vac.dev/waku/standards/core/13/store) query SHOULD use the `mix` protocol to route their messages to the destination. +Sender Node that would like to use `mix` protocol SHOULD 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 large enough for the mixing to be effective. +We RECOMMEND a pool size of at least 100 mix nodes for the mixing to be effective. + +The serialized [Waku Message](https://rfc.vac.dev/waku/standards/core/14/message) SHOULD be the payload in the [sphinx packet](https://rfc.vac.dev/vac/raw/mix#4-sphinx-packet-format). + +In order to provide anonymity of the sender node from the `service-node`, `Single Use reply blocks` or `anonymous replies` as specified in the original [sphinx](#references) paper SHALL be used. + +A node that sends messages using `mix` MAY use two redundant (paths)[https://rfc.vac.dev/vac/raw/mix#24-node-discovery] to have better reliability of the message being delivered. +It is up to the higher-layer mixed protocol to deduplicate redundant messages received in this way. + +## Node Roles + +Mix protocol defines 3 roles for the nodes in the mix network - `sender`, `exit`, `intermediary`. + +- An `sender` 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 delivering messages to destination peer in the network. +- An `intermediary` node is responsible for forwarding a mix packet to the next mix node in the path. + +A Waku relay node SHOULD by default have mix `intermediary` and `exit` node roles in the network. +The implementation MAY provide a configuration to disable a node from acting as an `intermediary\exit` node. + +Any waku node that wishes to publish/query messages from the waku network MUST act as a `sender` node. + +Resource-restricted/Edge nodes with short connection windows SHOULD always be acting as `sender` nodes. + +## ENR updates + +Each waku node that supports `mix` SHOULD indicate the same in its discoverable [ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md). +The following fields MUST be set as part of the discoverable ENR of a mix waku node: +- The `bit 5` in the [waku2 ENR key](https://github.com/waku-org/specs/blob/master/standards/core/enr.md#waku2-enr-key) is reserved to indicate `mix`support. This bit MUST be set to true to indicate `mix` support. +- A new field `mix-key` SHOULD be set to the `ed25519 public key` which is used for sphinx encryption. + +### Discovery + +Mix protocol provides better anonymity when an originator node has a sufficiently large pool of mix nodes to do path selection. +This moves the problem into discovery 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 mix paths that are selected are not broken which lead to reliability issues. + +Point-2 above can be mitigated partially by choosing redundant mix paths for the same message by the sender node. +This may not be an effective solution as it increases the overall bandwidth usage. + +## Spam Protection + +Mix protocol in waku network SHOULD have `rate-limiting/spam` protection to handle scenarios such as below: + +1. Any node can generate a mix packet and publish into the mix network. Hence 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 intentionally generate paths which are broken and send messages into the mix network. +3. An attacker can spawn a huge number of mix nodes so that user behaviour is observed in order to determine traffic patterns and deanonymize users. + +There is a need to enforce rate-limits and spam protect the mix network. +The rate-limiting and spam protection SHALL be addressed as part of future work. + +## Tradeoffs + +Using `mix` protocol for publishing and querying messages adds certain overhead which is primarily the delay in delivering message to the destination. +The overall additional delay `D` depends on the following params: +- path length `L` +- delay added by each intermediary node `dm` +- connection establishment time `dc` +- processing delay `dp` + +Delay overhead can be calculated as `D = L * (dm + dc +dp)` + +## 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) + - [ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md) + - [sphinx encryption](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf) \ No newline at end of file From 61493278e359f6cdde47a7b6820837898c990c79 Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Wed, 12 Mar 2025 11:24:05 +0530 Subject: [PATCH 2/5] address review comments --- standards/core/mix.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/standards/core/mix.md b/standards/core/mix.md index 8c9ec40..2c541d4 100644 --- a/standards/core/mix.md +++ b/standards/core/mix.md @@ -54,7 +54,7 @@ Sender Node that would like to use `mix` protocol SHOULD discover enough mix nod The pool size of mix nodes SHOULD be large enough for the mixing to be effective. We RECOMMEND a pool size of at least 100 mix nodes for the mixing to be effective. -The serialized [Waku Message](https://rfc.vac.dev/waku/standards/core/14/message) SHOULD be the payload in the [sphinx packet](https://rfc.vac.dev/vac/raw/mix#4-sphinx-packet-format). +The serialized [Waku Message](https://rfc.vac.dev/waku/standards/core/14/message) MUST be the payload in the [sphinx packet](https://rfc.vac.dev/vac/raw/mix#4-sphinx-packet-format). In order to provide anonymity of the sender node from the `service-node`, `Single Use reply blocks` or `anonymous replies` as specified in the original [sphinx](#references) paper SHALL be used. @@ -78,9 +78,9 @@ Resource-restricted/Edge nodes with short connection windows SHOULD always be ac ## ENR updates -Each waku node that supports `mix` SHOULD indicate the same in its discoverable [ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md). +Each waku node that supports the `mix intermediary or exit role` SHOULD indicate the same in its discoverable [ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md). The following fields MUST be set as part of the discoverable ENR of a mix waku node: -- The `bit 5` in the [waku2 ENR key](https://github.com/waku-org/specs/blob/master/standards/core/enr.md#waku2-enr-key) is reserved to indicate `mix`support. This bit MUST be set to true to indicate `mix` support. +- The `bit 5` in the [waku2 ENR key](https://github.com/waku-org/specs/blob/master/standards/core/enr.md#waku2-enr-key) is reserved to indicate `mix` support. This bit MUST be set to true to indicate `mix` support. - A new field `mix-key` SHOULD be set to the `ed25519 public key` which is used for sphinx encryption. ### Discovery @@ -102,7 +102,7 @@ Mix protocol in waku network SHOULD have `rate-limiting/spam` protection to hand 3. An attacker can spawn a huge number of mix nodes so that user behaviour is observed in order to determine traffic patterns and deanonymize users. There is a need to enforce rate-limits and spam protect the mix network. -The rate-limiting and spam protection SHALL be addressed as part of future work. +The rate-limiting and spam protection shall be addressed as part of future work. ## Tradeoffs From 58e06e8c20003ae41b12b9d435086c57a8a50be8 Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Thu, 13 Mar 2025 18:52:09 +0530 Subject: [PATCH 3/5] address review comments --- standards/core/mix.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/standards/core/mix.md b/standards/core/mix.md index 2c541d4..d7cc087 100644 --- a/standards/core/mix.md +++ b/standards/core/mix.md @@ -33,7 +33,7 @@ Same applies for topic subscriptions via [Filter](https://rfc.vac.dev/waku/stand Anonymity is achieved by using the [Sphinx packet format](#references), which encrypts and routes messages through a series of mix nodes before reaching the recipient. By integrating the `mix` protocol into the waku network, we can improve the anonymity for publishers and store query users. -Each waku relay node will be acting as a mix node that forms an `overlay mix network`. +Each waku relay node SHOULD be acting as a mix node that forms an `overlay mix network`. This network of mix nodes SHALL relay mix messages anonymously to the recepient. Anonymity of [Filter](https://rfc.vac.dev/waku/standards/core/12/filter) users is not addressed by this document. @@ -44,9 +44,9 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL ## Theory / Semantics -Waku Mix creates an `overlay network` of all the waku nodes that support the `mix` protocol. +Waku Mix creates an `overlay network` of all the Waku nodes that support the `mix` protocol. -Nodes with `mix` protocol mounted SHOULD advertise that they support mix protocol via their their chosen discovery method. +Nodes with `mix` protocol mounted SHOULD advertise that they support `mix` protocol via their their chosen discovery method. They MAY do so by updating their [ENR](#enr-updates) and using one of the ENR based discovery methods. Nodes that want higher anonymity while publishing a message via [lightpush](https://rfc.vac.dev/waku/standards/core/19/lightpush) or performing a [store](https://rfc.vac.dev/waku/standards/core/13/store) query SHOULD use the `mix` protocol to route their messages to the destination. @@ -72,7 +72,7 @@ Mix protocol defines 3 roles for the nodes in the mix network - `sender`, `exit` A Waku relay node SHOULD by default have mix `intermediary` and `exit` node roles in the network. The implementation MAY provide a configuration to disable a node from acting as an `intermediary\exit` node. -Any waku node that wishes to publish/query messages from the waku network MUST act as a `sender` node. +Any waku node that wishes to publish/query messages via `mix` from the waku network MUST act as a `sender` node. Resource-restricted/Edge nodes with short connection windows SHOULD always be acting as `sender` nodes. @@ -85,7 +85,7 @@ The following fields MUST be set as part of the discoverable ENR of a mix waku n ### Discovery -Mix protocol provides better anonymity when an originator node has a sufficiently large pool of mix nodes to do path selection. +Mix protocol provides better anonymity when a sender node has a sufficiently large pool of mix nodes to do path selection. This moves the problem into discovery 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 mix paths that are selected are not broken which lead to reliability issues. From 6a3d3dde9b4847fe3472953d8308325d300b32d7 Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Mon, 24 Mar 2025 13:49:17 +0530 Subject: [PATCH 4/5] chore: apply suggestions from code review Co-authored-by: AkshayaMani --- standards/core/mix.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/standards/core/mix.md b/standards/core/mix.md index d7cc087..8f2d1c5 100644 --- a/standards/core/mix.md +++ b/standards/core/mix.md @@ -56,7 +56,7 @@ We RECOMMEND a pool size of at least 100 mix nodes for the mixing to be effectiv The serialized [Waku Message](https://rfc.vac.dev/waku/standards/core/14/message) MUST be the payload in the [sphinx packet](https://rfc.vac.dev/vac/raw/mix#4-sphinx-packet-format). -In order to provide anonymity of the sender node from the `service-node`, `Single Use reply blocks` or `anonymous replies` as specified in the original [sphinx](#references) paper SHALL be used. +To allow acknowledgments from the `service-node` while preserving sender anonymity, `Single Use Reply Blocks` or `anonymous replies` as specified in the original [sphinx](#references) paper SHALL be used. A node that sends messages using `mix` MAY use two redundant (paths)[https://rfc.vac.dev/vac/raw/mix#24-node-discovery] to have better reliability of the message being delivered. It is up to the higher-layer mixed protocol to deduplicate redundant messages received in this way. @@ -74,7 +74,7 @@ The implementation MAY provide a configuration to disable a node from acting as Any waku node that wishes to publish/query messages via `mix` from the waku network MUST act as a `sender` node. -Resource-restricted/Edge nodes with short connection windows SHOULD always be acting as `sender` nodes. +Resource-restricted/Edge nodes with short connection windows MUST _only_ act as `sender` nodes and cannot function as intermediaries or exit nodes. ## ENR updates From a5832e3268d7f8f3cd60c213da8b4e2d2badc0d0 Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Mon, 24 Mar 2025 14:02:31 +0530 Subject: [PATCH 5/5] chore: address review comments --- standards/core/mix.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/standards/core/mix.md b/standards/core/mix.md index 8f2d1c5..f75d851 100644 --- a/standards/core/mix.md +++ b/standards/core/mix.md @@ -20,7 +20,6 @@ Both of these are `request-response` based protocols that follow a service-user A node that initiates the request is a `service-user/client` whereas a node that replies to the request is the `service-provider/service-node`. This document also covers the aspect of relay nodes acting as mix nodes. -Integration of [waku relay](https://rfc.vac.dev/waku/standards/core/11/relay) with mix is not covered in this document. ## Background / Rationale / Motivation @@ -83,14 +82,17 @@ The following fields MUST be set as part of the discoverable ENR of a mix waku n - The `bit 5` in the [waku2 ENR key](https://github.com/waku-org/specs/blob/master/standards/core/enr.md#waku2-enr-key) is reserved to indicate `mix` support. This bit MUST be set to true to indicate `mix` support. - A new field `mix-key` SHOULD be set to the `ed25519 public key` which is used for sphinx encryption. +Adding these fields to the ENR may cause the ENR size to cross the 300 byte limit especially in case a node supports multiple transports. +This limitation will have to be addressed in future. ### Discovery Mix protocol provides better anonymity when a sender node has a sufficiently large pool of mix nodes to do path selection. This moves the problem into discovery 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 mix paths that are selected are not broken which lead to reliability issues. +2. The discovery mechanism MUST be unbiased and not biased toward specific subsets (e.g., nodes that are topologically closer). +3. It is important to have the most recent online status of the nodes so that mix paths that are selected are not broken which lead to reliability issues. -Point-2 above can be mitigated partially by choosing redundant mix paths for the same message by the sender node. +Point-3 above can be mitigated partially by choosing redundant mix paths for the same message by the sender node. This may not be an effective solution as it increases the overall bandwidth usage. ## Spam Protection @@ -115,6 +117,12 @@ The overall additional delay `D` depends on the following params: Delay overhead can be calculated as `D = L * (dm + dc +dp)` +## Future Work + +- Integration of [waku relay](https://rfc.vac.dev/waku/standards/core/11/relay) with mix. +- [Spam protection](#spam-protection) of mix overlay network. +- Alternative way to communicate mix-public-key in order to overcome [ENR](#enr-updates) size limitations. + ## Copyright Copyright and related rights waived via