Zusammenfassung

  • ASPA signiert autorisierte vorgelagerte Netzanbieter und ergänzt Origin-Validierung um Pfadevidenz.
  • Veröffentlichung, Validierung, Klassifizierung und Filterung sind getrennte Zustände.
  • Bei Teilabdeckung ist Unknown notwendige Unsicherheit, nicht gleichbedeutend mit Valid.

Ein korrektes Objekt, eine weiter akzeptierte Route

Das neue ASPA erscheint im RPKI-Dashboard. Danach wird derselbe absichtlich ungültige Kundenpfad am Produktionsrand angekündigt. Er bleibt installiert, weil die produktive Import-Richtlinie das ASPA-Ergebnis des Validators nicht verarbeitet. Das Objekt hat seine Aufgabe erfüllt; der Test isoliert die fehlende Richtlinienaktion.

APNIC beschreibt ASPA als signierte Liste autorisierter vorgelagerter Netzanbieter eines ASN-Inhabers. Eine ROA autorisiert den Ursprung eines Präfixes, nicht den gesamten AS_PATH. Deshalb unterscheidet der IETF-Entwurf den Empfang von Kunden, Peering-Partnern, vorgelagerten Netzanbietern, Route-Server-Kunden und verbundenen AS derselben Organisation.

Fehlende ASPA-Daten erzeugen während schrittweiser Einführung häufig Unknown. RIPE empfiehlt, diesen Zustand anzunehmen, damit unvollständige Abdeckung keine Störung auslöst. Invalid braucht einen nachweisbaren Widerspruch. Alle akzeptierten Routen als validiert zu melden, würde die Lücke verbergen.

ASPA verhindert zudem nicht jeden lokal ausgelösten Leak; der IETF-Entwurf empfiehlt OTC als Ergänzung. Das kryptografische Ergebnis beweist weder Paketweiterleitung noch Kapazität oder Geschäftsbeziehungen.