Wer kontrolliert die ROA in einem IPv4-Lease?

Zusammenfassung

Eine Route Origin Authorization (ROA) ist eine signierte Erklärung, dass ein benanntes autonomes System bestimmte Präfixe ankündigen darf. Sie ist keine Eigentumsübertragung, kein Befehl an Router, keine Garantie, dass die Route unbedenklich ist, und kein Nachweis, dass das benannte AS im Rahmen eines privaten Leases weiterhin berechtigt ist.
Bei den meisten Leases bleibt der Leasinggeber der direkte Ressourceninhaber und steht daher der RPKI-Zertifizierungskette am nächsten. Der Leasingnehmer betreibt das Netzwerk und weiß, welche Ursprungs-ASes und spezifischeren Routen betrieblich notwendig sind. Der Upstream führt oder filtert die Route. Die RIR betreibt einen Trust Anchor oder einen übergeordneten Zertifizierungsdienst. Dies sind unterschiedliche Befugnisse.
Gehostetes und delegiertes RPKI ändern die Verwahrung und Ausführung, nicht das zugrunde liegende Handelsgeschäft. Ein gehosteter Dienst platziert Schlüsseloperationen und Veröffentlichung bei einer RIR; ein delegierter Dienst erlaubt dem Inhaber, eine CA und normalerweise ihren privaten Schlüssel zu betreiben. Keine der beiden Vereinbarungen gibt einem Leasingnehmer allein zeitnahe Rechte oder schützt ihn vor einer strittigen Löschung.
Jeder Lease sollte einen Autorisierungsplan beifügen, der die genauen Präfixe, erlaubten Ursprungs-ASes, maximale Längen, Start- und Endzeitfenster, die Frist für gewöhnliche Änderungen, die Notfallfrist, Genehmiger, Authentifizierungskanäle und aufzubewahrende Nachweise benennt. Ein allgemeines Versprechen, eine Autorisierungsbescheinigung auszustellen, ist nicht ausreichend.
Vertragszeit und RPKI-Zeit müssen bewusst aufeinander abgestimmt werden. Gehostete Dienste können signierte Objekte automatisch erneuern, Caches aktualisieren sich in ihrem eigenen Rhythmus, und eine Route kann nach Ablauf der kommerziellen Laufzeit sichtbar bleiben. Ein Ablauf um Mitternacht ist daher weder ein sofortiger technischer Widerruf noch ein sicherer Grund, die einzige gültige ROA zu löschen, bevor der Verkehr migriert wurde.
Der Notfallzugriff sollte eng gefasst und redundant sein. Ein Leasingnehmer benötigt eine Möglichkeit, schnell einen vorab genehmigten DDoS-Abwehr- oder Ersatzursprung hinzuzufügen, während der Leasinggeber Grenzen braucht, die eine unbegrenzte Delegation verhindern. Gegenseitige Genehmigung, begrenzte Präfixe, kurzlebige Notfallbefugnisse, unabhängige Protokolle und eine Überprüfung nach dem Vorfall können beiden Anforderungen gerecht werden.
Ein Handelsstreit sollte nicht durch Überraschung des globalen Routingsystems ausgetragen werden. Außer bei einem aktiven Sicherheitsnotfall sollte die Löschung der ROA einer Ankündigung folgen, einem kurzen Kontinuitätsfenster, einer unabhängigen Eskalation und einem koordinierten Routenrückzug. Der endgültige Widerruf muss sicher sein; der Weg dorthin sollte Kunden nicht zu Druckmitteln machen.

Der Lease trennt Nutzung von Bescheinigung

Die unangenehme Frage bei einem IPv4-Lease ist nicht, wem der Router gehört. Es geht darum, wer die kryptografische Erklärung abgeben kann, auf die sich andere Router verlassen können.

Der Leasingnehmer kann das Ursprungs-AS konfigurieren, das Präfix ankündigen, Kunden bedienen, Missbrauchsmeldungen beantworten und die Transitkosten bezahlen. Wenn das Präfix jedoch auf den Leasinggeber zertifiziert bleibt, kann der Leasingnehmer möglicherweise die ROA, die seine eigene Live-Ankündigung beschreibt, nicht erstellen, ändern oder löschen. Der Leasinggeber kann wirtschaftlich passiv und technisch entscheidend sein. Ein vergessenes Portal-Konto oder ein nicht verfügbarer Unterzeichner kann eine routinemäßige Routing-Änderung in ein Ausfallrisiko verwandeln.

Das macht Leasing nicht fehlerhaft. Es bedeutet, dass ein Lease zwischen zwei Autoritätssystemen liegt. Das Vertragsrecht bestimmt, was eine Partei der anderen versprochen hat. RPKI bestimmt, ob eine signierte Autorisierung durch eine Kette validiert werden kann, die in der Nummernressourcen-Hierarchie verwurzelt ist. BGP bestimmt, welche Pfade Netzwerke tatsächlich ankündigen und auswählen. Transitverträge legen fest, was ein Upstream akzeptiert. Keines dieser Systeme liest automatisch die anderen.

RFC 9582definiert eine ROA als signiertes Objekt, mit dem ein Adressblock-Inhaber ein AS autorisiert, Routen zu einem oder mehreren Präfixen zu veranlassen. Der Sicherheitsabschnitt ist für Governance ungewöhnlich nützlich: RPKI bietet Autorisierung statt Identitätsauthentifizierung oder Nichtabstreitbarkeit. Das Objekt beweist, dass ein gültiger Zertifizierungspfad die Erklärung unterstützt hat, als sie von vertrauenden Parteien verarbeitet wurde. Es veröffentlicht nicht den Lease, den Preis, den Kunden, den wirtschaftlich Berechtigten, den Grund für die Route oder die Frist im kommerziellen Vertrag.

Diese Unterscheidung widerlegt zwei gängige Abkürzungen. Die erste besagt, dass die Partei, die die ROA erstellen kann, der wirtschaftliche Eigentümer sein muss. Das folgt nicht daraus. Die zweite besagt, dass die Partei, die als Ursprung in der ROA genannt wird, die Adressrechte kontrollieren muss. Auch das folgt nicht. Ein Inhaber kann das AS eines Kunden, einen Upstream, ein Cloud-Netzwerk oder einen DDoS-Abwehranbieter autorisieren, ohne die Ressource zu übertragen. Das signierte Objekt ist bewusst enger gefasst als die umgebende Beziehung.

Die richtige Frage ist daher nicht einfach: „Wer kontrolliert die ROA?" Es ist eine Reihe von Fragen: Wer kann eine Änderung verlangen? Wer entscheidet, dass die Anforderung in den Rahmen des Leases fällt? Wer betreibt das Signatursystem? Wer kann eine unsichere Änderung stoppen? Wer kann handeln, wenn die primäre Partei nicht erreichbar ist? Wer trägt den Verlust, wenn eine versprochene Änderung verspätet ist? Wer muss die Autorisierung aufheben, wenn das Recht zur Routenankündigung endet?

Ein Lease, der nur die erste Frage beantwortet, überlässt den Rest der Improvisation.

Vier Akteure halten vier verschiedene Arten von Macht

Leasinggeber, Leasingnehmer, Upstream und RIR-CA werden oft beschrieben, als seien sie Punkte in einer einzigen Befehlskette. Sie sind besser als vier Akteure mit sich überschneidender, aber nicht identischer Macht zu verstehen.

