Zusammenfassung

  • ARIN führt für jede Customer ASN ein eigenes ASPA und lässt den Halter dessen Satz von Provider ASes ändern. Auch eine einzelne Ergänzung ersetzt damit eine vollständige Aussage.
  • ARIN trennt die sofortige Wirkung in seiner RPKI-Datenbank, das Erscheinen im öffentlichen Repository innerhalb von 24 Stunden, Repository-Aktualisierungen alle paar Minuten und die Prüfung mit einem Validator. Das sind verschiedene Zustände.
  • Die aktiven IETF-Entwürfe verlangen die Vereinigung aller Provider einschließlich nichttransparenter Route Server und unterscheiden No Attestation von Not Provider+. Ein fehlender Provider kann relevant sein, ohne jede betroffene Route automatisch ungültig zu machen.
  • Ein datensparsamer Differenzbeleg sollte den autorisierten Vorzustand, den vollständigen Nachzustand, das atomare Transaktionsergebnis, das veröffentlichte Objekt und eine unabhängige Validator-Beobachtung binden.

Kleine Netzänderungen haben kurze Namen. Ein neuer Upstream. Ein alter Vertrag. Ein zusätzlicher Route Server. Ein Notfallpfad. Diese Kürze hilft der Einsatzplanung, beschreibt jedoch nicht die Bedeutung eines ASPA-Updates. Der Relying Party wird kein einzelner Arbeitsauftrag vorgelegt. Sie erhält eine signierte Menge von Providern für eine Customer ASN.

Daraus entsteht ein klassischer Zustandskonflikt. Ein Ingenieur liest {A, B} und bereitet {A, B, C} vor. Bevor er sendet, ergänzt eine Automatisierung den nichttransparenten Route Server R; der aktuelle Zustand lautet nun {A, B, R}. Die spätere Einreichung des Ingenieurs entfernt R. Beide Requests können formal korrekt und erfolgreich sein. Der zweite beruhte lediglich auf einem veralteten Vorzustand.

ARINs Dokumentation macht die Mengenstruktur sichtbar. Hält eine Organisation mehrere ASNs, muss für jede Customer ASN ein eigenes ASPA-Objekt angelegt werden. In ARIN Online wird der „Set of Provider ASes“ geändert. Die RPKI-REST-API beschreibt aspaDelete und aspaAdd mit customerAsId und providerAsIds. ASPA- und ROA-Operationen können in derselben Transaktion liegen, in der alles gelingt oder alles scheitert.

Atomarität ist wichtig. Sie verhindert, dass nur ein Teil eines eingereichten Pakets Registerzustand wird. Sie erkennt aber nicht automatisch ein insgesamt veraltetes Paket. Ein positives Ergebnis belegt ARINs Annahme dieses Pakets als Einheit. Es belegt weder, dass der Autor die jüngste Menge gesehen hatte, noch die Sichtbarkeit des neuen Objekts im öffentlichen Repository oder seine Verarbeitung durch eine Relying Party.

Die Oberfläche zeigt Zeilen, das signierte Objekt einen Zustand

Mengen als Listen darzustellen ist vernünftig. Eine Zeile wird ergänzt, eine andere entfernt, anschließend erscheint die Bestätigung. Der Nutzer denkt in Differenzen. Das kryptografische Ergebnis enthält dagegen den Zustand nach dem Edit, nicht die Folge der Klicks.

Der ASPA-Profile-Entwurf in Version 29 fordert alle Provider ASes einschließlich der ASNs nichttransparenter Route Server. Gibt es mehrere gültige ASPAs für denselben Kunden, bildet die Relying Party ihre Vereinigung. Zugleich empfiehlt der Entwurf, mehrere Objekte zu vermeiden, weil unterschiedliche Gültigkeitsintervalle Rennen erzeugen können. Der Verification-Entwurf in Version 28 empfiehlt ebenfalls ein einziges ASPA mit der vollständigen Vereinigung.

Beide Texte sind aktive Internet-Drafts und keine endgültigen RFCs. Ihre Formulierungen können sich ändern. Diese Einordnung darf nicht verloren gehen. Dennoch definieren sie die derzeit relevante semantische Einheit: die vollständige Menge. Ein ausgelassenes Mitglied ist keine fehlende Randnotiz, sondern verändert die signierte Aussage.

