Für jede Route eine gültige ROA: MANRS muss klären, wer sie ausstellen kann

Zusammenfassung

Andrei Robachevsky beschrieb auf der RIPE 93 einen Entwurf, der Route Origin Validation als MUST einstufen und für jedes von einem MANRS-Mitglied angekündigte Präfix eine gültige ROA verlangen würde.
Unterschriftsberechtigung und Betrieb fallen nicht immer zusammen: Legacy-Inhaber ohne ARIN-Vertrag können ARIN RPKI nicht nutzen; Kunden, die Präfixe mieten, haben möglicherweise keine ROA erstellt.

Analyse

Ein Netzbetreiber kann eine Route ankündigen, ohne die Registrierung zu kontrollieren, die ihren Ursprung belegt. Genau dort wird der geplante RPKI-Anspruch von MANRS auf 100 Prozent zur Governance-Frage.

Am 27. Oktober stellte Andrei Robachevsky auf der RIPE 93 den Stand der Arbeitsgruppe vor, die das MANRS-Programm für Netzbetreiber überprüft. Seit dem Start 2014 waren die Actions nicht grundlegend überarbeitet worden. Die Gruppe trennte Anforderungen von Umsetzung und Audit-Leitfaden und nutzte IETF-Begriffe wie MUST und MUST NOT, um Auslegungsspielräume zu verkleinern. In dem Entwurf, den Robachevsky erläuterte, wäre ROV ein MUST und die IRR-Registrierung ein SHOULD. Für die Routing-Informationen diskutierte die Gruppe eine vollständige RPKI-Abdeckung: Jedes angekündigte Präfix eines Teilnehmers sollte eine gültige ROA haben.

Das war ein Vorschlag, keine geltende MANRS-Regel. Robachevsky kündigte einen letzten internen Aufruf und danach eine breitere Kommentierungsrunde an. Der Text sollte mehr Stimmen abbilden als nur die Arbeitsgruppe und heutige MANRS-Teilnehmer. Das offizielle RIPE-Transkript hält den damaligen Arbeitsstand fest.

Die MANRS-Umfrage vom März erhielt 38 Antworten, überwiegend von Netzbetreibern. Klarere Anforderungen und bessere Prüfbarkeit standen weit oben; die Hälfte der Antwortenden setzte das Betreiberprogramm an die erste Stelle der Review-Prioritäten. Die veröffentlichte Seite nennt nicht, wie viele Personen eingeladen wurden. Eine Rücklaufquote lässt sich deshalb nicht berechnen.

Der Zugang zum RPKI hängt auch an der Vertragsbeziehung. ARIN erklärt, dass Inhaber von Legacy-Ressourcen ohne Vertrag seine RPKI- und IRR-Dienste nicht nutzen können. Mit einem Vertrag erhalten sie Zugang. Außerdem darf eine ROA nur Ressourcen abdecken, die im Ressourcenzertifikat des Inhabers stehen. Ein Betreiber kann die Autorisierung für fremde Ressourcen nicht einfach mit seinem eigenen Zertifikat ausstellen.

Robachevsky nannte genau diese Reibungsflächen: Legacy-Inhaber im ARIN-Gebiet ohne RPKI-Zugang und von Kunden gemietete Präfixe, für die der Kunde keine ROA angelegt hat. Der Betreiber kündigt die Route an, doch der Kunde oder Ressourceninhaber kann den Eintrag im Register kontrollieren. Bei einem binären Audit wird trotzdem der Betreiber als nicht konform sichtbar.

IRR bleibt Teil des Entwurfs, nur mit niedrigerer Verbindlichkeit. Die Gruppe diskutierte IRR als SHOULD, ROV als MUST. Einige Netze arbeiten weiter mit IRR; welche Register und Objekte zählen, war noch offen. IRR pauschal als Ersatz für RPKI zu behandeln, würde die vorgeschlagene Rangfolge aufheben. IRR auszublenden hieße, ein Werkzeug zu übersehen, das Betreiber noch für Routing-Informationen und Filterlisten nutzen.

Nach Robachevskys Angaben wuchs MANRS von neun Netzbetreibern 2014 auf rund 1.400 Teilnehmer zum Zeitpunkt seines Vortrags. Der Zweck des Baselines ist breite Übernahme, nicht eine perfekte Prüfung für wenige. Eine Regel, die Netze mit schwierigen Ressourcenbeziehungen aus der Mitgliedschaft drängt, kann die Quote der verbleibenden Mitglieder heben und zugleich die erfasste Routingfläche verkleinern.

Die 100-Prozent-Zahl braucht deshalb einen Weg zur Erfüllung: Welche Ankündigungen zählen, wer legt die ROA an, was gilt bei kundenkontrollierten Ressourcen und wie viel Zeit erhalten bestehende Mitglieder? Ohne diese Antworten wandert die Verantwortung zwischen Firmen, während die fehlende Autorisierung fehlt.