Zusammenfassung

  • Siddiqui schlug vor, welche Ursprungs-ASN in APNIC-ROAs zulässig sein sollten. Als Vorsitzender der Routing Security SIG wirkte er außerdem an einem Bericht über eine Umfrage zu möglichen APNIC-Diensten mit.
  • Für den Richtlinienvorschlag gibt es öffentliche Versionen, einen Konsens, eine veröffentlichte Leitlinie und einen Implementierungsstatus. Die Umfrage hielt Präferenzen zu ROA-Benachrichtigungen und APIs fest; sie ordnete weder eine Produktfreigabe an noch belegt sie sichereres Routing.

Zwei Wege, zwei Arten von Nachweis

Eine regionale Internet-Registry kann betriebliche Anliegen über verschiedene Kanäle aufnehmen. Ein Richtlinienvorschlag durchläuft ein festgelegtes Verfahren mit überarbeiteten Fassungen, öffentlicher Diskussion und einem dokumentierten Entscheidungspunkt. Eine Dienstumfrage erfüllt eine andere Funktion: Sie erfasst Präferenzen und Arbeitsprobleme, die einem Produktteam bei der Prüfung von Optionen helfen können. Sie ersetzt dessen Entscheidung nicht.

Aftab Siddiquis öffentliche APNIC-Akte verbindet beide Wege. 2021 schlug er vor, die Autonomen-System-Nummern einzuschränken, die als Ursprung in einer Route Origin Authorization (ROA) eingetragen werden dürfen. Unabhängig davon verfasste er als Vorsitzender der Routing Security Special Interest Group (SIG) einen Bericht über eine Umfrage zu ROA-Benachrichtigungen und Verwaltungs-APIs. Die Themen liegen technisch nahe beieinander, folgen institutionell aber unterschiedlichen Abläufen.

Diese Trennung ist wichtig, weil ein Registereintrag noch kein Routingverhalten beschreibt. Eine API kann einer berechtigten Person Änderungen erleichtern. Eine ROA gibt an, welches autonome System ein Präfix originieren darf. Danach müssen die Daten veröffentlicht, von Validatoren verarbeitet und von einzelnen Netzen gemäß ihrer Routing-Policy genutzt werden. Eine Umfrage zu einem Verwaltungswerkzeug belegt keinen dieser nachgelagerten Schritte.

Die SIG sammelt Rückmeldungen, sie gibt keine Releases frei

Der APNIC-49-Bericht von 2020 dokumentiert eine Vorsitzwahl und eine Diskussion über Namen und Charta der bereits bestehenden Routing Security/RPKI SIG. Nach Zustimmung aus der Community wurde der Name Routing Security SIG angenommen, die Charta vereinbart und Siddiqui zum Vorsitzenden gewählt. Die Charta beschreibt ein Forum für betriebliche Probleme und bewährte Verfahren. Sie sieht außerdem Rückmeldungen von Netzbetreibern zu APNIC-Diensten wie RPKI, IRRd und RRDP sowie eine beratende Rolle bei technischen Teilen routingbezogener Richtlinienvorschläge vor.

Damit entsteht eine praktische Verbindung zwischen Netzbetrieb und dem APNIC-Serviceteam: Betreiber können erklären, wo der Arbeitsablauf hakt; das Team kann mögliche Änderungen prüfen. Die SIG darf deshalb aber weder APNICs Produktprioritäten festlegen noch einen Veröffentlichungstermin zusagen. Siddiqui beschrieb die Gruppe in seiner Kandidatenerklärung 2022 ähnlich: Sie solle betriebliche Fragen sowie mögliche Zusatzfunktionen und Unterstützung durch APNIC besprechen. Zugleich sagte er, die Pandemie habe dem Austausch Schwung genommen. Das ist seine damalige Einschätzung, keine unabhängig erhobene Messung von Teilnahme oder Wirkung.

Wer über den nächsten Schritt entscheiden musste, wird in einem APNIC-Beitrag aus dem Jahr 2022 sichtbar: Das Serviceteam sollte die Kosten und den Nutzen der vorgeschlagenen Funktionen vorstellen. Das Forum konnte die Frage auf die Tagesordnung setzen; die Produktverantwortlichen mussten sie noch bewerten.

Was die Umfragewerte zeigen – und was offenbleibt

Laut dem im September 2022 von Siddiqui, Di Ma und Afifa Abbas mitverfassten APNIC-Beitrag fand die Umfrage nach der offenen Sitzung vom Oktober 2021 statt. Auf die Frage nach einer E-Mail-Benachrichtigung bei Erstellung einer ROA antworteten 52,4 Prozent mit Ja, 33,3 Prozent bevorzugten eine freiwillige Aktivierung, 9,5 Prozent befürchteten zu viele Nachrichten und 4,8 Prozent wollten die Frage weiter erörtern. Unter den Befürwortern einer Benachrichtigung bevorzugten 47,6 Prozent Webhooks, 28,6 Prozent hielten E-Mail für ausreichend und 23,8 Prozent waren unentschieden.

Bei APIs zur ROA-Verwaltung – über MyAPNIC oder selbst gehostete RPKI-Software wie Krill – lauteten die veröffentlichten Werte: 66,7 Prozent Ja, 19 Prozent Nein und 14,3 Prozent Vielleicht.

