GOpenCNR-Richtlinie zu Registry-Daten

Was diese Richtlinie regelt

Was die GOpenCNR-Registry veröffentlicht und über welche Schnittstellen, was sie zurückhält, was alle, die die Daten in großer Menge beziehen, damit tun dürfen, und wie zurückgehaltene Daten herausgegeben werden. Sie gilt für jedes Objekt der Registry: Inhaber, Pools, Zuteilungen, ASNs, Routen, die Zielgruppen, die GOpenCNR nutzt, Endpunkte, Knoten und Dienste.

Verantwortlich für alle Registry-Daten ist Gelhaus Solutions, und jede Anfrage dazu kommt zu uns. Was wir über die Registry hinaus über Sie verarbeiten, steht im Datenschutzhinweis.

Was öffentlich ist, und warum

Eine Registry besteht, damit andere sich auf sie verlassen können. Diese Teile sind öffentlich:

• Das Handle des Inhabers. Der Name einer Person erscheint nur, wenn sie ihn zeigen will. Eine verifizierte Organisation erscheint mit dem, was die Bedingungen für die Verifizierung von Organisationen veröffentlichen.
• Für jede Zuteilung: das Präfix, seine Größe, der Pool, aus dem es stammt, wann es zugeteilt wurde und bis wann es bestätigt ist, sein Status (zugeteilt, ausgesetzt oder in Quarantäne), ob es angekündigt wird und ob es offen oder geschlossen ist.
• Für jede Route: das Präfix, seine Ursprungs-ASN und das Ergebnis der Validierung des Routenursprungs.
• Für jede ASN: ihr Inhaber, wann sie vergeben wurde, die Provider, die sie für ASPA nennt, und wie viele offene und geschlossene Routen sie ankündigt.
• Die Missbrauchs-Weiterleitungsadresse jedes Inhabers, abuse+<handle>@relay.csr.gplatform.org.
• Für jeden Pool: sein Präfix, sein Zweck, seine Größen und der Antrag des GOpenCNR-Community-Rats, durch den er entstanden ist.
• Für jedes geschlossene Präfix dasselbe wie für jedes andere: das Präfix, das Handle des Inhabers, seine Ursprungs-ASN und seine ROA. Geschlossen ist nur seine Erreichbarkeit.
• Das RPKI-Repository: für jede Route eine ROA mit dem genauen Präfix und seiner Ursprungs-ASN sowie die ASPA-Objekte.

Jeder dieser Teile ist aus einem Grund öffentlich:

• Eindeutigkeit ist der Zweck der Registry, und sie lässt sich nur prüfen, wenn alle sehen können, wer was hält.
• Routing hängt davon ab: Die Filter anderer Netze, die Validierung des Routenursprungs und IRR-Werkzeuge brauchen Präfixe und ihre Ursprünge.
• Dass ein Präfix geschlossen ist, sagt allen außerhalb seiner Zielgruppe, dass sie es nicht erreichen werden, ohne zu sagen, wer es darf: Die Mitglieder der Zielgruppe und die Routen zum Präfix bleiben privat.
• Einen Inhaber erreichen können muss jeder, der von Missbrauch betroffen ist, und die Weiterleitung macht das möglich, ohne die Adresse des Inhabers preiszugeben.

Wir stützen uns dafür auf Art. 6 Abs. 1 lit. f DSGVO; das berechtigte Interesse ist eine Registry, nach der jeder routen und die jeder prüfen kann.

Was geschwärzt ist

• Admin- und Tech-Kontakte werden für jeden Inhaber geführt und sind nur für Tier 0 sichtbar. RDAP-Antworten führen sie als geschwärzt, nach RFC 9537, sodass eine Antwort zeigt, dass es sie gibt und dass sie bewusst zurückgehalten wurden.
• Der Name einer Person, sofern sie ihn nicht zeigen will. Überall steht das Handle an seiner Stelle.
• Die eigene Adresse des Inhabers für Missbrauchsmeldungen. Veröffentlicht wird nur die Missbrauchs-Weiterleitungsadresse.

Was nie herausgeht

