niom-turn/docs/testing_todo.md

60 lines
2.2 KiB
Markdown

# Test-ToDo (Vorschläge)
Dieses Dokument sammelt **konkrete** Test-Ideen, die den sicheren/stabilen Betrieb (insb. unter Last/Fehlverhalten) absichern sollen.
## Stream (TCP/TLS) Robustheit
- Split-Reads: STUN Header (20B) in 2 Reads, Body in mehreren Reads
- Split-Reads: ChannelData Header (4B) und Payload getrennt
- Mixed Frames: STUN → ChannelData → STUN in einem Read (und in mehreren Reads)
- Oversize Frames:
- STUN Length > Max → Verbindung wird geschlossen (oder Frame gedroppt, je nach Policy)
- ChannelData Length > Max → Verbindung wird geschlossen (oder Frame gedroppt)
- Garbage Resync:
- Zufallsbytes vor gültigem STUN (bereits abgedeckt)
- Zufallsbytes zwischen gültigen Frames
## TURN Flows (Happy + Negative)
- Negative pro Methode (UDP/TCP/TLS jeweils):
- ohne Allocation → 437 Allocation Mismatch
- ohne Permission → 403 Peer Not Permitted
- ChannelData ohne ChannelBind → drop + optional log counter
- Stale Nonce → 438
- falsches MI → 401/403 je nach Policy
## Auth
- TURN REST:
- abgelaufener Username → reject
- Username zu weit in der Zukunft (max TTL) → reject
- falsches HMAC/base64 → reject
- „user exists in store“ vs. „REST fallback“ Priorität
## Lifecycle
- Allocation expiry:
- Refresh verkürzt/verlängert, Min/Max Lifetime
- Expiry entfernt Allocation und beendet Relay-Task (keine Task-Leaks)
- Permission expiry:
- Peer wird nach Ablauf verworfen
- Channel binding expiry:
- Rückweg fällt auf Data Indication zurück, wenn Binding abläuft
## Abuse-/DoS Prevention (sobald Limits implementiert sind)
- Rate limit: auth failures pro IP/Username
- Max allocations pro IP
- Max permissions/channels pro allocation
- Bandwidth caps (bytes/s) pro allocation
- Backpressure: Writer-Queue voll → Verhalten definieren (drop/close)
## Interop (manuell reproduzierbar, aber dokumentiert)
- Browser Plan:
- Trickle ICE / webrtc-internals: forced relay
- UDP-only block: erwarte TCP/TLS fallback
- `turns:` mit self-signed vs. valid cert
Wenn du willst, kann ich als nächsten Schritt aus diesen Punkten eine priorisierte Test-Roadmap machen (P0/P1/P2) und direkt die nächsten P0-Tests implementieren.