Zusammenfassung

  • Der GROW-Entwurf bindet mit src-members einen unmittelbaren RPSL-Set-Verweis an eine benannte IRR-Registry; diese Bindung darf sich aber nicht auf die rekursiven Verweise des gefundenen Objekts fortsetzen.
  • Solange moderne und ältere Resolver nebeneinander bestehen, kann ein gültiges Objekt verschiedene Policies erzeugen. Vor dem Deployment braucht es deshalb einen Auflösungsnachweis mit jedem Quellentscheid und dem exakten Ergebnisunterschied.

Ein Policy-Build trägt oft eine Versionsnummer, einen Zeitstempel und einen Hash. Das wirkt reproduzierbar, bis derselbe Root-Set-Name auf einem zweiten System ein anderes Ergebnis liefert. Dann zeigt sich, dass der Hash nur das Ende der Berechnung schützt. Welche Registry an welchem Verweis gewählt wurde, ist darin nicht enthalten.

draft-ietf-grow-rpsl-registry-scoped-members-00 setzt genau an einem solchen Quellenentscheid an. Der Entwurf ergänzt RPSL-Objekte der Klassen as-set und route-set um src-members. Ein Eintrag wie RIPE::AS-EXAMPLE nennt nicht nur den Primärschlüssel, sondern auch die Registry, in der das referenzierte Set gesucht werden soll.

Die Präzisierung löst eine reale Mehrdeutigkeit. Sie ist dennoch kein Herkunftsnachweis für die vollständige Expansion. Das Präfix steuert eine Kante im Graphen, nicht automatisch alle folgenden Kanten.

Getrennte Registries, gleiche Schlüssel

RPSL-Sets können AS-Nummern und Präfixe direkt aufnehmen oder andere Sets referenzieren. Diese Verweise lassen sich rekursiv fortsetzen. Mehrere IRR-Registries werden unabhängig betrieben; ihre Primärschlüssel sind über die gesamte Landschaft nicht garantiert eindeutig. Ein Server mit mehreren Spiegelquellen kann somit mehrere Objekte namens AS-EXAMPLE kennen.

Der Entwurf beschreibt zwei Fehlerklassen. Der Resolver wählt möglicherweise das gleichnamige Objekt einer nicht beabsichtigten Registry und berechnet daraus unbeabsichtigte Routing-Policy. Oder er findet das beabsichtigte Objekt nicht, wodurch eigentlich zulässige Präfixe fehlen. Das Dokument nennt Route Leaks, die Begünstigung von Hijacking und gestörte Erreichbarkeit als Risiken. Es liefert aber keinen neuen benannten Vorfall und keine Verbreitungsmessung; diese Grenzen bleiben bestehen.

Ein src-members-fähiger Resolver muss Registry-Name und Primärschlüssel gemeinsam abgleichen. Kennt er die ausdrücklich genannte Registry nicht, gibt es für den Verweis kein passendes Set. Ein stiller Rückfall auf irgendein unqualifiziertes Objekt würde die neue Aussage des Maintainers verwerfen.

Nach dem Fund endet die Bindung. Für die Verweise im Kindobjekt gelten dessen eigene Attribute. Ein weiteres src-members kann eine andere Registry ausdrücklich wählen. Ein alter members- oder mp-members-Eintrag aktiviert wieder den bisherigen Quellenauswahlalgorithmus. Das Registry-Präfix des Elternobjekts kaskadiert nicht.

Auch eine Einschränkung der Ausgangsabfrage gilt nur für den Root-Lookup. Software muss einen Parameter für diese Einschränkung anbieten, darf ihn aber nicht auf die nachfolgenden Auflösungen übertragen. Wer mit RIPE::RS-FIRST beginnt, hat nicht belegt, dass jeder Nachfahre aus RIPE stammt.

Der Kompatibilitätsschatten hat eigene Semantik

Der Entwurf plant einen schrittweisen Übergang. Alte Software versteht src-members nicht, und bestehende Objekte werden nicht gleichzeitig umgestellt. Deshalb bleiben members und mp-members erhalten. Eine autoritative Registry muss prüfen, dass jeder neue Wert nach Entfernung seines Registry-Präfixes auch in den alten Attributen vorkommt.

Fehlen die Legacy-Attribute in der Einreichung, soll autoritative Software sie aus src-members erzeugen. Hat der Nutzer sie selbst geliefert, dürfen sie nicht überschrieben werden. Nicht autoritative Server dürfen eine solche Projektion nicht herstellen. Umgekehrt darf Software aus einem unqualifizierten Legacy-Namen kein src-members ableiten: Die verlorene Registry lässt sich nicht zuverlässig erraten.

Damit besitzt ein gültiges Objekt zwei Lesarten. Der moderne Resolver folgt RIPE::RS-SECOND. Der alte Resolver sieht RS-SECOND und benutzt seine lokale Quellenauswahl. Die Validierung beweist die Übereinstimmung der entschärften Namen, nicht die Identität der abgerufenen Objekte.

Der neue Ausdrucksraum wird sogar begrenzt, um die alte Projektion eindeutig zu halten. RIPE::AS-OTHER und ARIN::AS-OTHER dürfen nicht gemeinsam in src-members stehen, weil beide nach Entfernung des Präfixes zu AS-OTHER werden. Das alte Format kann die zwei Objekte nicht unterscheiden.