Nichts davon steht in einer öffentlichen Schnittstelle, einem Export, einer Kopie oder der Historie:

• Endpunkte, die öffentlichen IP-Adressen, unter denen die Router und Geräte der Mitglieder erreichbar sind. Endpunkte werden verschlüsselt gespeichert und nur Tier 0 und den Peers gezeigt, die das Mitglied akzeptiert hat. Das Transparenzlog enthält nur einen gesalzenen Hash (siehe „Historie“).
• Wer zu einer Zielgruppe gehört. Der Inhaber der Zielgruppe und Tier 0 sehen ihre Mitglieder; jedes andere Mitglied sieht nur, dass es selbst dazugehört; das Transparenzlog hält jede Änderung nur als gesalzene Hashes fest.
• Admin- und Tech-Kontakte, außer gegenüber Tier 0.
• Der bürgerliche Name und das Land einer Person, angegeben für die Sanktionsprüfung, die nur Tier 0 sieht, und ob eine Sanktionsprüfung läuft, was nur der Inhaber und Tier 0 wissen. Kein Ergebnis der Prüfung wird in das Transparenzlog geschrieben.
• Geschlossene Routen, so wie die Hubs sie transportieren, außer gegenüber ihrer Zielgruppe. Das Looking Glass zeigt eine geschlossene Route nur angemeldeten Mitgliedern ihrer Zielgruppe; sie erscheint nie in den veröffentlichten Dumps des Collectors und überquert nie eine Netzverbindung.

Auf anderem Weg geht davon nur heraus, was das Gesetz verlangt, wie unter „Geschwärzte Daten herausgeben“ beschrieben.

RDAP

RDAP antwortet für die IP-Netze und Nummern autonomer Systeme in GOpenCNR, bereitgestellt unter cnr.gplatform.org, mit Abfragen nach RFC 9082 und Antworten nach RFC 9083. Geschwärzte Felder werden gekennzeichnet, wie es RFC 9537 vorsieht.

Der Adressraum von GOpenCNR ist privater Adressraum und steht daher nicht in den RDAP-Bootstrap-Registern der IANA. Wir veröffentlichen eine eigene Bootstrap-Datei, die die Namen von GOpenCDR und die Nummern von GOpenCNR gemeinsam abdeckt, sodass ein damit eingerichteter RDAP-Client für beide den richtigen Server findet.

Whois auf Port 43

Ein Whois-Dienst auf Port 43 antwortet für dieselben Objekte mit denselben öffentlichen Daten, als reiner Text, für Werkzeuge, die kein RDAP sprechen.

RPSL, das IRR und NRTMv4

Die Registry wird in RPSL exportiert und von einem IRR-Server im Spiegelbetrieb bereitgestellt, sodass bgpq4 und andere IRR-Werkzeuge daraus Filter bauen können. Der IRR-Server wird nur aus der Registry gespeist und nie direkt beschrieben: Eine Änderung geht, vom Inhaber signiert, in die Registry oder nirgendwohin. RPSL-Objekte enthalten dieselben öffentlichen Daten und keinen anderen Kontakt als die Missbrauchs-Weiterleitungsadresse.

Die Registry ist außerdem eine NRTMv4-Quelle, sodass IRR-Spiegel ihren Änderungen laufend folgen können.

Exporte im dn42-Format

Für Werkzeuge, die für dn42 gebaut sind, veröffentlichen wir Registry-Objekte und ROA-Dateien in den Formaten, die die Werkzeuge von dn42 lesen, eine ROA-Datei im JSON-Format von dn42, SLURM-Dateien nach RFC 8416 für Mitglieder, die auch das öffentliche RPKI validieren, und ROA-Tabellen für BIRD. Diese Exporte werden aus denselben Daten erzeugt wie alles andere und enthalten nichts, was nicht oben als öffentlich genannt ist.

Der signierte Export und seine Git-Kopie

Die Registry veröffentlicht einen signierten Export: Momentaufnahmen, ein Journal jeder Änderung und inkrementelle Abrufe dessen, was sich seit einem bestimmten Zeitpunkt geändert hat. Jede Person kann ihn spiegeln und gegen das Transparenzlog prüfen. Derselbe Export wird als schreibgeschütztes Git-Repository veröffentlicht, das jede Person klonen und vergleichen kann.