Der Leasinggeber behält normalerweise die registrierte Beziehung, aus der die Ressourcenzertifizierung abgeleitet wird. Bei einem gehosteten RPKI-Dienst kann ein autorisierter Benutzer der Organisation des Leasinggebers ROA-Konfigurationen über die Schnittstelle der RIR erstellen. Bei einer delegierten Vereinbarung kann der Leasinggeber seine eigene CA betreiben und den entsprechenden privaten Schlüssel besitzen. Die entscheidende Fähigkeit des Leasinggebers ist die Bescheinigung: Er kann bewirken, dass eine Aussage über ein Präfix und ein Ursprungs-AS in den validierten RPKI-Satz aufgenommen oder daraus entfernt wird.

Der Leasingnehmer verfügt über betriebliches Wissen. Er kennt den beabsichtigten Ursprung, das Upstream-Design, den Stand der Kundenmigration, Traffic-Engineering-spezifischere Routen, DDoS-Abwehrvereinbarungen und das Datum, an dem eine neue Route funktionieren muss. Seine entscheidende Fähigkeit ist die Nutzung: Er oder seine Anbieter können BGP-Ankündigungen konfigurieren und veranlassen. Diese Fähigkeit kann auch dann bestehen, wenn die Route RPKI Invalid wird, denn RPKI schaltet BGP nicht ab. Die praktischen Folgen hängen davon ab, welche Netzwerke die Routenursprungsvalidierung anwenden und wie.

Der Upstream hat Annahme- und Verbreitungsmacht. Er kann eine Autorisierungsbescheinigung, ein IRR-Objekt, eine passende ROA, vertragliche Nachweise oder eine Kombination verlangen. Er kann aus seinen eigenen Aufzeichnungen, einem IRR, RPKI-validierten Nutzdaten oder manueller Prüfung Kunden-Präfixfilter erstellen. Er kann eine ansonsten gültige Route ablehnen, weil die Kundenbeziehung nicht verifiziert ist, oder eine Not Found-Route gemäß seiner Richtlinie befördern. Eine gültige ROA ist ein relevanter Beleg, kein Befehl an den Upstream.

Die RIR-CA befindet sich in der Zertifizierungshierarchie.RFC 6480beschreibt eine Architektur, die auf die Zuweisung von Nummernressourcen abgestimmt ist. Dienste der RIR stellen das übergeordnete Ressourcenzertifikat aus oder pflegen es, hosten die Signierung für viele Inhaber, veröffentlichen Material und verbinden Änderungen an zertifizierten Ressourcen mit der Hierarchie. Die RIR ist bei den meisten Leases keine Partei und kennt normalerweise nicht deren vollständige kommerzielle Bedingungen. Ihr System kann das Konto des Inhabers authentifizieren und die Ressourcenabdeckung validieren, ohne zu wissen, ob eine Rechnung des Leasingnehmers strittig ist.

Diese Befugnisse sollten nicht zusammengefasst werden. Die Fähigkeit eines Leasinggebers, eine ROA zu löschen, bedeutet nicht, dass er den Router des Leasingnehmers kontrollieren sollte. Die Fähigkeit eines Leasingnehmers, eine Ankündigung zu senden, bedeutet nicht, dass er uneingeschränkte Signierungsbefugnis über das Aggregat des Leasinggebers haben sollte. Ein Filter eines Upstreams regelt nicht den Lease. Ein Zertifikat einer RIR entscheidet nicht über die wirtschaftliche Nutzung.

Gute Governance beginnt mit der Einsicht, dass kein einzelner Akteur die gesamte Beziehung überblickt.

Eine ROA autorisiert einen Ursprung, nicht eine Route in all ihren Dimensionen

Die Enge der ROA ist eine Stärke, aber sie wird gefährlich, wenn Verträge sie zu weit fassen.

Eine ROA identifiziert ein Ursprungs-AS und ein oder mehrere Präfixe. Sie kann eine maximale Länge enthalten, die bestimmte spezifischere Ankündigungen erlaubt. Wenn mehrere ASes autorisiert sind, dasselbe Präfix anzukündigen, sind separate ROAs erforderlich. Das Objekt gibt nicht an, welcher Upstream die Route führen darf, welcher AS-Pfad akzeptabel ist, ob der Ursprung über einen aktuellen Servicevertrag verfügt, welcher Kundenverkehr zu den Adressen gehört oder ob eine Ankündigung geografisch erwartet wird.

Deshalb kann ein „RPKI-konformer Lease" mehr verbergen als offenbaren. Ein Leasinggeber kann eine technisch gültige ROA für die ASN einer falschen Geschäftspartei erstellen. Ein Leasingnehmer kann weiterhin über den autorisierten Ursprung ankündigen, nachdem ein Servicevertrag beendet wurde. Ein autorisiertes AS kann versehentlich oder absichtlich eine spezifischere Ankündigung leaken, die durch eine zu breite maximale Länge erlaubt wird. Eine Route kann RPKI Valid sein und dennoch betrieblich falsch oder missbräuchlich sein.

RFC 6483warnt, dass eine ROA andere Ankündigungen beeinflussen kann, die denselben Adressraum betreffen: Routen von nicht aufgeführten Ursprüngen oder spezifischere Routen jenseits der erlaubten Länge können Invalid werden. Es wird empfohlen, alle legitim autorisierten Ursprünge und relevanten spezifischeren Routen zu berücksichtigen.RFC 7115behandelt die Ursprungsvalidierung ebenfalls als betriebliche Eingabe und nicht als universelles Routenauswahlurteil.

Für einen Lease bedeutet dies, dass der Plan nicht einfach sagen kann: „Der Leasinggeber wird eine ROA erstellen." Er muss die genauen Präfix-Ursprungs-Paare angeben und die Richtlinie für spezifischere Routen erläutern. Wenn ein /20 nur als /20 von der ASN des Leasingnehmers angekündigt wird, sollte eine unnötig großzügige maximale Länge nicht aus Bequemlichkeit gewährt werden. Wenn der Leasingnehmer während der Migration /24-Ankündigungen von zwei Ursprüngen benötigt, sollten beide Ursprünge und der temporäre Zeitraum explizit sein.

Die Rolle des Upstreams bleibt getrennt. DieMANRS-Maßnahmen für Netzwerkbetreiberfordern Betreiber auf, die Korrektheit ihrer eigenen und der Kundenankündigungen sicherzustellen, nutzbare Kontakte zu pflegen und Informationen zu veröffentlichen, die andere validieren können. Ein Transit-Provider, der nur prüft, ob eine ROA existiert, erfüllt diese Aufgabe nicht. Er muss weiterhin wissen, dass sein Kunde die Partei ist, die autorisiert ist, ihn mit der Führung der Route zu beauftragen.

Der Lease sollte daher mehrere koordinierte Fakten versprechen, keinen magischen Status: kommerzielle Erlaubnis des Leasinggebers, betriebliche Anweisung des Leasingnehmers, Ursprungsautorisierung in RPKI, genaue Routing-Informationen und Akzeptanz durch den beabsichtigten Upstream.

Gehostetes RPKI konzentriert die Ausführung auf das Konto des Inhabers

Gehostetes RPKI ist attraktiv, weil es den größten Teil der kryptografischen Verwaltung vom Ressourceninhaber fernhält. Diese Bequemlichkeit verdeutlicht auch, wo die Abhängigkeit des Leases liegt.

DerLeitfaden für die gehostete CA von RIPE NCCbesagt, dass der gehostete Dienst ROA-Objekte aus Konfigurationen signiert, veröffentlicht und erneuert, die von einem autorisierten Konto verwaltet werden. Der Benutzer verwaltet die Informationen zu beabsichtigtem Ursprung und Präfix; der Dienst kümmert sich um Schlüssel, Objekterneuerung und Veröffentlichung. DieDokumentation zum gehosteten RPKI von ARINlegt die CA und Signierung ebenfalls bei ARIN und besagt, dass nachgelagerte Organisationen ihren Upstream-Provider beauftragen müssen, ROAs in ihrem Namen einzureichen, wenn sie nicht direkt teilnehmen können.

