Zusammenfassung

  • TED konzentrierte mehr als 34.000 Pakete, die über 4,2 Sekunden gesendet wurden, innerhalb von 250 Millisekunden an einem kontrollierten Empfänger.
  • Die 1.909.440 gezählten Tunnelhosts stammen aus Messungen von Juni 2025 bis Januar 2026 und erfüllen definierte Weiterleitungs- und Timingbedingungen.

Die Studie von Le Gai, Zedong Jia, Lin He, Daguo Cheng, Chentian Wei und Ying Liu macht aus einem unscheinbaren Bauteil einen Zeitgeber: den Tunnelhost. Für die Evaluation verteilten sie 35.029 Pakete gleichmäßig über 4,2 Sekunden, durchschnittlich etwa 8.340 pro Sekunde. Mehr als 34.000 trafen in einem Viertelsekundenfenster ein.

Die oft zitierte 180×-Zahl ist präziser als ihr Klang. Sie vergleicht die maximale Empfangsrate in einem 20-Millisekunden-Fenster mit der durchschnittlichen Senderate über die gesamte Einspeisezeit. Die Pakete werden nicht größer. Ihre Ankunft wird enger getaktet. Verschachtelte Tunnelpfade und die Verarbeitung von IPv6-Erweiterungsheadern liefern unterschiedliche Verzögerungen; der Sendeplan bringt sie am Ziel zusammen.

Das Problem beginnt an der Einlasskontrolle. Ein Tunnel nimmt ein inneres Paket in einer äußeren IP-Hülle mit. Prüft ein Endpunkt nur die äußere Route, kann er die innere Quelle und weitere Headerketten unzureichend kontrollieren. Unauthentifizierte Gegenstellen, fehlende Source-Address-Validation und erlaubte Rekursion geben dem Pfad seine Bausteine. Nicht jeder Tunnel erfüllt diese Bedingungen; der konkrete Endpunkt entscheidet.

Zwischen Juni 2025 und Januar 2026 führten die Autoren 44 zeitlich verteilte Scans durch. Jeder erfasste rund 3,7 Milliarden IPv4-Adressen und 20 Millionen IPv6-Hitlist-Adressen. Insgesamt bestanden 1.909.440 Hosts die Tests über sechs Tunneltypen. Für die kontrollierte Wirkungsmessung nutzte das Team sechs eigene Dual-Stack-Server in China, Japan, Deutschland und den USA. Livebetriebene Dienste wurden laut Paper nicht angegriffen.

Die Standardpassage des Papers braucht eine genauere Einordnung. Es schreibt RFC 8200 eine allgemeine Regel zu, nach der Erweiterungsheader nur am Ziel verarbeitet würden. Bei Hop-by-Hop-Optionen erlaubt RFC 8200 eine Verarbeitung auf dem Pfad, wenn der jeweilige Knoten dafür konfiguriert ist; RFC 9673 aktualisiert die Abläufe. TEDs operativer Befund liegt daher bei der Tunnelzulassung, der Weiterleitung verschachtelter Pakete und der Kontrolle nach dem Entkapseln.

Die Autoren nennen Quellenvalidierung am Tunneleingang, authentifizierte Gegenstellen, Grenzen für verschachtelte Kapselung und tiefergehende Paketprüfung. Wer jede ungewöhnliche Headerfolge pauschal verwirft, kann auch legitime VPN- und Übergangsverbindungen treffen. Eine protokollbezogene Freigabeliste samt Ausnahmeprotokoll macht die Abwägung prüfbar.

Die Messreihe endet im Januar 2026. Erst eine Wiederholung nach den Gegenmaßnahmen würde zeigen, wie viele der damals gefundenen Pfade noch bestehen.

Quellen: USENIX-Konferenzseite · USENIX-Security-2026-Paper · RFC 8200 · RFC 9673 · RFC 2473