Zusammenfassung

  • Nach Darstellung der Number Resource Society bindet eine ROA ein Präfix an die autorisierte Origin-ASN, kann spezifischere Ankündigungen mit maxLength begrenzen und sollte in einem kontrollierten Verfahren geändert werden.
  • Valid, Invalid oder NotFound ist die Beobachtung eines Validators. Sie belegt allein weder Antrag und Freigabe noch die beabsichtigten Werte oder den Abschluss der Rücknahme.
  • Ein versioniertes Autorisierungs- und Rücknahmebuch kann menschliche Entscheidungen mit RIR-Veröffentlichung, Validator-Beobachtungen und Routing-Bestätigungen verbinden, ohne einen technischen Zustand zur Absichtserklärung zu machen.

Valid ist noch keine Entscheidungshistorie

Der RPKI-Leitfaden der Number Resource Society beschreibt die Grundfunktion: Die Resource Public Key Infrastructure bindet Internetnummernressourcen kryptografisch an ihre legitimen Inhaber. Eine Route Origin Authorization benennt das autonome System, das ein Präfix originieren darf. Das optionale maxLength legt fest, bis zu welcher Länge spezifischere Ankündigungen zulässig sind. Ein RIR kann Zertifizierung und Veröffentlichung hosten; im delegierten Modell betreibt der Ressourceninhaber seine eigene Zertifizierungsstelle.

Damit lässt sich prüfen, ob ein beobachteter Ursprung zu einer veröffentlichten Autorisierung passt. Die Entscheidungsfolge dahinter entsteht jedoch nicht automatisch. Ein aktuelles Ergebnis verrät nicht, wer eine neue Origin-ASN beantragt, wer ein größeres maxLength freigegeben, welches Änderungsfenster gegolten oder welche Evidenz einen Notfall-Rollback ausgelöst hat.

Der NRS-Auditbeitrag empfiehlt, Existenz der ROA, Origin-ASN, Präfix, Angemessenheit von maxLength sowie Valid, Invalid oder NotFound zu prüfen. Ebenso wichtig ist die Frage, wer ROAs anlegen, ändern oder entfernen darf. Ein zu großzügiges maxLength kann unnötige spezifischere Routen autorisieren; ein zu enges kann legitime Ankündigungen Invalid machen.

Das sind Fakten aus dem eingefrorenen Quellensatz. Das hier vorgeschlagene Buch ist eine redaktionelle Schlussfolgerung. Es behauptet weder, dass NRS es bereits nutzt, noch dass eine reale ROA fehlerhaft ist.

Die Änderung als genaue Version freigeben

Kontrolliert werden sollte die Änderung selbst, nicht bloß der Endstatus. Sie erhält eine feste ID und dokumentiert Präfix, Origin-ASN und maxLength vor und nach dem Eingriff. Hinzu kommen verantwortlicher Ressourceninhaber, Antragsteller, Genehmiger, Zeitpunkt, Fenster und Begründung. Verkürzt ein Notfallverfahren den normalen Weg, müssen Regel und verantwortliche Person benannt werden.

Befugnis und Ausführung bleiben getrennt. Der Antragsteller darf möglicherweise nicht genehmigen; der Genehmiger bedient vielleicht nicht das RIR-Portal; der Routing-Operator kann BGP umstellen, ohne ROAs bearbeiten zu dürfen. Ein sauberer Endzustand ersetzt diese Rollentrennung nicht.

Auch die Grenzen gehören in die Freigabe. Eine Erlaubnis für ein Präfix umfasst nicht stillschweigend ein zweites. Die Änderung der Origin-ASN erlaubt nicht automatisch die Erweiterung von maxLength. Eine zeitlich begrenzte Migrationsbefugnis darf nach Abschaltung des alten Pfads nicht weiterleben.

Ein Hash des freigegebenen Änderungsobjekts kann die Entscheidung an die später eingereichten Werte binden. Er beweist weder die Qualität noch die Rechtswirkung der Entscheidung. Er belegt nur, dass sich das beobachtete Objekt mit der vom Genehmiger gesehenen Version vergleichen lässt.

Veröffentlichung, Validierung und Aktivierung getrennt beobachten