Für einen Leasinggeber kann der gehostete Dienst betriebliche Ausfälle reduzieren. Es gibt kein privates CA-Repository, das der Leasingnehmer überwachen müsste, und keinen Signierschlüssel, der auf einem Mitarbeiter-Laptop platziert werden müsste. Für einen Leasingnehmer wird jedoch die Kontoverwaltung zur Schlüsselfrage. Welche Personen beim Leasinggeber können eine Anforderung genehmigen? Gibt es eine Rund-um-die-Uhr-Abdeckung? Kann der Leasingnehmer eine eingeschränkte Rolle erhalten, oder muss jede Änderung vom Inhaber übertragen werden?

Was passiert, wenn das Konto des Leasinggebers während einer Identitätsprüfung, eines Unternehmenswechsels oder eines Streitfalls gesperrt wird?

Portalzugänge sollten nicht leichtfertig geteilt werden. Dem Leasingnehmer die allgemeinen Anmeldedaten des Leasinggebers zu geben, kann nicht zusammenhängende Präfixe, andere Kunden und destruktive Aktionen offenlegen. Es verwischt auch die Zurechenbarkeit: Der Leasinggeber kann später nicht mehr feststellen, ob sein Mitarbeiter, Auftragnehmer oder Kunde eine Änderung vorgenommen hat. Selbst wenn eine Schnittstelle mehrere Benutzer unterstützt, sollte die Autorisierung auf die Organisation und die Aufgaben beschränkt sein, die jede Person ausführen darf.

Das sicherere gehostete Modell behandelt den Leasingnehmer als authentifizierten Anforderer und den Leasinggeber als begrenzten Genehmiger. Anforderungen nutzen einen definierten Kanal, identifizieren den Lease und die Präfixe, enthalten den vorgeschlagenen Ursprung und die maximale Länge und erhalten einen Transaktionsdatensatz. Routinemäßige Änderungen haben eine Servicefrist. Notfalländerungen nutzen einen schnelleren Kanal mit separater Authentifizierung. Zwei Personen beim Leasinggeber sollten handlungsfähig sein, und der Leasingnehmer sollte mindestens zwei genehmigte Anforderer haben.

Automatisierung kann Verzögerungen reduzieren, sollte aber den Autorisierungsplan durchsetzen und nicht umgehen. Eine Anforderung für ein aufgeführtes Präfix, eine gelistete ASN und die erlaubte maximale Länge kann für eine schnelle Genehmigung in Frage kommen. Eine Anforderung zur Autorisierung einer unbekannten ASN oder eines breiteren spezifischeren Bereichs sollte zur menschlichen Prüfung angehalten werden. Der Unterschied liegt in der Automatisierung eines bekannten Versprechens und der stillschweigenden Erweiterung des Versprechens.

Der gehostete Dienst löst den Schlüsselbetrieb. Er löst nicht die kommerzielle Delegation, es sei denn, der Vertrag und die Kontorollen tun dies.

Delegiertes RPKI verschiebt den Schlüssel, nicht die übergeordnete Beziehung

Delegiertes RPKI kann einem Ressourceninhaber mehr technische Autonomie geben. Es kann auch den irrigen Glauben erzeugen, der Inhaber sei jeder Upstream-Abhängigkeit entkommen.

DerVergleich von gehosteten und delegierten Diensten von RIPE NCCbesagt, dass ein delegierter Betreiber sein Ressourcenzertifikat und den entsprechenden privaten Schlüssel kontrolliert und wählen kann, wo veröffentlicht wird. DieBereitstellungsoptionen von ARINgeben an, dass ein direkter Inhaber seine eigene CA betreiben, ROAs signieren und im delegierten Modell Ressourcenzertifikate für Kunden ausstellen kann. APNIC identifiziert in seinemMaterial zur Ressourcenzertifizierungden selbst gehosteten Modus ebenfalls als delegiertes RPKI.

Diese Architektur kann eine direktere Aufteilung unterstützen. Ein erfahrener Leasinggeber kann eine übergeordnete CA betreiben und ein untergeordnetes Ressourcenzertifikat ausstellen, das auf die Präfixe des Leasingnehmers beschränkt ist. Der Leasingnehmer kann dann Objekte innerhalb dieses begrenzten Satzes signieren, ohne Befugnis über die anderen Ressourcen des Leasinggebers zu erhalten. Am Ende des Leases kann der Leasinggeber das untergeordnete Zertifikat widerrufen oder gemäß der vereinbarten Reihenfolge auslaufen lassen.

Die scheinbare Eleganz bringt betriebliche Pflichten mit sich. Jemand muss den privaten Schlüssel sichern, die CA warten, aktuelle Objekte veröffentlichen, Manifeste und Widerrufsinformationen verwalten, die Verfügbarkeit überwachen, Schlüssel rollen und Wiederherstellungszugänge bewahren. DieRichtlinie von RIPE NCC zu dauerhaft nicht funktionsfähigen delegierten CAsveranschaulicht die Folgen eines längeren Ausfalls: Nach längerer Unfähigkeit, aktuelles Material zu entdecken und zu validieren, kann die übergeordnete Instanz das delegierte Ressourcenzertifikat widerrufen. Delegation ist Kontrolle verbunden mit Wartung, keine einmalige Übergabe.

Die übergeordnete Beziehung bleibt ebenfalls bestehen. Ein delegiertes Zertifikat existiert innerhalb einer Hierarchie. Wenn sich die zertifizierten Ressourcen ändern oder das übergeordnete Zertifikat widerrufen wird, ist die untergeordnete Autorität betroffen.RFC 8211untersucht nachteilige oder fehlerhafte Handlungen von CAs und Repository-Managern, gerade weil der lokale Besitz eines Schlüssels hierarchische und Veröffentlichungsabhängigkeiten nicht beseitigt.

Für viele Leasingnehmer wäre der Betrieb einer CA unverhältnismäßig. Für große Betreiber mit häufigen Ursprungswechseln, mehreren Upstreams oder strengen Kontinuitätsanforderungen kann eine begrenzte Delegation die Kosten wert sein. Die Wahl sollte von der Änderungshäufigkeit, der Ausfalltoleranz, der Personalkapazität und dem Portfolio-Design des Leasinggebers abhängen, nicht vom Prestige, einen Schlüssel zu besitzen.

Am wichtigsten ist, dass delegiertes RPKI nicht zu einer informellen dauerhaften Gewährung werden darf. Die untergeordneten Ressourcen, die Zertifikatslaufzeit, die Erneuerungsregel, Widerrufsereignisse, Repository-Pflichten, Notfallkontakte und der Nachweis der Vernichtung oder Übertragung beim Ausstieg gehören alle in den Lease. Den privaten Schlüssel näher zum Leasingnehmer zu verlagern, verringert eine Verzögerung, erhöht aber die Bedeutung einer disziplinierten Beendigung.

Der Autorisierungsplan ist das fehlende kommerzielle Instrument

Die Hauptvereinbarung kann das wirtschaftliche Geschäft festlegen. Ein separater Autorisierungsplan sollte das Routing-Sicherheitsgeschäft in Begriffen festlegen, die sowohl ein Ingenieur als auch ein Anwalt prüfen können.

Der Plan beginnt mit exakten CIDRs. Dann listet er jedes erlaubte Ursprungs-AS, die juristische Person, die dieses AS kontrolliert, die beabsichtigte Transit- oder Hosting-Beziehung und die erlaubte Präfixlänge für jede Ankündigung auf. Wenn mehrere Ursprünge temporär sind, gibt der Plan Start- und Entfernungsdaten an. Falls der Leasingnehmer einen DDoS-Abwehranbieter nutzen darf, kann dessen ASN vorab genehmigt werden, ohne bis zu einem Vorfall aktiviert zu werden.

