Zusammenfassung

  • LACNIC erklärte am 20. Juli, FORT 1.7.0 validiere ASPA-Objekte und teile die Daten mit Routern; zugleich nennt der Beitrag die Funktion experimentell, weil ASPA noch nicht offiziell als Standard veröffentlicht sei.
  • Das Release 1.7.0.experimental setzt --server.max-rtr-version standardmäßig auf 0, obwohl laut markierter Anleitung erst RTRv2 ASPAs an Router liefert. Auch --output.aspa ist zunächst deaktiviert.
  • Ein belastbarer Aktivierungsnachweis trennt Softwarestand, Konfiguration, ausgehandelte Version, akzeptierte Objekte, berechneten Pfadstatus und angewandte Routingpolitik.

Das neue Merkmal wurde eingebaut, aber nicht zum voreingestellten Router-Verhalten gemacht.

Der LACNIC-Beitrag beschreibt FORT 1.7.0 als Validator für ASPA-Objekte, die bereits in einigen RPKI-Repositories liegen, und als Quelle für Router-Entscheidungen. Das vier Tage zuvor veröffentlichte Projekt-Release heißt vollständig 1.7.0.experimental. Es implementiert ASPA und RTRv2, belässt die maximal angebotene RTR-Version jedoch bei null.

Die eine Aussage betrifft Möglichkeit, die andere Ausgangszustand. Keine von beiden sagt, wie ein bestimmtes Netz konfiguriert ist.

LACNIC verschweigt den Entwurfsstatus nicht. Der Beitrag weist ausdrücklich auf mögliche Änderungen hin. Das Projekt begründet die Vorsicht: FORT liefert derzeit keine Router Keys, sodass RTRv1 für dieses Produkt keinen zusätzlichen Nutzinhalt bringt; RTRv2 wird weiterhin überarbeitet. Die Kontrollfrage lautet nicht, ob null richtig oder falsch ist, sondern ob der Übergang zur wirksamen Route nachvollziehbar bleibt.

Drei getrennte Stellflächen

Die Dokumentation des konkreten Tags nennt drei relevante Einstellungen.

Einstellung Vorgabe Gesteuerter Zustand
--aspa.max-providers 4.000 Anbieter-ASNs je Kunden-ASN und Validierungszyklus
--output.aspa NULL (deaktiviert) JSON-Ausgabe gültiger ASPAs
--server.max-rtr-version 0 Höchste mit Router-Clients aushandelbare RPKI-to-Router-Version

Eine Validierungsgrenze öffnet keine Datei. Eine Datei öffnet keine Router-Sitzung. Eine v2-Sitzung legt noch keine Routenentscheidung fest.

Nach der Anleitung transportiert RTRv0 Präfix-VRPs, RTRv1 zusätzlich Router Keys und RTRv2 zusätzlich ASPAs. Bei Vorgabewerten kann FORT ein ASPA intern validieren und nach gesonderter Konfiguration ausgeben. Eine Sitzung in Version 0 trägt aber keinen ASPA-PDU der Version 2.

Daraus folgt nicht, dass niemand v2 eingeschaltet hat. Es folgt nur, was die ausgelieferte Vorgabe erlaubt.

Aushandlung ist kein Konfigurationskommentar

Der aktuelle RTRv2-Entwurf in Revision 27 lässt den Router mit seiner höchsten implementierten Version beginnen. Der Cache eröffnet die Sitzung dort oder fällt auf eine kompatible niedrigere Version zurück. Nach einem solchen Downgrade stehen höhere Funktionen in dieser Sitzung nicht zur Verfügung.

Ein auf 2 gesetzter Serverwert ist deshalb Bereitschaft. Der Client muss v2 implementieren und anfordern; die Sitzung muss tatsächlich in v2 enden; relevante Objekte müssen ankommen; der Router muss sie auswerten; die lokale Politik muss handeln.

Die Wirkung kann an Binary, Validierung, Ausgabe, Obergrenze, Client, Objektabdeckung, Pfadberechnung oder Politik scheitern. Wer alle Fälle als ASPA an oder ASPA aus behandelt, kann weder Ursache noch Reparatur sauber bestimmen.

Drei Arten von Ergebnis

