# 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.