Als nächstes kommen die Rollen. Nennen Sie den Serviceverantwortlichen des Leasinggebers und den Ersatzgenehmiger, den Netzwerkleiter des Leasingnehmers und den Ersatzanforderer sowie die Kontakte bei jedem beabsichtigten Upstream. Verwenden Sie Rollenadressen und authentifizierte Kanäle, nicht nur namentlich genannte Mitarbeiter. Mitarbeiter gehen; die Autorisierung sollte überleben, ohne veraltete persönliche Konten zurückzulassen.

Der Plan setzt dann Fristen. Eine normale Anforderung kann die Erledigung innerhalb eines Geschäftstages erfordern. Eine geplante Migration kann eine Vorankündigung von fünf oder zehn Geschäftstagen verlangen. Ein schwerer Ausfall kann eine Rückmeldung innerhalb von fünfzehn Minuten und eine begrenzte Änderung innerhalb von sechzig Minuten erfordern. Die genauen Zahlen hängen vom Dienst ab, aber Schweigen ist kein Servicelevel.

Der Änderungsdatensatz sollte die Anforderungszeit, den authentifizierten Anforderer, das betroffene Präfix, den alten und neuen Ursprung, die maximale Länge, den geschäftlichen Grund, die Genehmigung, die Veröffentlichungsbeobachtung und die Validierungsbeobachtung enthalten. Dies ist keine Bürokratie um ihrer selbst willen. Wenn eine Route Invalid wird, müssen die Parteien wissen, ob die ROA nie geändert wurde, geändert aber noch nicht sichtbar ist, falsch geändert wurde oder durch eine andere überdeckende ROA unwirksam gemacht wurde.

Geben Sie schließlich an, welche Anforderungen der Leasinggeber ablehnen darf. Eine Anforderung außerhalb des geleasten Präfixes, eine ASN, die nicht von einem genehmigten Betreiber kontrolliert wird, eine maximale Länge, die breiter ist als das vereinbarte Routing-Design, oder eine Änderung, die die Routen eines anderen Kunden ungültig machen würde, können eine Änderung statt sofortiger Ausführung erfordern. Eine Ablehnung sollte begründet und mit Zeitstempel versehen sein, nicht eine vage Berufung auf Sicherheit.

Der Plan sollte versioniert sein mit Signaturen oder einer gleichwertigen authentifizierten Akzeptanz. Der aktive ROA-Satz sollte bei der Aktivierung, nach jeder genehmigten Änderung, bei periodischer Überprüfung und vor der Beendigung damit verglichen werden. Die Vereinbarung hat dann eine messbare Antwort auf die Kontrolle: Der Leasinggeber kontrolliert die Zertifizierung innerhalb eines vorab vereinbarten Mandats; der Leasingnehmer kontrolliert betriebliche Anforderungen im selben Mandat; keiner darf das Risiko der anderen Partei stillschweigend vergrößern.

Vertragszeit und RPKI-Zeit sind unterschiedliche Uhren

Leases verwenden Daten, weil Daten für Gerichte und Finanzteams lesbar sind. Die Routing-Sicherheit arbeitet über Veröffentlichung und Abruf, die selten dieselbe Grenze teilen.

Ein Lease könnte am Montag um 00:00 UTC beginnen. Die ROA kann früher erstellt werden, damit die Caches der vertrauenden Parteien sie vor der ersten Ankündigung abrufen können. Ein gehosteter Dienst kann das signierte Objekt automatisch erneuern, solange seine Konfiguration aktiv bleibt. Wenn der Lease endet, kann das kommerzielle Recht ablaufen, obwohl die zuletzt veröffentlichte Autorisierung gültig und sichtbar bleibt. Umgekehrt beweist das Löschen der Konfiguration um 00:00 Uhr nicht, dass jede vertrauende Partei die entsprechenden validierten Nutzdaten um 00:01 Uhr entfernt hat.

Der Vertrag benötigt daher drei Zeitpunkte statt einem. Der Zeitpunkt der Autorisierungsbereitschaft ist, wenn die beabsichtigte Route eine sichtbare gültige Autorisierung hat und der Upstream seine Filter bestätigt hat. Der Zeitpunkt der Servicenutzung ist, wenn der Leasingnehmer ankündigen und Kundenverkehr auf dem Präfix platzieren darf. Der Zeitpunkt des Autorisierungsendes ist, wenn der alte Ursprung nicht mehr als in RPKI erlaubt dargestellt werden darf, nachdem der Verkehr abgezogen wurde.

Diese Zeitpunkte können sich ohne Widerspruch überschneiden. Eine ROA kann vor der kommerziellen Nutzung vorbereitet werden, sofern dem Leasingnehmer eine frühe Ankündigung untersagt ist. Sie kann während eines geordneten Rückzugs kurz bestehen bleiben, sofern dem Leasingnehmer untersagt ist, neue Kunden hinzuzufügen, und er den Verkehr reduzieren muss. Die verbleibende Autorisierung ist kontrollierte Übergangskapazität, keine Verlängerung der ökonomischen Laufzeit des Leases.

Dies erklärt auch, warum der Ablauf einer ROA ein schlechter Ersatz für die Beendigung ist. Eine lange Zertifikats- oder Objektlebensdauer kann den Lease überdauern. Eine kurze Lebensdauer kann vermeidbare Erneuerungsrisiken während der Laufzeit schaffen. Gehostete Systeme können weit vor dem Ablauf erneuern, während delegierte Systeme von lokalem Betrieb abhängen. Das maßgebliche Ereignis sollte eine explizite Endanweisung sein, gestützt durch Beobachtung, nicht die Hoffnung, dass ein Timer mit dem Geschäft zusammenfällt.

Die umgekehrte Fehlanpassung ist ebenfalls wichtig. Wenn ein Leasinggeber die ROA löscht, bevor die Ersatzadressen oder der alternative Ursprung des Leasingnehmers bereit sind, können Netzwerke, die Invalid-Routen ablehnen, aufhören, Verkehr zu befördern. Kunden tragen den Ausfall, selbst wenn der Leasinggeber vertraglich im Recht bezüglich des Enddatums ist. Wenn der Leasinggeber sie nie löscht, behält der ehemalige Leasingnehmer eine schwächere, aber reale Möglichkeit, eine Route zu veranlassen, die einige Validatoren als autorisiert betrachten werden.

Zeitliche Abstimmung ist daher keine Nachsicht. Es ist die Disziplin, die Autorisierung vor der Abhängigkeit erscheinen und nach der Abhängigkeit verschwinden zu lassen, mit so wenig unsicherer Überlappung, wie der Dienst tolerieren kann.

Notfalländerungsrechte müssen vor dem Notfall gestaltet werden

Der aufschlussreichste Test für ROA-Governance ist nicht eine geplante Migration. Es ist ein Samstag-Ausfall, wenn der genehmigte Ursprung keinen Verkehr befördern kann und der einzige Ingenieur, der normalerweise Änderungen signiert, schläft oder nicht erreichbar ist.

Ein Notfall kann einen neuen Transit-Provider, eine DDoS-Abwehr-ASN, ein Backup-Rechenzentrum, einen Ersatzursprung nach einem Router-Ausfall oder eine temporäre spezifischere Ankündigung erfordern. Er kann auch kompromittierte RPKI-Anmeldeinformationen oder eine versehentliche Autorisierung umfassen, die legitime Routen Invalid macht. Die Partei, die den Vorfall beobachtet, kann der Leasingnehmer, Upstream, Leasinggeber oder ein externes Netzwerk sein.

