Zusammenfassung

  • Das öffentliche Register verbindet AS210833 mit Florian Bauer, dem Namen Florian-Bauer und RIPE-Organisation ORG-FB169-RIPE. Diese Zuordnung ist ein historischer beziehungsweise verzeichnisbasierter Befund, kein alleiniger Nachweis gegenwärtiger operativer Kontrolle.
  • Für eine belastbare Aussage über die heutige Kontinuität müssten Registerpflege, deklarierte Routing-Policy, beobachtetes BGP, RPKI-Autorisierung, Interconnection-Abhängigkeiten und zurechenbare Betriebs- oder Wiederherstellungsmaßnahmen zeitlich zusammengeführt werden.
  • In diesem Recherchelauf konnten keine aktuellen Werte für Präfixe, BGP-Zustand, Peers, Upstreams, RPKI oder PeeringDB abgerufen werden. Daraus folgt weder, dass AS210833 ausgefallen ist, noch dass die genannten Dienste nicht verfügbar sind.

Der erste Befund ist eine Identität, kein Betriebsnachweis

Das eingefrorene Directory-Ziel ordnet den öffentlichen Namen Florian Bauer dem RIPE-Aut-num AS210833, dem AS-Namen Florian-Bauer und der Organisation ORG-FB169-RIPE zu. Die Directory-Zusammenfassung verbindet das autonome System außerdem mit FSRV und as210833.net. Der Registereintrag ist damit nützlich: Er benennt eine öffentlich sichtbare administrative Beziehung und liefert den Ausgangspunkt für weitere Prüfungen. Er beantwortet aber nicht automatisch die Fragen, wer heute Router betreibt, wer Zugang zu den relevanten Konten besitzt oder wer bei einem Ausfall Entscheidungen treffen kann.

Die Grenze ist praktisch, nicht semantisch. Ein Name kann in einem Register stehen, während Maintainer-Zugänge, technische Zuständigkeiten oder Wiederherstellungspläne später geändert wurden. Umgekehrt kann ein unveränderter Registereintrag mit einem weiterhin funktionierenden Betrieb zusammenfallen. Ohne datierte Folgemessungen lässt sich zwischen diesen Möglichkeiten nicht sicher unterscheiden. Der geeignete Schluss lautet daher: Die administrative Zuordnung ist öffentlich dokumentiert; die gegenwärtige operative Kontrolle bleibt in diesem Lauf unbestätigt. Die Registerspur ist in den RIPE-Aut-num-Daten zu AS210833 und im Directory-Eintrag zu Florian Bauer verankert.

Vier Datenebenen, vier verschiedene Fragen

Für AS210833 sollte die Prüfung mindestens vier technische Ebenen trennen.

Erstens beschreibt die Registry-Ebene, welcher Organisation oder welchem Maintainer ein Objekt zugeordnet ist, welche Attribute es enthält und wann es zuletzt verändert wurde. Die RIPE-Aut-num- und Route6-Suchen können hierfür die maßgeblichen Objekte liefern. In diesem Lauf wurden die RIPE-Aut-num-Abfrage und die RIPE-Route6-Suche als geeignete Quellen identifiziert, ihre aktuellen Inhalte und Änderungsdaten aber nicht verifiziert.

Zweitens beschreibt die deklarierte Routing-Policy, welche Importe, Exporte, Routen oder Route6-Objekte vorgesehen sind. Eine Policy ist eine Absichtserklärung oder ein administratives Modell. Sie beweist nicht, dass Sessions weiterhin aktiv sind, dass die angekündigten Wege tatsächlich implementiert werden oder dass ein benannter Betreiber die Änderungen noch kontrolliert.

Drittens zeigt beobachtetes BGP, was aus bestimmten Messpunkten und Sammlern sichtbar war. RIPEstat stellt dafür unter anderem Endpunkte für angekündigte Präfixe, Routing-Status, BGP-Zustand und Looking-Glass-Daten bereit. Diese Beobachtungen sind zeitgebunden und vom Blickwinkel abhängig. Die RIPEstat-Daten zu angekündigten Präfixen, zum Routing-Status, zum BGP-Zustand und zum Looking Glass wurden in diesem Recherchelauf jedoch nicht mit aktuellen Werten abgerufen.

Viertens beschreibt RPKI, ob eine zeitgestempelte Validierungsansicht eine Route-Origin-Autorisierung für einen Präfixbereich und eine maximale Präfixlänge enthält. RPKI kann eine wichtige Sicherheitsbeziehung belegen. Es beweist weder, dass eine Route sichtbar ist, noch wer die Person hinter der Pflege der Autorisierung ist. Ein belastbarer Check müsste einen Validator-Snapshot für AS210833 filtern, Präfix, Origin-AS, maximale Länge, Validierungskategorie und Trust-Anchor-Kontext speichern und diese Ergebnisse mit einer exakt beobachteten Route vergleichen. Die Cloudflare-RPKI-Datenquelle ist dafür eine mögliche Referenz; ein aktueller Wert wurde hier nicht festgestellt.

