# 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](../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](../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](../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](../src/alloc.rs)
- TLS-Listener re-used Control-Plane Logik, aber kein TCP-Relay: [src/tls.rs](../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](../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](../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](../src/alloc.rs)
- ChannelBindings nutzen denselben TTL-Wert (`PERMISSION_LIFETIME`): [src/alloc.rs](../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](../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/server.rs), [src/turn_stream.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](../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](../src/auth.rs), Trait: [src/traits/credential_store.rs](../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](../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](../tests/udp_turn.rs) und [tests/tls_turn.rs](../tests/tls_turn.rs).