Ein sicherer Schreibvorgang braucht deshalb die kanonische Prüfsumme des gelesenen Vorzustands. Der Request sagt dann: „Ersetze den Zustand mit Hash H durch die vollständige Menge S.“ Ist H nicht mehr aktuell, meldet ARIN einen Konflikt und liefert den neuen Zustand. ARIN entscheidet nicht, ob C oder R die wahre Geschäftsbeziehung ist. Es verhindert nur, dass eine Abweichung still in einem grünen Ergebnis verschwindet.

Compare-and-set erzeugt Reibung nur dann, wenn tatsächlich zwei Entscheidungen kollidieren. Genau dann ist sie produktiv. Nach einem Vorfall muss der frühere Satz sonst aus Browseransichten, API-Logs, alten Repository-Objekten und Validator-Caches rekonstruiert werden, die nicht für eine gemeinsame Beweiskette gebaut wurden.

Keine Aussage ist etwas anderes als eine negative Menge

Der Verification-Entwurf unterscheidet die Autorisierungsergebnisse. Ohne nutzbaren ASPA-Eintrag lautet der Zustand No Attestation. Befindet sich der Provider in der nutzbaren Menge, lautet er Provider+. Existiert eine nutzbare Menge, aber der Provider fehlt, lautet er Not Provider+.

Ein ASPA zu löschen ist daher nicht dasselbe wie ein nichtleeres ASPA zu publizieren, das einen Provider auslässt. Im ersten Fall gibt es keine nutzbare Aussage. Im zweiten existiert eine Aussage, die dieses Kunden-Provider-Paar nicht bestätigt. Ein Protokoll mit der bloßen Zeile „Änderung erfolgreich“ kann diese Grenze nicht wiederherstellen.

Not Provider+ darf allerdings nicht zur Behauptung verkürzt werden, jede betreffende Route sei automatisch ungültig. Die vollständige AS-Pfadprüfung berücksichtigt Richtung, Segmente und verfügbare Autorisierungen. Der Entwurf warnt, dass ein fehlender Provider später zu einer fälschlich als ASPA Invalid bewerteten Route beitragen kann. Das beschreibt einen Mechanismus, keinen nachgewiesenen ARIN-Vorfall.

Standby-Verbindungen verschärfen die Zeitfrage. Der Entwurf empfiehlt, Standby- oder Notfallprovider im Voraus einzutragen. Wird die Autorisierung erst während einer Störung ergänzt, werden ARINs Annahme, Repository-Veröffentlichung und Validator-Refresh Teil der Wiederherstellungszeit. Gerade die im Normalbetrieb stille Beziehung wird bei einer nur am aktuellen Traffic orientierten Prüfung leicht vergessen.

Auch ein nichttransparenter Route Server kann außerhalb der gewohnten Einkaufskategorie „Transit“ liegen. Semantisch gehört seine ASN dennoch in die Menge. Ein vollständiger Satz mit einer geschützten Rollenannotation hilft beim Review, ohne dass ARIN aus der Topologie Geschäftsbeziehungen erraten muss.

Vier Uhren hinter einer grünen Bestätigung

Die erste Uhr gehört der Autorisierung. Sie hält fest, welchen Zustand eine befugte Person oder Automatisierung sah und welchen vollständigen Nachzustand sie freigab. Öffentlich muss kein Mitarbeitername erscheinen; Rollenklasse, Zustands-Hash und Zeitpunkt genügen, während die interne Genehmigung geschützt bleibt.

Die zweite Uhr gehört der Transaktion. ARIN empfängt, authentifiziert, prüft und nimmt atomar an oder lehnt ab. Teilen ASPA und ROA eine Transaktion, bindet eine gemeinsame Kennung das Alles-oder-nichts-Ergebnis. Nicht benötigte Präfixdetails müssen dadurch nicht öffentlich werden.

Die dritte Uhr misst die Veröffentlichung. ARIN schreibt, eine Änderung wirke sofort in der RPKI-Datenbank und erscheine innerhalb von 24 Stunden im öffentlichen Repository. Dieselbe Seite nennt Aktualisierungen alle paar Minuten. Die 24 Stunden sind keine typische Laufzeitmessung. Benötigt werden der Hash des ausgestellten Objekts, ein Repository- oder Manifest-Verweis und die erste tatsächliche Beobachtung.

Die vierte Uhr gehört dem Konsum. Ein Validator lädt das Material, validiert die Kette und konstruiert den nutzbaren Providersatz. Das Ergebnis ist an einen Messpunkt, eine Softwareversion und einen Zeitpunkt gebunden. Es beweist diese eine Sicht, nicht die gleichzeitige Konvergenz aller Relying Parties.

