115 lines
4.8 KiB
Markdown
115 lines
4.8 KiB
Markdown
# 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).
|