GOpenCNR privacy notice

The short version

• Your account stays in GOpenCSR. GOpenCNR adds your address space, your routers and what the network needs to carry your traffic.
• The registry shows your space, not you. It publishes your handle, your prefixes and ASNs, their sizes and dates, whether each prefix is open or closed, its origin ASN and an abuse relay address. Your name appears only if you choose to show it. Admin and tech contacts never appear.
• Your legal name and country are for sanctions screening only. You give them when you become a member. Only Tier 0 sees them, and they are never public.
• Your public IP address is never published. Endpoints are stored encrypted, shown only to Tier 0 and to peers you accept, and never appear in an export or in RDAP. The transparency log keeps only a salted hash that cannot be guessed back.
• Private keys stay on your devices. A device key made in your browser is shown once, for 15 minutes, and never stored.
• Between agents, hubs see only ciphertext. They count packets and keep no record of who talked to whom. Flows are sampled only inside an open abuse case, for at most 7 days, and never with content.
• Health reports are kept for 12 months, detailed counters for 90 days, then daily totals until 12 months; the published route dumps for 2 years.
• Who is in an audience is shown only to the audience's holder and to Tier 0.
• No trackers, no analytics, no advertising. Our servers are in Germany. Hubs run by others may be in other countries: the network map shows each hub's country, and an operator in a country without an adequate level of data protection signs the EU standard contractual clauses.

Who is responsible

The controller is Gelhaus Solutions, a sole proprietorship of Enno Gelhaus, Eichenwald 3, 49624 Löningen, Germany, reachable at contact@gplatform.org.

We run three services as one controller. GOpenCSR holds your account and what the services share, GOpenCDR holds names, and GOpenCNR, the Gelhaus Open Community Network Registry, allocates private addresses and ASNs and connects its members to each other. This notice covers only what GOpenCNR adds. Your account, signing in, passkeys and sessions, organisations and roles, invitations and vouches, how sanctions screening works, abuse cases, the audit log, the request logs of the API front door, the session cookie and the transparency log are covered by the GOpenCSR privacy notice, and so are your rights in general. GOpenCNR writes its own audit records in the same way. The website around it is covered by the site's privacy policy.

Your legal name and country

When you first become a GOpenCNR member, you give your legal name and your country. Organisations give neither: they are screened by their verified name and country. These details serve one purpose: screening against the EU consolidated financial sanctions list, when you give them and every day after. Only Tier 0 sees them. They are never public, never in RDAP and never in an export, and they are kept while you hold resources and for 12 months after.

Why. The EU sanctions regulations forbid making resources available to listed persons (Art. 6(1)(c) GDPR).

Automated holds. A match places holds automatically: no new names or addresses and no transfers out, while what you already hold keeps working. That is an automated decision within the meaning of Art. 22 GDPR. The comparison takes names and country and includes near matches. It is permitted because it is necessary to perform the contract and to comply with Union law (Art. 22(2)(a) and (b) GDPR), and it comes with the safeguards of Art. 22(3) GDPR: a person at Tier 0 reviews every match, and you may obtain human intervention, express your point of view and contest the decision. Only you and Tier 0 learn that a review exists. Anybody else sees only that something cannot be added right now, and the transparency log records no screening outcome. The GOpenCSR privacy notice describes screening in full.

Your address space

When you hold space in GOpenCNR, the registry stores:

• allocations: each prefix, its size and the pool it came from, its status (allocated, suspended or quarantined), when it was allocated and until when it is reconfirmed, whether it is open or closed, the audience of a closed prefix, and the parts you delegate to sub-holders;
• ASNs: each number, when it was issued and the providers it names for ASPA. For an ASN you bring from dn42 or from a regional internet registry, the proof of holdership you gave and when it was last checked;
• routes: each prefix with the ASN allowed to originate it;
• services you declare: the address, the port and the audience the service is open to;
• reverse zones: the zone created for your space when it is allocated, and where it is delegated;
• requests and their reasons: the written justification for a larger allocation, a transfer with both holders' consent, a request for a closed prefix, and the decision on each;
• the signature on every change: a passkey assertion over the change's hash, made in GOpenCSR's signing step, or the signature of an automation key you registered under a passkey;
• admin and tech contacts, which only Tier 0 sees.

