Zusammenfassung

  • Ein ASPA ist eine signierte Behauptung des Kunden-AS über alle Provider; eine überzählige Eintragung erweitert die akzeptierbaren Pfade, eine fehlende kann legitime Pfade als Invalid erscheinen lassen.
  • Revision 28 behandelt Unknown auf derselben Präferenzstufe wie Valid, macht Invalid nicht auswählbar und behält es zur Neubewertung; keine dieser Regeln beweist Auswahl, FIB-Installation oder Zustellung.

Der grüne Haken prüft nicht die Liste gegen den Vertrag

Ein Relying Party kann Signatur, Zertifikatskette, Manifest und Widerruf korrekt prüfen. Der ASPA-Inhalt ist dann kryptografisch gültig. Ob die Providerliste mit den heutigen Verträgen und Sitzungen übereinstimmt, ist eine andere Kontrolle.

Bleibt ein früherer Provider versehentlich eingetragen, kann die Verifikation Pfade akzeptieren, deren Kunden-Provider-Hop betrieblich nicht mehr gelten sollte. Fehlt ein neuer Provider, entsteht Not Provider+; ein legitimer Failover kann Invalid werden. Die Spezifikation verlangt deshalb korrekte, aktuelle Objekte und empfiehlt, Standby-Provider vor ihrer Nutzung einzutragen.

Revision 28 wurde am 24. August 2026 veröffentlicht und läuft am 25. Februar 2027 ab. Datatracker führt sie als aktiven SIDROPS-Arbeitsgruppenentwurf mit WG Consensus: Waiting for Write-Up und IESG-Status I-D Exists. Das ist kein RFC und kein Nachweis weltweiter Einführung.

Die signierte Aussage ist absichtlich schmal

Der Inhaber des Kunden-ASN listet alle Provider-ASN auf, einschließlich nichttransparenter Route-Server, die im AS_PATH erscheinen. Die RPKI-Kette belegt die Ressourcenbefugnis des Unterzeichners und die Integrität des Objekts. Sie belegt weder eine aktive Session noch Vertragsbedingungen oder Verkehrsfluss.

Ein Objekt pro Kunde ist vorgesehen. Existieren mehrere gültige Objekte, bildet die Verifikation die Vereinigung. Das verhindert, dass ein Teilobjekt während eines Updates einen Provider verschwinden lässt. Gleichzeitig bleibt jede zusätzliche Eintragung wirksam, bis sie aus allen gültigen Objekten entfernt ist.

Ein AS0-ASPA erklärt, dass kein Transit-Provider und keine Kundschaft bei einem nichttransparenten RS besteht. Es ist keine Aussage über Erreichbarkeit oder darüber, ob das AS überhaupt Präfixe ankündigt.

Drei Werte erhalten die Unsicherheit

Für (x, y) liefert die Funktion Provider+, wenn y in der gültigen Providervereinigung von x steht. Not Provider+ bedeutet: Es gibt eine gültige, als vollständig gedachte Liste, aber y fehlt. No Attestation bedeutet: Kein brauchbares ASPA wurde gefunden.

Die Unterscheidung verhindert, dass fehlende Einführung als negative Aussage behandelt wird. Nach Rekonstruktion und Kompression des AS_PATH berechnet der Algorithmus minimale und maximale Kunden-Provider-Rampen.

Kann selbst das Maximum den Pfad nicht abdecken, ist er Invalid. Reicht das Maximum, während fehlende Attestierungen das Minimum stoppen, ist er Unknown. Deckt das Minimum den Pfad, ist er Valid.

Der Status gilt für einen Datenstand, einen Pfad und eine lokal gewählte Richtung. Er beweist nicht, dass das UPDATE tatsächlich über jede angegebene Verbindung lief.

Die lokale Rolle steuert die Prüfung

Von Kunden oder Peers gelernte Routen nutzen die Upstream-Prüfung; von Providern gelernte die Downstream-Prüfung. BGP Roles nach RFC 9234 können die Rollen in OPEN abgleichen. Die Eingabe bleibt dennoch lokale Konfiguration.

Bei Complex-Beziehungen können getrennte Sessions oder eine Präfix-spezifische Auswahl nötig sein. Wo beides fehlt, darf der permissivere Downstream-Algorithmus eingesetzt werden, um falsche Positive zu vermeiden. Das ist eine Kontinuitätsentscheidung, keine Vereinfachung der realen Beziehung.

AS_SET-Fehlerbehandlung und Nachbar-ASN-Abgleich liegen vor ASPA. Ein Ursachenlog muss diese Fälle von einer Providerlisten-Widerspruch trennen.

Unknown erhält Behandlung, nicht Herkunft

Unknown soll dieselbe Präferenzstufe wie Valid erhalten. So werden Netze ohne vollständige ASPA-Abdeckung nicht automatisch benachteiligt. Aus fehlenden Daten wird dadurch keine positive Autorisierung.

Invalid soll für die Auswahl unzulässig sein, aber im Adj-RIB-In bleiben. Ein korrigiertes ASPA kann über Repository, Validator und Cache eintreffen, ohne dass der Nachbar ein neues UPDATE sendet. Die gespeicherte Route ermöglicht eine sofortige Neubewertung.

Danach folgen weiterhin BGP-Auswahl, Loc-RIB, FIB-Programmierung und Paketübertragung. Valid kann verlieren, eine gewählte Route kann nicht installiert werden, und eine installierte Route kann keinen Dienst liefern.

Ein Fehlerpaar ist kein Schuldiger

Für Invalid sollten die Not Provider+-Paare protokolliert werden. Der protokollierende Router kann daraus aber nicht immer das verursachende AS bestimmen. Veraltete Objekte, ASN-Migrationen oder eine frühere Pfadmanipulation können den sichtbaren Bruch verschieben.

Provider können manche Kundepfade so manipulieren, dass ASPA sie nicht erkennt. Hinzufügen oder Entfernen wiederholter ASNs bleibt ebenfalls unsichtbar. ROA, BGPsec und OTC beantworten Herkunfts-, Weitergabe- und Propagationsfragen, die ASPA nicht übernimmt.

Zudem gilt die U-SPAS-Vereinigung zugleich für IPv4 und IPv6. Eine Beziehung in nur einer Familie macht die andere Prüfung permissiver. Die Spezifikation wählt Einfachheit und weniger falsche Invalids; der Betreiber muss die Adressfamilienrealität separat belegen.

Von der Liste bis zum Paket

Eine belastbare Spur enthält Objektinhalt und Hash, Zertifikats- und Repository-Stand, Validatorversion, Importzeit am Router, lokale Rolle, rohen und rekonstruierten AS_PATH, jede Paarantwort, Rampengrenzen, Endstatus und Richtlinienaktion. Danach folgen Loc-RIB, FIB und Verkehrsmessung.

Lu Hengs Running-Code-Prinzip setzt hier eine klare Grenze. Die signierte Koordinationsaussage ist für ihren Inhalt maßgeblich. Was der Router tat, belegt nur dessen laufender Zustand. Was Nutzer erfuhren, belegt nur Beobachtung. Kein grüner Haken darf die anderen Belege ersetzen.

Was die Quellen nicht belegen

Die eingefrorenen Quellen belegen Entwurfsregeln und genannte Einschränkungen. Sie belegen weder Softwarekonformität noch die Aktualität eines realen Providervertrags, eine verhinderte Route Leak oder messbare Wirksamkeit. Das Eingangsbeispiel ist eine Mechanismenanalyse ohne behaupteten Vorfall.

Quellen