Zusammenfassung

  • RFC 5128 beschreibt zur Veröffentlichungszeit eingesetzte P2P-NAT-Traversal-Verfahren und billigt als Informational RFC keine konkrete Implementierung.
  • Ein Rendezvous-Dienst kann private und öffentliche Endpunkte verteilen, die behauptete private Adresse aber aus dem öffentlichen Registrierungsaustausch nicht prüfen.
  • Dieselbe private Adresse bezeichnet in verschiedenen Haushalten, Unternehmen und NAT-Ebenen unterschiedliche Geräte.
  • Eine Probe zum privaten Kandidaten kann deshalb einen fremden lokalen Host erreichen, auch ohne Angreifer.
  • Ein böswilliger Registrant kann eine Opferadresse nennen und die Versuche vieler Peers dort bündeln.
  • Vor authentifizierter wechselseitiger Kommunikation müssen Pakete, Bytes, Ziele, Wiederholungen, Verarbeitung und gespeicherter Zustand begrenzt sein.
  • Eine Antwort belegt, dass auf einem Pfad etwas antwortete, nicht die erwartete Person, Organisation oder Berechtigung.
  • Die Quell-IP genügt nicht zur Authentifizierung, weil NAT-taugliche Signalisierung Adressumschreibung gerade zulassen muss.
  • Höherschichtige Identität muss den Anwendungsinhalt authentifizieren und an den gewählten Pfad binden; Verschlüsselung schließt Verkehrsanalyse nicht aus.
  • Endpoint-unabhängiges Mapping und Endpoint-unabhängige Filterung sind verschiedene Eigenschaften.
  • ICE-Prüfungen und TURN-Allokationen erzeugen Pfadbelege, aber keinen universellen Identitäts-, Autorisierungs- oder Ergebnisnachweis.
  • Registrierung, Entdeckung, Probenbudget, Pfad, Authentifizierung, Autorisierung, Ressource und Ergebnis brauchen getrennte Belege.

Die Nominierung beendet nur die Pfadsuche

ICE sammelt Kandidaten, bildet Paare, prüft Konnektivität und nominiert schließlich einen Pfad. Dieser Ablauf schafft wertvolle, überprüfbare Zustände. Gerade deshalb darf der letzte Transportzustand nicht mit allen nachfolgenden Entscheidungen beladen werden.

Eine credential-geschützte Prüfung kann zeigen, dass die Gegenseite die kurzfristigen Daten der ICE-Sitzung besitzt und das Kandidatenpaar funktioniert. Sie beweist nicht ohne Weiteres eine dauerhafte Benutzer- oder Unternehmensidentität. Diese Bindung gehört dem Anwendungsprotokoll.

Auch eine authentifizierte Identität ist keine pauschale Erlaubnis. Ein bekannter Peer darf vielleicht eine kleine Kontrollnachricht austauschen, aber keine große Relay-Kapazität reservieren, umfangreiche Daten abrufen oder lange Berechnungen auslösen. Authentifizierung beantwortet „wer“, Autorisierung „was“, der Ressourcenbeleg „wie viel tatsächlich“.

Ändert sich der Pfad durch neue Nominierung, Mobilität, NAT-Rebinding oder Wechsel zu TURN, muss die Bindung neu bewertet werden. Das Protokoll legt fest, ob Channel Binding genügt, die Sitzung fortbesteht oder eine erneute Authentifizierung nötig ist. Ein unverändertes grünes Symbol wäre sonst nur grafische Kontinuität.

Eine private Adresse trägt ihren Verwaltungsraum nicht mit

192.168.1.100 kann beim Registranten dessen Notebook sein und beim Empfänger einen Drucker bezeichnen. Private Adressräume werden absichtlich wiederverwendet. Der Rendezvous-Dienst kann von außen nicht feststellen, welche Maschine diese Zeichenfolge in jedem fremden Netz benennt.

Versucht der Empfänger den privaten Kandidaten, entscheidet sein eigenes Routing. Das Paket kann auf einem völlig unbeteiligten lokalen Gerät landen. Diese Verwechslung entsteht auch zufällig; eine falsche Zustellung allein beweist keine Absicht.

Deshalb braucht die Untersuchung eine Kette: Welches Konto meldete welchen Kandidaten? Wem wurde er wann offengelegt? Welches Ziel wurde tatsächlich erreicht? Welche höherstufige Identität antwortete? Wo scheiterte die Authentifizierung? Erst die Kette trennt Überlappung, Fehlkonfiguration und Angriff.

Antwortet der falsche Host, wird ein einfaches Erfolgsmodell besonders gefährlich. Socket, STUN-Antwort oder Connectivity Check sind Pfadbeobachtungen. Sie verleihen dem antwortenden Gerät nicht die erwartete Identität.

Rendezvous verbreitet Behauptungen innerhalb eines engen Mandats

Peers hinter NAT kennen ihre äußere Darstellung oft nicht. Ein Rendezvous-Dienst kann ein öffentliches Tupel beobachten, Kandidaten einer Sitzung zuordnen und sie mit Ablaufzeit verteilen. Das ist eine wirksame begrenzte Koordination.

Ein signierter Entdeckungsbeleg beweist, dass der Dienst diese Liste ausgab. Er beweist weder Kontrolle über jeden Kandidaten noch identische Bedeutung privater Kandidaten in anderen Netzen. Auch die Authentifizierung des registrierenden Kontos überträgt sich nicht automatisch auf den später antwortenden Endpunkt.

Jeder Kandidat sollte seine Herkunft behalten: lokale Behauptung, server-reflexive Beobachtung, peer-reflexiv gelernt oder Relay-Allokation. Herkunft ist kein Sicherheitsstempel, ermöglicht aber Priorisierung und Ursachenanalyse.