Pools, from which space is allocated, are created by motions of the GOpenCNR Community Council and hold no personal data.

Why. Holding space, routing it and keeping it unique is the service (Art. 6(1)(b) GDPR).

What becomes public. For each allocation: the holder's handle, the prefix, its size, its dates, its status, whether it is open or closed, its origin ASN, and the holder's abuse relay address, abuse+<handle>@relay.csr.gplatform.org, which forwards messages to you without showing anybody your address. For each ASN: its holder, when it was issued, its ASPA providers and how many open and closed routes it originates. The RPKI repository publishes a ROA for each route, naming the prefix and its origin ASN, and the ASPA objects naming your providers. A closed prefix is published like any other, with its prefix, the holder's handle, its origin ASN and its ROA: only its reachability is closed, and the audience's members and the routes to the prefix stay private. A person's name appears only if that person chooses to show it; a verified organisation appears as the organisation verification terms set out. Endpoints, admin and tech contacts, and your legal name and country are never public. Every interface and export, and how the registry's history works, are set out in the registry data policy.

For what is published we rely on Art. 6(1)(f) GDPR, the legitimate interest being a registry that anyone can route by and check: other networks' filters and route origin validation need prefixes and their origins, uniqueness has to be visible to be trusted, and anyone affected by abuse needs a way to reach the holder.

Public history is kept for good. The registry shows every object's timeline and can be read as it stood at any past moment, and its signed export with its change journal and the git copy of it carry the same history to everyone who mirrors them. A name you show and later withdraw leaves the current pages, the interfaces and every later state of the export, and stays in the past states.

Your routers, devices and keys

When you enrol a router, the agent makes an Ed25519 key on the router and registers its public half, using a single-use enrolment token that is valid for 24 hours. Every request the agent makes after that is signed with this key. For each router we store its name, its platform and agent version, whether the agent runs in managed or include mode, its protection (end to end, encrypted to a hub operator, or hop by hop), its sessions to each hub, the configuration bundles it applied or rolled back, and when it last reported.

For each router and device we store its address in your space, its WireGuard public keys and its endpoint (see the next section). Devices take their addresses from your space and connect to your own router or to your hosted router.

Private keys stay where they are made. A router's private keys are made on the router and never leave it; only the public halves are registered. A device's private key may be made in your browser for its one-time QR configuration: it is shown once, for 15 minutes, and never stored. We hold two kinds of WireGuard key ourselves, in our key store (HashiCorp Vault on our own hardware in Germany): those of Tier 0's hub and those of hosted routers on Tier 0's hub, which the hub fetches when it starts. A hosted router on a certified hub has its keys made on that hub, where they stay.

Names under your free name in GOpenCDR's gnet TLD, such as your devices' names, and the PTR records in your reverse zones are DNS data in GOpenCDR and resolve for anyone who follows it. The GOpenCDR privacy notice covers them.

Why. Connecting your routers and devices is the service (Art. 6(1)(b) GDPR).

Endpoints

An endpoint address is the public IP address and port at which your router or device is reached, very often your home connection. It is never public.

• It is stored encrypted.
• It is shown only to Tier 0 and to members whose direct peering you accepted. When both sides accept, the agents exchange their endpoints through the registry and the session comes up on its own.
• It never appears on a registry page, in an export, in RDAP, whois or the IRR, in the looking glass or on the network map.
• The transparency log keeps only a salted hash of it. Each hash gets a random 32-byte salt, which is kept encrypted beside the record and given only to you and the peers you accepted, with the receipt, so that you can check the entry. Nobody can guess the address back from the log.

Any hub your router connects to receives its packets and therefore sees the address they come from, as any server you connect to does. The operator of a certified hub handles it as our processor and is bound by the hub operator agreement to keep no records of traffic.

Why. Your router cannot be reached without it (Art. 6(1)(b) GDPR).

What your router reports, and what hubs count

Health reports. Your agent reports to the registry the state of its sessions, its latency to each hub, the results of its MTU probes, the packets it dropped and why, its agent version, and whether a configuration change applied cleanly. A change that could cut your router off is rolled back unless the router reports healthy within 5 minutes.

