Zusammenfassung

  • Die geltende RIPE-NCC-Anleitung verlangt sämtliche Upstream-Provider, Nachbarn mit Providerrolle und nicht transparente Route Server im ASPA. Gleichzeitig liefert das RPKI-Dashboard laut Anleitung keine Hinweise darauf, welche Provider für das AS in BGP sichtbar sind.
  • Der Activity Plan 2026 sieht Vorschläge auf Grundlage der ASes vor, die RIPE NCC für Upstreams hält. Das ist bewusst eine Inferenz und weder ein Nachweis der Geschäftsbeziehung noch ein datierter Liefertermin.
  • Jeder Kandidat sollte Quelle, Beobachtungspunkte, Zeitraum, Adressfamilie, Pfadposition, Begründung und Unsicherheit mitbringen. Erst der Betreiber klassifiziert ihn; das veröffentlichte ASPA bleibt die Autorisierung.

Die digitale Signatur löst das letzte Problem in der Kette. Das schwierigste liegt davor.

Im RPKI-Dashboard von RIPE NCC kann der Inhaber einer Autonomous-System-Nummer ein Autonomous System Provider Authorization anlegen. Darin autorisiert der Customer AS andere ASes als Transitprovider. Die Signatur macht überprüfbar, wer diese Erklärung abgegeben hat und ob sie verändert wurde. Sie prüft jedoch nicht, ob alle Verträge, Ersatzwege und Rollen richtig in die Liste übersetzt wurden.

Die öffentliche Anleitung überträgt dem Betreiber eine präzise Pflicht. Alle Upstreams müssen enthalten sein und das Objekt muss mit jeder Veränderung des Provider-Mixes aktualisiert werden. Hat ein Nachbar mehrere Rollen und ist eine davon die Providerrolle, gehört er in das ASPA. Ein nicht transparenter Route Server an einem Internet Exchange erscheint ebenfalls mit Providerrolle im Pfad und muss aufgenommen werden. Laterale Peers und Kunden dürfen nicht hinein.

Eine Auslassung ist nicht nur ein unvollständiger Datensatz. RIPE NCC warnt, dass Routen über einen nicht aufgeführten Provider abgelehnt werden können. Danach nennt die Anleitung die Grenze der Oberfläche: Das RPKI-Dashboard gibt weder Hinweise noch Hilfestellung dazu, welche Provider für das betreffende AS in BGP gesehen werden. Der Betreiber muss dies selbst sicherstellen.

Damit steht die Befugnis zur Veröffentlichung vor der Beweisführung. RIPE NCC stellt Signatur und Publikation bereit, zeigt dem Unterzeichner aber nicht die BGP-Beobachtungen, die eine vergessene Beziehung sichtbar machen könnten. Die Eingabe einer ASN ist leicht. Die Einordnung eines beobachteten Nachbarn als autorisierter Provider ist die eigentliche Entscheidung.

Eine zu lange Liste schützt ebenso schlecht wie eine zu kurze

Das bei der Recherche aktuelle IETF-Profil lag in Revision 29 vor und war weiterhin ein Internet-Draft. Es verlangt von einem Customer AS mit mehreren Providern die vollständige Aufzählung, einschließlich nicht transparenter Route-Server-ASes, und empfiehlt ein einziges Objekt mit dem gesamten Provider-Set.

Der Verifikationsentwurf in Revision 28 beschreibt die entgegengesetzten Fehlerfolgen. Wird ein Provider irrtümlich aufgenommen, sinkt die Fähigkeit zur Erkennung von Route Leaks. Fehlt ein Provider, können legitime Routen später fälschlich als ASPA Invalid gelten. Beide Entwürfe können sich vor einer RFC-Veröffentlichung noch ändern. Die operative Spannung ist dennoch real.

Ein Vorschlagssystem, das nur auf Vollständigkeit optimiert ist, kann zu viele Beziehungen autorisieren. Eines, das nur häufig sichtbare Pfade berücksichtigt, kann den selten genutzten Ersatztransit übersehen. Im ersten Fall wird die Schutzwirkung großzügiger, im zweiten entsteht ein mögliches Fehlurteil über Erreichbarkeit.

Der täglich genutzte Hauptprovider steht meist in der Betriebsdokumentation. Schwieriger sind kalte Backups, regionale Anbieter, IPv6-spezifische Beziehungen, aus einer Übernahme geerbte Sessions, Gegenparteien mit mehreren Rollen und Route Server, deren ASN je nach Betriebsart im Pfad erscheint oder verborgen bleibt. Gerade diese Fälle fehlen leicht im Gedächtnis und in einem kurzen Beobachtungsfenster.

BGP beobachtet einen Pfad, nicht den Vertrag

Jede BGP-Beobachtung hat einen Standort und einen Zeitpunkt. Ein öffentlicher Collector sieht, was seine Teilnehmer nach ihren eigenen Exportentscheidungen liefern. Kein einzelner Blickpunkt zeigt das gesamte Internet. Eine Adjazenz kann an einem Ort häufig und an einem anderen unsichtbar sein. IPv4 und IPv6 können unterschiedliche Wege nehmen. Während einer Wartung kann für wenige Minuten ein Backup auftauchen, das zuvor monatelang still war.

