Commit Graph

10 Commits

Author SHA1 Message Date
Prem Chaitanya Prathi
dabc31786b fixing format errors in mix rfc (#229)
<img width="1158" height="635" alt="image"
src="https://github.com/user-attachments/assets/3f3582b4-77b2-4eb5-a7ea-12b60951303c"
/>
2025-12-15 13:26:43 +05:30
Prem Chaitanya Prathi
4f54254706 fix format errors in math sections for mix rfc (#225) 2025-12-12 14:59:14 +05:30
Prem Chaitanya Prathi
7f1df32779 chore: use sembreaks for easy review and edits (#223)
Modified the mix spec to use sembreaks and not break line at charater limits
as per
https://github.com/vacp2p/rfc-index/pull/194#pullrequestreview-3562274262
2025-12-11 21:02:15 +05:30
AkshayaMani
e742cd5192 RFC Addition: Section 9 Security Considerations (#194)
This PR continues work from PR #158 and PR #173, and introduces a new
**Section 9: Security Considerations** to the Mix Protocol RFC. It
formalizes the protocol’s core guarantees, trust assumptions, and known
limitations.

### New Section Added

Structured Section 9 with the following subsections:

- [x] **9.1 Security Guarantees of the Core Mix Protocol**
Defines sender anonymity, metadata protection, and statelessness
guarantees.

- [x] **9.2 Exit Node Trust Model**
  Trust assumptions at the final hop:

  - [x] `9.2.1 Message Delivery and Origin Trust`
  - [x] `9.2.2 Origin Protocol Trust and Client Role Abuse`

- [x] **9.3 Destination as Final Hop**
Optional deployment model where the destination operates its own Mix
instance to eliminate exit-level trust.

- [x] **9.4 Known Protocol Limitations**
  Clearly outlines out-of-scope threats:
  - Undetectable node misbehavior
  - Lack of built-in retries or acknowledgments
  - No Sybil resistance
  - Vulnerability to DoS attacks

### Key Improvements
- Clearly delineates what the Mix Protocol guarantees and what it leaves
to external systems.
- Formalizes the exit trust boundary, a key concept for downstream
applications.
- Introduces an alternative destination participation model.
- Enables future discussions around accountability, reliability, and
Sybil resistance.

---------

Co-authored-by: Prem Chaitanya Prathi <chaitanyaprem@gmail.com>
2025-12-10 20:15:32 +05:30
AkshayaMani
9d11a22901 docs: finalize Section 8 Sphinx Packet Construction and Handling (#202)
This PR builds on PR #173 and completes the remaining construction and
runtime processing logic in `Section 8` of the Mix Protocol RFC. It
finalizes the last steps of packet construction (`Section 8.5.2 step 3.
e–f`) and introduces the complete mix node handler logic in `Section
8.6`, including intermediary and exit processing.
It clearly separates construction, role determination, and processing
logic.

### Changes Introduced in This PR

- **8.5.2 Construction Steps (Final Steps Added)**
  - Sphinx packet construction
    - [x] Assemble Final Packet
    - [x] Transmit Packet
    
- **8.6 Sphinx Packet Handling**
  - [x] **8.6.1 Shared Preprocessing**
- Derives session key, validates replay tag and MAC, decrypts
header/payload
  - [x] **8.6.2 Node Role Determination**
- Inspects decrypted header prefix and padding to classify node as
intermediary or exit
  - [x] **8.6.3 Intermediary Processing**
    - Parses next hop address and mean delay
    - Updates ephemeral key and routing fields
    - Samples actual forwarding delay and transmits packet
    - Erases all temporary state.
  - [x] **8.6.4 Exit Processing**
    - Verifies payload padding and extracts destination address
    - Parses and validates application-layer message
- Hands off to Exit Layer along with origin protocol codec and
destination address

### Highlights
  - Explicit role determination via zero-delay and padding inspection
  - Fully decoupled construction and handling logic
  - Forwarding delay behavior updated:
    - Sender selects per-hop mean delay
    - Mix node samples actual delay using pluggable distribution

---------

Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>
2025-12-10 12:24:23 +00:00
AkshayaMani
36be428cdd RFC Refactor: Sphinx Packet Format (#173) 2025-10-05 20:21:16 -04:00
AkshayaMani
5e3b4788ec RFC Refactor PR: Modular Rewrite of Mix Protocol Specification (#158)
This PR rewrites the Mix Protocol RFC for clarity, layering, and
implementability. It reorganizes the spec into a modular structure
aligned with RFC 7322 and RFC 2119, with clean separation between
protocol logic, integration, and pluggable components.

### Goals

- Clearly define Mix as a **message-based routing protocol**, not a
transport or application-layer solution.
- Support **per-message anonymity** via a `mixify` flag and **external
integration** through Entry and Exit layers.
- Adopt a clean, layered structure: motivation → integration → routing
model → cryptographic structure → node behavior.
- Use correct RFC formatting, keywords, and SEMBR for implementation
clarity.

### Changes Completed in This PR

#### Sections 0–5: Foundational Structure and Protocol Layering

* [x] **Abstract**: Concise, non-repetitive summary of protocol purpose
and scope.
* [x] **§1 Introduction**: Cleanly describes protocol role, document
scope, and integration model.
* [x] **§2 Terminology**: Defines all key terms; includes correct use of
`MUST`, `SHOULD`, and informal variants.
* [x] **§3 Motivation and Background**: Articulates need for sender
anonymity in libp2p; includes `§3.1 Comparison with Tor`.

#### Section 4 Mixing Strategy and Packet Format

* [x] **§4.1 Mixing Strategy**: Defines continuous-time mixing;
justifies choice over batching.
* [x] **§4.2 Packet Format Overview**: Defines what a mix packet must
achieve; outlines Sphinx format properties and rationale.

#### Section 5 Protocol Overview and Integration

* [x] **§5 Protocol Overview**: Clean, layered walkthrough of core
protocol behavior and layering in libp2p.
* [x] **§5.1 Integration with Origin Protocols**: External interface
components (Mix Entry/Exit layers).
* [x] **§5.2 Mixify Option**: Per-message flag defined.
* [x] **§5.3 Why a Protocol, Not a Transport**: Explains why Mix is
layered as a libp2p protocol, not a transport.
* [x] **§5.4 Protocol Interaction Flow**: Three-phase diagram and
explanation (entry → routing → exit).

#### Section 6 Pluggable Components

* [x] Discovery: advertise Mix support via ENR, X25519 key
* [x] Delay strategy: sender-defined per-hop delay
* [x] Spam protection: PoW/VDF/RLN options, exit node validation
* [x] Cover traffic: periodic loops for unobservability
* [x] Incentivization: nodes MUST participate to send

#### Section 7 Core Mix Protocol Responsibilities

* [x] Define Sender, Intermediary, Exit node roles
* [x] Specify lifecycle and message flow per role

#### Section 8 Sphinx Packet Format (Detailed Spec)

* [ ] Full field definitions (α, β, γ, δ, delays, MACs)
* [ ] Encoding and padding behavior

#### Section 9 Node Behavior (Mix Protocol Handler)

* [ ] Describe sender node logic: path selection, packet wrapping
* [ ] Describe intermediary/exit node behavior: decryption, delay,
forwarding

#### Section 10 Limitations and Future Work

* [ ] SURB-based reply support (unimplemented)
* [ ] DoS/Sybil attack surface
* [ ] Path overlap, message reordering, end-to-end acks

#### Appendices

* [ ] Appendix A: Proof-of-Work Example
* [ ] Appendix B: ENR-Based Discovery Example
2025-06-27 14:03:10 -04:00
Jimmy Debe
db90adc94e Fix LaTeX errors (#163)
LaTeX are causing build errors on rfc.vac.dev. Potential fixes..
2025-06-02 17:33:46 -04:00
ksr
38fce27d33 typo fix 2024-11-08 08:42:02 +01:00
AkshayaMani
7f5276e18c libp2p Mix Protocol Spec Draft (#97)
Old PR can be found here: [Mix Protocol Spec
#85](https://github.com/vacp2p/rfc-index/pull/85)
2024-09-16 08:05:47 -04:00