Der Lease sollte Kategorien vorab autorisieren, nicht unbegrenztes Handeln. Eine Liste von Standby-ASNs kann bei der Unterzeichnung verifiziert werden. Eine maximale Notfall-Präfixlänge kann festgelegt werden. Dem Leasingnehmer kann erlaubt werden, nur die Präfixe zu aktivieren, die er least, und nur für einen kurzen Zeitraum. Jede breitere Änderung erfordert einen zusätzlichen Genehmiger. Dies gibt dem Betreiber Geschwindigkeit, ohne ihm einen dauerhaften Blankoscheck auszustellen.

Die Authentifizierung muss denselben Vorfall überstehen. Wenn gewöhnliche Anforderungen von einer E-Mail-Domäne abhängen, die hinter dem betroffenen Präfix gehostet wird, kann der Kanal versagen, wenn er benötigt wird. Nutzen Sie mindestens eine Out-of-Band-Methode und pflegen Sie Kontakte bei beiden Organisationen. Der Leasinggeber sollte einen Anforderungscode, eine benannte Rolle, einen Rückruf oder eine kryptografische Genehmigung verlangen, die dem Risiko der Parteien angemessen ist. Es geht darum, Identitätsdiebstahl zu widerstehen, ohne die Identitätsprüfung zu einer mehrstündigen Barriere zu machen.

Die Änderung selbst sollte umkehrbar sein. Fügen Sie den eng erforderlichen Ursprung hinzu; erweitern Sie keine nicht zusammenhängenden ROAs. Setzen Sie eine Ablauf- oder Überprüfungsfrist für die Notfallautorisierung. Bestätigen Sie, dass die neue Route beobachtet und akzeptiert wird, bevor der alte Pfad zurückgezogen wird. Entfernen Sie nach dem Vorfall die temporäre Befugnis und gleichen Sie den aktiven Satz mit dem Plan ab.

Die Haftung sollte kontrollierbaren Verzögerungen folgen. Wenn der Leasingnehmer es versäumt hat, genehmigte Kontakte zu pflegen, oder eine nicht gelistete ASN ohne Nachweis verlangt hat, sollte er diese Konsequenz tragen. Wenn der Leasinggeber eine vereinbarte Notfallfrist trotz einer gültigen Anforderung versäumt hat, kann eine Gebührengutschrift allein den Kundenverlust nicht widerspiegeln; die Vereinbarung benötigt möglicherweise eine Schadensersatzobergrenze, ein Kündigungsrecht oder das Recht, zu einer begrenzten Delegation überzugehen.

Wenn der Upstream eine Route abgelehnt hat, obwohl er alle erforderlichen Nachweise erhalten hat, gelten seine Servicebedingungen gesondert.

Notfallrechte sollten selten ausgeübt werden. Ihr Wert liegt darin, dass jede Partei den Pfad unter Druck kennt, nicht darin, dass der Leasinggeber zu einem 24-Stunden-Routing-Schalter für Routineänderungen wird.

Die maximale Länge ist eine kommerzielle Risikoentscheidung

Das technisch aussehendste Feld in einer ROA kann große kommerzielle Konsequenzen haben.maxLengthbestimmt, wie spezifisch eine Ankündigung des autorisierten AS sein darf, während sie mit dieser ROA konsistent bleibt.

Eine zu enge Autorisierung kann eine legitime Traffic-Engineering- oder DDoS-Abwehrroute ungültig machen. Eine zu breite kann spezifischere Ankündigungen erlauben, die für den Lease nie notwendig waren. Die Entscheidung beeinflusst die Fehlereingrenzung, die Upstream-Praxis und den Bereich von Routen, die Validatoren als autorisiert akzeptieren können.

Der häufige Entwurfsfehler ist, das Maximum für jedes geleaste IPv4-Aggregat auf /24 zu setzen, weil /24 in der globalen Tabelle allgemein akzeptiert wird. Das mag betrieblich bequem sein, delegiert aber mehr Befugnis, als ein Leasingnehmer benötigt, der nur ein Aggregat ankündigt. Wenn ein /19 immer als /19 veranlasst wird, schafft ein /24-Maximum Raum für 32 separate spezifischere Routen, ohne zu erklären, warum.RFC 9582sagt, dass das Feld weggelassen werden sollte, wenn es der Präfixlänge entspricht, und definiert, wie es die Autorisierung spezifischerer Routen begrenzt.

Der entgegengesetzte Fehler ist, nur das Aggregat zu autorisieren, wenn das dokumentierte Design des Leasingnehmers auf spezifischeren Routen beruht. Ein Notfall-Scrubbing-Provider kann /24s ankündigen. Eine Migration zwischen zwei Ursprüngen kann ein Aggregat vorübergehend teilen. Wenn der Vertrag dieses Design ignoriert, wird der Leasingnehmer im schlimmsten Moment um eine eilige Änderung bitten.

Der Autorisierungsplan sollte dem kleinsten Satz erwarteter Routen entsprechen, nicht dem breitesten technisch möglichen Satz. Wo mehrere /24s von verschiedenen Ursprüngen erwartet werden, können explizite ROAs die Aufteilung sichtbar machen. Wo ein vorübergehend breiteres Maximum gerechtfertigt ist, sollte es ein Enddatum und einen Grund haben.

Dies ist auch eine Portfoliofrage für Leasinggeber. Eine breite überdeckende ROA kann mit spezifischeren Leases darunter interagieren. Vor der Genehmigung einer Änderung muss der Leasinggeber prüfen, ob eine gültige Route eines anderen Kunden aufgrund einer überdeckenden Autorisierung mit einem anderen Ursprung oder einem restriktiven Maximum Invalid würde. Das Inventar des Leasinggebers muss daher Überlappungen verstehen, nicht nur Leasing-Zeilen.

Das kommerzielle Prinzip ist die geringstmögliche Befugnis. Der Leasingnehmer erhält genug kryptografische Erlaubnis, um das vereinbarte Netzwerk zu betreiben, einschließlich realistischer Ausfallsicherheit. Der Leasinggeber behält kein künstliches Veto über dokumentierte Abläufe, veröffentlicht aber auch keine Erlaubnis, die breiter ist als das Geschäft.

Der Upstream ist eine unabhängige Kontrolle, kein Bote

Transit-Provider werden oft als letzte Ausgabestelle für eine Autorisierungsbescheinigung behandelt. In einem ausgereiften Lease sollten sie früher einbezogen werden.

Vor der Aktivierung sollte der beabsichtigte Upstream die genauen Präfixe und die Ursprungs-ASN, die er akzeptieren wird, die erforderlichen Nachweise, die minimale Routengröße, die Behandlung spezifischerer Routen, ob er Filter aus IRR- oder RPKI-Daten erstellt und wie schnell diese Filter aktualisiert werden, bestätigen. Diese Bestätigung gehört neben den ROA-Plan, denn eine technisch korrekte Autorisierung hat wenig betrieblichen Wert, wenn der Kundenfilter des Upstreams die Route immer noch ablehnt.

Der Upstream sollte seinen Kunden unabhängig authentifizieren. Eine gültige ROA kann zeigen, dass eine Zertifizierungskette die Ursprungs-ASN für ein Präfix autorisiert. Sie beweist nicht, dass die Person, die ein Transit-Ticket öffnet, diese ASN kontrolliert oder dass der Leasinggeber das kommerzielle Konto genehmigt hat. Eine Autorisierungsbescheinigung kann die Parteien verbinden, aber Schreiben sind leicht weiterzuleiten und global schwer zu widerrufen. Kontodaten, verifizierte Kontakte und die direkte Bestätigung des Leasinggebers machen die Nachweise stärker.

