Zusammenfassung

  • APNIC erläuterte auf der APNIC 62, dass die gehostete ASPA-Oberfläche Provider-Vorschläge aus RIPE RIS ableitet. Sie sind probabilistisch, müssen geprüft werden und fallen eher zu weit als zu eng aus.
  • Die Oberfläche prüft zudem, wie eingereichte Änderungen beobachtete BGP-Pfade beeinflussen. Das schützt die Gegenwart, ist aber keine Probe sämtlicher künftiger Pfade.
  • Der aktuelle IETF-Entwurf empfiehlt, Reserve- oder Notfall-Provider vorab in das ASPA aufzunehmen, damit die RPKI-Verteilung nicht gegen die Routenpropagierung verliert. Ein wirklich ruhender Provider hat noch keinen sichtbaren Pfad.
  • APNIC sollte einen Herkunfts- und Szenariobeleg speichern, der Beobachtungsvorschläge, menschliche Erklärungen, verworfene Kandidaten, Ist-Pfad-Prüfungen und nicht erprobte Umschaltungen trennt.

Gute Automatisierung beginnt mit einem Eingeständnis

Ein ASPA ist die signierte Erklärung eines ASN-Inhabers darüber, welche autonomen Systeme als Upstream-Provider autorisiert sind. RPKI schützt das Objekt und ermöglicht die Prüfung von Beziehungen in einem AS_PATH. Die Signatur löst jedoch nicht die redaktionelle Frage vor dem Signieren: Welche ASN gehören vollständig und korrekt in die Liste?

APNIC setzt an diesem Punkt an. Laut der Präsentation „APNIC RPKI Updates“ auf der APNIC 62 nutzt die gehostete Oberfläche den asn-neighbours-Endpunkt von RIPEstat. Aus den im RIPE Routing Information Service beobachteten Nachbarschaften entstehen Kandidaten, ähnlich den Vorschlägen in der Routenverwaltung.

Bemerkenswert ist die bescheidene Produktbeschreibung. APNIC nennt die Vorschläge probabilistisch, verlangt eine Prüfung und erwartet eher Über- als Unterinklusion. Danach folgt ein Änderungstest: Das geplante Provider-Set wird gegen beobachtete BGP-Pfade gehalten. Wer versehentlich einen gegenwärtig sichtbaren Provider entfernt, kann vor der Veröffentlichung gewarnt werden.

Diese Arbeitsteilung ist sinnvoll. Die Maschine liefert Auffälligkeiten, der Mensch entscheidet über die Autorisierung. Ihr blinder Fleck liegt nicht im Code, sondern im Zeitpunkt. Ein DDoS-Mitigator, der nur während eines Angriffs übernimmt, ein Notfalltransit für ein abgeschnittenes Segment oder eine kalte Ersatzleitung muss im Alltags-BGP nicht auftauchen. Unsichtbarkeit ist hier das Soll, nicht der Fehler.

Eine beobachtete Nachbarschaft ist kein Vertragsverzeichnis

RIPEstat beschreibt die Aussagekraft des Endpunkts präzise. ASN Neighbours liefert in RIS beobachtete Nachbarn eines ASN. Je nach Abfrage kommen Position im Pfad, Anzahl der Pfade, Zahl der beobachtenden Full-Table-Peers sowie Abfragezeit oder Gültigkeitsfenster hinzu. Eine Nachbarschaft kann als uncertain markiert werden, wenn die direkte Beziehung zu einem RIS-Kollektor das Bild selbst erzeugt haben könnte.

Diese Angaben machen einen Vorschlag nachvollziehbar. Sie entscheiden nicht über die Rolle. Ein benachbartes ASN kann Provider, Kunde, lateraler Peer, nichttransparenter Route Server oder Teil einer komplexen, nach Adressfamilie oder Präfix wechselnden Beziehung sein. RIS sieht die Pfade seiner Messpunkte. Einen noch nicht aktivierten Vertrag kann es nicht sehen.

Eine tendenziell breite Kandidatenliste kann deshalb die vorsichtige Voreinstellung sein. Einen zusätzlichen Peer kann der Betreiber verwerfen; ein übersehener aktiver Provider könnte aktuelle Pfade in Konflikt mit dem neuen Objekt bringen. Aus dieser Vorsicht folgt aber keine Vollständigkeitsgarantie. Die künftige Absicht steckt nicht automatisch im heutigen Routingbild.

Die Oberfläche braucht zwei Herkunftsarten. „In diesem RIS-Zeitfenster beobachtet“ ist eine Messung. „Als Provider autorisiert, auch wenn derzeit inaktiv“ ist eine verantwortliche Erklärung des Inhabers. Werden beide als gleichartige Häkchen gespeichert, verliert man gerade die Information, die ihre Kombination wertvoll macht.

Der IETF-Entwurf verlegt die Entscheidung vor den ersten Pfad

Die eingefrorenen IETF-Entwürfe machen aus dem Grenzfall ein Rennen. Revision 29 des ASPA-Profils beschreibt ein einzelnes Objekt je Customer AS, das alle Provider enthält, einschließlich relevanter nichttransparenter Route Server. Ein vollständiges Objekt soll Aktualisierungsrennen vermeiden.

Revision 28 der AS_PATH-Verifikation nennt Reserve-Provider ausdrücklich. Beispiele sind ein zeitweise eingesetzter DDoS-Mitigator und ein Notfall-Provider, der isolierte Segmente wieder verbindet. Solche Provider sollen im Voraus aufgenommen werden, damit die weltweite Verteilung des ASPA-Objekts nicht hinter der Ausbreitung der Route zurückbleibt.

