GOpenCNR enterprise data processing agreement

This agreement

This agreement is between the customer, as controller, and Gelhaus Solutions, a sole proprietorship of Enno Gelhaus, Eichenwald 3, 49624 Löningen, Germany, as processor, under Art. 28 GDPR. It is part of every order form signed under the GOpenCNR enterprise terms and is concluded with it; the order form names the version it was signed under. Contact for anything in it: contact@gplatform.org.

It is GOpenCNR's part of the general data processing agreement, and it is complete in itself: it sets out every point Art. 28(3) GDPR requires for GOpenCNR's enterprise services. Where the two differ on a point about GOpenCNR, this agreement wins.

What it covers, and what it does not

It covers the personal data we process on the customer's behalf in three services:

• managed edge routers that Tier 0 manages for the customer;
• dedicated hubs that Tier 0 runs for the customer, on its own servers;
• the administration of the customer's sub-pools: who holds which role on them, the contacts the customer enters for them, and the parts of its address plan that the registry does not publish.

It does not cover what we process as controller: the accounts, sessions and organisation records in GOpenCSR; the public registry data, the RPKI and the transparency log; abuse cases, including flow samples taken inside a case; requests from authorities; and the free core of GOpenCNR. The GOpenCSR privacy notice and the GOpenCNR privacy notice describe them. Nor does it cover what a member processes on its own account.

Subject matter and duration

The subject matter is operating the enterprise services named in the customer's order forms. This agreement lasts as long as any of them runs, and after that until the data has been returned or deleted as described below.

Nature and purpose of the processing

• Managed edge routers: storing the configuration the customer asks for, building it into signed bundles and applying it to the router; receiving the router's health reports, telemetry and traffic counters; installing updates; finding and fixing faults.
• Dedicated hubs: terminating the outer tunnels of the customer's routers, running their BGP sessions, forwarding their traffic and counting it.
• Sub-pool administration: keeping the roles, contacts and address plan the customer enters for its sub-pools, and acting on them.

The purpose is providing those services to the customer, and nothing else. We do not analyse the data for any other purpose, build profiles from it or use it for advertising.

Categories of data subjects

• The customer's staff and the other people it admits to its organisation.
• The people the customer names as contacts for its sub-pools and their sub-holders.
• People who use the devices and networks behind a managed edge router.
• People whose traffic passes a managed edge router or a dedicated hub.

Categories of personal data

• Configuration of a managed edge router: the address plan, DHCP and router advertisement settings, firewall zones and rules, port forwards and NAT, routes and BGP sessions, VLANs, Wi-Fi network names and keys, local DNS names, and devices with their names and public keys. Device and host names can identify a person.
• Reports and counters: the health reports and telemetry of managed edge routers, and per-member counters on a dedicated hub: bytes, packets and dropped packets by reason, refused routes, sessions held down after flapping, and bandwidth used against the fair-use limit. Counters say how much, never who talked to whom and never what was said.
• Endpoint addresses: the public addresses at which the customer's routers connect. They are stored encrypted, shown only to Tier 0 and to peers the customer accepted, and never published.
• Traffic in transit: a dedicated hub sees the outer addresses of two routers and the size and timing of each packet, and forwards the inner traffic between agents as ciphertext. It keeps nothing of it beyond the counters.
• Sub-pool administration data: roles held on the sub-pool and on its sub-allocations, contacts for them, and the unpublished parts of the address plan.

We never read the content of traffic. The services are not built for special categories of personal data, and the customer puts none into configurations, names or contacts.

Processing operations

Storing, generating and signing configuration, sending it to routers, receiving reports, forwarding packets, counting, controlling access, backing up and deleting.

Instructions

• We process the data only on the customer's documented instructions, including on any transfer to a third country. Its instructions are this agreement, the order form, the settings it chooses in the portal, and what the contacts the order form names for instructions ask for in writing.
• Where an instruction appears to us to breach the GDPR or another data protection rule, we say so, and may hold it until the customer confirms or withdraws it.
• An instruction that would breach the GOpenCNR terms, the acceptable use policy, the network participation agreement or a rule that protects other members, such as switching off anti-spoofing or opening a closed prefix beyond its audience, is not carried out. We say which rule stands in the way.
• Where Union or Member State law requires us to process beyond the instructions, such as under an order handled by the authority request policy, we tell the customer before we do, unless the law forbids it.