Nach der Freigabe vermerkt das Buch den Veröffentlichungsvorgang und einen autoritativen RIR-Nachweis mit Beobachtungszeit. NRS empfiehlt, datierte RIR-Datensätze als Auditbelege aufzubewahren. Das ist stärker als die Erinnerung an eine grüne Anzeige, beschreibt aber eine Beobachtung und nicht die Begründung der Autorisierung.

Unabhängige Validator-Sichten werden separat mit Zeit, Standort und Software oder Dienst gespeichert. Repositorys, Caches und Aktualisierungszyklen können vorübergehend unterschiedliche Ergebnisse liefern. Eine Abweichung ist zu untersuchen; sie beweist nicht automatisch einen Publikationsfehler oder ein Fehlverhalten.

Sinnvolle Zustände sind beantragt, genehmigt, eingereicht, Veröffentlichung beobachtet, Validierung beobachtet, Route aktiviert, Rücknahme beantragt, Rücknahme beobachtet, zurückgerollt und ersetzt. Jeder Übergang bekommt eine eigene Zeit und einen Akteur oder Beobachter.

NotFound zeigt die notwendige Vorsicht: In der Sicht des Validators wurde keine deckende ROA gefunden. Ob das beabsichtigt, verspätet, fehlerhaft oder außerhalb des Änderungsumfangs ist, bleibt offen. Valid bestätigt eine Übereinstimmung in dieser Sicht, nicht die fortbestehende geschäftliche Befugnis der Person, die die Änderung angestoßen hat.

Eine Migration braucht eine geordnete Rücknahme

Laut NRS sollte bei einer Migration die neue Autorisierung normalerweise eingerichtet und validiert werden, bevor die alte Route zurückgezogen oder die alte ROA entfernt wird. Das Buch macht aus dieser Reihenfolge überprüfbare Evidenz.

Vor Beginn definiert es die Voraussetzung: Welche neue ROA muss von welchen Validatoren gesehen werden, und welcher Routentest muss bestehen? Danach benennt es, wer den neuen Ursprung aktiviert, die alte Route zurückzieht, die alte ROA verengt oder entfernt und jeden Schritt bestätigt.

Rücknahme ist keine Löschung der Vergangenheit. Die frühere Autorisierung bleibt erhalten; ein Endereignis erklärt den Grund und verweist auf Ersatz oder Rollback. Wird eine Änderung rückgängig gemacht, bleibt erkennbar, dass die erste Veröffentlichung damals genehmigt war, wann der Auslöser eintrat und welcher Zustand wiederhergestellt wurde.

Der Rollback muss vor Öffnung des Fensters entworfen werden. Messbare Auslöser sind unerwartetes Invalid, fehlende Verbreitung nach der Frist, Erreichbarkeitsverlust, Abweichungen zwischen genehmigten und beobachteten Werten oder ein nicht bestätigbarer Operator. „Zurücksetzen“ ist kein Ablaufplan, wenn RPKI-Veröffentlichung und BGP-Rückzug auf verschiedenen Zeitskalen laufen.

Fakten, Folgerungen und Unbekanntes trennen

Die NRS-Quellen belegen ROA-Mechanik, maxLength, Validierungszustände, kontrollierte Änderung, Auditfragen und Migrationsreihenfolge. Sie benennen keinen nachlässigen Betreiber, kein kompromittiertes Konto, keine strittige Route und keinen gescheiterten RIR-Prozess.

Die vorgeschlagenen Felder sind eine Governance-Empfehlung. Es ist plausibel, dass die Verbindung von Freigabe, Publikation, Validierung und Rücknahme eine Änderung rekonstruierbarer macht. Es wäre nicht zulässig, aus einer fehlenden öffentlichen Beschreibung auf fehlende interne Kontrollen bei NRS oder einer anderen Organisation zu schließen.

Im konkreten Fall bleiben der tatsächliche Befugnisinhaber, die verwendete Plattform, Aktualisierungszeiten, Reichweite der Routing-Aktion und rechtliche oder vertragliche Wirkung unbekannt. Das Buch sollte diese Lücken festhalten. Die kryptografische Autorisierung wird so von menschlicher Verantwortlichkeit und einem sicheren Ausstieg begleitet.

Quellen