Vor der Umschaltung existiert kein Notfallpfad für die Ist-Prüfung. Nach der Umschaltung kann die Veröffentlichung zu spät beginnen. Die maßgebliche Entscheidung fällt in einer Phase, in der Autorisierung und Plan vorhanden sind, die Produktionsbeobachtung aber noch nicht.

Das ist die Umkehrung einer bekannten Evidenzgrenze. Ein Eintrag im ASPA beweist keinen laufenden Transit. Ebenso beweist ein fehlender sichtbarer Transit nicht, dass der Provider aus dem ASPA herausgehört. Autorisierung und Beobachtung bleiben in beide Richtungen verschieden.

Daraus folgt kein Vorwurf an APNIC. Die öffentliche Präsentation berichtet weder von einer gescheiterten Umschaltung noch von einer verworfenen Route, falschen Empfehlung oder ausgelassenen Reserve. Sie bittet ausdrücklich um Rückmeldungen. Auch die IETF-Texte sind veränderliche Internet-Drafts, keine fertigen RFCs. Belegt ist nur die Asymmetrie: Der beschriebene Test prüft Beobachtetes; die Empfehlung umfasst eine bewusst noch unbeobachtete Autorisierung.

Ein grünes Ergebnis darf nicht drei Prüfungen vertreten

Nehmen wir an, ein Customer AS nutzt A und B im Normalbetrieb und hält C für die DDoS-Abwehr bereit. RIS sieht A und B, vielleicht zusätzlich Peer D. Die Oberfläche schlägt A, B und D vor. Der Betreiber entfernt D und trägt C von Hand ein.

Der Test kann zeigen, dass A weiterhin im Pfad vorkommt, B nur in IPv6 sichtbar ist oder D aus einer unsicheren Kollektor-Nachbarschaft stammt. Er kann ehrlich feststellen, dass das neue Set in den untersuchten Ist-Pfaden keinen Konflikt erzeugt.

Er kann nicht nachweisen, dass C im Ernstfall die richtigen Präfixe ankündigt, den vorgesehenen Pfad behält, genügend Kapazität liefert oder erst startet, nachdem das neue ASPA bei den Relying Parties sichtbar ist. Auch ein Labortest bleibt von der realen Krise verschieden.

„Kein Konflikt in den beobachteten Pfaden“ ist ein wertvolles Ergebnis. „Failover validiert“ ist eine andere Behauptung. Wandert nur ein grünes Symbol in ein Ticket, kann es als syntaktisch gültiges Objekt, kompatibler Ist-Pfad oder vollständig erprobte Reserve gelesen werden. Dafür braucht es drei Belege.

Ein Beleg für den Pfad, der noch nicht existiert

Ein brauchbarer Beleg muss keine Verträge, Zugangsdaten oder geschützte Topologie offenlegen. Er kann im MyAPNIC-Konto und im internen Change-Datensatz bleiben.

Jeder Kandidat erhält eine Herkunft: RIS-Vorschlag, manuell eingetragener aktiver Provider, Reserve, Notfall-Provider oder nichttransparenter Route Server. Beim Vorschlag werden Zeit, Endpunktversion oder Antwort-Digest, Position, Unsicherheit, Pfad- und Peerzahl gespeichert. Eine Ablehnung bekommt eine begrenzte Klasse wie Kunde, Peer, transparenter Route Server, Beobachtungsartefakt oder ungeklärt — nicht den Vertragstext.

Bei einem ruhenden Provider genügen Aktivierungsklasse, betroffene Adressfamilien, verantwortliche Rolle, Datum der letzten Plan- oder Laborprobe und nächste Überprüfung. Der Ist-Pfad-Test speichert Beobachtungsfenster, Digest der Pfade, vorgeschlagenes Set und Ergebnis. Entscheidend ist die explizite Liste autorisierter Provider, die nicht beobachtet und daher nicht erprobt wurden.

Zum Schluss werden menschliche Bestätigung, finales Provider-Set, Objektidentität, Veröffentlichungszeit und erste unabhängige Sichtbarkeit verbunden. Beginnt der Notfall früher, bleibt die tatsächliche Reihenfolge erhalten.

APNIC meldete auf der APNIC 62 einen Stand von 293 ASPAs: 257 in gehosteten und 36 in delegierten CAs. Das ist eine Momentaufnahme erstellter Objekte, keine Quote validierender Netze, vollständiger Provider-Sets oder getesteter Reserven. Die neue ASPA-Ansicht in DASH könnte die Zustände veröffentlicht, beobachtet, szenariogeprüft und zur Überprüfung fällig getrennt darstellen.

Die Routingentscheidung gehört weiterhin dem Betreiber

Der IETF-Entwurf prüft geordnete ASN-Paare und daraus den Pfad. Ein gelisteter Provider kann eine positive Attestierung ergeben, ein nicht gelisteter bei vorhandenem gültigem ASPA eine negative, und ohne gültiges Objekt fehlt die Attestierung. Der Entwurf empfiehlt den Umgang mit Invalid und Unknown, überlässt die Mitigationsrichtlinie aber dem empfangenden Netz.

Diese Verben sollten nicht in einem Statussymbol verschwinden. RIPE RIS beobachtet. APNIC schlägt vor, warnt und veröffentlicht. Der ASN-Inhaber autorisiert. Der Validator berechnet. Der Betreiber entscheidet über die Route.

Der Reserve-Provider macht die Grenze sichtbar, weil sein Nutzen vor seinem Verkehr entsteht. APNICs Test verbessert den Normalfall. Ein Szenariobeleg würde auch den Ausnahmefall präzise beschreiben: autorisiert, nicht beobachtet, außerhalb der Produktion geprüft und rechtzeitig sichtbar veröffentlicht.

Quellen