niom-turn/docs/testing_todo.md

2.2 KiB

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.