Zusammenfassung

  • RFC 5210 meldete den erwarteten Erfolg für vollständig ausgestattete AS mit Validierung im Zugangsnetz, innerhalb des AS und zwischen AS. Wo ein Zaun fehlt, ist die Aussage entsprechend kleiner.
  • Portbindung, routingbasierte Präfixregel und Allianz-Tag sind veränderliche Zustände. Ohne Version und Zeit wird ein historisch richtiger Befund zu einer unzulässigen Daueraussage.
  • Quellvalidierung erschwert Spoofing. Ein kompromittierter Rechner kann mit seiner rechtmäßig zugewiesenen Adresse angreifen und dabei alle drei Prüfungen korrekt bestehen.

Was um 09:00 tatsächlich geprüft wurde

Um 09:00 verlässt ein IPv6-Paket einen Rechner am Switchport 17. Die Zuordnung von Adresse, MAC und Port stimmt. Am Eingang des AS passt das Quellpräfix nach damaliger Routing-Sicht zur Schnittstelle. Beim entfernten Allianzmitglied wird der temporäre Tag für seine aktuelle Epoche akzeptiert. Drei grüne Befunde.

Eine genaue Aufzeichnung lautet: Dieses Paket bestand zu diesem Zeitpunkt diese drei Prüfungen unter den genannten Zuständen. Die Oberfläche verkürzt sie jedoch zu Quelle authentifiziert.

Um 09:12 wechselt der Rechner auf einen Ausweichanschluss. Eine Präfixzuordnung ändert sich, gleichzeitig rotiert der Allianz-Tag. Eine Validation Engine kennt schon die neue Regel, eine andere noch die alte Projektion. Alter und neuer Tag gelten wenige Sekunden parallel. Um 09:15 bleibt die Anzeige grün.

Der Befund von 09:00 ist nicht falsch geworden. Falsch ist die Gegenwartsform ohne neue Messung. Hinzu kommt der Kategorienfehler: Aus der Zulässigkeit einer Adresse wird die Identität eines Absenders.

Das Szenario ist konstruiert und berichtet weder über einen Betreiber noch über ein Produkt oder einen Vorfall. Es zeigt, welche Felder einen SAVA-Befund zusammenhalten: Paket, Kontrollpunkt, Zustandsversion und Zeit.

Der Versuch war konkret – nicht universal

RFC 5210 erschien im Juni 2008 als Experimental. Der SAVA-Prototyp wurde in zwölf Universitäts-AS an CNGI-CERNET2 eingesetzt. Sechs dieser AS besaßen alle drei Teile und galten als vollständig ausgestattet.

Die Testfälle umfassten normalen Betrieb, dynamische Änderungen und Spoofing-Abwehr. Beim Verfahren für nicht benachbarte AS wurden das Einfügen und Entfernen von Tags, gültiger Verkehr, Tagwechsel, neue Mitglieder sowie das Hinzufügen und Löschen von Adressraum geprüft.

Für die vollständig ausgestatteten AS lautet das Ergebnis: Pakete ohne authentifizierte Quelladresse wurden nicht weitergeleitet. Die Bedingung ist Teil des Ergebnisses. Sie darf weder auf das ganze Internet noch auf heutige Produkte oder Betreiber übertragen werden.

Die Autoren bezeichnen Prototyp und Ergebnisse als Beitrag zu späterer Arbeit und nicht als Vorwegnahme künftiger IETF-Lösungen. Die Grenzen bei Einsatz, Synchronisation, Sicherheit und Leistung gehören deshalb zur Auswertung.

Der Zugangskontrollpunkt kennt eine Anbindung

Eine Variante bildet IP-Adresse, MAC-Adresse und Switchport dynamisch ab. Passt das Paket nicht zur Kombination aus Adresse und Port, wird es verworfen. Eine zweite Variante leitet aus der Zugangsauthentisierung Schlüsselmaterial ab und schützt damit Pakete bis zum SAVA-Gerät.

Das erste Verfahren bestätigt die Übereinstimmung mit einer lokalen Zuweisung und Anbindung. Das zweite fügt eine Sitzungsevidenz hinzu. Keines nennt den Benutzer, den Prozess, die Organisation oder die Absicht hinter dem Verkehr.

RFC 5210 weist darauf hin, dass die Bindungsmethode des Prototyps für eine Produktion nicht genügt. Multihoming, Failover, Mobilität, Funkzugang und Anschlusswechsel verändern die Bindung. Erzeugung, Ablauf, Umzug und Konfliktbehandlung müssen belegt werden.

Innerhalb des AS geht es um topologische Plausibilität

Die interne Schicht nutzt die Ideen aus RFC 2827 und RFC 3704. Sie fragt, ob ein Quellpräfix nach dem gewählten Routingmodell an dieser Schnittstelle plausibel ist. Das ist eine Netz-, keine Hostaussage.

Striktes Reverse Path Forwarding, Feasible Path und lockerere Varianten liefern verschiedene Evidenz. Bei asymmetrischen Wegen oder Multihoming kann der legitime Eingang vom besten Rückweg abweichen. Mehr Toleranz reduziert Fehlverwerfungen, macht die Aussage aber gröber.

Ein bestandener Test bedeutet daher nur: Dieses Präfix wurde unter dieser Routing-Sicht, Betriebsart und Schnittstellenregel akzeptiert. Routingstand, Regelkennung, Erzeugungszeit, Verteilung und Installation müssen mitgeführt werden.

Zwischen AS wird Koordination zur Laufzeitabhängigkeit

Für benachbarte AS verknüpft der Prototyp eingehende Schnittstellen mit erlaubten Quellblöcken. Eine Engine erzeugt Regeln auf AS-Ebene, ein Dienst bildet AS auf IPv6-Präfixe ab, und Validation Engines erhalten die Projektion.