Git ist nie der Ort, an dem die Registry geführt wird. Die Registry ist maßgeblich, und die Git-Kopie folgt ihr. Ein Inhaber, der seine Objekte aus einem eigenen Git-Repository verwaltet, sendet seine signierten Commits über die API, wo sie zu gewöhnlichen Änderungen werden.

Der Export und seine Git-Kopie enthalten die oben beschriebenen öffentlichen Daten und sonst nichts.

Die Daten in großer Menge beziehen

Jede Person darf die Exporte herunterladen, spiegeln und verarbeiten und die Schnittstellen in großer Menge abfragen, ohne uns vorher zu fragen, und zwar für:

• Routing: Filter bauen, Routenursprünge validieren, IRR-Spiegel und Route-Server betreiben;
• Forschung zu Routing, Adressierung und zur Registry selbst;
• Spiegelung: Kopien vorhalten, die andere gegen das Transparenzlog prüfen können.

Nicht verwendet werden dürfen sie:

• für Werbung oder um Inhaber wegen etwas anderem anzusprechen als der Sache, für die die Daten veröffentlicht sind;
• für Spam, auch über die Missbrauchs-Weiterleitungsadressen;
• um Menschen zu re-identifizieren: Handles, Adressraum oder Missbrauchs-Weiterleitungsadressen mit anderen Daten zu verknüpfen, um herauszufinden, wer eine Person ist, wo sie sich aufhält oder sonst etwas, das sie nicht veröffentlichen wollte.

Eine Quellenangabe ist nicht erforderlich, es sei denn, eine Datei sagt, dass Daten darin aus einer Quelle stammen, die sie verlangt.

Ihren Namen zeigen

Eine Person, die Adressraum hält, erscheint unter einem Handle. Sie können wählen, Ihren Namen dazu zu zeigen, und diese Wahl jederzeit zurücknehmen. Ein zurückgezogener Name verlässt die Registry ab diesem Zeitpunkt: Er verschwindet von den aktuellen Seiten, aus jeder Schnittstelle und aus jedem späteren Stand des Exports.

Frühere Stände behalten ihn, weil die Historie der Registry zeigt, was wann öffentlich war, und Kopien, die andere vom Export angefertigt haben, liegen außerhalb unserer Reichweite. Entscheiden Sie in diesem Wissen. Wenn Ihr Name auch aus der Historie entfernt werden soll, die wir veröffentlichen, schreiben Sie an contact@gplatform.org; wir wägen die Anfrage im Einzelfall nach Art. 17 und 21 DSGVO ab.

Einen Inhaber erreichen

Die meisten, die fragen, wer hinter einem Präfix steht, wollen erreichen, wer es betreibt. Dafür gibt es die Missbrauchs-Weiterleitungsadresse: Eine Nachricht an abuse+<handle>@relay.csr.gplatform.org wird an den Inhaber weitergeleitet, ohne dessen Adresse preiszugeben. Jeder Absender kann darüber 20 Nachrichten pro Stunde senden, mit Belegen bis 20 MB, und wird über die Weiterleitung nur kontaktiert, wenn er dem zugestimmt hat. Die Weiterleitung führt ein Protokoll der Absenderadressen und Ergebnisse, das 12 Monate aufbewahrt wird.

Missbrauch kann auch an abuse@gplatform.org gemeldet werden; wie eine Meldung bearbeitet wird, regelt die Richtlinie zu Missbrauch und Sanktionen.

Geschwärzte Daten herausgeben

Behörden erhalten geschwärzte Daten und Endpunkte nur nach der Richtlinie zu Behördenanfragen. Anordnungen deutscher Gerichte und Behörden sowie Europäische Herausgabe- und Sicherungsanordnungen nach der Verordnung (EU) 2023/1543 werden nach Prüfung unmittelbar beantwortet. Andere ausländische Ersuchen werden nur auf dem Weg der deutschen Rechtshilfe beantwortet. Freiwillig geben wir nur heraus, um eine unmittelbare Gefahr für Leib oder Leben abzuwenden, und nie Verkehrsdaten der Telekommunikation: Diese geben wir nur aufgrund einer gesetzlichen Vorschrift heraus, die sich ausdrücklich auf Telekommunikation bezieht (§ 3 Abs. 3 TDDDG). Unterlagen zu Behördenanfragen werden 5 Jahre nach Abschluss der Anfrage aufbewahrt.

