specs/standards/core/mix.md

title	name	editor	contributors
WAKU-MIX	Waku Mix	Prem Chaitanya Prathi <premprathi@proton.me>	Akshaya Mani <akshaya@status.im> Hanno Cornelius <hanno@status.im>

Tags

waku/core-protocol

Abstract

The document describes libp2p 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 and 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 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. 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 query messages sent by a user. Same applies for topic subscriptions via 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, 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 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 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.

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 and using one of the ENR based discovery methods.

Nodes that want higher anonymity while publishing a message via lightpush or performing a 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 MUST be the payload in the sphinx packet.

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 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 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.

ENR updates

Each waku node that supports the mix intermediary or exit role SHOULD indicate the same in its discoverable ENR. 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 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 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.

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.

References

• libp2p mix
• waku lightpush
• waku relay
• ENR
• sphinx encryption