niom-turn/docs/mvp_gaps_and_rfc_notes.md

MVP-Lücken & RFC-Notizen (STUN/TURN)

Dieses Dokument listet bewusst vereinfachte/fehlende Teile im aktuellen niom-turn MVP auf, jeweils mit kurzer Auswirkung und Code-Anker.

Ziel: Klarheit, was schon interoperabel ist, und wo (für Production/Interop) noch Arbeit nötig ist.

---

1) STUN Binding ist minimal

Ist-Zustand

• METHOD_BINDING beantwortet der Server als "Success" und enthält XOR-MAPPED-ADDRESS (IPv4+IPv6): src/stun.rs

Auswirkung

• Für STUN-Diagnose/ICE-NAT-Discovery ist das damit deutlich interoperabler.

---

2) IPv6 wird nicht unterstützt (historisch)

Ist-Zustand

• XOR-Address Encoding/Decoding unterstützt IPv4 und IPv6 (XOR-Key: Magic Cookie + Transaction ID): src/stun.rs

Auswirkung

• TURN/STUN kann IPv6-Adressen in XOR-ADDRESS Attributen korrekt verarbeiten.

---

3) TURN Allocate ist stark vereinfacht

Ist-Zustand

• allocate_for bindet immer ein UDP-Relay auf 0.0.0.0:0: src/alloc.rs
• REQUESTED-TRANSPORT wird nicht ausgewertet (es gibt nur UDP-Relay).
• Weitere RFC-TURN Optionen (EVEN-PORT, RESERVATION-TOKEN, DONT-FRAGMENT, etc.) sind nicht implementiert.

Auswirkung

• Das MVP deckt den typischen UDP-Relay-Fall ab, aber nicht die volle TURN-Feature-Matrix.

---

4) Data Plane: UDP-relay ja, TCP-relay nein

Ist-Zustand

• Relay-Datenpfad ist UDP-only (Relay-Socket ist tokio::net::UdpSocket): src/alloc.rs
• TLS-Listener re-used Control-Plane Logik, aber kein TCP-Relay: src/tls.rs

Auswirkung

• turns: (TLS) kann Control-Plane, aber der Rückweg der relayed Daten läuft derzeit weiterhin über UDP an die Client-UDP-Adresse.
• Für echte TURN-over-TCP/TLS Data Plane (Interoperabilität mit restriktiven Netzwerken) fehlt ein eigener TCP-Relay-Pfad.

---

5) Allocation- und Timer-Verhalten ist MVP-artig

Ist-Zustand

• Allocation-Lifetime wird über refresh_allocation gesetzt/geklemmt: src/alloc.rs
• remove_allocation entfernt den Eintrag.
• Der Relay-Task (spawn in allocate_for) läuft jedoch weiter und prüft nur noch, ob Allocation existiert: src/alloc.rs

Auswirkung

• Bei vielen Allocations kann das zu unnötigen Hintergrund-Tasks führen (Resource-Management/Backpressure fehlt).

---

6) Permissions & ChannelBindings sind minimal

Ist-Zustand

• Permission TTL ist statisch (300s) und wird nur durch erneutes CreatePermission erneuert: src/alloc.rs
• ChannelBindings nutzen denselben TTL-Wert (PERMISSION_LIFETIME): src/alloc.rs

Auswirkung

• Funktional ok für MVP, aber nicht unbedingt exakt RFC-getreu im Detail (separate Lifetime-Regeln/Refresh-Strategien sind üblich).

---

7) MESSAGE-INTEGRITY/FINGERPRINT

Ist-Zustand

• MESSAGE-INTEGRITY wird RFC-konform geprüft (HMAC-SHA1 über die Message bis inkl. MI-Attribut; Header-Länge wird dafür auf „Ende von MI“ gesetzt, d.h. kompatibel mit nachfolgenden Attributen wie FINGERPRINT): src/stun.rs
• Für TURN-Responses nach erfolgreicher Authentisierung hängt der Server MESSAGE-INTEGRITY an und setzt FINGERPRINT als letztes Attribut: src/server.rs, src/turn_stream.rs
• FINGERPRINT wird bei allen vom Server gebauten STUN-Nachrichten als letztes Attribut angehängt und bei eingehenden Nachrichten (falls vorhanden) validiert: src/stun.rs

Auswirkung

• Bessere Browser/ICE-Interop und leichtes Hardening (Messages mit ungültigem FINGERPRINT werden verworfen).

---

8) Observability / Limits / Hardening fehlen (noch)

Ist-Zustand

• Keine Quotas pro User/IP, keine Rate-Limits, keine Bandbreitenlimits pro Allocation.
• Credential Store ist In-Memory (Test/Dev): src/auth.rs, Trait: src/traits/credential_store.rs

Auswirkung

• Für Production braucht es Limits, persistente Credentials, Monitoring/Metrics und härteres Error-Handling.

---

9) Weitere RFC-Ecken (nicht implementiert)

Typische Punkte, die im MVP fehlen/noch offen sind:

• Full attribute coverage (z.B. UNKNOWN-ATTRIBUTES, SOFTWARE, etc.)
• Vollständige STUN/TURN Class/Method Encoding nach RFC (hier bewusst vereinfacht über METHOD | CLASS_*): src/constants.rs
• IPv6, Hairpinning-Sonderfälle, NAT-bezogene Interop-Edge-Cases

---

Was bereits gut abgedeckt ist

• End-to-end UDP TURN Core: Allocate → CreatePermission → Send/ChannelData → Rückweg als Data Indication/ChannelData.
• Long-term Auth (Realm/Nonce + MI) mit klaren 401/438/437/403 Pfaden.
• TLS Listener (Control-Plane) mit STUN-Framing über TCP/TLS.

Siehe auch die Integrationstests: tests/udp_turn.rs und tests/tls_turn.rs.