Zusammenfassung

  • FORTs voreingestellte ASPA-Grenze beträgt 4.000 Provider. Im untersuchten Merge prüft das Programm die Summe zweier aktueller Listenlängen vor dem Entfernen ihrer Duplikate.
  • Der Überschreitungszweig liefert einen Nullzeiger und den Zählerstand null, laut Typvertrag für eine Rücknahme. Ein betroffener Kunde, eine beim Router eingegangene Rücknahme oder eine Ressourcenaufhebung wurde nicht beobachtet.

Zwei Listen können mehr Zwischenraum benötigen als ihre gemeinsame Mitgliedschaft. FORTs festgehaltener Veröffentlichungscode prüft das Budget an genau dieser Stelle: Er addiert die Längen, bevor er die Vereinigung ohne Duplikate bildet.

Man nehme zwei sortierte Provider-AS-Listen desselben Kunden mit je 2.500 ASIDs und identischer Mitgliedschaft. Die mathematische Vereinigung enthält 2.500 AS. Die vorläufige Summe beträgt 5.000 und kann die Vorgabe von 4.000 überschreiten. Das ist eine bedingte Herleitung aus der Funktion, kein in Produktion gefundenes ASPA-Paar. Vorausgesetzt werden Listen, die die übrigen Prüfungen bestanden haben und diesen Merge erreichen.

LACNICs Einführung zu ASPA vom 9. September 2026 nennt FORT als vorhandene Implementierung. ASPA stellt die vom Kunden-AS autorisierten Provider-Beziehungen bereit, nicht bloß eine Prüfung des Routenursprungs. Hier geht es um die Zählung überlappender Informationen, nicht um Verbreitungszahlen oder die mit einem Router ausgehandelte Protokollversion.

Untersucht wird 1.7.0.experimental, veröffentlicht am 16. Juli, mit dem festen Commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e. Die Septemberanalyse meldet keinen September-Release und erfasst nicht sämtliche aktuellen Installationen. FORT wurde nicht ausgeführt, die Produktion nicht abgefragt und kein synthetisches ASPA veröffentlicht.

Ein Budget an zwei Stellen

Die Anleitung definiert aspa.max-providers als über Argument oder JSON konfigurierbare Ganzzahl: Standard 4.000, Bereich null bis 16.380. Sie beschreibt die Kundendeklarationen über alle RPKI-Bäume eines Validierungszyklus und nennt überschreitende Kunden ungültig. Der Konfigurationscode bestätigt die Werte. Dieser Beitrag erklärt sie nicht zur Protokollgrenze und stellt null nicht als unbegrenzte Option dar.

Zunächst prüft der Objektparser eine einzelne Liste. parse_providers weist sie bei Überschreitung zurück, bevor das Array angelegt und das Objekt weitergereicht wird. ASIDs müssen aufsteigend sein, dürfen sich innerhalb der Liste nicht wiederholen und dürfen nicht den Kunden selbst bezeichnen. Überschneidungen zwischen zwei zugelassenen Listen sind deshalb etwas anderes als Duplikate in einem Objekt. Listenform allein belegt auch nicht alle Signatur- und Zertifikatsbedingungen.

Der zweite Weg führt durch kundenspezifische Datenbankeinträge. Gibt es schon einen Eintrag desselben Kunden, ruft add_aspa die Funktion merge_providers auf. Diese setzt m zunächst auf old->count plus new->count. Ist der alte Provider-Zeiger null oder die Summe größer als die Vorgabe, gibt sie einen Nullzeiger und Anzahl null zurück.

Erst nach dieser Schranke wird Platz für die Summe reserviert und die sortierte Vereinigung erstellt. Duplikate zwischen den Listen werden dabei entfernt. Die kleinere Mitgliedszahl kommt nach der ersten Budgetentscheidung. add_aspa setzt das Ergebnis im neuen Kundeneintrag und gibt ersetzten Speicher frei. Der Typ-Header beschreibt Nullzeiger und null als Rücknahme.

Damit ist das 2.500-plus-2.500-Beispiel begrenzt, aber aussagekräftig: Die Prüfung sieht 5.000 vor der möglichen Vereinigung von 2.500 unterschiedlichen Mitgliedern. Es weist weder eine echte Rücknahme noch einen Verkehrsausfall nach.

Keine zwingende Rohsumme des ganzen Zyklus

Die alte Anzahl kann bereits aus einer früheren Vereinigung ohne Duplikate stammen. Sie hält nicht unbedingt die Längen aller ursprünglichen Objekte fest.

In einer bedingten Folge für einen einzigen intakten Zieleintrag liefern drei identische Listen mit je 1.500 ASIDs zuerst eine Summe von 3.000 und dann eine Vereinigung von 1.500. Mit der dritten Liste ist die Prüfsumme erneut 3.000. Obwohl die ursprünglichen Listen 4.500 Einträge enthalten, muss diese konkrete Folge nicht über 4.000 liegen.

Das garantiert keine tatsächliche Gruppierung der RPKI-Bäume. Es trennt ursprüngliche Einträge, aktuelle Zwei-Eingangs-Kapazität und unterschiedliche Mitglieder. Unter dem einen Begriff „Provider-Anzahl“ können mehrere Einheiten verschwinden.

Die numerische Bedingung lautet größer, nicht gleich. Gleichheit löst diesen Zweig nicht aus; andere Prüfungen bleiben bestehen. Ein Nullergebnis beweist ebenso wenig eine Überschreitung, denn der alte Nullzeiger ist eine eigene Bedingung. Alle Merge-Reihenfolgen wurden nicht geprüft, und eine universelle Unumkehrbarkeit ungültiger Marker wird nicht behauptet.

Den geschützten Umfang benennen

Die Reihenfolge ist mit einem defensiven Allokationsbudget vereinbar: Der folgende Speicherbedarf wird gerade durch die Summe bemessen. Zwischenkapazität zu begrenzen kann sinnvoll sein, selbst wenn die Vereinigung kleiner ausfiele. Das ist eine strukturelle Schlussfolgerung, keine bestätigte Absicht des Betreuers oder Leistungsmessung. Sie reicht nicht, die Schranke zum Fehler zu erklären.

Der Betreiber sieht dagegen möglicherweise vor allem die unterschiedlichen AS im Ergebnis. Eine hilfreiche Erläuterung würde das geschützte Budget benennen: Zwischenkapazität beider Eingaben oder endgültige unterschiedliche Mitglieder. Textpräzisierung und Änderung der Reihenfolge sind verschiedene Entscheidungen. Keine wird als umgesetzt gemeldet; eine pauschale Erhöhung der Grenze wird nicht empfohlen.

Die weitere Wirkung braucht eigene Belege. Nullergebnis und Rücknahmevereinbarung zeigen nicht, was eine Routersitzung empfing, welche Richtlinie sie anwendete oder ob Verkehr sich änderte. Eine Cache-Entscheidung über Provider-Informationen hebt die ASN oder Ressourcenregistrierung des Kunden nicht auf. Der Befund betrifft die Aufnahme in ein Softwareergebnis, keinen beobachteten Vorfall.

Quellen

  1. LACNICs Einführung zu ASPA
  2. FORT 1.7.0.experimental
  3. Parameteranleitung im festen Commit
  4. Provider-Prüfung des ASPA-Objekts
  5. Kundenspezifische Vereinigung und Zählreihenfolge
  6. Konfigurationswerte und Grenzen
  7. Provider-Typ und Rücknahmevereinbarung