Zusammenfassung

  • RFC 9507 überträgt Traceroute auf CCNx und NDN. Interests folgen Namen statt eindeutigen Zieladressen; Data kehrt über den hopweise aufgebauten Zustand der Pending Interest Tables zurück.
  • Ein Nonce verhindert die Aggregation der Diagnosesonden. Vier Codes unterscheiden Hop, Verwaltungsname, lokale Anwendung und Cacheobjekt. Ein Path Label kann spätere Anfragen auf denselben beobachteten Ast lenken.
  • Das Ergebnis belegt einen Antwortweg unter dokumentierten Bedingungen. Es belegt weder eine einzige Inhaltsquelle noch alle Routen, die normale Auslieferung oder den Anwendungserfolg.

Der kürzeste Trace war zugleich der irreführendste. Nach drei Forwardern endete er bei einem Content Store, der das gesuchte Objekt enthielt. Die Latenz war ausgezeichnet, der Absendername signiert. Das Betriebsdashboard meldete: Ursprung erreichbar.

Der Ursprung war aber nie geprüft worden. Eine weitere Anfrage konnte einen anderen Zweig zu einer Erzeugeranwendung nehmen. Für den Leser war die Cacheantwort nützlich; für die Frage nach dem Erzeuger war sie ein anderer Befund. Die Technik hatte korrekt geantwortet. Die Bezeichnung des Messwerts hatte zwei Wirklichkeitsebenen zusammengezogen.

RFC 9507 liefert das Diagnoseverfahren für diese Architektur. Das Dokument erschien im März 2024 als Experimental RFC im IRTF-Stream und gehört nicht zum IETF Standards Track. Es beschreibt CCNx- und NDN-Pakete, Client- und Forwarder-Verhalten, Pfadsteuerung und Sicherheitsgrenzen. Sein Gegenstand ist mindestens ein Weg zu einem Namen, nicht ein Host hinter einer anders geschriebenen Adresse.

Namen schaffen eine andere Messgeometrie

IP-Traceroute erhöht die TTL aufeinanderfolgender Pakete. Der Router, an dem sie abläuft, sendet ICMP Time Exceeded an die Quelladresse. Filter, Asymmetrie und Load Balancing begrenzen die Aussage; dennoch bildet eine Zieladresse die Grundkoordinate.

Ein ICN-Interest besitzt keine Quelladresse. Er wird nach einem hierarchischen Namen weitergeleitet. Data nutzt auf dem Rückweg den Zustand, den der Interest in den PITs der Forwarder angelegt hat. Derselbe Name kann von einer Anwendung, mehreren Erzeugern oder Content Stores im Netz bedient werden. Zwei aufeinanderfolgende Interests können verschiedene Äste und Datenquellen erreichen.

Gleichnamige Interests dürfen außerdem in einem PIT-Eintrag zusammengeführt werden. Das spart Übertragungen, zerstört aber die Unabhängigkeit einer Messsonde. Eine spätere Anfrage kann in den Zustand einer früheren einsteigen und eine kürzere Laufzeit erleben als bis zum eigentlichen Erzeuger. Schon die Lebensdauer des PIT-Eintrags verändert den Befund.

RFC 9507 versieht die Zielbezeichnung deshalb mit einem Nonce. CCNx verwendet ein typisiertes 64-Bit-Namenssegment; bei NDN gehören Ziel, Nonce und das Suffix traceroute zusammen. Dadurch bleibt jede Sonde für die PIT einzigartig und die Antwort lässt sich zuordnen. Bei der Suche im Content Store wird der Nonce ignoriert, damit das ursprünglich benannte Objekt weiterhin gefunden werden kann.

Das ist keine Formalität. Die Messung braucht eine eigene Identität, ohne die Identität des Inhalts umzuschreiben. Ein Nonce identifiziert den Versuch, nicht dessen Produzenten.

Vier Antwortcodes beschreiben vier Tatbestände

Eine Sitzung beginnt mit HopLimit 1 und erhöht den Wert. Der Forwarder prüft und dekrementiert ihn. Solange er positiv bleibt, folgen Cacheprüfung, PIT-Erzeugung, Longest Name Prefix Match und gegebenenfalls die Pfadsteuerung. Gibt es keinen gültigen nächsten Hop, meldet CCNx No Route oder NDN einen Netzwerk-NACK.

Erreicht HopLimit den Wert null, antwortet der aktuelle Forwarder mit seinem Verwaltungsnamen und Code 4. Die Sonde hat die gewählte Entfernung erreicht. Über die Erreichbarkeit von Inhalt oder Anwendung sagt das nichts.