Counters. Each hub counts, per member, bytes, packets and dropped packets by reason, the routes its filters refused and the rule that refused each, sessions held down after flapping, and the bandwidth you use against the fair-use limit. Counters say how much, never who talked to whom, and never what was said.

The collector's live feed. The hubs stream their routing state to our route collector over BMP. It watches for hijacks, leaks, invalid routes and withdrawals, and alerts the holder of the prefix concerned.

Measurements. If you opt in to the measurement network, your agent runs ping, traceroute and DNS measurements between members. Only aggregates are published.

You see your own reports, sessions, latency, drops and refusals. Tier 0 sees them for every member. The operator of a hub sees the sessions, counters and refusals of the members connected to that hub. The public sees aggregates only, on the network map and the statistics page.

Health reports, other telemetry and measurement results are kept for 12 months. Counters are kept in full detail for 90 days; after that only daily totals per member remain, until 12 months. What the collector keeps is described below.

Why. Running your connection and showing you its state (Art. 6(1)(b) GDPR), and keeping the network secure, stable and fair for every member (Art. 6(1)(f) GDPR).

Hubs see ciphertext

Traffic between members runs in two layers. The outer WireGuard tunnel runs from your router to a hub, which decrypts it. Inside it, an inner WireGuard layer runs end to end between the two members' agents, and only members allowed to talk to each other receive each other's inner keys. A hub therefore forwards ciphertext. It sees the two routers' addresses, the size of each packet and when it passed, and nothing more. Hubs keep counters and no records of traffic.

Two set-ups let a hub see more, and both say so on every device they concern:

• A hosted router runs for you on Tier 0's hub or on a certified hub, so that phones, laptops and servers can join with plain WireGuard. Their traffic is decrypted on that hub and encrypted end to end from there, and the devices are labelled accordingly: encrypted to the hub's operator, end to end from there. On Tier 0's hub, the operator is us. A certified hub's operator acts as our processor and is bound by the hub operator agreement not to inspect or record that traffic.
• A router without the agent, running a generated configuration (MikroTik, VyOS, FRR, or plain WireGuard and BIRD), has no inner layer. Hubs see its traffic in the clear. It is labelled "Hop by hop" and never receives closed routes.

Flow sampling inside a case

Hubs keep no flow records. The one exception is an open abuse case, in which Tier 0 may sample the flows of the reported source:

• for at most 7 days, and Tier 0 can end it sooner;
• one packet in 1,000;
• recording source, destination, port and size, never content;
• started and ended as actions recorded in the case.

The samples are deleted when the case closes. What was found in them stays with the case, which is kept for 12 months after it closes.

Why. Stopping abuse of the network and of its members (Art. 6(1)(f) GDPR), within what the secrecy of telecommunications allows.

The secrecy of telecommunications

GOpenCNR carries other people's communications, so their content and their circumstances are protected by the secrecy of telecommunications (Section 3 TDDDG). It binds us and every hub operator. We pass on traffic data only under a law that expressly refers to telecommunications (Section 3(3) TDDDG), never of our own accord. A breach affecting telecommunications data is reported to the Bundesnetzagentur and the BfDI (Section 169 TKG). GOpenCNR and the secrecy of telecommunications sets out what all this means for the counters, for flow sampling and for hosted routers.

Looking glass, network map and statistics

• The looking glass shows routes as the hubs see them: prefix, origin ASN, AS path and RPKI state. Anyone sees open routes. A signed-in member also sees the closed routes of the audiences it is in.
• The network map shows in public each hub with its kind and its country, how many members use it and its health, and totals of sessions and of routes accepted and refused. Each member also sees its own sessions, latency and drops. Endpoint addresses are never shown.
• The statistics page shows counts: holders, prefixes, route origin validation coverage, hubs and growth.

The route collector

The collector publishes MRT dumps of the open routes the hubs carry, every 15 minutes, at cnr.gplatform.org. A published dump holds prefixes, origin ASNs and AS paths, and when routes were announced and withdrawn. It holds nothing about closed routes and no endpoint addresses. Published MRT dumps are kept for 2 years.

What the collector receives and does not publish, the live BMP feed and the raw dumps, closed routes included, is used to watch for hijacks and leaks and is kept for 12 months.

Why. A routing system that anyone can study and debug, and early warning for holders whose prefixes are hijacked or leaked (Art. 6(1)(f) GDPR).

