Zusammenfassung

  • RFC 1326 verband X-in-Y und Y-in-X durch eine mögliche Routing-Schleife. Vor dem vorgesehenen Tunnelausgang erhielt das noch gekapselte Paket immer weitere Hüllen.
  • Ohne Übernahme des früheren Hop-Zählers brachte jeder Außenheader eine neue aktive Lebensdauer. Erreichte der Stapel die MTU, konnten Fragmente dieselbe Schleife wiederholen und sich weiter teilen.
  • Zählerübernahme, Header-Inspektion und Verbote bestimmter Verschachtelungen hatten jeweils Wissens- oder Kompatibilitätsgrenzen. Entscheidend war ein über alle Grenzen fallendes Budget.

Der sichtbare Wert gehörte nur zur jüngsten Hülle

Eine normale Weiterleitungsschleife endet, weil TTL oder Hop Count sinkt. Im gefährlichen Fall von RFC 1326 bewahrte die nächste Kapselung diese Information nicht im neuen Header. Der alte Wert blieb möglicherweise unverändert im Inneren, doch die äußeren Router lasen einen neuen Wert.

Damit wurde aus einem Ablaufbeweis eine Reihe lokaler Uhren. Ein positiver äußerer Zähler sagte, wie weit diese Hülle noch reisen durfte. Er sagte nicht, wie oft das ursprüngliche Paket bereits eine Tunnelgrenze erreicht hatte. Die Existenz des Feldes war keine Evidenz für eine gemeinsame, kumulative Lebensdauer.

Auch eine Übersetzung der Werte war nicht neutral. RFC 1326 nannte X.25 und SMDS als Header ohne Hop Count. AppleTalk erlaubte höchstens 16 Hops, IP bis zu 256. Eine Abbildung auf den kleineren Bereich konnte die Schleife begrenzen und zugleich legitime IP-Wege mit mehr als 16 Hops abschneiden.

Lokale Interoperabilität erzeugte das globale Problem

Ein einfacher Tunnel blieb sinnvoll: X musste durch ein Y-Backbone, erhielt am Eingang einen Y-Header und wurde am Ausgang wieder freigelegt. Das Rückgrat brauchte den Inhalt nicht zu verstehen.

Das RFC betrachtete Netze, in denen diese Beziehung anderswo umgekehrt bestand. Es nannte IP über AppleTalk und AppleTalk über IP und erwartete weitere Kombinationen zwischen IP, CLNP, IPX, DECNET und proprietären Protokollen.

Bei einer vorübergehenden Routing-Schleife wurde X zu Y<X>. Statt am Ausgang anzukommen, erreichte es einen Eingang zu einem X-Netz und wurde zu X<Y<X>>. Nach der Rückkehr entstand Y<X<Y<X>>>.

Jeder Router konnte für seinen nächsten Link richtig handeln. Keiner dieser Schritte belegte jedoch Fortschritt zum Endziel. Der Fehler lag in der Komposition: Es gab keinen Zustand, der mit jeder neuen Hülle zwingend näher an null kam.

An der MTU wurde Wachstum zu Vervielfachung

Zunächst wuchs ein einzelnes Paket um Header. Sobald es nicht mehr in die Maximum Transmission Unit passte, entstanden Fragmente. Jedes Fragment blieb in der fehlerhaften Routenbeziehung, bekam weitere Header und konnte erneut fragmentieren.

Die vom RFC beschriebene exponentielle Paketexplosion war dieser rekursive Mengeneffekt. Sie war weder eine physische Explosion noch der Bericht über einen Angriff. Das Informational RFC erklärte ausdrücklich, Sicherheitsfragen nicht zu behandeln.

Die Schleife konnte Links sättigen. Wurden dabei Routing-Updates oder Managementpakete verworfen, verlor das Netz gerade den Verkehr, mit dem es die Route selbst korrigieren konnte. Das Datenproblem schwächte den Kontrollmechanismus seiner Wiederherstellung.

Nach dem Aufbrechen der Schleife, so die Mechanismenaussage, würden die Pakete schnell ausgespült. Das belegt keine konkrete Reparatur. Routenänderung, Verkehrsabbau und beobachtete Dienstwiederkehr bleiben getrennte Nachweise.

Mehr Einblick bedeutete nicht vollständiges Wissen

Das Bewahren des Hop Count funktionierte nur, wenn beide Protokolle passende Felder und Bedeutungen besaßen. Header Peeking sollte vorhandene Kapselungen erkennen, stieß aber auf unbekannte Typen, Verschlüsselung und Protokolle oberhalb der erwarteten Schicht.

Außerdem konnte derselbe Protokollheader in einer legitimen Verschachtelung zweimal vorkommen. Eine Wiederholung war ein Warnsignal, kein allgemeiner Ungültigkeitsbeweis. Eine Instanz, die nicht weiter lesen konnte, wusste nur, wo ihre Sicht endete; sie gewann daraus kein Urteil über den verborgenen Rest.

RFC 1326 kombinierte daher Vorsicht: wechselseitige Kapselung vermeiden, verschachtelte wechselseitige Kapselung untersagen, Zähler erhalten und wo sinnvoll inspizieren. Es präsentierte keine allwissende Instanz und keinen universellen Algorithmus.

Eine zweite Grenze für eine zweite Operation

RFC 2003 legte später für IP-in-IP fest, bei Kapselung als Teil der Weiterleitung den inneren TTL einmal zu senken und Datagramme mit TTL null nicht zu kapseln. Bestimmte Schleifen, in denen die Quelle dem Kapselungsknoten oder Tunnelziel entsprach, sollten ebenfalls verworfen werden.

RFC 2473 trennte für IPv6 den Hop Limit des ursprünglichen Pakets vom Tunnel Encapsulation Limit. Der erste zählt Weiterleitung, der zweite weitere Verschachtelungen. Bei null darf das Paket keinen neuen Tunnel betreten, bevor es den aktuellen verlassen hat.

Das war kein doppelter Zähler, sondern eine saubere Zuordnung. Weiterleiten und eine Hülle hinzufügen sind verschiedene Ereignisse. RFC 2473 hielt auch fest, dass die Fragmentierung eines bereits fragmentierten Tunnelpakets die Fragmentzahl verdoppelt. Die spätere Norm gab dem Risiko von 1992 eine eigene messbare Schranke.

Quellen

Die Quellen belegen Dokumentstatus, beschriebene Mechanismen und spätere Protokollantworten. Sie belegen keinen Vorfall von 1992, heutigen Tunnel, Angreifer, Herstellerfehler, Verbreitungsgrad, Schaden oder Reparaturerfolg.