Diese Beschränkung ist ein bewusster Migrationskompromiss. Sie zeigt, weshalb „von der Registry akzeptiert“ und „von allen Verbrauchern gleich aufgelöst“ unterschiedliche Prüfaussagen sind.

Ein Beleg für jede Auflösungskante

Die fertige Member-Liste hat ihren Berechnungsweg verloren. Gleiche Stückzahlen können verschiedene Mitglieder verbergen. Identische Mengen können auf unterschiedlichen Mirrors oder Auswahlregeln beruhen und beim nächsten Refresh auseinanderlaufen. Deshalb schlägt dieser Artikel einen Auflösungsherkunftsbeleg vor — als Betreiberpraxis, nicht als IETF-Feld.

Der Beleg erfasst Root-Schlüssel und anfängliche Registry-Einschränkung, Resolverprodukt und -version, aktivierte Unterstützung für src-members und alle sichtbaren Registries. Für jede Quelle wird ein überprüfbarer Serial, Snapshot oder Inhalts-Hash samt Abrufzeit festgehalten.

Jede rekursive Kante erhält einen Datensatz: Registry und Schlüssel des Elternobjekts, gelesenes Attribut, wörtlicher Kindverweis, explizite oder implizite Quellenwahl, tatsächlich gewählte Registry und Objekt-Hash. Unbekannte Registries, fehlende Objekte, Kollisionen, Zyklen sowie Tiefen- und Größenlimits sind Ergebnisse. Sie gehören nicht ausschließlich in flüchtige Debug-Logs.

Während der Migration werden zwei Resultate gebildet. Eines folgt der scope-fähigen Semantik. Das andere reproduziert die tatsächlich noch eingesetzten Legacy-Werkzeuge. Beide Hashes und die genaue Mengendifferenz werden gespeichert. Eine zugelassene Abweichung benötigt Prüfer, Begründung, Ablaufdatum, betroffene Verbraucher und Rollback-Befugnis.

Zum Schluss bindet der Beleg die Auflösung an Compiler-Version, Filter, Normalisierung, Konfigurations-Hash, Change-Referenz und Deployment-Ziel. Ohne diesen Abschluss kann eine Organisation einen korrekten Datenabruf nachweisen, aber nicht, dass genau das geprüfte Artefakt installiert wurde.

Nachvollziehbarkeit ersetzt keine Autorität

Ein sauberer Herkunftspfad macht ein IRR-Objekt nicht automatisch maßgeblich für Route Origin, Ressourceninhaberschaft oder Geschäftsbeziehungen. Er ersetzt RPKI nicht. Er macht die Transformation und die Genehmigung prüfbar.

Geheime Policies oder Zugangsdaten müssen dafür nicht veröffentlicht werden. Objekt- und Ergebnis-Hashes, Quellkennungen, Rollen, Differenzen und Change-Referenzen erhalten die Beweiskette, ohne vollständige Routerkonfigurationen offenzulegen.

Auch eine Differenz zwischen modernem und altem Ergebnis ist kein automatisches Urteil. Der qualifizierte Verweis kann die alte Mehrdeutigkeit richtig beheben. Solange jedoch ein Legacy-Generator bei einem Dienstleister oder in einer Geschäftseinheit produktiv ist, bleibt seine Lesart operativ relevant. Die Differenz verlangt eine benannte Entscheidung über Zielergebnis, Verbraucher, Frist und Rückweg.

Der Entwurf verlangt zudem, Zyklen zu erkennen, und empfiehlt Grenzen für Tiefe oder Ergebnisgröße. Eine Änderung dieser Parameter kann die Policy verändern, ohne dass ein RPSL-Objekt geändert wird. Deshalb gehören auch sie in Beleg und Freigabe.

src-members macht einen bisher verborgenen Quellenentscheid sichtbar. Gute Governance verhindert, dass der Export ihn gleich wieder löscht. Das Präfix endet nach einem Sprung; der Verantwortungsnachweis erst nach dem Deployment.

Quellen

  1. Datatracker-Eintrag zu Registry-scoped RPSL Members
  2. Versionsgeschichte des aktuellen Entwurfs
  3. Revision 00 als HTML
  4. Revision 00 als Text
  5. Revision 00 als XML
  6. Datensatz des Vorgängerentwurfs
  7. Geschichte des Vorgängerentwurfs
  8. Revision 01 des Vorgängers
  9. Auftrag der GROW Working Group
  10. Dokumente der GROW Working Group
  11. Mitteilung über die GROW-Adoption
  12. Quellrepository der Autoren
  13. RFC 2622: Routing Policy Specification Language
  14. RFC 4012: RPSL Next Generation
  15. RFC 2725: Sicherheit des Routing-Policy-Systems
  16. RFC 2650: RPSL in der Praxis
  17. RFC 7682: Überlegungen zu IRRs und Policy-Konfiguration
  18. RFC 7909: Problemdefinition und RPKI für Route-Origin-Validierung
  19. Lu Heng: minimale Anfangsspezifikation, lokalisierte Zukunftsentscheidung und freiwillige Einführung
  20. Lu Heng: The Policy Mirror