Während des Leases sollte der Upstream eine Ursprungsänderung nicht allein deshalb akzeptieren, weil eine neue ROA erschienen ist. Die Änderung kann versehentlich, bösartig oder für einen anderen Anbieter bestimmt sein. Er sollte auch einen neuen Invalid-Status nicht ignorieren. Er sollte den Leasingnehmer und Leasinggeber über bekannte Kanäle kontaktieren, die Route mit der vereinbarten Präfixliste vergleichen und feststellen, ob die Route oder die Autorisierung falsch ist.

Bei der Beendigung hat der Upstream eine entscheidende Rolle, den Widerruf real zu machen. Der Leasinggeber kann eine ROA entfernen, aber der ehemalige Leasingnehmer kann weiterhin die BGP-Ankündigung senden. Der Upstream kann die Kunden-Präfixerlaubnis entfernen und die Route an der direkten Grenze ablehnen. Diese lokale Aktion ist oft schneller und sicherer, als darauf zu warten, dass jedes Netzwerk aktualisierte Validierungsdaten anwendet.

Diese Aufteilung ist gesund. RPKI bietet global verifizierbare Ursprungsautorisierung. Der Upstream setzt die Kundenbeziehung an der Quelle am nächsten durch. Der Lease verbindet beide. Keiner sollte die gesamte Last tragen müssen.

Ein Upstream, der geleaste Präfixe unterstützt, kann seine Nachweisanforderungen und Notfallkontaktwege veröffentlichen. Vorhersehbarkeit macht sicheres Leasing einfacher. Geheime, inkonsistente Überprüfungen treiben Betreiber zu Last-Minute-Tickets und informellen Ausnahmen, was sowohl Sicherheit als auch Rechenschaftspflicht schwächt.

Streitigkeiten müssen vom Kundenverkehr isoliert werden

Die schwierigste Klausel betrifft den Fall, dass Leasinggeber und Leasingnehmer über Geld, Vertragsverletzung, Missbrauch oder Verlängerung uneins sind, während das Präfix noch Live-Dienste befördert.

Der Leasinggeber könnte befürchten, dass eine Kontinuitätsphase Nichtzahlung belohnt oder Schaden erlaubt. Der Leasingnehmer könnte befürchten, dass der Leasinggeber die ROA-Löschung als Fern-Kill-Schalter einsetzt. Beide Bedenken sind berechtigt. Die Antwort kann keine dauerhafte Autorisierung sein, sollte aber auch kein unangekündigter kryptografischer Hinterhalt sein.

Beginnen Sie mit der Unterscheidung von Ereignissen. Ein geplanter Ablauf und eine gewöhnliche Nichtverlängerung sollten dem vollständigen Ausstiegsplan folgen. Eine strittige Rechnung sollte eine Benachrichtigung und eine kurze Heilungsfrist auslösen, es sei denn, die Vereinbarung macht die Zahlung eindeutig sofort und kritisch. Glaubwürdige Hinweise auf aktiven Missbrauch können strengere Kontrollen rechtfertigen, aber das Entfernen einer ROA stoppt nicht unbedingt die missbräuchliche Route; der direkte Upstream und die Ausrüstung des Leasingnehmers bleiben näherliegende Eingriffspunkte.

Ein kompromittierter Signierschlüssel erfordert Sicherheitsmaßnahmen, selbst wenn die kommerzielle Beziehung intakt ist.

Während eines echten Streitfalls sollten diskretionäre Erweiterungen eingefroren werden. Der Leasingnehmer sollte keine Kunden hinzufügen, keine neuen Ursprünge anfordern oder maximale Längen erweitern. Der Leasinggeber sollte die letzten bekannten sicheren Autorisierungen für den begrenzten Kontinuitätszeitraum bewahren. Beide Parteien sollten den Upstream benachrichtigen, dass keine Änderung ohne doppelte Bestätigung gültig ist, außer bei einem dokumentierten Notfall zum Schutz des Verkehrs.

Ein unabhängiger Eskalationskontakt kann feststellen, ob eine Anforderung in den bestehenden Plan passt, ohne den gesamten Rechtsstreit zu entscheiden. Die Frage ist eng: Bewahrt die angeforderte Aktion einen bereits autorisierten Dienst oder erweitert sie Rechte? Diese begrenzte Feststellung kann das Routing stabil halten, während kommerzielle Ansprüche anderweitig verfolgt werden.

Die Vereinbarung sollte auch einen harten Stopp definieren. Kontinuität darf nicht zu einer unbefristeten Besetzung werden. Am Ende der Heilungs- oder Migrationsphase muss der Leasingnehmer Routen zurückziehen, der Upstream muss Filter entfernen, und der Leasinggeber muss die ROA entfernen. Das Versäumnis einer Seite führt zu festgelegten Nachweisen und Abhilfemaßnahmen. Wenn die Kundensicherheit eine gerichtliche Verfügung oder einstweilige Notfallmaßnahmen erfordert, wissen die Parteien, welche Handlungen unterbunden werden müssen.

Protokolle sind hier am wichtigsten. Eine Partei, die eine unrechtmäßige Löschung behauptet, sollte die vereinbarte Autorisierung, die Anforderung, die Bestätigung, die Änderungszeit und die Auswirkungen auf die Validierung vorlegen können. Ein Leasinggeber, der eine fortgesetzte Nutzung behauptet, sollte Routenbeobachtungen nach der Rückzugsfrist vorlegen können. Streitisolierung funktioniert nur, wenn Fakten rekonstruiert werden können, ohne dem Posteingang einer Seite zu vertrauen.

Die leitende Norm ist einfach: Machen Sie unbeteiligte Internetnutzer nicht zum Vollstreckungsmechanismus für private Schulden, und nutzen Sie deren Abhängigkeit nicht, um einen Lease unbefristet zu machen.

Widerruf ist notwendig, aber Löschung ist kein vollständiges Heilmittel

Ein Lease muss damit enden, dass der ehemalige Leasingnehmer sich nicht mehr auf die Autorisierung des Leasinggebers verlassen kann. Dies erfordert Widerruf oder Entfernung auf der entsprechenden Ebene. Es erfordert auch mehr als nur Widerruf.

Wenn der Zeitpunkt des Autorisierungsendes erreicht ist, sollte der Leasinggeber die entsprechende ROA-Konfiguration entfernen oder ändern. In delegierten Vereinbarungen kann er das begrenzte untergeordnete Zertifikat widerrufen, nachdem er bestätigt hat, dass keine fortlaufende Autorisierung erforderlich ist. Die Parteien sollten die resultierenden validierten Nutzdaten von mehr als einem unabhängigen Beobachtungspunkt beobachten. Eine Portal-Erfolgsmeldung ist ein Beleg für eine eingereichte Handlung, kein Beweis dafür, dass der öffentliche Zustand konvergiert ist.

Zur gleichen Zeit muss der Leasingnehmer die BGP-Route zurückziehen, und seine Upstreams müssen die Kundenerlaubnis entfernen. IRR-Routenobjekte, die noch den alten Ursprung nennen, sollten gelöscht oder aktualisiert werden. Reverse-DNS und öffentliche Kontakte sollten nicht mehr auf einen ehemaligen Betreiber verweisen, wenn dies betriebliche oder Missbrauchsmeldungen fehlleiten würde. Diese Systeme haben unterschiedliche Aktualisierungszeiten und Betreuer, sodass ein einzelner Zeitstempel keinen vollständigen Ausstieg beweisen kann.

Die Löschung kann auch Folgeschäden haben. Eine ROA kann mehrere Präfixe abdecken, und ein delegiertes Zertifikat kann Ressourcen über einen Lease hinaus enthalten, wenn der Leasinggeber es schlecht entworfen hat. Der Betreiber muss das genaue zu ändernde Objekt oder die Autorisierung identifizieren. „Widerrufen Sie das RPKI des Kunden" ist keine sichere Anweisung, es sei denn, die Zertifizierungsgrenze stimmt mit der Kundengrenze überein.