Das ASPA-Objektprofil beschreibt die signierte Ermächtigung eines Kunden-ASN für seine Anbieter-ASNs. Die Relying Party prüft Objekt und Zertifikat. Damit ist noch kein empfangener BGP-Pfad bewertet.

Der Verifikationsentwurf erzeugt später Valid, Unknown oder Invalid. Er empfiehlt, Invalid aus der Routenauswahl auszuschließen und Unknown gleichrangig mit Valid zu behandeln; die konkrete Mitigation bleibt aber Sache des Netzbetreibers.

Objektzahlen messen den Validator. Eine v2-Sitzung misst Transport. Statuszähler messen Berechnung. Erst RIB, FIB und dokumentierte Politik zeigen die Wirkung. Ein gelieferter ASPA-Datensatz ist keine automatisch verworfene Route.

Umgekehrt ist v0 nicht gleichbedeutend mit fehlender Sicherheit. Origin Validation funktioniert weiter; JSON kann Tests versorgen. Belegt ist nur: FORT liefert eine experimentelle Fähigkeit, deren Router-Pfad und Mitigation weitere Entscheidungen brauchen.

Entwurfsrevision als Liefermerkmal

Die Tag-Dokumentation nennt 8210bis-25 als Implementierungsbasis. Am Stichtag war Revision 27 aktuell, das ASPA-Profil stand bei 29 und die Verifikation bei 28.

Das beweist keine Inkompatibilität. Revisionen können redaktionelle oder technische Änderungen enthalten; nur Vergleich und Test liefern ein Urteil. Es beweist jedoch, dass RTRv2-Unterstützung ohne Revision, Commit, Build und getestete Gegenstelle zu ungenau ist.

RFC 8210 bleibt die veröffentlichte Spezifikation für Version 1. Der ASPA-PDU gehört zur noch nicht als RFC veröffentlichten Version 2. Der konservative Standardwert ist damit nachvollziehbar; seine spätere Änderung muss deshalb umso genauer protokolliert werden.

Downloadzahlen sind keine Abkürzung: Download ist nicht Installation, Installation nicht Prozess, Prozess nicht v2-Sitzung und Sitzung nicht Mitigation.

Öffentliche Fähigkeitskarte, lokaler Aktivierungsbeleg

Die Fähigkeitskarte enthält Tag und Commit, Paketnamen und Hashes, implementierte Revisionen, Vorgaben und Grenzen, bekannte Abweichungen, getestete Clients sowie Ablösung und Rollback. Dafür braucht der Hersteller keine private Netztelemetrie.

Der Betreiberbeleg verbindet Paket- und Konfigurationshash mit Prozessstart, RTR-Obergrenze, aggregierten Clients nach ausgehandelter Version, Validierungszeit, angenommenen und verworfenen ASPAs nach Grund, Ausgabestatus, Pfadstatus, Mitigationspolitik und Rückkehrzustand.

Routeridentitäten und Topologie können geschützt bleiben. Für Öffentlichkeit genügen sichere Aggregate; für Audits bleibt der Detailbeleg lokal.

Die Verbindung läuft über Paket-Hash, Entwurfsrevision und Konfigurationsfingerabdruck. Ohne sie beschreibt die Release-Seite ein Potenzial und der Betriebsbericht einen namenlosen Prozess. Mit ihnen ist erkennbar, welche Fähigkeit aktiviert wurde.

Grenzen der Aussage

Die Quellen zählen weder Installationen noch v2-Sitzungen, ASPA-Objekte oder abgelehnte Routen. Sie beweisen weder eine falsche LACNIC-Aussage noch die Notwendigkeit von v2 als Vorgabe oder eine Unvereinbarkeit der Revisionen 25 und 27.

ASPA bietet außerdem keine vollständige BGP-Sicherheit. Es beschreibt Anbieterautorisierung und unterstützt Leakerkennung; es prüft nicht die Forwarding-Ebene, beseitigt Unknown nicht und ersetzt keine lokale Politik.

Fest steht nur: FORT 1.7.0.experimental implementiert ASPA und RTRv2, startet am Router mit v0, lässt die Datei-Ausgabe geschlossen und übergibt die Mitigation dem Betreiber. Aus einer Marketingfrage wird damit eine prüfbare Kette: welcher Build, welcher Entwurf, welche Sitzung, welcher Status, welche Entscheidung?

Quellen