RDAP, whois, the IRR and the exports

The public registry data described above is also served through RDAP, through port 43 whois, as an RPSL export and an IRR mirror, through NRTMv4, as dn42-format exports, as a signed export (a snapshot plus a change journal) and as a read-only git copy of that export. RDAP marks admin and tech contacts as redacted, following RFC 9537. None of them carries an endpoint, an audience's members, an admin or tech contact, or a legal name.

Anyone may mirror the export, so copies of public registry data exist beyond our reach. What each interface holds, and what bulk users may do with it, is in the registry data policy.

Audiences: who sees the members

Audiences are held in GOpenCSR. GOpenCNR uses an audience to decide who receives a closed route and the keys that go with it.

• The audience's holder and Tier 0 see its members.
• Every other member sees only that it is included itself, and the closed routes that follow from that.
• The transparency log records each change only as salted hashes, never the members. Each salt is random, 32 bytes long, kept encrypted beside the record and given to the audience's holder with the receipt.

A certified hub that carries a closed route exports it only to the sessions of the audience's members on that hub, so the hub's operator can tell which of its own sessions are among them. Community hubs never carry closed routes.

Requests to cnr.gplatform.org

Agents, hubs, RDAP clients, RPKI validators fetching the repository and anyone who downloads an export talk to cnr.gplatform.org directly. Each request is logged with the IP address it came from, as the GOpenCSR privacy notice describes for request logs, and request logs are deleted after 14 days (Art. 6(1)(f) GDPR).

Mail and notifications

GOpenCNR tells you of every change to your objects, Tier 0's included, and alerts you about your prefixes. Mail is plain text, sent from cnr@gplatform.org by our own mail server, with no tracking pixels and no links that identify who opened it. If you register a webhook, the same events go to the address you give.

The mail server (Stalwart) runs on the same IONOS server as the services. Neither its delivery log nor the mail in our shared mailboxes (csr@, cnr@, cdr@, contact@ and abuse@gplatform.org) is deleted automatically: it is deleted by hand once it is no longer needed. Cases and requests from authorities follow their own rules.

If you run a hub

If you enrol a hub, we store its name, its public endpoint, its location, its kind (certified or community), its operator and ASN, the results of its automated conformance checks, the history of its probes, and, for a certified hub, its audits, its spot checks and the agreement you signed. The hub's name, kind and country, how many members use it and its health are public on the network map, and its public endpoint is in the configuration of every member who connects to it.

As the operator of a certified hub, you process members' data as our processor under the Art. 28 GDPR clause of the hub operator agreement, and you are your own controller only for the logs of your own infrastructure. The same holds for an audited transit operator under the transit operator agreement.

The operator of a certified hub holds an ex officio seat on the GOpenCNR Operators Council, and so does an audited transit operator. What is published about seats is in the GOpenCSR privacy notice.

We keep these records while the hub or the transit role exists, and for 12 months after (Art. 6(1)(b) GDPR).

Who else receives it

• Hub and transit operators. Certified hub operators and audited transit operators process members' data for us as our processors, under an Art. 28 GDPR clause in the hub operator agreement and the transit operator agreement; each is its own controller only for the logs of its own infrastructure. Community hubs pass automated conformance, carry open routes only, and are used only by members who pick them by name. A hub you use sees what is described above: the address your router connects from, the two routers' addresses and the size and timing of the ciphertext it forwards, your session, your counters and its refusals. Hubs and transit may be run in any country that is not subject to EU sanctions, and the public network map shows each hub's country.
• Members you accept for direct peering receive your endpoint. Members allowed to talk to your router receive its inner public key.
• Interconnected networks. dn42 and NeoNetwork receive GOpenCNR's open routes, with their prefixes, origin ASNs and paths, and exchange traffic with them. Closed routes never cross an interconnect.
• IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Germany, provides the server in Germany on which the portal, the API, the databases, Tier 0's hub and the hosted routers on it, the RPKI repository, the collector and our mail server run.
• Sentry (Functional Software, Inc.), on its EU data region, receives error reports. It is configured to receive no user identifier, cookie, header, request body, query string or value of a local variable: an error report carries the exception, its stack trace, the route that failed and the request identifier. Error events are kept for 90 days. The data is stored in the EU. The company is based in the United States, so access from there cannot be ruled out, and it is covered by the EU standard contractual clauses in Sentry's data processing agreement.
• Courts and authorities receive data only under the authority request policy.
• The public sees what this notice lists as public.