Confidentiality

• Everyone we authorise to process the data is bound to confidentiality, by contract or by a statutory duty, and stays bound after their work ends.
• The content of traffic and its circumstances are also protected by the secrecy of telecommunications (Section 3 TDDDG), which binds us and everyone who works for us. GOpenCNR and the secrecy of telecommunications sets out what that means for counters, flow sampling and hosted routers.
• Access to production systems is limited to those who need it to run the service, every Tier 0 change needs a passkey, and every access that changes something is logged.

Security

We take the measures Art. 32 GDPR requires. In short:

• Keys are held in HashiCorp Vault on our own hardware in Germany, and signatures are made there. Router and device keys are made on their host and never leave it.
• Every change is signed, by a passkey or an automation key registered under one, and Tier 0's approvals run under the four-eyes principle.
• Traffic is encrypted: WireGuard between routers and hubs, and end to end between agents. Endpoint addresses are encrypted at rest.
• Hubs forward ciphertext and keep counters, and flows are sampled only inside an open case.
• Routers apply only signed bundles, and a change that could cut one off rolls back on its own.
• Audit records are append-only, and backups are encrypted, kept on our own hardware in Germany for 90 days, and restored in drills.
• Personal data is processed only in the EU, on servers in Germany.

The full list is the annex "Technical and organisational measures" at the end of this agreement. We may replace a measure with one that protects at least as well, and we never lower the overall level.

Sub-processors

The customer gives general authorisation for us to engage sub-processors. These are engaged:

• IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Germany, rents us the servers in Germany on which the GOpenCNR control plane, Tier 0's hubs and our own mail server (Stalwart) 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. The data is stored in the EU, and error events are kept for 90 days. 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.

Our signing keys and encrypted backups are on our own hardware in Germany, reached over WireGuard; that is not a sub-processor. Mail goes out from our own mail server.

Certified hub and transit operators are not involved. Dedicated hubs are run only by Tier 0, on its own servers, and managed edge routers report directly to our own systems, so nothing we process under this agreement is handed to a hub or transit operator. Where the customer's routers also use the shared network, that traffic belongs to GOpenCNR's free core, which we process as controller. There, certified hub operators and audited transit operators are our processors under Art. 28 clauses in their agreements, bound by the EU standard contractual clauses (module 2, controller to processor) where they are outside the EU and the EEA and outside countries with an adequacy decision, as the GOpenCNR privacy notice describes.

Every sub-processor is bound by a contract with the same data protection obligations as this agreement, and we remain liable to the customer for each of them (Art. 28(4) GDPR).

Changes. We tell the customer's contacts before we add or replace a sub-processor, and the notice states the period in which the customer may object. If the customer objects on reasonable data protection grounds and we cannot offer an alternative, it may end the affected order, and any fee paid in advance for the time after that is refunded.

Helping the customer

• Requests from data subjects (Arts. 12 to 23 GDPR). We help the customer find, correct, export or delete the data in our systems, and point it to the feature that does so where there is one. A data subject who comes to us about data the customer controls is referred to the customer, and the customer is told.
• Arts. 32 to 36 GDPR. We help with securing the processing, with notifying and communicating breaches, with impact assessments and with consulting the supervisory authority, by providing what we know about how the services work.
• Ordinary assistance is included. Where a request is disproportionate, we may charge for the effort, and say so before starting.

Personal data breaches

• We notify the customer of a personal data breach without undue delay after becoming aware of it, and in any event in time for the customer to meet its own 72-hour deadline under Art. 33 GDPR.
• The notice describes what happened, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact. Where we do not have everything at once, we send what we have and follow up.
• We do not notify the customer's supervisory authority or data subjects on its behalf unless it asks us to in writing.
• Our own duties as a network operator run alongside this and replace nothing we owe the customer: reporting security incidents under Section 168 TKG to the Bundesnetzagentur and the BSI within 24 hours, 72 hours and one month, and notifying breaches of personal data in telecommunications under Section 169 TKG to the Bundesnetzagentur and the Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI).