Warum mehrere Dashboards nicht automatisch mehrere Beweise liefern

Öffentliche Plattformen können unterschiedliche Darstellungen derselben zugrunde liegenden Registry-, Validator- oder Route-Collector-Daten anbieten. PeeringDB kann deklarierte Netz- und Interconnection-Informationen liefern. BGPView, BGP.Tools und Hurricane Electric können beobachtete oder abgeleitete Routingbeziehungen darstellen. CAIDA AS Rank kann Beziehungskontext liefern. Diese Quellen sind wertvoll, aber ihre Unabhängigkeit muss geprüft werden, bevor aus übereinstimmenden Anzeigen eine starke Bestätigung wird.

Die in diesem Lauf vorgesehenen Quellen sind die PeeringDB-Netzdaten, die BGP.Tools-Ansicht, die Hurricane-Electric-Ansicht, die BGPView-Präfixdaten, die BGPView-Upstreamdaten, die BGPView-Peerdaten und der CAIDA-AS-Rank-Eintrag. Für keine dieser Quellen wurde in dieser Recherche ein aktueller Wert verifiziert. Eine Liste von Kandidatenquellen ist deshalb noch keine Aussage über aktuelle Präfixe, Peers, Upstreams oder Redundanz.

Der eigentliche Kontinuitätstest

Die relevante operative Frage lautet nicht nur, ob AS210833 irgendwo sichtbar ist. Sie lautet, ob die Kontrollschichten noch zusammenpassen und ob bei einer Störung eine zurechenbare Person oder Organisation handeln kann.

Ein erster Test würde die aktuellen Registerobjekte, Organisationen, Personen, Rollen und Maintainer erfassen. Für jedes Objekt müssten Abfragezeitpunkt, Status, Änderungsdatum und die konkret gestützte Beziehung gespeichert werden. Ein zweiter Test würde deklarierte Import-, Export-, Route- und Route6-Attribute mit beobachteten Pfaden vergleichen. Ein dritter würde Präfixe, Origins, Pfade, Sichtbarkeitsdauer, Rückzüge und die Abdeckung mehrerer Sammler zeitlich dokumentieren.

Danach käme der Vergleich mit RPKI: Welche Autorisierung galt zu welchem Zeitpunkt, und entsprach sie exakt der beobachteten Route? Die Interconnection-Ebene müsste deklarierte PeeringDB-Angaben von collector-sichtbaren Pfaden und unabhängig datierten Beziehungsdaten trennen. Ein Eintrag über einen Austauschpunkt, ein vermuteter Transitpfad und eine deklarierte Policy sind nicht dasselbe wie vertragliche oder physische Redundanz.

Erst die letzte Ebene betrifft die operative Zurechenbarkeit. Dafür wären direkte Hinweise auf gepflegte Zugänge, konsistente Updates, Reaktionsfähigkeit, Incident-Handling sowie Wiederherstellungs- oder Nachfolgeregelungen nötig. Die bloße Übereinstimmung zwischen einem Personennamen und einem Registerfeld reicht dafür nicht. Die vorliegenden Quellen zeigen in diesem Lauf keine solche longitudinale Verbindung.

Was aus der fehlenden Messung folgt – und was nicht

Die Recherche scheiterte an der Produktion aktueller Evidenz, nicht an einem nachgewiesenen Netzereignis. Es wurde kein aktueller Präfixwert, keine aktuelle RPKI-Autorisierung, kein aktueller Upstream, kein Peer und kein PeeringDB-Wert abgerufen. Daraus darf nicht geschlossen werden, dass AS210833 nicht routet, dass eine Registry oder ein Validator ausgefallen ist oder dass eine operative Beziehung beendet wurde.

Ebenso wenig darf aus dem Registereintrag ein heutiger Kontinuitätsnachweis abgeleitet werden. Die korrekte Zwischenbilanz liegt zwischen diesen beiden Übertreibungen: Die historische beziehungsweise administrative Identität ist öffentlich belegbar; die aktuelle Ausrichtung von Register, Policy, BGP, RPKI, Interconnection und Stewardship ist noch nicht verifiziert.

Öffentliche Quellen und Prüfgrenzen

Für die geplante Wiederholung der Prüfung sollten die Quellen mit Abrufzeit, Antwortstatus, Datenstand und möglicher gemeinsamer Datenbasis archiviert werden:

Diese Quellen können zusammen ein belastbares Messprotokoll bilden. Sie ersetzen aber nicht die Prüfung, ob die Daten unabhängig sind und ob sie dieselbe Zeitspanne abdecken. Die wesentliche offene Frage bleibt, ob öffentliche, unabhängig zurechenbare und longitudinal vergleichbare Belege zeigen können, wer die Registry-, Routing-, RPKI- und Wiederherstellungskontrollen hinter AS210833 gegenwärtig pflegt.