Nicht jede beobachtete Nachbarschaft ist berechtigt. Ein Leak, eine Fehlkonfiguration oder ein Übergangszustand kann zwei ASes nebeneinanderstellen, ohne eine legitime Providerbeziehung zu schaffen. Häufigkeit belegt die Beständigkeit eines Signals, nicht die Zustimmung der Parteien. Im AS_PATH stehen weder Rechnung noch Vertrag, Zahlungsrichtung oder beabsichtigte Rolle.

Ein eigener BMP-Feed des Betreibers ist reichhaltiger. Er kann pro Router und Nachbar die vor lokaler Policy empfangenen Routen erfassen und so Backups oder Unterschiede zwischen Adressfamilien zeigen. Doch auch BMP beschreibt Routingzustand. Es entscheidet keine kommerzielle oder organisatorische Beziehung.

Vier Ebenen müssen getrennt bleiben. RIS und andere Collector-Daten sowie lokale Telemetrie liefern Beobachtungen. Verträge, Session-Inventar und Netzdesign klassifizieren Rollen. Der AS-Inhaber autorisiert. RIPE NCC publiziert das signierte Objekt, das Validatoren und Router später nach einem sich entwickelnden Standard und lokaler Policy verwenden.

Wer diese Ebenen vermischt, verleiht einem Hinweis die Autorität des Registers. Wer sie trennt, macht den Hinweis zu einer prüfbaren Frage.

Der Plan für 2026 verwendet bereits die richtige Vorsicht

Der Activity Plan and Budget 2026 von RIPE NCC kündigt bessere BGP-Informationen für die Verwaltung von ROAs und ASPAs an. Für ROAs ist von nahezu zeitnahen BGP-Daten die Rede. Für ASPA sollen ähnliche Vorschläge auf Grundlage derjenigen entstehen, die RIPE NCC für die Upstreams eines AS hält.

Die Formulierung „für Upstreams hält“ ist wichtig. Sie beansprucht keine Kenntnis eines privaten Vertrags. Sie beschreibt eine Inferenz, die dem Betreiber Arbeit abnehmen kann, ohne ihm die Entscheidung abzunehmen.

Ein Lieferdatum enthält die Passage nicht. Die erfasste Quartalsplanung für RPKI trägt die Überschrift Q3 2026 und wurde am 11. Juni aktualisiert. Sie nennt vier Vorhaben: automatische Aufhebung dauerhaft funktionsloser delegierter Zertifizierungsstellen, Ersatz der bisherigen API-Schlüssel durch OpenID Connect, Compliance-Arbeit und bei verfügbarer Kapazität API-Unterstützung für Resource Signed Checklists. Provider-Vorschläge für ASPA sind dort nicht aufgeführt.

Das beweist nur ihre Abwesenheit aus dieser veröffentlichten Quartalsliste. Es beweist keine Verspätung, Streichung oder Aufgabe. Ein nachträglich erfundener Termin würde aus berechtigter Beobachtung eine unbelegte Behauptung machen.

Der Jahresbericht 2025 liefert dagegen ein festes Datum: RIPE NCC startete die ASPA-Unterstützung im RPKI-Dashboard am 26. November 2025. Die Signiermöglichkeit kam also vor der im Folgeplan beschriebenen Evidenzhilfe. Als vorsichtiger Produktstart ist diese Reihenfolge nachvollziehbar. Für frühe Nutzer verlagert sie die gesamte Bestandsprüfung in den eigenen Betrieb.

Das stärkste Argument für das leere Feld

Keine Vorschläge zu machen kann institutionelle Zurückhaltung sein. RIPE NCC kennt nicht sämtliche Transitverträge, privaten Verbindungen, Notfallkonfigurationen und Route-Server-Modi. Derselbe Nachbar kann in einer Session Provider und in einer anderen Peer sein. Aus einem Pfad „Ihr Upstream“ zu machen würde mehr behaupten, als die Daten tragen.

Auch der Ort der Empfehlung zählt. Eine vorausgefüllte Liste direkt neben der Signatur wirkt, als habe das Register sie geprüft. Nutzer könnten sie aus Vertrauen in die Oberfläche gesammelt übernehmen. Ein ehrliches leeres Feld mit einer deutlichen Warnung ist sicherer als eine nicht erklärte Empfehlung.

Zurückhaltung muss aber nicht Blindheit bedeuten. Das Dashboard kann zeigen, was beobachtet wurde, offenlegen, was unbekannt ist, und eine Klassifikation verlangen.

Für jeden Kandidaten ein Evidenzbeleg

Eine nackte Liste „wahrscheinlicher Provider“ reicht nicht. Jeder ASN-Kandidat braucht eine kompakte Belegkarte.

