Zusammenfassung

  • Breizh-IX beschreibt nächtlich erzeugte strenge Präfixlisten, Prüfungen von RPKI-Daten und die Beachtung des PeeringDB-Feldes „Never via route servers“. Der Vortrag über RS-API auf RIPE 93 nennt darüber hinaus die Plausibilität der Routenmenge und den Wunsch des Kunden nach Weitergabe.
  • PeeringDB bezeichnet das Feld als Hinweis für Austauschpunkte. Erst wenn der Betreiber es abruft, in eine Richtlinie überführt und am laufenden Server prüft, wirkt die Entscheidung des Mitglieds.

Ein korrektes Register kann die falsche Frage beantworten

Eine Route steht im AS-SET des Kunden. Ihr Route-Objekt ist vorhanden. Der Filter lässt sie passieren. Diese Folge klingt nach einem erfolgreichen Prüfprozess, bis jemand fragt, wer den Route Server beauftragt hat, sie an weitere Mitglieder auszugeben. Das AS-SET beschreibt einen deklarierten Kreis von Netzen. Es enthält keine automatische Vollmacht für jede Weitergabe an jedem Austauschpunkt.

Im offiziellen Abstract von RIPE 93 stellen Evann Dreumont und Alarig Le Lay von Breizh-IX drei Prüfungen nebeneinander. Erstens: Stimmen Route und Kunden-AS-SET im IRR überein? Zweitens: Ist die Anzahl der angekündigten Routen plausibel, auch wenn ein verschachteltes AS-SET einen großen Teil der weltweiten Routingtabelle hereinziehen kann? Drittens: Will der Kunde überhaupt, dass seine Route vom Server erneut angekündigt wird? Die ersten beiden Fragen betreffen Datensätze und Mengen. Die dritte betrifft einen handelnden Netzbetreiber.

RFC 7947 beschreibt den Route Server als Vermittler für multilaterale BGP-Verbindungen an einem Internetknoten. Mitglieder sparen einzelne Sitzungen mit jedem Gegenüber; die Verteilentscheidung bündelt sich im Server. Damit erhält seine Richtlinie eine größere Reichweite. Ein Fehler bei der Auswahl der Empfänger kann mehrere Verbindungen zugleich treffen. Der Standard behandelt Regeln pro Kunde. Die Zustimmung eines Kunden entsteht dennoch außerhalb des Filters und muss als eigene Eingabe in die laufende Regel gelangen.

Ein Häkchen hat keine direkte Leitung zum BGP-Prozess

Die eigene Website von Breizh-IX nennt konkrete laufende Kontrollen. Der ehrenamtlich geführte Verein aus Rennes erzeugt demnach nachts mit bgpq4 im strengen Modus neue Präfixlisten; ohne Route-Objekt wird ein Präfix verworfen. Die Server prüfen ROAs über RIR-RPKI und das OTC-Attribut, der zweite Server zusätzlich ASPA. Außerdem beachtet der Austauschpunkt das Feld „Never via route servers“ in PeeringDB. Das ist eine Aussage des Betreibers über seinen Betrieb. Der neue RS-API-Ansatz ist im Konferenzabstract als Entwurf einer vermittelnden Automatisierung beschrieben, ohne veröffentlichte Leistungsdaten.

In der PeeringDB-FAQ heißt das Feld info_never_via_route_servers. PeeringDB nennt es einen Hinweis: Austauschpunkte sollen die Information regelmäßig prüfen und berücksichtigen. Das Mitglied setzt ein Zeichen im Profil. PeeringDB hält es fest. Der Austauschpunkt muss es lesen, entscheiden, in Konfiguration umsetzen und am Server kontrollieren. Ein gespeicherter Wunsch ist keine bereits ausgeführte BGP-Regel.

Diese Trennung wird beim Zeitstempel scharf. Ändert das Mitglied die Einstellung nach der letzten Abfrage, arbeitet der Server möglicherweise noch mit dem vorigen Wert. Die nächtliche Neuerstellung von IRR-Filtern sagt für sich genommen nichts über den Abrufrhythmus der PeeringDB-Einstellung. Die geprüften öffentlichen Quellen liefern keine einzelne Änderungs- und Wirksamkeitskette bei Breizh-IX; ein Vorfall wird hier nicht behauptet. Für eine belastbare Prüfung wäre genau diese Kette nötig: Änderung, Abruf, Freigabe der neuen Regel und beobachteter Export.

Auch die Mengenkontrolle besitzt einen politischen Kern. Die rekursive Auflösung eines AS-SET kann technisch richtig sein und trotzdem eine grotesk große Liste liefern. Ein sehr hoher Grenzwert schützt nicht vor dieser Ausweitung. Das Abstract beschreibt RS-API als Proxy, der vorhandene Werkzeuge und Daten miteinander konfrontiert und manuelle Nachpflege verringern soll. Es enthält weder Quellcode noch Zahlen zur Einführung oder zu Fehlentscheidungen. Sein Wert liegt zunächst darin, die Bedingungen einer später überprüfbaren Entscheidung zu benennen.

Die Ausgaberegel braucht eine nachvollziehbare Herkunft

Für eine Route sollte der Betreiber die benutzten AS-SET- und Route-Objekt-Versionen, die Größe der Auflösung, den Grenzwert, den abgerufenen PeeringDB-Wert samt Zeitpunkt, die geladene Richtlinienversion und die Empfänger zeigen können. Bei Ablehnung ist dann der konkrete Grund sichtbar. Bei Annahme ist nachvollziehbar, auf welcher Grundlage der Server im Namen des Mitglieds sprach. Genau diese zweite Hälfte geht in vielen sauberen Filterdiagrammen verloren.

Eine Frage bleibt in den Quellen offen: Welcher Standard gilt bei fehlender, alter oder widersprüchlicher Einstellung? Eine veröffentlichte Ersatzregel und ein datierter Ausführungsnachweis würden die Beurteilung ändern. Der Server kann Präfixe zählen; über die Bedeutung einer leeren Einwilligungsangabe entscheidet sein Betreiber. Diese Entscheidung gehört in die Öffentlichkeit des Dienstes.

Quellen