Summary

  • Paweł Foremskis bgpipe kann zwischen BGP-Sprechern sitzen und Nachrichten durch Herkunfts- und ASPA-Prüfungen schicken. RIPE 92 stellte seine Arbeit als Weg vor, ROA- und ASPA-Validierung zu bestehenden Routern zu bringen.
  • Die ASPA-Anleitung des Projekts verlangt eine Nachbarrolle. Bei --role auto wird die Prüfung für eine Sitzung übersprungen, wenn der Nachbar in seiner OPEN-Nachricht keine BGP-Role-Fähigkeit sendet. Für Sicherheitszwecke soll die Rolle ausdrücklich gesetzt werden.

Ein fehlendes Firmware-Update ist eine bequeme Erklärung für einen fehlenden Routenschutz. Paweł Foremski nimmt dem Betreiber diese Ausrede: bgpipe spricht auf beiden Seiten BGP, verarbeitet Updates in einer Kette von Schritten und leitet sie an vorhandene Geräte weiter. Der Router muss die neue Funktion nicht selbst beherrschen.

Eine Software zwischen zwei Geräten kennt aber nicht von allein deren geschäftliche und technische Beziehung. ROV vergleicht den Ursprungs-AS eines Präfixes mit validierten ROA-Daten. ASPA prüft den AS-Pfad und die attestierten Providerbeziehungen. Die ROV-Dokumentation beschreibt Zustände je Präfix; ASPA urteilt über den ganzen Pfad. UNKNOWN heißt, dass Attestierungen fehlen. INVALID ist ein anderer Befund. Wer beides als „schlechte Route“ zusammenzählt, verschlechtert gerade die Information, für die er den Proxy installiert hat.

Für ASPA muss bgpipe wissen, ob der Nachbar Kunde, Provider, Peer oder Route Server ist. Der Betreiber kann die Rolle nach seiner eigenen Peering-Vereinbarung ausdrücklich setzen. --role auto übernimmt dagegen die Angabe aus der OPEN-Nachricht des Nachbarn. Lässt der Nachbar diese Fähigkeit weg, warnt das Programm und überspringt ASPA für die Sitzung. Meldet er Provider oder Route Server, gelten teils andere und großzügigere Prüfungen. Das Projekt rät deshalb bei Sicherheitsbetrieb von der unkontrollierten Selbstauskunft ab.

Foremskis Ansatz verschiebt den Ort der Regel, nicht die Verantwortung für ihren Inhalt. Der Betreiber braucht eine gepflegte Liste seiner BGP-Beziehungen, eine RPKI-Datenquelle und eine Entscheidung über INVALID. Die ASPA-Stufe kann erreichbare Präfixe zurückziehen, das gesamte UPDATE verwerfen oder es nur markieren und weitergeben. Mit Markierungen lässt sich zunächst messen. Zurückziehen verändert unmittelbar, was der Router lernt.

Sogar die Reihenfolge der Prüfungen beeinflusst die Rechenschaft. Verwirft eine vorgeschaltete ROV-Stufe ein UPDATE, erreicht es ASPA nie und fehlt in deren Zählern. Die Projektanleitung empfiehlt ASPA zuerst, wenn Tags und Messwerte alle Updates erfassen sollen. Ein sauberer Zähler kann sonst bloß die Reste der vorigen Stufe zählen.

Die Quellen zeigen keine datierte Produktionssitzung mit konfigurierter Rolle, empfangenem OPEN, ASPA-Cache und tatsächlich verworfenen oder weitergereichten Updates. Solche Aufzeichnungen würden den konkreten Effekt belegen. Der derzeit belegte Konflikt reicht für eine klare Frage: Wenn der alte Router nun geprüft werden kann, warum darf dann ausgerechnet der geprüfte Nachbar seine Rolle im Test bestimmen?

Quellen: RIPE-92-RACI-Profil · bgpipe-Projektübersicht · ASPA-Dokumentation · ROV-Dokumentation.