Commit Graph

6 Commits

Author SHA1 Message Date
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