Zusammenfassung

  • Eine ASPA ist ein signiertes RPKI-Objekt, in dem ein Kunden-AS eine Menge von Provider-AS autorisiert. Sie belegt eine Beziehung für einen Algorithmus, nicht jeden Hop des Pfads.
  • Die Prüfung liefert je nach verfügbaren Objekten und Ausbreitungskontext Valid, Invalid oder Unknown. Sie ersetzt weder Ursprungsvalidierung noch reale Identität oder lokale Policy.
  • Ein belastbares Register trennt Objektgültigkeit, Vollständigkeit, Cache-Zeit, Sitzungsrolle, Ergebnis, lokale Aktion und Unsicherheit.

„Valid“ klingt nach einem vollständigen Urteil. Bei ASPA bedeutet es enger, dass der beobachtete Pfad mit den Kunden-Provider-Autorisierungen vereinbar ist, die der Algorithmus in der maßgeblichen Richtung prüfen kann. Das ist nützlich, aber keine signierte Lebensgeschichte der Route.

Das aktuelle ASPA-Profil ist noch ein Internet-Draft. Es definiert ein signiertes RPKI-Objekt, in dem der Inhaber des Kunden-AS seine autorisierten Provider aufführt. Das Profil erwartet alle Provider in einem Objekt pro Kunden-AS. Eine Relying Party validiert es, bevor sie den Inhalt nutzt.

Die Frage lautet also: Hat der Kunde diesen Provider in den veröffentlichten Daten autorisiert? Das Objekt enthält kein angekündigtes Präfix. ROAs und Route Origin Validation behandeln diese andere Dimension; beide Kontrollen ergänzen einander.

Die Signatur authentifiziert auch keine reale Organisation. RFC 9255 grenzt RPKI als Ressourcenautorisierung, nicht als Identitätsnachweis ab. Ein gültiges Objekt beweist weder einen aktuellen Vertrag noch eine korrekte Eingabe oder gegenwärtigen Verkehr auf einer Verbindung.

Vollständigkeit ist die nächste Grenze. Der Verifikationsentwurf erwartet alle Provider und einschlägigen nicht transparenten Route Server. Fehlt ein legitimer Provider, kann eine echte Route mit wachsender Abdeckung Invalid werden. Die Kryptografie kann korrekt und die gepflegte Erklärung trotzdem unvollständig sein.

Der Algorithmus unterscheidet Provider+, Not Provider+ und No Attestation sowie Valid, Invalid und Unknown für den Pfad. Unknown ist kein schwaches Invalid, sondern fehlende Evidenz für ein Urteil. Valid beweist umgekehrt weder den Ursprung noch die Signatur jedes AS oder die Einhaltung jeder Exportregel.

ASPA und BGPsec besitzen unterschiedliche Evidenzsemantik. ASPA vergleicht den Pfad mit getrennt veröffentlichten Provider-Autorisierungen; es signiert nicht Hop für Hop. Auch die Reihenfolge zählt. RFC 9774 stuft AS_SET und AS_CONFED_SET als veraltet ein, weil ungeordnete Mengen die Kunden-Provider-Richtung nicht erhalten.

Die BGP Roles aus RFC 9234 liefern Sitzungskontext für Route-Leak-Prävention. Eine ausgehandelte Fähigkeit ist jedoch kein universelles Vertragsregister. Der empfangende Betreiber entscheidet weiterhin, wie Ergebnis, Erreichbarkeit, Abdeckung und Ausnahmen zusammenwirken.

Ein revisionssicheres Register trennt sechs Ebenen: validiertes ASPA-Objekt; Nachweis der Inventarvollständigkeit; Cache-Beobachtung und Zeit; geordneter Pfad und Rolle; begründetes Ergebnis; lokale Maßnahme mit Verantwortlichem und Ablauf. Providerzugang am Freitag, Objektänderung am Samstag und Cache-Aktualisierung am Sonntag sind verschiedene Zustände.

Die zitierten Entwürfe können sich vor ihrer Veröffentlichung als RFC noch ändern; ein realer Vorfall wird nicht behauptet. Die dauerhafte Regel lautet: ASPA ist eine begrenzte Provider-Autorisierung. Gültigkeit, Vollständigkeit und Verwendung bleiben getrennte Evidenz.

Quellen