Das Restrisiko besteht in beide Richtungen. Wenn die ROA bestehen bleibt, behält der ehemalige Leasingnehmer einen Validierungsvorteil, falls er weiterhin ankündigt. Wenn die ROA verschwindet, während eine veraltete Route bestehen bleibt, kann die Route Invalid werden und ungleichmäßig abgelehnt werden, was zu teilweiser Erreichbarkeit statt universeller Stille führt. Wenn keine überdeckende ROA bestehen bleibt, kann die Route Not Found werden und unter vielen Richtlinien weiterhin verbreitet werden. Der RPKI-Status ist daher kein zuverlässiger Ersatz für den Rückzug an der Quelle.

Ein Abschlussbericht sollte festhalten: Route vom alten Ursprung zurückgezogen; Upstream-Filter entfernt; alte ROA nicht vorhanden oder ersetzt; keine unbeabsichtigte überdeckende Autorisierung verbleibt; delegiertes Zertifikat gegebenenfalls geschlossen; IRR-Einträge abgeglichen; und Überwachung über einen definierten Beobachtungszeitraum fortgesetzt. Ausnahmen sollten benannt werden, statt sie in „erledigt" zu runden.

Widerruf schützt den Leasinggeber und den nächsten Nutzer. Koordinierter Rückzug schützt aktuelle Kunden. Ein verantwortungsvoller Ausstieg leistet beides.

Die RIR sollte die Zertifizierungsbefugnis authentifizieren, nicht den Lease entscheiden

RIRs nehmen eine sensible Position ein, weil der gehostete Dienst sie zu dem Ort machen kann, an dem eine strittige Änderung ausgeführt wird. Das bedeutet nicht, dass sie zu Tribunalen für jeden IPv4-Lease werden sollten.

Die RIR hat ein legitimes Interesse daran, die Organisation zu authentifizieren, die zur Nutzung ihres Zertifizierungsdienstes berechtigt ist, Konten zu schützen, die Hierarchie aufrechtzuerhalten und auf nachgewiesene Kompromittierung von Anmeldeinformationen zu reagieren. Sie muss möglicherweise zertifizierte Ressourcen nach einer Übertragung, Rückgabe oder Registrierungsänderung anpassen. Die gehostete Dokumentation von RIPE NCC weist darauf hin, dass Ressourcenzertifikate aktualisiert werden, wenn Ressourcen verschoben werden, und veröffentlichte ROAs angepasst werden, wenn Ressourcen entfernt werden.

Dies sind Folgen der Zertifizierungshierarchie.

Ein privater Lease-Streit ist anders. Die RIR verfügt normalerweise nicht über den Vertrag, die Zahlungshistorie, die Fakten zur Kundenmigration und die nach dem anwendbaren Recht erforderlichen Beweise, um zu entscheiden, welche Partei vertragsbrüchig ist. Wenn sie nicht unterstützte Anweisungen eines Leasingnehmers akzeptiert, kann sie die Befugnis des Inhabers verdrängen. Wenn sie jede Anweisung des Inhabers trotz einer gerichtlichen Verfügung oder einer nachgewiesenen Kontokompromittierung als schlüssig behandelt, kann sie Schaden vergrößern. Die Antwort ist eine enge Rolle mit klarem Prozess.

Die RIR kann Protokolle aufbewahren, Kontobeteiligte authentifizieren, den Dienststatus veröffentlichen, dokumentierte Notfallkanäle für Sicherheitsvorfälle bereitstellen und gültigen rechtlichen Anordnungen nachkommen. Sie kann Kontorollen so granular gestalten, dass ein Inhaber keine breiten Anmeldeinformationen teilen muss. Sie kann die technischen Auswirkungen von gehosteten und delegierten Entscheidungen erklären. Sie sollte vorsichtig sein, eine mehrdeutige Leasing-Richtlinie in eine diskretionäre Kontrolle über Live-Routen umzuwandeln.

Diese Zurückhaltung steht im Einklang mit der begrenzten Bedeutung der ROA. Der Zertifizierungsdienst überprüft die Befugnis innerhalb der Nummernressourcen-Hierarchie. Er zertifiziert nicht jeden privaten Grund für die Ausübung dieser Befugnis. Die kommerzielle Verpflichtung bleibt zwischen den Parteien durchsetzbar und, wo nötig, durch Gerichte oder vereinbarte Streitbeilegungsmechanismen.

Die Registrierungsebene kann das Leasing dennoch verbessern, ohne eine neue Eigentumskategorie anzuerkennen. Sie kann eingeschränkte Benutzer, maschinenlesbare Änderungsverläufe, Benachrichtigungen an mehrere Kontakte, verzögerte destruktive Aktionen, wo sicher, und exportierbare Nachweise aktueller und früherer Konfigurationen unterstützen. Diese Werkzeuge verringern die Abhängigkeit von einem einzelnen Kontoinhaber und belassen das rechtliche Geschäft außerhalb der CA.

Das politische Ziel sollte vorhersehbare Ausführung sein, nicht moralische Zustimmung zu jedem Lease. Ein sicheres System kann die Person, die technisch zur Signierung berechtigt ist, von der Person unterscheiden, die vertraglich zur Anforderung berechtigt ist, ohne vorzutäuschen, dass dies immer dieselbe Person ist.

Kontrolle hat einen wirtschaftlichen Preis

Die ROA-Kontrolle wird oft in den Lease-Preis einbezogen, als wäre sie eine kostenlose Verwaltungsaufgabe. Sie ist ein separater Kontinuitätsdienst.

Ein Leasinggeber, der schnelle Änderungen verspricht, muss geschultes Personal, geschützte Anmeldeinformationen, Überwachung, Ersatzgenehmiger und Vorfallsabdeckung aufrechterhalten. Ein delegiertes Modell erfordert CA-Betrieb und Veröffentlichungszuverlässigkeit. Ein Leasingnehmer, der häufige Ursprungsänderungen benötigt, verursacht höhere Kosten und schafft mehr Fehlermöglichkeiten als ein Leasingnehmer mit einer stabilen ASN. Die Preisgestaltung sollte diese Unterschiede sichtbar machen.

Die Alternative ist eine Milchmädchenrechnung. Ein kostengünstiger Lease mit einer fünftägigen Reaktionszeit auf eine Notfall-ROA-Änderung kann für ein Netzwerk mit strengen Verfügbarkeitsverpflichtungen unbrauchbar sein. Ein Leasingnehmer könnte dann Anmeldeinformationen informell teilen, einen Upstream um Ausnahmen bitten oder eine zu breite Autorisierung aufrechterhalten, um zukünftige Verzögerungen zu vermeiden. Jede Abkürzung verwandelt eine unbezahlte Serviceanforderung in ein Sicherheitsrisiko.

Die breitere ökonomische Betrachtung der Netzwerkidentität verdeutlicht diesen Punkt. Lu Hengs Anmerkung zuNetzwerkidentität und Kundenkontinuitätargumentiert, dass eine Adresse in Kunden-Whitelists, Partnerregeln, APIs und Compliance-Systemen eingebettet werden kann. Sobald dies geschieht, ist eine fehlgeschlagene ROA-Änderung nicht nur eine Routine-Unannehmlichkeit. Sie kann eine Geschäftsidentität unterbrechen, der externe Parteien bereits vertrauen.

