AtHeartEngineer/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-06 22:34:02 -05:00
Code Issues Packages Projects Releases Wiki Activity

include spam protection specification and interface details

Browse Source
This commit is contained in:
Prem Chaitanya Prathi
2025-12-19 21:29:52 +05:30
parent dabc31786b
commit ad26780dfc
1 changed files with 355 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

389
vac/raw/mix.md
View File

@@ -273,7 +273,7 @@ Pluggable components define functionality that extends or configures the behavio
Each component in this section falls into one of two categories:
- Required for interoperability and path construction (_e.g.,_ discovery, delay strategy).
- Optional or deployment-specific (_e.g.,_ spam protection, cover traffic, incentivization).
- Optional or deployment-specific (_e.g._ spam protection, cover traffic, incentivization).
The following subsections describe the role and expected behavior of each.
@@ -322,24 +322,20 @@ Delay strategies SHOULD introduce enough uncertainty to prevent adversaries from
### 6.3 Spam Protection
The Mix Protocol supports optional spam protection mechanisms to defend recipients against abusive or unsolicited traffic.
These mechanisms are applied at the exit node, which is the final node in the mix path before the message is delivered to its destination via the respective libp2p protocol.
The Mix Protocol supports optional spam protection mechanism to defend the mixnet against denial-of-service (DoS) or resource exhaustion attacks.
Without spam protection, malicious actors could flood mix nodes with valid Sphinx packets, exhausting computational resources or bandwidth of the mix nodes eventually making them unusable.
Spam protection is critical to make the mixnet robust enough to be used in a production environment.
Exit nodes that enforce spam protection MUST validate the attached proof before forwarding the message.
If validation fails, the message MUST be discarded.
Spam protection mechanism is considered pluggable because different deployments may require different trade-offs between computational overhead, attack resistance, and Sybil resistance.
The specific mechanism used MUST be followed by all participating mix nodes within a deployment to ensure interoperability.
Common strategies include Proof of Work (PoW), Verifiable Delay Functions (VDFs), and Rate-limiting Nullifiers (RLNs).
Two primary architectural approaches exist for integrating spam protection: sender-generated per-hop proofs and per-Hop Generated Proofs.
Each approach has distinct implications for computational overhead, latency, security properties, Sybil resistance, and implementation complexity.
The sender is responsible for appending the appropriate spam protection data (e.g., nonce, timestamp) to the message payload.
The format and verification logic depend on the selected method.
An example using PoW is included in Appendix A.
Detailed design requirements, architectural approaches, packet structure considerations, node responsibilities, and recommendedions are specified in [Section 9](#9-spam-protection-architecture).
Note:
The spam protection mechanisms described above are intended to protect the destination application or protocol from message abuse or flooding.
They do not provide protection against denial-of-service (DoS) or resource exhaustion attacks targeting the mixnet itself (_e.g.,_ flooding mix nodes with traffic, inducing processing overhead, or targeting bandwidth).
Protections against attacks targeting the mixnet itself are not defined in this specification but are critical to the long-term robustness of the system.
Future versions of the protocol may define mechanisms to rate-limit clients, enforce admission control, or incorporate incentives and accountability to defend the mixnet itself from abuse.
Note that application-level or origin-protocol spam protection mechanisms are out of scope for the Mix Protocol and MUST be handled by the appropriate protocol layer itself.
For example, Waku protocols use RLN (Rate Limiting Nullifiers) for spam protection, which is handled by [Waku-Relay](https://rfc.vac.dev/waku/standards/core/17/rln-relay) protocol, and the RLN proof would be included as part of the mix payload.
### 6.4 Cover Traffic
@@ -438,8 +434,6 @@ A mix node performing intermediary processing MUST treat each packet as stateles
To process a Sphinx packet as an exit, a mix node MUST:
- Extract the plaintext message from the final decrypted packet.
- Validate any attached spam protection proof.
- Discard the message if spam protection validation fails.
- Forward the valid message to the Mix Exit Layer for delivery to the destination origin protocol instance.
The node MUST NOT retain decrypted content after forwarding.
@@ -685,7 +679,7 @@ The construction process wraps the message in a sequence of encryption layers&md
To initiate the Mix Protocol, the origin protocol instance submits a message to the Mix Entry Layer on the same node.
This layer forwards it to the local Mix Protocol instance, which constructs a Sphinx packet using the following REQUIRED inputs:
- **Application message**: The serialized message provided by the origin protocol instance. The Mix Protocol instance applies any configured spam protection mechanism and attaches one or two SURBs prior to encapsulating the message in the Sphinx packet. The initiating node MUST ensure that the resulting payload size does not exceed the maximum supported size defined in [Section 8.3.2](#832-payload-size).
- **Application message**: The serialized message provided by the origin protocol instance. The Mix Protocol instance attaches one or two SURBs prior to encapsulating the message in the Sphinx packet. The initiating node MUST ensure that the resulting payload size does not exceed the maximum supported size defined in [Section 8.3.2](#832-payload-size).
- **Origin protocol codec**: The libp2p protocol string corresponding to the origin protocol instance. This is included in the payload so that the exit node can route the message to the intended destination protocol after decryption.
- **Mix Path length $L$**: The number of mix nodes to include in the path. The mix path MUST consist of at least three hops, each representing a distinct mix node.
- **Destination address $Δ$**: The routing address of the intended recipient of the message. This address is encoded in $(tκ - 2)$ bytes as defined in [Section 8.4](#84-address-and-delay-encoding) and revealed only at the last hop.
@@ -699,7 +693,6 @@ The construction MUST proceed as follows:
1. **Prepare Application Message**
- Apply any configured spam protection mechanism (_e.g.,_ PoW, VDF, RLN) to the serialized message. Spam protection mechanisms are pluggable as defined in [Section 6.3](#63-spam-protection).
- Attach one or more SURBs, if required. Their format and processing are specified in [Section X.X].
- Append the origin protocol codec in a format that enables the exit node to reliably extract it during parsing. A recommended encoding approach is to prefix the codec string with its length, encoded as a compact varint field limited to two bytes. Regardless of the scheme used, implementations MUST agree on the format within a deployment to ensure deterministic decoding.
- Pad the result to the maximum application message length of $3968$ bytes using a deterministic padding scheme. This value is derived from the fixed payload size in [Section 8.3.2](#832-payload-size) ($3984$ bytes) minus the security parameter $κ = 16$ bytes defined in [Section 8.2](#82-cryptographic-primitives). The chosen scheme MUST yield a fixed-size padded output and MUST be consistent across all mix nodes to ensure correct interpretation during unpadding. For example, schemes that explicitly encode the padding length and prepend zero-valued padding bytes MAY be used.
@@ -1155,12 +1148,11 @@ Once the node determines its role as an exit following the steps in [Section 8.6
- Next, parse the unpadded message deterministically to extract:
- optional spam protection proof
- zero or more SURBs
- the origin protocol codec
- the serialized application message
- Parse and deserialize the metadata fields required for spam validation, SURB extraction, and protocol codec identification, consistent with the format and extensions applied by the initiator.
- SURB extraction, and protocol codec identification, consistent with the format and extensions applied by the initiator.
The application message itself MUST remain serialized.
- If parsing fails at any stage, discard $m$ and terminate processing.
@@ -1171,14 +1163,344 @@ Once the node determines its role as an exit following the steps in [Section 8.6
- The Exit Layer is responsible for establishing a client-only connection and forwarding the message to the destination. Implementations MAY reuse an existing stream to the destination, if doing so does not introduce any observable linkability between forwarded messages.
## 9. Security Considerations
## 9. Spam Protection Architecture
This section provides detailed specifications for integrating a spam protection mechanism with the Mix Protocol.
As introduced in [Section 6.3](#63-spam-protection), Mix protocol supports a pluggable spam protection mechanism.
This section defines design requirements, architectural approaches, packet structure modifications, and node responsibilities for spam protection.
This section also defines the interfaces between the Mix Protocol and spam protection mechanisms.
### 9.1 Spam Protection Mechanism Requirements
Any spam protection mechanism integrated with the Mix Protocol MUST satisfy the following requirements:
- Each mix node in the path MUST verify proofs before applying delay and forwarding or taking further action (in the case of exit nodes).
- Spam protection data and verification MUST NOT enable linking or correlating packets across hops.
Spam protection proofs MUST be unique per hop.
- Spam protection proofs MUST NOT be reusable across different packets or hops.
Each hop SHOULD be able to detect replayed or forged proofs (e.g., via cryptographic binding to packet-specific or hop-specific data).
- Proofs SHOULD be bound to fresh, packet-specific data (_e.g.,_ payload states, timestamps) that cannot be known in advance, preventing adversaries from pre-computing large batches of proofs offline for spam attacks.
- Verification overhead MUST be significantly lower than proof generation cost.
Otherwise, the spam protection mechanism would add substantial delay at each hop.
- Proof generation and verification methods MUST preserve unlinkability of the sender and MUST NOT leak any additional metadata about the sender or node.
- The mechanism SHOULD provide a way to punish spammers or detect misuse.
### 9.2 Integration Architecture
Two primary architectural approaches exist for integrating spam protection with the Mix Protocol, each with distinct trade-offs.
This section elaborates on each approach and also lists down trade-offs and provides a comparison which helps in making a decision for deployments.
#### 9.2.1 Sender-Generated Per-Hop Proofs
In this approach, the sender generates spam protection proofs for all hops in the mix path during Sphinx packet construction.
Proofs are embedded within each hop's routing block in the encrypted header $\beta$.
##### 9.2.1.1 How It Works
During Sphinx packet construction, as defined in [Section 8.5.2](#852-construction-steps), the sender follows the standard construction process (computing ephemeral secrets in step 3.a and encrypted payloads in step 3.d).
After steps 3.a and 3.d, the sender additionally performs the following spam protection steps:
1. **Generate and Embed Proofs:**
For each hop $i$ in the path:
a. The sender computes the spam protection proof cryptographically bound to $\delta_{i+1}$ (the decrypted payload that hop $i$ will compute).
This binding ensures proofs are path-specific and tied to specific encrypted message content, preventing proof extraction and reuse.
b. The proof and related metadata required for verification are embedded in hop $i$'s routing block within $\beta_i$ during header construction (step 3.c)
2. **Verification at Each Hop:**
During Sphinx processing, hop $i$ decrypts $\beta_i$ to extract the proof and metadata, decrypts $\delta$ to get $\delta'$, then verifies the proof matches $\delta'$ using the provided metadata
##### 9.2.1.2 Advantages
- Only the sender performs the expensive proof generation.
Intermediate nodes only verify proofs, which is less expensive and also reduces latency per hop.
- Each hop's proof is encrypted in a separate layer of $\beta$, making proofs unique per hop and cryptographically isolated.
- Aligned with Sphinx philosophy wherein complexity is at the sender while intermediate nodes perform lightweight operations.
##### 9.2.1.3 Disadvantages
- Sender must generate $L$ proofs, which can be expensive.
- Each hop's routing block must include spam protection data, increasing overall header and packet size (see impact analysis below).
- Sender must know the full path before generating proofs and cannot reuse the proofs if two different paths are chosen for the same message.
- Proofs can only be verified AFTER expensive Sphinx processing operations (session key derivation, replay checking, header integrity verification, and decryption), since they are encrypted within the $\beta$ field and bound to the decrypted payload state $\delta'$.
Deployments using this approach SHOULD augment with additional network-level protections (connection rate limiting, localized peer reputation) to defend against attacks that can lead to draining node's resources.
- This approach does not inherently provide Sybil resistance as intermediate nodes do not generate any proof using their credentials.
A separate Sybil resistance mechanism (such as membership proofs) would be required, which would add additional data to the packet header.
##### 9.2.1.4 Impact on Header Size
If spam protection proofs are embedded in $\beta$, the per-hop routing block size increases from $(t+1)\kappa$ bytes to $(t+1)\kappa + |\mathrm{spam\_proof}|$ bytes.
The total $\beta$ size becomes: $(r(t+1) + 1)\kappa + r \times |\mathrm{spam\_proof}|$ bytes, where $r$ is the maximum path length.
With the current recommended values ($r=5$, $t=6$, $\kappa=16$):
- Original header size: $624$ bytes
- Header size increase: $5 \times |\mathrm{spam\_proof}|$ bytes
Note that $|\mathrm{spam\_proof}|$ includes both the proof and all verification metadata.
e.g. If using RLN, where proof + metadata ~= $300$ bytes, Header size becomes: $624 + 1500 = 2124$ bytes
#### 9.2.2 Per-Hop Generated Proofs
In this approach, each mix node generates a completely fresh spam protection proof for the next hop after verifying proof for the incoming packet.
The proof is added as an additional packet header field (e.g., $\sigma$) that is updated at each hop, similar to how $\alpha$, $\beta$, and $\gamma$ are transformed during Sphinx processing.
The proof MAY be generated by binding to all the components of outgoing sphinx packet $(\alpha', \beta', \gamma', \delta')$.
##### 9.2.2.1 How It Works
1. The sender generates an initial spam protection proof $\sigma_0$ for the first hop, along with any verification metadata required by the spam protection mechanism (such as merkle roots, epoch identifiers, public parameters, or identifiers).
The proof MAY be cryptographically bound to the outgoing Sphinx packet structure.
This is included as a new header field in the Sphinx packet.
2. The first hop verifies $\sigma_0$ using the provided metadata before processing the Sphinx packet.
3. After successful verification and Sphinx processing, the hop generates a completely new proof $\sigma_1$ (with updated metadata) for the next hop bound to the transformed packet state.
4. The updated packet $(\alpha', \beta', \gamma', \delta', \sigma_1)$ is forwarded to the next hop.
5. This process repeats at each intermediate hop until the packet reaches the exit.
##### 9.2.2.2 Advantages
- Sender only generates one initial proof instead of $L$ proofs.
- Spam protection data has less overhead on packet header size.
- Proofs can be verified BEFORE expensive Sphinx processing operations (session key derivation, header integrity verification, and decryption).
This provides better DoS protection by allowing nodes to reject invalid packets earlier, before performing costly cryptographic operations.
- If a membership-based spam protection mechanism is used (_e.g.,_ Rate Limiting Nullifiers), the same mechanism can provide Sybil resistance.
Nodes must prove membership or ownership of resources at each hop, making it economically infeasible to operate large numbers of Sybil nodes.
##### 9.2.2.3 Disadvantages
- Each node must generate fresh proofs, adding additional latency and processing cost at each hop.
The proof generation latency can be overcome by doing pre-computation of proofs but the proofs would not be bound to message contents rather some other means to add uniqueness.
- When using rate-limiting mechanisms (such as RLN), intermediate nodes may exhaust their rate limits due to random path selection by multiple independent senders, causing legitimate packets to be dropped even when no individual sender is misbehaving.
This creates availability bottlenecks at popular nodes and unpredictable message delivery.
This can be mitigated by assigning higher rate-limits to intermediate or popular nodes(e.g. tied to reputation).
##### 9.2.2.4 Impact on Header Size
A new header field $\sigma$ must be added to the Sphinx packet structure:
```text
+--------+----------+--------+----------+----------+
| α | β | γ | σ | δ |
| 32 B | variable | 16 B | variable | variable |
+--------+----------+--------+----------+----------+
```
The size of $\sigma$ depends on the spam protection method.
With the current recommended values:
- Original header size: $624$ bytes
- Header size increase: $|\sigma|$ bytes
Note that $|\sigma|$ includes both the proof and all verification metadata.
e.g. If using RLN, where metadata + proof ~= $300$ bytes, Header size becomes: $624 + 300 = 924$ bytes
#### 9.2.3 Comparison
The following table provides a brief comparison between both integration approaches.
| Aspect | Sender-Generated Per-Hop Proofs | Per-Hop Generated Proofs |
| ---------------------------------- | --------------------------------------- | ------------------------------------------ |
| **DoS protection** | Weaker (verify after Sphinx decryption) | Stronger (verify before Sphinx decryption) |
| **Sender burden** | High (generates $L$ proofs) | Low (generates 1 proof) |
| **Per-hop computational overhead** | Low (verify only) | High (verify + generate) |
| **Per-hop latency** | Minimal (fast verification) | Higher (mitigated with pre-computation) |
| **Total end-to-end latency** | Lower | Higher (mitigated with pre-computation) |
| **Sybil resistance** | Requires separate mechanism | Can be integrated |
| **Header size increase** | $L \times \mathrm{spam\_proof}$ | $\|\sigma\|$ |
Separate specifications defining concrete spam protection mechanisms SHOULD specify recommended approaches and provide detailed integration instructions.
### 9.3 Node Responsibilities
In addition to the standard Sphinx processing responsibilities described in [Section 8](#8-sphinx-packet-format), nodes MUST implement the following spam protection responsibilities based on the chosen architectural approach.
#### 9.3.1 For Sender-Generated Per-Hop Proofs
- **Sender nodes**: MUST generate spam protection proofs for each hop during packet construction as described in [Section 9.2.1.1](#9211-how-it-works).
The sender MUST NOT include any identifying information in the proofs.
- **Intermediate and exit nodes**: MUST verify the spam protection proof during packet processing as described in [Section 9.2.1.1](#9211-how-it-works).
Verification occurs after decrypting $\beta$ and $\delta$ during the shared preprocessing steps in [Section 8.6.1](#861-shared-preprocessing).
If verification fails, nodes MUST discard the packet and MAY apply penalties or rate-limiting measures.
#### 9.3.2 For Per-Hop Generated Proofs
- **Sender nodes**: MUST generate the initial spam protection proof $\sigma_0$ for the first hop as described in [Section 9.2.2.1](#9221-how-it-works).
The proof MAY be bound to the outgoing Sphinx packet and MUST NOT contain identifying information.
- **Intermediate nodes**: MUST verify the incoming proof $\sigma$ BEFORE any other Sphinx processing.
If verification fails, nodes MUST discard the packet and MAY apply penalties or rate-limiting measures to the previous hop.
If incoming proof is valid, nodes MUST generate a fresh proof $\sigma'$ for the next hop that is unlinkable from $\sigma$.
- **Exit nodes**: MUST verify the incoming proof $\sigma$ before decrypting the final payload.
Exit nodes do not generate new proofs.
### 9.4 Anonymity and Security Considerations
Spam protection mechanisms MUST be carefully designed to avoid introducing correlation risks:
- **Timing side channels**: Proof verification and generation time SHOULD be constant to prevent packet fingerprinting through timing analysis.
- **Proof uniqueness and unlinkability**: Each hop's proof MUST be unique and unlinkable from other hops' proofs.
- **Verification failure handling**: Nodes MUST handle failures in a manner such that probing attacks can be prevented.
- **Global state and coordination**: Mechanisms requiring global state MUST ensure access/updates don't leak any additional information.
State lookups SHOULD use privacy-preserving techniques.
- **Sybil attacks**: For sender-generated proofs, Sybil resistance cannot be included and nodes can still perform Sybil attacks by colluding.
For per-hop generation, membership-based methods can provide Sybil resistance.
### 9.5 Recommended Methods
Specific spam protection methods fall outside this specification's scope.
Common strategies that MAY be adapted include:
- **PoW style approaches**: Approaches like [EquiHash](https://github.com/khovratovich/equihash) or [VDF Client puzzles](https://www.researchgate.net/publication/356450648_Non-Interactive_VDF_Client_Puzzle_for_DoS_Mitigation) that satisfy spam protection requirements can be used.
But these do not provide Sybil resistance and hence would require to augment with another approach.
- **Privacy preserving Rate-limiting**: Rate limiting approaches like [RLN](https://rate-limiting-nullifier.github.io/rln-docs/rln_in_details.html) with zero-knowledge cryptography that preserve user's privacy can be used.
Requires careful design of state access patterns.
May need to be augmented with staking and slashing to add Sybil resistance.
Deployments MUST evaluate each method's computational overhead, latency impact, anonymity implications, infrastructure requirements, attack resistance, Sybil resistance, pre-computation resistance, economic cost, and architectural fit.
### 9.6 Spam Protection Interface
This section defines the standardized interface that spam protection mechanisms MUST implement to integrate with the Mix Protocol.
The interface is designed to be architecture-agnostic, supporting both sender-generated per-hop proofs and Per-Hop Generated Proofs approaches described in [Section 9.2](#92-integration-architecture).
Initialization and configuration of spam protection mechanisms is out of scope for this interface specification.
Implementations are expected to handle their own initialization, configuration management, and runtime state independently before being integrated with the Mix Protocol.
Any spam protection mechanism integrated with the Mix Protocol MUST provide implementations of the procedures defined in this section.
The specific cryptographic constructions, proof systems, and verification logic are left to the mechanism's specification, but the interface signatures and the behavior defined here MUST be adhered to for interoperability.
#### 9.6.1 Deployment Configuration
The following parameters MUST be agreed upon and configured consistently across all nodes in a deployment:
- **Proof Size**: The fixed size in bytes of `encoded_proof_data` produced by `GenerateProof`.
This value is used by Mix Protocol implementations to calculate header sizes and payload capacity.
- **Integration Architecture**: The spam protection integration architecture used by the deployment.
Must be one of:
- `SENDER_GENERATED_PER_HOP`: Sender generates proofs for each hop (see [Section 9.6.3.1](#9631-for-sender-generated-per-hop-proofs))
- `PER_HOP_GENERATION`: Each node generates a fresh proof for the next hop (see [Section 9.6.3.2](#9632-for-per-hop-generated-proofs))
All nodes in a deployment MUST use the same integration architecture.
Nodes MUST refuse to process packets that do not conform to the deployment's configured architecture.
#### 9.6.2 Interface Procedures
All spam protection mechanisms MUST implement the following procedures.
##### 9.6.2.1 Proof Generation
`GenerateProof(binding_data) -> encoded_proof_data`
Generate a spam protection proof bound to specific packet data.
**Parameters**:
- `binding_data`: The packet-specific data to which the proof MAY be cryptographically bound.
For sender-generated per-hop proofs, this is $\delta_{i+1}$ (the decrypted payload that hop $i$ will see).
For per-hop generated proofs, this is the complete outgoing Sphinx packet state $(\alpha', \beta', \gamma', \delta')$.
**Returns**:
- `encoded_proof_data`: Serialized bytes containing the spam protection proof and any required verification metadata.
This is treated as opaque data by the Mix Protocol layer.
**Requirements**:
- The spam protection mechanism is responsible for managing its own runtime state (_e.g.,_ current epochs, difficulty levels, merkle tree states).
The Mix Protocol layer does not provide or track mechanism-specific runtime context.
- The encoding MUST produce a fixed-length output, or include a length prefix if variable-length encoding is used.
##### 9.6.2.2 Proof Verification
`VerifyProof(encoded_proof_data, binding_data) -> valid`
Verify that a spam protection proof is valid and correctly bound to the provided packet data.
**Parameters**:
- `encoded_proof_data`: Serialized bytes containing the spam protection proof and verification metadata, extracted from the routing block $\beta$ (for sender-generated approach) or from the packet header field $\sigma$ (for per-hop generation approach).
- `binding_data`: The packet-specific data against which the proof SHOULD be verified.
For nodes verifying sender-generated proofs, this is $\delta'$ (the decrypted payload).
For per-hop verification, this is the received Sphinx packet state $(\alpha', \beta', \gamma', \delta')$.
**Returns**:
- `valid`: Boolean indicating whether the proof is valid.
**Requirements**:
- Implementations MUST handle malformed or truncated `encoded_proof_data` gracefully and return `false`.
- For mechanisms that maintain global state (_e.g.,_ nullifier sets, rate-limit counters, membership trees), this procedure MUST update the internal state atomically when verification succeeds.
State updates (_e.g.,_ recording nullifiers, updating rate-limit counters) and state cleanup (_e.g.,_ removing expired epochs, old nullifiers) are managed internally by the spam protection mechanism.
#### 9.6.3 Integration Points in Sphinx Processing
The Mix Protocol invokes spam protection procedures at specific points in Sphinx packet construction and processing:
##### 9.6.3.1 For Sender-Generated Per-Hop Proofs
**Sender Nodes - During Packet Construction** ([Section 8.5.2](#852-construction-steps)):
After computing encrypted payloads $\delta_i$ for each hop (Step 3.d), the sender MUST:
1. For each hop $i$ in path (from $i = 0$ to $L-1$):
- Call `GenerateProof(binding_data = δ_{i+1})` to generate `encoded_proof_data` for hop $i$
- Embed the `encoded_proof_data` in hop $i$'s routing block within $\beta_i$ during header construction (Step 3.c)
**Intermediate Nodes- During Packet Processing** ([Section 8.6.1](#861-shared-preprocessing)):
After decrypting the routing block $\beta$ and payload $\delta'$ (Steps 4-5), the node MUST:
1. Extract `encoded_proof_data` from the routing block $\beta$ at the appropriate offset
2. Call `VerifyProof(encoded_proof_data, binding_data = δ')`
3. If `valid = false`, discard the packet and terminate processing
4. If `valid = true`, continue with role-specific processing (intermediary or exit)
##### 9.6.3.2 For Per-Hop Generated Proofs
**Sender Nodes - During Packet Construction** ([Section 8.5.2](#852-construction-steps)):
After assembling the final Sphinx packet (Step 3.e), the sender MUST:
1. Call `GenerateProof(binding_data)` to generate `encoded_proof_data` for the initial proof $\sigma_0$
2. Include the `encoded_proof_data` as an additional header field $\sigma_0$ in the Sphinx packet
**Intermediate Nodes - During Packet Processing** ([Section 8.6](#86-sphinx-packet-handling)):
**Before** any Sphinx decryption operations, the node MUST:
1. Call `VerifyProof(encoded_proof_data, binding_data)` where `binding_data` is the received packet state $(\alpha, \beta, \gamma, \delta)$
2. If the proof is not valid, discard the packet and terminate processing immediately (before session key derivation)
3. If the proof is valid, generate fresh proof for next hop as explained above.
**Exit nodes** verify the incoming proof but do not generate a new proof.
## 10. Security Considerations
This section describes the security guarantees and limitations of the Mix Protocol.
It begins by outlining the anonymity properties provided by the core protocol when routing messages through the mix network.
It then discusses the trust assumptions required at the edges of the network, particularly at the final hop.
Finally, it presents an alternative trust model for destinations that support Mix Protocol directly, followed by a summary of broader limitations and areas that may be addressed in future iterations.
### 9.1 Security Guarantees of the Core Mix Protocol
### 10.1 Security Guarantees of the Core Mix Protocol
The core Mix Protocol—comprising anonymous routing through a sequence of mix nodes using Sphinx packets—provides the following security guarantees:
@@ -1192,14 +1514,14 @@ These guarantees hold only within the boundaries of the Mix Protocol.
Additional trust assumptions are introduced at the edges, particularly at the final hop, where the decrypted message is handed off to the Mix Exit Layer for delivery to the destination outside the mixnet.
The next subsection discusses these trust assumptions in detail.
### 9.2 Exit Node Trust Model
### 10.2 Exit Node Trust Model
The Mix Protocol ensures strong sender anonymity and metadata protection between the Mix Entry and Exit layers.
However, once a Sphinx packet is decrypted at the final hop, additional trust assumptions are introduced.
The node processing the final layer of encryption is trusted to forward the correct message to the destination and return any reply using the provided reply key.
This section outlines the resulting trust boundaries.
#### 9.2.1 Message Delivery and Origin Trust
#### 10.2.1 Message Delivery and Origin Trust
At the final hop, the decrypted Sphinx packet reveals the plaintext message and destination address.
The exit node is then trusted to deliver this message to the destination application, and—if a reply is expected—to return the response using the embedded reply key.
@@ -1225,7 +1547,7 @@ That is, the exit remains a necessary point of trust for message delivery and re
The next subsection describes a related limitation:
the exit's ability to pose as a legitimate client to the destination's origin protocol, and how that can be abused to bypass application-layer expectations.
#### 9.2.2 Origin Protocol Trust and Client Role Abuse
#### 10.2.2 Origin Protocol Trust and Client Role Abuse
In addition to the message delivery and origin trust assumption, the exit node also initiates a client-side connection to the origin protocol instance at the destination.
From the destination's perspective, this appears indistinguishable from a conventional peer connection, and the exit is accepted as a legitimate peer.
@@ -1245,7 +1567,7 @@ It allows applications to preserve sender anonymity without requiring any partic
However, in scenarios that demand stronger end-to-end guarantees—such as verifiable message delivery, origin authentication, or control over client access—it may be beneficial for the destination itself to operate a Mix instance.
This alternative model is described in the next subsection.
### 9.3 Destination as Final Hop
### 10.3 Destination as Final Hop
In some deployments, it may be desirable for the destination node to participate in the Mix Protocol directly.
In this model, the destination operates its own Mix instance and is selected as the final node in the mix path.
@@ -1272,13 +1594,13 @@ Additional details on discovery configurations are out of scope for this specifi
This trust model is not required for interoperability, but is recommended when assessing deployment-specific threat models, especially in protocols that require message integrity or authenticated replies.
### 9.4 Known Protocol Limitations
### 10.4 Known Protocol Limitations
The Mix Protocol provides strong sender anonymity and metadata protection guarantees within the mix network.
However, it does not address all classes of network-level disruption or application-layer abuse.
This section outlines known limitations that deployments MUST consider when evaluating system resilience and reliability.
#### 9.4.1 Undetectable Node Misbehavior
#### 10.4.1 Undetectable Node Misbehavior
The Mix Protocol in its current version does not include mechanisms to detect or attribute misbehavior by mix nodes.
Since Sphinx packets are unlinkable and routing is stateless, malicious or faulty nodes may delay, drop, or selectively forward packets without detection.
@@ -1290,7 +1612,7 @@ As a result, unreliable nodes cannot be penalized or excluded based on observed
Future versions may explore accountability mechanisms.
For now, deployments MAY improve robustness by sending each packet along multiple paths as defined in [Section X.X], but MUST treat message loss as a possibility.
#### 9.4.2 No Built-in Retry or Acknowledgment
#### 10.4.2 No Built-in Retry or Acknowledgment
The Mix protocol does not support retransmission, delivery acknowledgments, or automated fallback logic.
Each message is sent once and routed independently through the mixnet.
@@ -1307,7 +1629,7 @@ To improve reliability, the sender MAY:
These strategies MUST be implemented at the origin protocol layer or through Mix integration logic and are not enforced by the Mix Protocol itself.
#### 9.4.3 No Sybil Resistance
#### 10.4.3 No Sybil Resistance
The Mix Protocol does not include any built-in defenses against Sybil attacks.
All nodes that support the protocol and are discoverable via peer discovery are equally eligible for path selection.
@@ -1321,7 +1643,7 @@ More advanced mitigations such as stake-based participation or resource proofs t
Such defenses are out of scope in the current version of the Mix Protocol, but are critical to ensuring anonymity at scale and may be explored in future iterations.
#### 9.4.4 Vulnerability to Denial-of-Service Attacks
#### 10.4.4 Vulnerability to Denial-of-Service Attacks
The Mix Protocol does not provide built-in defenses against denial-of-service (DoS) attacks targeting mix nodes.
A malicious mix node may generate a high volume of valid Sphinx packets to exhaust computational, memory, or bandwidth resources along random paths through the network.
@@ -1330,14 +1652,13 @@ This risk stems from the protocol's stateless and sender-anonymous design.
Mix nodes process each packet independently and cannot distinguish honest users from attackers.
There is no mechanism to attribute packets, limit per-sender usage, or apply network-wide fairness constraints.
Application-level defenses—such as PoW, VDFs, and RLNs (defined in [Section 6.3](#63-spam-protection)) to protect destination endpoints—do not address abuse _within_ the mixnet.
Mix nodes remain vulnerable to volumetric attacks even when destinations are protected.
While the Mix Protocol includes safeguards such as layered encryption, per-hop integrity checks, and fixed-size headers, these primarily defend against tagging attacks and structurally invalid or malformed traffic.
The Sphinx packet format also enforces a maximum path length $(L \leq r)$, which prevents infinite loops or excessively long paths being embedded.
However, these protections do not prevent adversaries from injecting large volumes of short, well-formed messages to exhaust mix node resources.
DoS protection—such as admission control, rate-limiting, or resource-bound access—MUST be implemented outside the core protocol.
DoS protection—such as admission control, rate-limiting, or resource-bound access—can be plugged in as explained in [Spam protection](#63-spam-protection).
Any such mechanism MUST preserve sender unlinkability and SHOULD be evaluated carefully to avoid introducing correlation risks.
Defending against large-scale DoS attacks is considered a deployment-level responsibility and is out of scope for this specification.