Für nicht benachbarte AS gibt es eine Allianz mit temporären Tags. Der Ausgangsrouter fügt einen Wert abhängig vom Ziel-AS ein; der Eingangsrouter prüft und entfernt ihn. Kontrollserver tauschen Mitglieder, Präfixbesitz und Tags aus.

Damit hängen Ergebnisse von Mitgliedschaft, Vertrauen, Zuordnung, Synchronisation und Installation über mehrere Verwaltungsbereiche ab. Dynamischer Beitritt und Austritt waren vorgesehen, doch das anfängliche Vertrauen im Versuch wurde offline bestätigt. Das ist kein Beleg für eine selbstentstehende globale Vertrauensstruktur.

Regeln altern während der Verteilung

RFC 5210 beschreibt, dass das nach AS-Beziehungen arbeitende Verfahren schnellen Routingänderungen hinterherhinken und Fehlannahmen erzeugen kann. Im relativ stabilen Testnetz funktionierte es gut. Diese Stabilität ist Teil des Kontextes.

Auch Tags haben Epochen. Ein alter Wert soll nicht unbegrenzt akzeptiert werden. Im Versuch waren alter und neuer Tag fünf Sekunden gemeinsam gültig, um Paketverlust beim Wechsel zu vermeiden.

Ein belastbarer Beleg umfasst deshalb Zugangsbindung, Routing-Sicht, AS-Beziehung, Präfixabbildung, Regelversion, Verteilbestätigung, Installationshash, Mitgliedschaftsstand, Tag-Epoche und Ende der Überlappung. Außerdem benennt er den ersten fehlenden, veralteten oder umgangenen Zaun.

valid=true speichert ein Ergebnis, aber nicht die Wirklichkeit, aus der es entstand.

Rückverfolgung ist noch keine Identifizierung

Weniger Spoofing macht Adresse und Pfad zu besseren Ermittlungsindizien. Das ist für Diagnose und Reaktion wertvoll. Ein besseres Indiz wird dadurch aber nicht zur Personenidentität.

RFC 7039 warnt ausdrücklich davor, aus Quellbindungsdaten die Person oder sogar das Endsystem hinter einem Datagramm abzuleiten. Sie liefern Indizien. Mehrbenutzersysteme, Relays, Proxys, Plattformen und kompromittierte Endgeräte unterbrechen die einfache Kette.

Akzeptierte Adresse, Anschluss, Gerät, Workload, Konto, Organisation, Person und Absicht sind getrennte Stufen. Jede braucht eine zusätzliche Quelle und eine eigene Unsicherheitsangabe.

Bindungsprotokolle können zudem Aufenthalts- und Aktivitätsdaten offenlegen. Zweck, Aufbewahrung, Zugriff und Berichtigung müssen festgelegt sein. Eine plausible technische Zuordnung darf nicht automatisch zur Sanktion werden.

Ein Botnetz braucht keine gefälschte Adresse

RFC 5210 nennt die Obergrenze selbst: Viele Denial-of-Service-Angriffe können von Botnetz-Clients mit legitimen IP-Adressen ausgehen. Selbst weltweit eingesetzte Quellvalidierung würde diese Angriffe nicht verhindern.

SAVA bekämpft Spoofing, nicht kompromittierte Hosts, unerlaubte Anwendungen, schädliches Volumen oder Absicht. Ein infizierter Rechner besteht alle Zäune gerade deshalb, weil er seine zugewiesene Adresse verwendet.

Dann muss die Untersuchung zu Endgerät, Prozess, Konto, Berechtigung und Verhalten wechseln. Der Ausdruck „authentifizierter Verkehr“ verdeckt diese Grenze und kann andere Kontrollen verdrängen.

Konfiguration und Datenebene sind zwei Beweise

Der leichte Tag im Versuch war ein geteilter Zufallswert, keine kryptografische Identität pro Paket. RFC 5210 erörtert die Gefahr eines Angreifers auf dem Pfad und den Rechenaufwand stärkerer Verfahren. IPv6-Hop-by-Hop-Optionen liefen mit bestimmten Routern nur begrenzt schnell.

Eine Controller-Regel belegt Absicht. Eine Installationsbestätigung belegt Annahme des Zustands. Zähler, Testpakete und Beobachtung am richtigen Punkt belegen die Wirkung. Keine Stufe darf die nächste vertreten.

Ein Slow Path kann selbst zur Überlastungsfläche werden; ein Notfall-Bypass kann einen Zaun entfernen, ohne das Sollbild im Dashboard zu ändern. Entscheidend ist der Anteil des Verkehrs, der tatsächlich mit der aktuellen richtigen Regel geprüft wurde.

Der Betriebsbeleg

Er beginnt mit Paket oder Flow, Beobachtungspunkt, Zeit und erwartetem Profil. Am Zugang stehen Zuweisung, Adresse, Anker, Port, Erzeugung, Ablauf und Umzug. Innerhalb des AS stehen Modus, Schnittstelle, Routing-Sicht, Präfix und Regel.

Zwischen AS kommen Beziehung, Mapping, Erzeuger, Version, Verteilung und Installation hinzu. Für die Allianz: Mitglieder, Partner, Besitzdaten, Tag oder Seed, Epoche, Überlappung und Ablauf. Hardware, Software, Optionsbehandlung, Zähler, Drops und Testherkunft gehören dazu.

Dann endet die Aussage. Ohne unabhängige Geräte-, Konto- oder Personenbelege heißt das Ergebnis: Adresse und Pfad akzeptiert; Handelnder unbekannt. Diese Genauigkeit ermöglicht den nächsten Schritt.

Quellen