RFC 5128 verlangt, neue Adressen bis zum authentifizierten Austausch als verdächtig zu behandeln. Sie dürfen billig getestet werden. Sie dürfen vor dieser Schwelle keine erhebliche Arbeit anordnen.

Das Vor-Authentifizierungsbudget muss aggregieren

Ein Angreifer kann eine Opferadresse registrieren. Viele Peers senden darauf kleine Verbindungsversuche. Der Angreifer erzeugt nicht jedes Paket selbst; die Koordinationsplattform verteilt die Arbeit.

Ein Limit pro Sitzung reicht nicht. Tausende regelkonforme Sitzungen können dasselbe Ziel überlasten. Deshalb sind Pakete, Bytes und Zustand zusätzlich nach Ziel, Präfix, Registrant und Rendezvous-Objekt zu summieren.

Zum Budget gehören Kandidatenzahl, Wiederholungsrhythmus, Lebensdauer und Parallelität sowie CPU, Speicher, Timer, kryptographischer Kontext, Protokollierung und Relay-Vorbereitung. Ein kleines Datagramm kann große lokale Arbeit auslösen.

Die Ressourcenfreigabe erfolgt stufenweise. Minimale Proben vor Identität, begrenzte Kontrollarbeit nach Identität, größere Bindung erst nach Autorisierung. Jede Erweiterung braucht ihren eigenen Anlass und Beleg.

Mapping, Filterung und Hairpinning sind keine NAT-Persönlichkeit

Endpoint-unabhängiges Mapping erlaubt die Wiederverwendung einer äußeren Abbildung zu mehreren Zielen. Zielabhängiges Mapping kann für jeden Remote-Endpunkt ein anderes Tupel erzeugen und Hole Punching verhindern.

Filterung ist davon getrennt. Ein NAT kann dieselbe Abbildung wiederverwenden und Rückverkehr nur von zuvor kontaktierten Quellen akzeptieren. Wiederverwendbares Mapping bedeutet kein offenes Eingangstor.

Hairpinning ist eine dritte Eigenschaft. Zwei Peers hinter verschiedenen unteren NATs können ein oberes NAT teilen. Wollen sie dessen öffentliche Kandidaten nutzen, muss es Verkehr an seine eigene äußere Adresse wieder nach innen führen. Ohne Hairpin existieren korrekte Abbildungen, aber kein direkter Pfad.

Connection Reversal passt nur, wenn ein Peer öffentlich und einer hinter NAT liegt. Relay ist zuverlässig, wenn beide den Server erreichen, kostet aber Verarbeitung, Bandbreite und oft Latenz. Keine Variante authentifiziert automatisch die Anwendungsperson.

Adressumschreibung begrenzt die Aussage der Quell-IP

NAT-freundliche Signalisierung akzeptiert unterschiedliche lokale und beobachtete Adressen. Ein Akteur auf dem Pfad kann versuchen, eine geänderte Quelladresse zu registrieren und spätere Kommunikation umzulenken.

Die Quell-IP allein kann das nicht lösen, weil Umschreibung zum normalen Mechanismus gehört. Authentifiziert werden müssen tatsächliche Anwendungsnachrichten unter einer höherstufigen Identität, gebunden an Sitzung und relevanten Transportkontext.

Verschlüsselung schützt Inhalt und Integrität innerhalb ihres Modells. Timing und Volumen können sichtbar bleiben. Auch Vertraulichkeit braucht daher einen genau benannten Geltungsbereich.

Der Rendezvous-Betreiber muss keine globale Identitätsinstanz werden. Er schützt sein Register, bewahrt Kandidatenherkunft, begrenzt Verstärkung und beschreibt seine Beobachtungsgrenze. Die Anwendung verantwortet Peer-Identität und Berechtigung.

Spätere Protokolle präzisieren den Lebenszyklus

RFC 5389 ordnete STUN als Protokollwerkzeug neu. RFC 8445 strukturierte ICE-Kandidaten, Checklisten und Nominierung. RFC 8656 spezifizierte TURN-Allokationen, Permissions, Channels und Ablauf. RFC 8835 ordnete diese Mechanismen in WebRTC ein.

Mehr definierte Schritte bedeuten mehr mögliche Belege, nicht einen allumfassenden Erfolg. Kandidat, geprüftes Paar, nominierter Pfad, authentifizierter Peer, autorisierte Aktion, gebundene Ressource und geliefertes Ergebnis bleiben getrennt.

Ein Relay ist nicht automatisch schwächeres Vertrauen. Ein direkter Pfad kann beim falschen lokalen Host enden; ein Relay kann kontrolliert und beobachtbar sein. Verglichen werden Identität, Politik, Kosten, Leistung, Widerstandsfähigkeit und Ergebnis.

Was der Quellenbestand belegt

RFC Editor und Datatracker belegen Veröffentlichung und Geschichte von RFC 5128. Der Text belegt die beschriebenen Verfahren und Risiken und erklärt ausdrücklich, sie nicht zu billigen. Weitere RFCs liefern Begriffe und spätere Entwicklung.

Nicht belegt sind heutige Produktkonformität, Häufigkeit falscher Ziele, Verstärkungsfaktor, Hairpin-Verbreitung oder universelle Erfolgsraten. Der Bestand enthält keine aktuelle Anbieterzählung, keinen aktuellen Vorfall und kein gemessenes Nutzerergebnis.

Standards beschreiben Mechanismen. Eine laufende Umgebung muss Konfiguration, Telemetrie, authentifizierte Transkripte, Ressourcenbuch und Resultate liefern. Dokumentautorität kann diese Beobachtung nicht ersetzen.

Quellen