Our signing keys are kept on our own hardware in Germany, and so are our encrypted backups (Proxmox Backup Server), which are made every night and kept for 90 days.

Outside the EU

What we run ourselves is in Germany. Two things can reach beyond the EU: error reports at Sentry, where access from the United States cannot be ruled out, as described above, and hubs and transit that others run outside the EU and the EEA. An operator in a country outside the EU and the EEA that has no adequacy decision signs the EU standard contractual clauses (module 2, controller to processor) as part of its agreement; that is the safeguard under Chapter V GDPR. The public network map shows each hub's country, so you can see where the hubs you use are.

Legal bases at a glance

• Art. 6(1)(b) GDPR: your space, routers, devices, keys and endpoints, your connection through the hubs, hosted routers, direct peering, the reports and counters you are shown, and the alerts and notifications you receive.
• Art. 6(1)(f) GDPR: the security and stability of the network (counters, the collector, leak detection, flow sampling inside a case, request logs), and the integrity of the public registry (the published data, its history, the exports, the looking glass and the published MRT dumps).
• Art. 6(1)(c) GDPR: sanctions screening under the EU sanctions regulations, incident reports under Section 168 TKG, breach notices under Section 169 TKG, and binding requests from authorities.

How long

• Allocations, ASNs, routes, services, reverse zones, routers, devices, endpoints and their keys, and admin and tech contacts: what is not public, while the resource exists and for 12 months after it ends.
• Public registry data: for good, as the registry's history (its past states, the change journal and the git copy).
• Your legal name and country: while you hold resources, and for 12 months after.
• Health reports, other telemetry and measurement results: 12 months.
• Per-member counters: in full detail for 90 days, then daily totals per member until 12 months.
• Collector data that is not published (the live BMP feed and the raw dumps, closed routes included): 12 months.
• Published MRT dumps of open routes: 2 years.
• Flow samples: deleted when the case closes. Cases: 12 months after they close.
• Records of requests from authorities: 5 years after the request is closed.
• Request logs at cnr.gplatform.org: 14 days.
• Error events at Sentry: 90 days.
• Mail in our shared mailboxes and the mail server's delivery log: not deleted automatically, but by hand once no longer needed.
• Device keys made in your browser: never stored. The one-time view ends after 15 minutes.
• Hub and transit operator records: while the role exists, and 12 months after.
• The transparency log: permanently, with identifiers and salted hashes only.
• Backups: made every night and kept for 90 days. They are not edited, and are restored only to recover the service.

Where a statutory retention period applies, it applies instead.

Your rights

You have the right of access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction of processing (Art. 18), data portability (Art. 20) and the right to object to processing based on legitimate interests (Art. 21 GDPR). Write to contact@gplatform.org; an informal email is enough, and we answer within 30 days. The GOpenCSR privacy notice sets out how these rights work for your account.

If you showed your name and want it gone from the history we publish as well, write to the same address, and we weigh the request case by case under Art. 17 and 21 GDPR. Copies that others have taken of the export are beyond our reach.

You have the right to lodge a complaint with a supervisory authority. For personal data we process to provide GOpenCNR's telecommunications service, the competent authority is Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI), Graurheindorfer Straße 153, 53117 Bonn (Section 29 TDDDG). For everything else, it is Die Landesbeauftragte für den Datenschutz Niedersachsen, Prinzenstraße 5, 30159 Hannover.

Holding space needs a handle and an abuse relay address and, for a person, a legal name and country for screening; a router cannot connect without its public keys and the address it connects from. Without them, we cannot provide GOpenCNR. Sanctions holds are the one automated decision within the meaning of Art. 22 GDPR, with the safeguards described under "Your legal name and country". Hubs apply route filters, max-prefix limits, the flap hold-down, the fair-use limit and the immediate cut of a leaked closed route automatically: these are technical rules that protect the network, not decisions about you. A sanction against you is decided by a person, in a case under the abuse and sanctions policy.

Changes

This notice changes when GOpenCNR does. Every version is kept in the document archive.