Wer vier Uhren in „zuletzt aktualisiert“ zusammenzieht, verliert die Diagnose. Die Absicht kann unvollständig gewesen sein, ein Request kann kollidiert haben, das Objekt kann noch unbeobachtet sein oder der gewählte Validator kann alten Stand nutzen. Jede Ursache verlangt einen anderen Eigentümer und eine andere Maßnahme.

Der Mindestinhalt des Differenzbelegs

Der Beleg beginnt mit Customer ASN und Zertifikats- oder CA-Kontext. Er speichert den kanonisch sortierten Vorzustand oder dessen Hash samt abrufbarem Verweis auf das frühere Objekt. Danach folgt die vollständige eingereichte Menge. Hinzugefügte, entfernte und unveränderte ASNs werden aus beiden Zuständen berechnet.

Die vollständigen Mengen sind die Primärbelege; die Differenz erläutert sie. „C hinzugefügt“ beweist nicht, dass B blieb. „A entfernt“ zeigt nicht, ob der Nachzustand leer oder {B, C} ist. Mit Vorher und Nachher kann ein unabhängiges System den Diff erneut berechnen.

Der Request-Teil enthält Kennung, authentifizierte Akteursklasse, Payload-Hash, Vorzustandsbedingung, Annahmezeit und Ergebnis. Ein Zustandskonflikt benötigt einen klaren eigenen Status. Bei einer gemischten ROA-Transaktion genügt öffentlich der Verweis auf ihre Verbindung und Atomarität.

Der Veröffentlichungsteil nennt den Hash des ausgestellten ASPA-Objekts, Repository oder Manifest und den ersten öffentlichen Beobachtungszeitpunkt. Der Validator-Teil nennt Messpunkt, Software und Version, Abrufzeit, beobachtete nutzbare Menge sowie die geprüften Übergänge zwischen No Attestation, Provider+ und Not Provider+.

Auch der Beleg braucht eine Historie: ersetzt durch, korrigiert durch, abgelaufen, zurückgesetzt auf. Ein Rollback ist eine neue Entscheidung über die vollständige Menge. Er darf das Zeitfenster des falschen Zustands nicht aus der Geschichte löschen, denn nur damit lassen sich Warnungen und Messungen zuordnen.

Rollen wie normaler Transit, nichttransparenter Route Server oder Notfallprovider können in einer zugriffsbeschränkten Ebene liegen. Sie helfen dem menschlichen Review, müssen aber weder Teil des signierten ASPA noch der öffentlichen Darstellung sein.

Datensparsamkeit ist kein Gedächtnisverlust

Provider-ASNs eines ASPA sind für den öffentlichen RPKI-Konsum bestimmt. Daraus folgt nicht, dass Preise, Traffic-Volumen, Ansprechpartner, Wartungsfenster, Zugangsdaten oder interne Topologie öffentlich werden. Der öffentliche Beleg kann sich auf Mengen, Hashes, Zeiten, grobe Rollen und Beobachtungen beschränken.

Ebenso präzise sollte die Validator-Aussage sein. „Monitor X sah mit Version Y zum Zeitpunkt Z die Menge S“ ist reproduzierbar. „Das Internet ist konvergiert“ überschreitet den Beleg. Mehrere unabhängige Messpunkte erhöhen Vertrauen, ohne zu einer allwissenden Perspektive zu werden.

Im März 2026 meldete ARIN, ASPA sei in ARIN Online vollständig verfügbar. Verfügbarkeit misst weder Nutzung noch Fehlerfreiheit. Bei ARIN 57 trennte John Curran die Rolle des Registers, ASPA bereitzustellen und zu erklären, von der Entscheidung der Betreiber, es einzusetzen.

Der vorgeschlagene Beleg wahrt diese Grenze. ARIN wählt keinen Provider aus und leitet keine Beziehung aus BGP ab. Es bewahrt die authentifizierte Entscheidung, erkennt veralteten Zustand, veröffentlicht das Objekt und zeigt, wo es beobachtet wurde.

Die Quellen belegen nicht, dass ARIN eine reale Providermenge verloren, umsortiert, verzögert oder falsch veröffentlicht hat. Es wird keine konkrete Route als ASPA Invalid bezeichnet. Die Kontrolle ist präventiv: Den Vorzustand während des Edits zu sichern ist billig; ihn nach dem Ablauf von Sessions und Caches zu rekonstruieren kann unmöglich sein.

Im Ticket ändert sich ein Provider. In der Signatur ändert sich die ganze Menge. Ein guter Differenzbeleg lässt die erste Wahrheit die zweite nicht verdecken.

Quellen