Zusammenfassung

  • Ein im September eingereichter individueller Entwurf sieht ein gesondertes Register für geschützte IPv4/IPv6-Delegationen vor. Ob ein Relying Party bestehende RPKI-Daten ausfiltert, bleibt freiwillige lokale Politik.
  • Werden alte VRPs entfernt, bevor neue Ursprungsautorisierungen bestätigt und final sind, kann die Route für diesen Nutzer NotFound werden – selbst bei weiterhin gültiger ROA. Das ist eine Warnung des Entwurfs, kein beobachteter Ausfall.

An der Schnittstelle zwischen zwei Registern ist „hinzufügen“ kein Synonym für „ersetzen“. Joseph Gerschs am 18. September eingereichter Internet-Draft setzt bei einer Schwäche delegierter Zertifikate an: Auch wer den privaten Schlüssel einer untergeordneten CA verwahrt, kann deren Aussteller nicht daran hindern, das Zertifikat zu widerrufen. In einem getrennten hierarchischen Ressourcenregister soll eine geschützte Delegation nach Erfüllung bestimmter Bedingungen gegen Rücknahme, konkurrierende Ausgabe oder Unterdrückung durch übergeordnete Akteure gesichert sein.

Der für Netzbetreiber kritische Schritt folgt jedoch erst beim Zusammenführen der Routenursprungsdaten.

Der Vorschlag ersetzt weder das RPKI flächendeckend noch gibt er rechtliches Eigentum an Adressraum vor. Router würden die übliche Origin Validation fortsetzen. Eine Delegation wäre erst unwiderruflich, wenn ein finaler Zustand erreicht, die Inhaberin oder der Inhaber bestätigt und ein vorläufiges Zeitfenster abgelaufen ist. Vorher muss eine vom Inhaber gewählte Wiederherstellungsregel feststehen. Übernommene RIR-, RDAP- oder RPKI-Angaben sind zunächst behauptete, keine bestätigten Daten. Für exportierte Ursprungsautorisierungen verlangt der Entwurf bestätigten und finalen Zustand.

Sichtbarkeit im Protokoll allein ist also kein Grund, die bisherige ROA zu verdrängen.

RFC 8416 erlaubt bereits lokale SLURM-Ausnahmen, sowohl zusätzliche Daten als auch Filter. Abschnitt 10.6 des neuen Entwurfs unterscheidet die Folgen ausdrücklich: Eine VRP des geschützten Registers ergänzen lässt die bisherige RPKI-VRP stehen. Ein Filter kann diese bisherige Autorisierung verbergen; bei einem Fehler wird legitime Autorität entzogen. Die Entscheidung, ihn zu laden, trifft der Verbraucher lokal. Abschnitt 10.5 warnt vor einem weiteren Grenzfall: Eine weniger spezifische ROA kann mit ihrem maxLength in den geschützten Bereich hineinreichen. Ein Filter für den exakten Präfix allein erfasst diese Reichweite nicht; eine begrenzte Unterdrückung braucht präzisere Ersatzdaten oder ein leistungsfähigeres Austauschformat.

Wird die bisherige VRP zuerst ausgeblendet, während die geschützte Herkunftsautorisierung noch nicht bestätigt und final ist, kann die Route für diesen Verbraucher NotFound erscheinen. Das ist nicht dasselbe wie Invalid und sagt ohne die Routing-Policy des Betreibers nichts Sicheres über den Verkehr aus. Wer nur exportierte VRPs bezieht, muss zudem dem Exporteur vertrauen: Die vorgeschlagene Ausgabe trägt keine Inhabersignatur. Der Entwurf zeigt damit selbst, dass die versprochene Schutzwirkung an einer lokalen Auswahl und an der Qualität des Exportpfads hängt.

Der Autor nennt einen Prototyp auf einer zugangsbeschränkten Blockchain und zugleich offene Arbeiten: unabhängige Implementierungen, produktionsfähige Finalitätsprofile, Messungen im Internetmaßstab und praktische Wiederherstellung. In der SIDROPS-Liste bezweifelte ein Teilnehmer die Zuständigkeit der Arbeitsgruppe; der Autor verwies auf die Vorsitzenden. Daraus folgt weder Annahme noch Ablehnung durch die Gruppe. Datatracker führt weiterhin einen individuellen, nicht gebilligten Entwurf. Die prüfbare Nachricht ist eine neue Stelle, an der vorhandene Belege durch eine Konfigurationsentscheidung verschwinden könnten.

Quellen