Was sollte ein VPN-Ausgangsadressregister eigentlich erfassen?
Ein Ausgangsregister ist nur nützlich, wenn jeder Eintrag seine Bedeutung, seinen Herausgeber und sein Ablaufdatum angibt. Klassifizierung ist keine Abonnentenidentifizierung.
Ausgangsregister klingen nach Listen, und die Liste ist nicht der schwierige Teil. Der schwierige Teil ist zu entscheiden, was jeder Eintrag behauptet, wer ihn veröffentlichen darf und was passiert, wenn die Behauptung nicht mehr zutrifft. In diesen Vorschlägen werden drei verschiedene Adressrollen vermischt, und ein Register, das sie vermischt, kann keine Frage zuverlässig beantworten. Verfolgt man einen Eintrag von der Veröffentlichung bis zum Widerruf, zeigen sich die Designanforderungen von selbst.
Beginnt mit dem Datensatz, nicht mit der Liste
Die erste Frage ist nicht, wie viele Adressen aufgenommen werden, sondern was eine einzelne Zeile bedeutet. Beschreibt sie, wo sich Clients verbinden, welche Quelle ein Ziel sehen darf oder wer eine Zuteilung in einem Register hält? Das sind drei Behauptungen mit drei Eigentümern und drei Fehlermodi. Ein Register, das nicht angibt, welche davon es erfasst, kann nicht validiert, korrigiert oder abgelaufen werden. Die Bedeutung richtig zu treffen ist die Designarbeit, und die Liste ist nur die Ausgabe.
Schreibt die Zeilendefinition, bevor ihr irgendein Schema schreibt. Wenn die Definition das Wort und braucht, sind es wahrscheinlich zwei Datensätze, die sich als einer ausgeben.
Drei Adressrollen, die ähnlich aussehen
Die Rollen sind leicht zu verwechseln, weil eine Bereitstellung alle drei gleichzeitig nutzen kann und es oft tut. Ein Dienst kann Verbindungen an einer Adresse beenden und Datenverkehr von einer anderen weiterleiten, während ein Register eine ganz dritte Tatsache erfasst.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
Ein Hosting-Block kann VPN-Ausgänge und unabhängige Arbeitslasten nebeneinander enthalten, daher sagt eine Übereinstimmung im Register nichts darüber aus, was eine bestimmte Adresse zu einem bestimmten Zeitpunkt tut. Ein Eintrag, der seine Rolle nicht nennt, ist kein Beweis für irgendetwas Bestimmtes. Die Rolle zu benennen macht den Datensatz falsifizierbar. Gebt auch die Adressfamilie an, denn ein Register, das stillschweigend nur IPv4 abdeckt, wird jeden irreführen, der etwas anderes annimmt.
Verfolgt einen Eintrag von der Veröffentlichung bis zum Widerruf
Nehmt einen hypothetischen Ausgang und verfolgt ihn. Ein Betreiber veröffentlicht das Präfix und seine Rolle zu einem angegebenen Wirksamkeitszeitpunkt, Nutzer rufen es ab, und später dient die Adresse nicht mehr als Ausgang. Jeder Schritt braucht eine Regel: wer veröffentlichen darf, was das Präfix tatsächlich abdeckt, wann der Eintrag wirksam wird und wie er widerrufen wird. Ein Feed ohne Widerrufspfad sammelt veraltete Behauptungen an, die niemand von aktuellen unterscheiden kann.
Trennt die Befugnis zur Veröffentlichung von der Genauigkeit des Labels. Ein Registereintrag, der eine Organisation mit einer Ressource verbindet, beweist die Zuteilung und nicht die aktuelle Nutzung, und das sind verschiedene Behauptungen mit verschiedenen Belegen. Nutzer müssen wissen, welcher der beiden sie vertrauen.
Definiert auch die Korrektur. Eine Adresse, die einem Kunden neu zugewiesen wird, oder ein unabhängiger Dienst, der von einem falschen Label erfasst wird, braucht einen dokumentierten Weg zu einer Korrektur statt einer Diskussion in einer Ticket-Warteschlange. Der Widerrufsauslöser gehört in dasselbe Dokument wie die Veröffentlichungsregel.
Was ein veröffentlichter Feed leisten kann und was nicht
Veröffentlichte Präfixattribute sind ein etabliertes Muster, und die bestehenden Beispiele beschreiben Geografie oder Eigentum statt Verhalten. Ein VPN-Feed bräuchte seine eigene Semantik, seine eigenen Belegregeln und seinen eigenen Prüfprozess, und eine Länderliste umzubenennen liefert davon nichts. Der ARIN-Registerleitfaden zeigt, was Zuteilungseinträge behaupten und was nicht, und ein neuer Feed muss dieselbe Klarheit über seine eigenen Behauptungen erringen. Das ist eine Spezifikationsaufgabe, keine Umbenennungsaufgabe.
Was ein solcher Feed leisten kann, ist eine Klassifizierungsentscheidung über eine Netzwerkquelle. Was er nicht kann, ist eine Person hinter einer geteilten Adresse zu identifizieren, zu beweisen, dass der gesamte Datenverkehr von dieser Adresse getunnelt wird, oder zu entscheiden, ob eine bestimmte Anfrage missbräuchlich ist. Das sind drei getrennte Fragen mit drei getrennten Beleganforderungen.
Haltet die Rechtsfrage außerhalb der Spezifikation
Eine technische Spezifikation kann nicht klären, ob eine vorgeschlagene Registrierungspflicht rechtmäßig, verhältnismäßig oder klug ist. Diese Bewertung braucht den tatsächlichen Gesetzestext, die betroffenen Rechte, die Gerichtsbarkeit und eine rechtliche Analyse, die ein Datenformat nicht liefern kann. Ein Format kann gut gestaltet sein und dennoch eine schlechte Politik stützen.
Was die Spezifikation leisten kann, ist, die Debatte konkret zu machen. Definiert zuerst die vorgeschlagenen Daten, ihre Grenzen und ihre Fehlermodi, damit die politische Argumentation einen realen Mechanismus betrifft und nicht eine undefinierte Liste, die sich jeder Beteiligte anders vorstellt. Das ist das Höchste, was ein technisches Dokument zu einer Rechtsfrage beitragen kann.