Alle anderen erhalten geschwärzte Daten nur mit Zustimmung des Inhabers oder wenn ein Gesetz uns zur Herausgabe verpflichtet. Ein berechtigtes Interesse allein genügt nicht. Das ist enger als die Richtlinie zur Herausgabe von Registrierungsdaten von GOpenCDR, die für Namen gilt und die diese Richtlinie nicht ändert.

Wie Sie anfragen. Schreiben Sie an contact@gplatform.org mit „Registry-Daten“ im Betreff. Nennen Sie, wer Sie sind, welches Präfix, welche ASN oder welchen Inhaber die Anfrage betrifft, was Sie brauchen, warum und auf welcher Rechtsgrundlage, und fügen Sie das Verfahren oder die Zustimmung des Inhabers bei. Liegt keines davon bei und verpflichtet uns kein Gesetz, fragen wir den Inhaber, ob er zustimmt, und geben nur heraus, was er freigibt.

Was herausgegeben wird. Das Wenigste, das dem Zweck dient, nur an die anfragende Stelle, in Textform, mit dem Hinweis, dass die Daten nur für den genannten Zweck verwendet werden dürfen und zu löschen sind, sobald er erfüllt ist.

Den Inhaber informieren. Der Inhaber erfährt, wer gefragt hat, warum und was herausgegeben wurde, es sei denn, das Gesetz verbietet es, und dann, sobald es das nicht mehr verbietet.

Zählung. Jede Anfrage und ihr Ergebnis werden im gemeinsamen Transparenzbericht gezählt, der alle sechs Monate erscheint.

Berichtigungen

Ihre eigenen Objekte berichtigen Sie über das Portal, die Kommandozeilenwerkzeuge oder die API, als Änderungen, die Sie signieren. Sind Daten über Sie falsch und können Sie sie nicht selbst ändern, oder nennt ein Objekt Sie oder Ihre Ressourcen zu Unrecht, schreiben Sie an contact@gplatform.org. Tier 0 berichtigt sie mit einer eigenen Änderung, über die Sie informiert werden und die das Transparenzlog festhält.

Eine Berichtigung ist ein neuer Stand. Die Historie behält den alten.

Historie

Jedes Objekt hat einen öffentlichen Verlauf: jede Änderung mit ihrem Unterschied zum vorigen Stand und der Signatur, die sie trug, aus dem Transparenzlog. Die ganze Registry oder jedes Objekt darin lässt sich so lesen, wie es zu jedem vergangenen Zeitpunkt war. Die Historie umfasst nur die öffentlichen Daten. Endpunkte und Mitglieder von Zielgruppen erscheinen im Log nur als gesalzene Hashes: Jeder erhält ein zufälliges Salt von 32 Bytes, das verschlüsselt neben dem Eintrag liegt und mit der Quittung dem Inhaber übergeben wird, bei einem Endpunkt auch den Peers, die der Inhaber akzeptiert hat, damit sie den Eintrag prüfen können. Aus dem Log lässt sich die Eingabe nicht erraten.

Die öffentliche Historie wird dauerhaft aufbewahrt: die früheren Stände, das Änderungsjournal und die Git-Kopie. Eine Registry, deren Vergangenheit sich ändern kann, kann keinen Streit entscheiden. Was über eine Ressource nicht öffentlich ist, wird 12 Monate nach ihrem Ende gelöscht.

Änderungen dieser Richtlinie

Eine wesentliche Änderung wird den Inhabern mindestens sechs Wochen vor ihrem Inkrafttreten angekündigt, wie es die allgemeinen Nutzungsbedingungen vorsehen. Jede Fassung wird im Dokumentenarchiv aufbewahrt.