Drei andere Zustände beenden die Sitzung semantisch. Code 1 bedeutet, dass der Zielname dem Verwaltungsnamen des Forwarders entspricht. Code 2 bedeutet, dass der längste FIB-Treffer auf eine lokale Anwendung zeigt. Code 3 bedeutet, dass ein Content Object im lokalen Store exakt passt, sofern der Client Cachetreffer als Abschluss zulässt.

Ein einziges Feld reachable vernichtet diese Aussage. Ein naher Cache kann Nutzer versorgen und gleichzeitig den Ausfall des Erzeugers verdecken. Eine lokale Face bestätigt die Übergabe an einen Prozess, nicht dessen Ergebnis. Ein Verwaltungsname identifiziert eine Managementoberfläche, nicht den Eigentümer der Daten. Code 4 ist ein Hopbefund.

Der Antwortgrund gehört daher in den Urteilssatz, nicht nur in ein Debugfeld.

Ein Path Label stabilisiert den Versuch

In einem Multipath-Netz kann die Anfrage mit HopLimit 2 einen anderen Ast nehmen als jene mit HopLimit 3. Aneinandergereiht entstünde ein vermeintlicher Pfad aus Forwardern, die nie gemeinsam auf einem Weg lagen.

RFC 9507 verwendet dazu Path Steering aus RFC 9531. Der Urheber einer Antwort beginnt mit einem leeren Path Label. Auf dem Rückweg ergänzt jeder Forwarder den Wert anhand seiner Next-Hop-Entscheidung. Der Client kann ihn in die nächste Anfrage übernehmen, um denselben Ast erneut anzusteuern. Ohne Label kann eine neue Sitzung Alternativen suchen.

Das Label schafft Kohärenz, keine Ewigkeit. Es verdichtet Entscheidungen einer bestimmten FIB, Strategie, Cachepopulation und Topologie zu einem Zeitpunkt. Seine Wiederverwendung prüft, ob der Ast noch begehbar ist. Sein Weglassen garantiert nicht, dass alle anderen Wege gefunden werden.

Eine belastbare Aussage nennt Zeitpunkt, Ziel, Nonce, HopLimits, Label und Abschlusscode. „Der Inhaltsweg ist X“ entfernt genau die Bedingungen, die das Ergebnis tragen.

Signaturumfang und Vertrauensumfang sind identisch

Die Antwort enthält den Verwaltungsnamen des Absenders, damit der Client weitere Managementinformationen abrufen kann. Ohne Schutz könnte ein Angreifer einen Opfernamen einsetzen und spätere Anfragen zum Opfer umleiten. Im CCNx-Format muss der Antworter seinen enthaltenen Namen signieren; der Client holt den öffentlichen Schlüssel und prüft ihn.

Die Maßnahme verhindert eine einfache Namenssubstitution. Ein kompromittierter Forwarder auf dem Weg kann jedoch Namen und Signatur durch sein eigenes gültiges Paar ersetzen. Eine Signatur über die ganze Antwort schützt mehr, erhöht aber die Rechenlast und kann selbst zum Ziel eines Erschöpfungsangriffs werden. Die RFC empfiehlt deshalb eine getrennte lokale Managementanwendung.

Im Nachweis müssen signierte Bytes, akzeptierter Schlüssel, Herkunft des Schlüssels, Prüfergebnis und Schutz der gesamten Nachricht stehen. Das bloße Wort „signiert“ verspricht sonst zu viel.

Lokale Namensräume brauchen ein sichtbares Gerüst

Ein lokal begrenzter Name kann vom Netz des Clients aus nicht routbar sein. Eine Variante hängt ein signiertes NDN Link Object mit routbaren Präfixen an, bis die Region erreicht ist, in der der lokale Name gilt. Wie der Client dieses Objekt erhält, bleibt ausdrücklich außerhalb des Dokuments.

Die andere Variante stellt dem lokalen Namen ein routbares Präfix voran. Ein Grenzforwarder entfernt es beim Eintritt und stellt den notwendigen Kontext für die Rückantwort wieder her. Dafür hält er zusätzlichen Zustand; bei Interest Flooding kann sich die Belastung verstärken.

Wer nur den endgültigen lokalen Namen speichert, versteckt das Gerüst. Link Object, Signatur, äußeres Präfix, umschreibende Grenze und Regionswechsel sind Bestandteil des Wegbelegs.

RFC 9507 macht namensbasierte Weiterleitung untersuchbar, ohne sie in eine eindeutige Route umzudeuten. Ein einzigartiger Probe, ein Antwortgrund, eine geprüfte Identität und ein beobachteter Ast sind erreichbar. Herkunft, Vollständigkeit, Anwendungsausführung und Nutzerwirkung bleiben eigenständige Beweisfragen.

Quellen