Die Prozentzahlen dokumentieren geäußerte Präferenzen. Der Beitrag nennt jedoch weder den Nenner noch die Erhebungsmethode oder eine Aufschlüsselung nach Netztyp. Daher lässt sich nicht ableiten, wie viele Personen antworteten oder ob sie APNIC-Mitglieder, Netzbetreiber allgemein oder die Region repräsentierten. Es war auch keine Abstimmung über Routing-Policy: Gefragt wurde nach möglichen Diensten, und einige Antworten verlangten ausdrücklich weitere Diskussion.

Die Fragen benennen trotzdem konkrete Reibungspunkte. Eine Benachrichtigung informiert den technischen Kontakt, dass eine ROA erstellt wurde; ein Webhook kann das Ereignis in interne Systeme des Betreibers leiten; eine API kann manuelle, wiederkehrende Änderungen automatisieren. Jede Option verändert einen Teil des Ablaufs. Keine entscheidet allein, ob die ROA korrekt ist oder ein Router eine ungültige Route verwirft.

Eine spätere API belegt keine Kausalität

Im Oktober 2024 kündigte APNIC die Verfügbarkeit seiner Registry API an. Sie erlaubt den Abruf von Delegationsdaten und die Verwaltung von Whois-Einträgen, Reverse DNS, ROAs und Routenobjekten. APNIC erklärte, die API reagiere auf Wünsche von Mitgliedern und könne Änderungen automatisieren, die zuvor manuell in MyAPNIC vorgenommen wurden. Im Jahresbericht 2022 war bereits ein öffentlich testbarer Prototyp beschrieben; die Produktionsentwicklung sollte 2023 beginnen.

Umfrage und Produkt überschneiden sich tatsächlich: Beide betreffen API-Zugänge zu Registry-Funktionen, einschließlich der ROA-Verwaltung. Die hier zitierten öffentlichen Quellen sagen jedoch nicht, dass die Umfrage von 2021 das Projekt auslöste, dass ihre Teilnehmenden zu den Mitgliedern gehörten, die die API anforderten, oder dass die SIG das Produktdesign bestimmte. Die spätere Verfügbarkeit beweist weder die Nutzung durch die Befragten noch weniger Route Leaks oder Hijacks.

Der Begriff „Routing-Sicherheit“ fasst leicht mehrere Ebenen zusammen. Eine Registry bietet eine Bedienoberfläche; ein Ressourceninhaber ändert seine Objekte; die Registry veröffentlicht signierte Daten; ein Validator verarbeitet sie; und jedes Netz entscheidet, wie es auf den Validierungsstatus reagiert. Ein Beleg für eine Ebene darf nicht stillschweigend als Beleg für die nächste gelten.

Der Richtlinienvorschlag hinterließ eine andere Spur

Siddiquis prop-138 bildet einen passenden Kontrast. Der Vorschlag beanstandete, dass APNICs ROA-Verwaltung private, reservierte und nicht zugewiesene ASN als Ursprung zuließ, und wollte solche ROAs begrenzen. Die zweite Version erweiterte die entsprechende Beschränkung auf route- und route6-Objekte. APNICs öffentlicher Tracker datiert die beiden Fassungen auf August und September 2021; er verzeichnet einen Konsens bei der offenen APNIC-52-Richtliniensitzung am 16. September, die Maßnahme als Leitlinie weiterzuverfolgen, die Veröffentlichung im Dezember sowie den aktuellen Status „Implemented“.

Das ist ein formellerer Beleg als eine Dienstumfrage: Der Regelvorschlag, seine Fassungen, das Konsensdatum und der Implementierungsstatus sind nachvollziehbar. Dennoch sagt der Tracker nicht, wie viele problematische Objekte verhindert wurden oder wie stark sich das Routingrisiko verändert hat. „Implemented“ bezeichnet einen Prozessstatus, keine Wirkungsstudie.

Der Vergleich macht die Umfrage nicht belanglos. Er zeigt, dass die beiden Kanäle unterschiedliche institutionelle Ergebnisse liefern. Das Richtlinienverfahren hält fest, ob ein Vorschlag den vorgesehenen Entscheidungspunkt der Community erreicht. Eine Dienstumfrage hilft Verantwortlichen, Präferenzen und offene Fragen zu erkennen. Für die Wirkung braucht es jeweils andere Belege: den Regelstatus, Spezifikation und Freigabe des Dienstes sowie Betriebsdaten zu nachgelagerten Folgen.

Was sich über Siddiqui belegen lässt

Die APNIC-Kandidatenbiografie von 2012 beschrieb Siddiqui als Netzwerkbetriebsleiter in Pakistan, der an IPv6-Einführung, Infrastruktursicherheit, der IPv6 Task Force Pakistan und regionalen Betreiberaktivitäten beteiligt war. Eine APNIC-Seite von 2022 hält seine eigene Beschreibung der SIG-Vorsitzrolle und sein Interesse fest, betriebliche Probleme mit APNIC-Unterstützung zu verbinden. Diese datierten Quellen verorten ihn zwischen Netzbetrieb, Policy-Diskussionen und Servicefeedback. Sie machen ihn weder zum alleinigen Urheber der Gruppenagenda noch zum Entscheider über APNIC-Systeme.

Die belastbare Schlussfolgerung ist entsprechend eng. Siddiqui verfasste einen Vorschlag, dessen Status sich in den Richtlinienunterlagen nachverfolgen lässt, und wirkte an einem Forum mit, das Dienstpräferenzen dokumentierte und an das Serviceteam weitergab. Der erste Weg hinterließ eine Konsens- und Implementierungsspur. Der zweite lieferte ein Signal für die Produktprüfung. Die spätere API macht das Thema greifbar, schließt aber weder die fehlende Kausalkette noch belegt sie einen Sicherheitsgewinn im Routing.

Quellen