Am Anfang steht die Herkunft: RIS, ein anderer öffentlicher Collector oder vom Betreiber bereitgestellte Telemetrie; die einbezogenen Beobachtungspunkte; Zeitpunkt des Snapshots und Analysefenster. Weiter gehören Adressfamilie, Position im Pfad, erstes und letztes Auftreten, Zahl der Beobachtungen und Verteilung über die Blickpunkte hinein.

Dann folgen die Ausnahmen. Ist der Kandidat dauerhaft sichtbar oder nur bei Ausfall und Wartung? Beschränkt er sich auf eine Region oder Adressfamilie? Gibt es Anzeichen für einen Route Server, und erscheint dieser transparent oder nicht transparent? Taucht ein nicht eingetragener Nachbar regelmäßig auf, oder ist ein vorhandener Provider lange nicht mehr beobachtet worden?

Die Grenze darf nicht im Kleingedruckten verschwinden. Eine beobachtete Adjazenz belegt weder Vertrag noch Providerrolle, Erlaubnis oder Vollständigkeit. Ein Konfidenzwert beschreibt die Stabilität der Beobachtung, nicht die Wahrheit der Geschäftsbeziehung. Auch die Version der Regel oder des Modells, das den Vorschlag erzeugt hat, muss sichtbar sein.

Der Betreiber benötigt mehr als „Übernehmen“. Er muss als Provider bestätigen, als Peer oder Kunde verwerfen, eine Mehrfachrolle markieren, eine zeitweilige oder Backup-Beziehung angeben oder die Prüfung zurückstellen können. Ein interner Verweis kann auf Vertrag oder Session-Liste zeigen, ohne vertrauliche Unterlagen im öffentlichen RPKI offenzulegen.

Bei der Signatur sollte der Dienst Ausgangsvorschlag, Einzelentscheidungen, Differenz zwischen altem und neuem Set, verantwortlichen Nutzer, Zeitpunkt und Hash des publizierten Objekts speichern. Eine spätere Korrektur verweist auf die vorige Fassung. Damit bleibt erkennbar, ob eine Auslassung beabsichtigt, vorläufig oder schlicht vergessen war.

Das öffentliche ASPA bleibt die Autorisierung. Der Beleg dokumentiert nur, wie unvollkommene Evidenz in diese Autorisierung überführt oder bewusst nicht überführt wurde.

Sichtbarkeit nach der Signatur beantwortet eine andere Frage

Ein am 29. Juni 2026 auf RIPE Labs veröffentlichter Community-Beitrag behandelt die fehlende Sicht auf die Wirkung eines ASPA im eigenen Routing. Die Autoren stellen RAVEN vor: ein Werkzeug, das BMP-Telemetrie mit über RTR v2 bereitgestellten RPKI-Daten verbindet, Routen annotiert und Was-wäre-wenn-Szenarien untersucht.

Der Beitrag ist ausdrücklich Community-Inhalt und kein Produktversprechen von RIPE NCC. Er zeigt dennoch zwei getrennte Kontrollpunkte. Vor der Signatur lautet die Frage, ob das Provider-Set die beabsichtigten Beziehungen abbildet. Danach lautet sie, wie reale empfangene Pfade mit diesem Objekt bewertet würden.

Eine Simulation kann ein mögliches Invalid-Ergebnis zeigen. Sie entscheidet nicht, ob das ASPA unvollständig, der Pfad falsch oder die Beobachtung lückenhaft ist. Sie zeigt Folgen, keine Beziehung. Ein reifer Ablauf stellt Inventar, Beobachtung und Wirkungstest nebeneinander, ohne ihre Aussagekraft zu vermengen.

Das vergessene Backup meldet sich im ungünstigsten Moment

Ein fehlender Hauptprovider fällt oft schnell auf. Ein Backup kann monatelang schweigen. Nach der Veröffentlichung geschieht zunächst nichts. Dann fällt eine Leitung aus, Wartung verschiebt den Verkehr oder ein Route Server ändert sein Verhalten. Der seltene Pfad wird genau dann gebraucht, wenn Redundanz zählen soll.

Die ausgewerteten Quellen belegen nicht, dass dies einem bestimmten RIPE-NCC-Mitglied passiert ist oder ein Router wegen eines bestehenden ASPA eine Route verworfen hat. Der Standard ist in Arbeit, und die Anwendung hängt von Software und lokaler Policy ab. Beschrieben wird ein Risikomechanismus, kein zugeschriebener Vorfall.

Ein datierter Beleg verlagert die Entdeckung nach vorn. Er erinnert vor der Signatur an den stillen Provider und hält fest, warum der Betreiber ihn aufgenommen oder ausgeschlossen hat. Dafür muss das System niemals so tun, als bedeute „in BGP gesehen“ bereits „als Provider autorisiert“.

RIPE NCC kann die im Plan skizzierte Brücke fertigstellen, ohne seine Macht auszuweiten. Es kann zeigen, wen es wann und von wo gesehen hat, seine Wissenslücken benennen, die Einordnung dem Inhaber überlassen und den signierten Unterschied bewahren. Das Register sieht Pfade. Der Betreiber kennt die Vereinbarung. Vertrauenswürdig wird ein ASPA, wenn diese Distanz erkennbar bleibt.

Quellen