Seine Diskussion überverwaltetes IPv4-Leasing und Registrierungsrisikobringt einen verwandten Marktpunkt: Der Erwerb von Adressen ist nur die sichtbare Transaktion; die fortgesetzte Betriebsfähigkeit hängt davon ab, wie Registrierungs-, Routing- und Lebenszyklusrisiken getragen werden. Eine neutrale Analyse muss nicht jede institutionelle Schlussfolgerung in diesem Argument akzeptieren, um das betriebliche Faktum anzuerkennen. Die Partei, die Kontinuität verkauft, sollte die Handlungen beschreiben und bepreisen, die Kontinuität erfordert.

Dies kann zu Service-Stufen führen. Ein Basis-Lease kann einen stabilen Ursprung und Änderungen während der Geschäftszeiten erlauben. Ein ausfallsicherer Lease kann zwei Ursprünge, vorab genehmigte DDoS-Abwehr, Rund-um-die-Uhr-Reaktion und periodischen Abgleich umfassen. Ein Leasingnehmer mit einer eigenen leistungsfähigen CA kann sich für eine begrenzte Delegation entscheiden und mehr Pflichten übernehmen. Transparente Stufen sind besser, als vorzutäuschen, jeder Lease enthalte eine sofortige, unbegrenzte RPKI-Administration.

Die Kontrolle sollte sich auch auf Abhilfemaßnahmen auswirken. Wenn der Leasinggeber für Notfallabdeckung Gebühren erhebt und diese nicht bereitstellt, sollte die Konsequenz spürbar sein. Wenn der Leasingnehmer eine langsamere Stufe wählt und später sofortiges Handeln verlangt, sollte der Leasinggeber nicht so behandelt werden, als hätte er versprochen, was er nicht verkauft hat.

Der Markt wird sicherer, wenn die kryptografische Abhängigkeit als Teil des Produkts benannt wird, anstatt sie hinter „Support" zu verstecken.

Eine praktische Aufteilung von Rechten

Es gibt keine universelle Regelung, aber ein vertretbarer Standard kann klar benannt werden.

Der Leasinggeber behält die letztendliche Kontrolle über die Ressourcenzertifizierungsbeziehung und kann Änderungen außerhalb des geleasten Umfangs ablehnen. Er muss mindestens zwei autorisierte Betreiber unterhalten, Anmeldeinformationen schützen, die anfänglichen ROAs vor der Aktivierung erstellen, definierte normale und Notfall-Änderungszeiten einhalten, vor destruktiven Handlungen benachrichtigen, außer in einem echten Sicherheitsnotfall, und die Autorisierung nach dem verifizierten Ausstieg aufheben.

Der Leasingnehmer kontrolliert sein Netzwerkdesign innerhalb des Plans. Er muss jede Ursprungs-ASN identifizieren und deren Kontrolle nachweisen, genaue Routenpläne vorlegen, zwei authentifizierte Anforderer unterhalten, den Leasinggeber vor geplanten Änderungen benachrichtigen, Ankündigungen außerhalb der Autorisierung vermeiden, den RPKI-Status überwachen, bei Beendigung unverzüglich zurückziehen und Nachweise über die Upstream-Schließung aufbewahren.

Der Upstream verifiziert unabhängig die Kunden-Präfix-Beziehung, bereitet Filter vor der Aktivierung vor, überwacht Abweichungen, unterstützt einen direkten Notfallkontakt, lehnt ungeplante Ursprungsänderungen bis zur Bestätigung ab und entzieht die Erlaubnis beim Ausstieg. Er verlässt sich nicht auf eine ROA als einzigen Nachweis der Kundenbefugnis.

Die RIR oder übergeordnete CA authentifiziert den Ressourceninhaber, betreibt oder unterstützt das gewählte Zertifizierungsmodell, schützt die übergeordnete Hierarchie, stellt zuverlässige Veröffentlichungs- und Änderungsdatensätze bereit und behandelt nachgewiesene Anmeldeinformations- oder rechtliche Ereignisse innerhalb eines transparenten Rahmens. Sie leitet den privaten Lease nicht aus BGP ab und entscheidet nicht über gewöhnliche Rechnungen.

Bei Leases mit häufigen Änderungen oder hoher Abhängigkeit kann eine begrenzte untergeordnete CA die Ausführung näher zum Leasingnehmer verlagern. Bei Leases mit geringen Änderungen kann ein gehosteter Dienst mit strengen Reaktionsverpflichtungen sicherer sein. Bei sehr kurzen Laufzeiten können die Kosten für RPKI und den Upstream-Übergang eine längere Ankündigungsfrist oder ein anderes Adressdesign rechtfertigen. Die Wahl sollte der betrieblichen Abhängigkeit folgen, nicht der Ideologie.

Jedes Modell benötigt dieselben Leitplanken: exakter Umfang, geringste Befugnis, redundante Kontakte, bemessene Reaktion, sichtbarer Zustand, sichere Überlappung, harte Beendigung und unabhängige Nachweise. Entfernen Sie eine, und die Kontrolle wandert zu demjenigen, der zufällig im Besitz der Anmeldeinformationen ist, wenn etwas schiefgeht.

Der Test ist, ob die Befugnis der Verantwortung folgt

Ein IPv4-Lease ist nachhaltig, wenn die für den Dienst verantwortliche Partei die notwendige Autorisierung erhalten kann, während die für die Ressource verantwortliche Partei eine unbefugte Erweiterung verhindern und den endgültigen Widerruf garantieren kann.

Dieses Gleichgewicht wird nicht erreicht, indem man die ROA einem Akteur in einem Satz zuweist. Es wird erreicht, indem die kommerzielle Erlaubnis mit betrieblichen Ereignissen verbunden wird. Die Zertifikatsbefugnis des Leasinggebers darf kein unbezahltes Veto gegen routinemäßige Netzwerkänderungen werden. Das Bedürfnis des Leasingnehmers nach Schnelligkeit darf keine dauerhafte Signierungsbefugnis über ein Aggregat werden. Der Upstream darf die Kundenverifizierung nicht an ein kryptografisches Objekt auslagern. Die RIR darf nicht in die Entscheidung über einen Vertrag gedrängt werden, den sie nicht einsehen kann.

Die Technologie legt die relevanten Unterscheidungen bereits offen. Eine ROA benennt ein Präfix, einen Ursprung und eine optionale maximale Länge. Der gehostete Dienst zentralisiert Signierungsvorgänge. Der delegierte Dienst verlagert die Schlüsselkontrolle und Wartung. Vertrauende Parteien rufen veröffentlichtes Material ab und validieren es. Router wenden lokale Richtlinien an. Die Governance-Aufgabe besteht darin, den Lease ebenso präzise zu gestalten.

Der sicherste Lease schafft die Autorisierung, bevor der Verkehr davon abhängt, hält die Autorisierung auf die dokumentierten Routen abgestimmt, erlaubt eine enge Notfallanpassung, isoliert Streitigkeiten von Kunden und zieht sowohl die Route als auch ihre kryptografische Erlaubnis am Ende zurück. Er zeichnet auf, wer jede Handlung wann vorgenommen hat.

Die endgültige Antwort auf „Wer kontrolliert die ROA?" ist daher absichtlich plural. Der Leasinggeber kontrolliert die zertifizierte Befugnis. Der Leasingnehmer kontrolliert die betriebliche Anforderung. Der Upstream kontrolliert die direkte Annahme. Die RIR kontrolliert einen übergeordneten oder gehosteten Dienst in ihrem Zuständigkeitsbereich. Der Vertrag kontrolliert, wie diese Befugnisse aufeinandertreffen.

Wenn der Vertrag schweigt, kontrolliert der Anmeldeinformationen-Inhaber die Krise. Wenn der Vertrag präzise ist, kontrolliert kein Akteur mehr als die Verantwortung, die zu tragen er sich bereit erklärt hat.