Deletion and return

• When an order ends, the customer chooses whether we return its data or delete it. Unless it says otherwise, the data stays available for export for 30 days after the order ends and is then deleted. On request we delete it sooner.
• A managed edge router keeps the configuration that is on it, which is the customer's. Our copies are deleted as above.
• During the term, health reports and telemetry are kept for 12 months. Fine-grained traffic counters are kept for 90 days; after that only daily totals per member remain, until 12 months.
• Backups are taken nightly to our own hardware in Germany and kept for 90 days. They are not edited, and data in a backup is restored only to recover the service, never to bring back what was deleted.
• We keep only what Union or Member State law requires us to keep, and tell the customer what and why if that ever applies.

Audits

• We make available what the customer needs to show that this agreement is kept: the annex below, the list of sub-processors, and answers about how the services handle data.
• Every change to the customer's registry objects is in the transparency log with a signed receipt, and every change to a managed edge router writes an audit record, which the customer may ask to see.
• Where that is not enough, an inspection can be arranged with reasonable notice, during business hours, without disrupting operations, by someone bound to confidentiality who is not a competitor of ours. Where an inspection goes beyond what Art. 28(3)(h) GDPR requires, we may charge for the time.

Transfers to third countries

• Personal data is processed only in the EU, on servers in Germany. The one exception is Sentry, as described above, under the EU standard contractual clauses.
• There is no other transfer, unless the customer instructs one in writing and Chapter V GDPR allows it.

Liability

Towards data subjects, each side is liable as Art. 82 GDPR provides. Between the two, each bears a damage in proportion to its share of responsibility for what caused it (Art. 82(5) GDPR). Beyond that, liability is as the general terms of service set it out for businesses. Nothing in this agreement limits liability under Art. 82 GDPR.

Changes

A material change to this agreement is emailed to the customer at least six weeks before it takes effect, and at its next sign-in the customer is asked to accept the new version, which is shown in full and linked in the document archive, without a list of what changed. A new version applies to an order only once the customer accepts it. Until then, each order stays under the version its order form names. If the customer does not accept, we may end the order at its next ordinary end date under its order form, and only then. Adding or replacing a sub-processor follows "Sub-processors" above, not this section. Every version stays in the document archive.

Annex: technical and organisational measures

These are the measures under Art. 32 GDPR for the services this agreement covers.

Identity and access

• People sign in at csr.gplatform.org with a passkey or a password. Passwords are stored as argon2id hashes and have at least 15 characters; five wrong attempts in a row lock the account for 15 minutes.
• Session tokens are stored only as hashes. A session ends after 7 days without use or 30 days at most; for Tier 0's root roles after 30 minutes without use or 12 hours at most. A confirmation with a passkey is valid for 5 minutes.
• Every Tier 0 change needs a passkey. Tier 0's approvals run under the four-eyes principle in the database, a request expires 72 hours after it was made, and an approval made alone while Tier 0 is one person is flagged as decided alone.
• Roles (owner, admin, tech, abuse, read-only) are given on the holder and inherited down the allocation tree. A role grant is never deleted; a revoked grant stays in the history.
• API keys always expire (at most 400 days, 90 days by default), never carry Tier 0 permissions, cannot decide an approval or manage keys, are shown once, can be limited to named addresses, and are limited to 600 requests a minute; failed key attempts are limited to 30 per address in 15 minutes.
• Support works through read-only views. Nobody signs in as a customer's user.

Integrity of changes

• Every change to the registry is signed by the holder, by a passkey assertion over the change's hash or an Ed25519 automation key registered under a passkey, and its receipt is its transparency log entry with an inclusion proof. A monitor checks every logged change against the holder's keys and alerts the holder to anything it did not sign.
• Bundles for routers and hubs are signed in Vault Transit and carry a serial number; a lower serial is refused, and the signing key is pinned in the agent release.
• Every agent request is an EdDSA signature bound to the hash of the request body, expiring after 60 seconds. Enrolment uses a single-use token valid for 24 hours, and the agent's key is made on the router.
• A change that could cut a router off applies commit-confirmed and rolls back unless the router reports healthy within 5 minutes. Hub changes reach a canary hub first and roll back on a health regression.
• Release images are rebuilt locally, their digests compared with the build, and signed through Vault. Agents and hubs run only signed digests.

Keys

• Keys are held in HashiCorp Vault, on our own hardware in Germany, reached only over WireGuard. Keys never leave it, with two written exceptions: RPKI one-time keys, made in memory and destroyed after one signature; and the WireGuard keys of Tier 0's hubs and hosted routers, kept in Vault and fetched at boot over a direct link that never runs over GOpenCNR.
• The RPKI trust anchor key is fenced so that only a ceremony identity can use it, in scripted ceremonies under the four-eyes principle with minutes in the transparency log.
• The keys of members' routers and devices, a managed edge router's included, are made on their host and never leave it; only their public halves are registered.

The network

• Two WireGuard layers: router to hub, and agent to agent end to end inside it. Hubs forward the inner traffic as ciphertext and keep counters, not traffic records.
• Flows are sampled only inside an open case, for at most 7 days, 1 in 1,000 packets, recording source, destination, port and size, never content; the samples are deleted when the case closes.
• Each tunnel accepts only sources inside the member's registered space, and hubs forward only packets whose source and destination both lie inside GOpenCNR ranges or a named interconnect.
• Import filters are generated from the registry and validate RPKI and ASPA. A hub that cannot load fresh data keeps its last good filters and never opens up.
• Closed routes travel only through Tier 0's and certified hubs, only audience members hold each other's inner keys, and a leak is cut at once.
• The agent's firewall denies traffic from GOpenCNR unless a declared service opens it.
• Endpoint addresses are encrypted at rest and never published. In the transparency log they appear only as hashes, each with its own random 32-byte salt, which is kept encrypted beside the record and given to the holder and accepted peers with the receipt, so that they can verify the entry and nobody can guess an address from the log.

Keeping data small

• The raw IP address in an audit record is deleted after 90 days; a keyed hash (HMAC-SHA256 under a secret in Vault) stays with the record.
• Request logs are deleted after 14 days. Rate-limit windows are keyed by the address hash only and deleted after 24 hours, and idempotency records after 24 hours.
• Health reports and telemetry are kept for 12 months; fine-grained traffic counters for 90 days, then only daily totals per member until 12 months.
• Application logs pass a redaction list. Error reports to Sentry carry no personal data, as configured above, and are kept for 90 days.
• The transparency log holds identifiers and hashes, never names, email addresses or IP addresses.

Availability and recovery

• The databases, the RPKI repository and the hubs' host configuration are backed up every night, encrypted, to a Proxmox Backup Server on our own hardware in Germany and kept for 90 days, and restoring them is drilled.
• Routers keep running on their last signed bundle when the control plane is down, and no critical path of the three services depends on another in a loop.
• Written runbooks cover a hub outage, a key compromise, a closed-route leak, a Vault outage and incident reporting.

Organisation

• Everyone who processes the data is bound to confidentiality and to the secrecy of telecommunications.
• The agent, the hub, the RPKI CA, change signing and closed prefixes each have a threat model, and every routing or filtering feature is proven by a lab scenario.
• Vulnerabilities are reported and handled under the GOpenCNR security and disclosure policy.
• We keep a security concept under Section 166(2) TKG, report security incidents under Section 168 TKG to the Bundesnetzagentur and the BSI within 24 hours, 72 hours and one month, and notify breaches of personal data in telecommunications under Section 169 TKG to the Bundesnetzagentur and the BfDI. Gelhaus Solutions is registered with the BSI as a particularly important entity (besonders wichtige Einrichtung).