GOpenCNR security and disclosure policy

How this relates to the Gelhaus Solutions policy

GOpenCNR is covered by Gelhaus Solutions' vulnerability disclosure policy, and everything in it applies here: how to report, the response times, the safe harbour, credit and identifiers. This page adds what is particular to a network: what is in scope, what matters most, and what testing must never do, because the hubs carry the traffic of members who never agreed to be part of a test, and the agent runs on their routers.

GOpenCNR is part of the scope of the Gelhaus Solutions CVE Numbering Authority, with full coverage, and identifiers are assigned as the disclosure policy describes.

Accounts, sign-in, the API front door, the transparency log and the agent core library that the join agent is built on belong to GOpenCSR, and the GOpenCSR security and disclosure policy covers them. Names, resolvers and certificates belong to GOpenCDR, whose security and disclosure policy covers them. If you are not sure where a finding belongs, report it here: every route reaches the same person.

How to report

Email contact@gplatform.org, or file the report through GAdvisory. Both reach the same person and start the same process. For anything sensitive, encrypt with the key whose fingerprint is on the disclosure policy. Please do not open a public issue.

Put "GOpenCNR" in the subject line, and "urgent" as well where the report concerns key material, the RPKI, a leak of closed prefixes or the hubs. Those are read first.

GOpenCNR's security.txt, at https://cnr.gplatform.org/.well-known/security.txt, points to this page, and so does the footer of every GOpenCNR page.

What is in scope

• The portal and the registry API at cnr.gplatform.org, including GOpenCNR's part of the API front door, csr.gplatform.org/api/cnr/v1.
• RDAP, whois, the IRR server and NRTMv4, and every export: the signed export and its git copy, the dn42-format exports, and the RPKI JSON, SLURM and BIRD files.
• The hubs and hub mode: Tier 0's hub, the hub software that certified and community hubs run, hosted routers, and the filters, forwarding checks and keys the hubs hold.
• The join agent on every platform, with its enrolment, its signed requests, its bundles and its updates, and the bundle builder that makes the bundles.
• The RPKI: the certification authority, the repository over RRDP and rsync, the TAL and the RTR caches.
• The route collector, the prefix alerts, the looking glass and the network map.
• The command-line tools gocnr and gocnrctl.

What we most want to hear about

1. Any way to reach a closed prefix from outside its audience, in routing or in forwarding, or to obtain the inner keys of a member you are not allowed to talk to.
2. Any way to leak closed routes: to make a closed route reach a community hub, a transit member, a direct session, an interconnect, the public looking glass, the collector's published dumps or anybody else outside its audience, or to learn who is in an audience.
3. Any way to learn a member's endpoint address without being a peer it accepted, or a member's legal name and country without being Tier 0: from a registry page, an export, RDAP, whois, the looking glass, the network map or the transparency log, including by working out what a salted hash in the log stands for.
4. Any way to forge or replay agent requests or bundles: to enrol without a valid token, to act as somebody else's agent, to have a signed request accepted after its 60 seconds or more than once, or to make an agent apply a bundle or an update we did not sign, or a bundle with a lower serial than the one it runs.
5. Any way to make a hub accept a route it should refuse: from an origin other than the route object's, invalid under RPKI or ASPA, more specific than a route object, outside GOpenCNR's ranges, a default route, or beyond the max-prefix limit. Equally, any way to make a hub forward packets whose source lies outside the sender's space, or carry traffic between the internet and members.
6. Any way to obtain an RPKI signature other than through the intended path: to make the online CA sign for space the registry does not hold, to use the trust anchor key outside a ceremony, or to recover a one-time EE key after its signature.
7. Any way to obtain an allocation without the review it needs: a size above the default, a closed prefix, a transfer or a reclamation without Tier 0's four-eyes approval, a pool without a council motion, approving your own request, or any registry change without the holder's valid signature or without its entry in the transparency log.
8. Any way to escape the agent's privileges on a member's router: from its network capabilities or its privileged helper to anything the agent does not manage, from a bundle to commands the agent should never run, or from one hosted router to another on the same hub.

Rules for testing

The network carries traffic for members who never agreed to be tested on, and the agent runs on their routers. Research here therefore has rules of its own, on top of those in the disclosure policy.

• Test against your own space, your own routers and devices and your own hosted router. Use the registry sandbox and the sandbox hub wherever they can show the problem.
• Do not scan other members. Scanning between members is forbidden; the exposure check scans your own space when you ask for it.
• No denial of service. Do not load-test, flood or try to exhaust the hubs, the RPKI repository, the RTR caches, RDAP, whois, the API or the portal, and do not use a hub to reflect or amplify traffic at anybody.
• Do not test hubs you do not operate beyond normal use as a member. To show a filter or forwarding problem, use your own space, the sandbox hub or a hub you run yourself.
• Do not announce space you do not hold on a live hub, and do not try to leak closed routes there.
• Do not test dn42, NeoNetwork or their members through the interconnects.
• Access only what you need to show the problem. If you reach other people's data or traffic, stop, keep none of it, and tell us.
• No social engineering of our staff, of hub operators or of members, no physical attacks, and nothing aimed at our own hardware, including the key store (HashiCorp Vault) and the network behind it.
• Keep the details private until the coordinated date.

Research within these rules is welcome, and the safe harbour in the disclosure policy covers it.

What is out of scope

• Findings in third-party software we run unmodified, such as BIRD, FRR, WireGuard, IRRd, Routinator, rpki-client, BGPalerter, HashiCorp Vault, Temporal or PostgreSQL. Report those to the project; we will help, and we will apply the fix.
• Weaknesses of BGP, the RPKI or WireGuard themselves with no impact particular to GOpenCNR.
• dn42 and NeoNetwork, and their registries.
• What a set-up shows by design and says on its label: that a hub operator sees the traffic of a hosted router on its hub, or that hubs see the traffic of a router running hop by hop. A way for anybody else to see that traffic is in scope.
• Findings that need an already compromised router or device, or administrative access to a hub you do not operate, unless GOpenCNR makes them worse.
• Output of automated scanners without a demonstrated impact, missing headers without an impact, and rate limits, filters and hold-downs working as described.
• Abuse by a member, such as scanning or attacks from GOpenCNR space, which goes to abuse@gplatform.org under the acceptable use policy.

If a key may be compromised

If you believe the RPKI trust anchor key, the online CA key, the bundle signing key, the release signing key or a hub's keys may be exposed, write at once, with "urgent" and "Key" in the subject line. Tier 0 can act immediately under its emergency procedure, which may only suspend or tighten, never loosen, and which lapses after 90 days unless it is reaffirmed. Every emergency action is published in the transparency log and reviewed afterwards. What happens to the RPKI in that case is set out in the RPKI certification practice statement.

If one of your own keys may be exposed, such as your agent's key, a router's or a device's WireGuard key or an automation key, revoke it in the portal at once. The rotation flow lists every change the key signed, and the objects it signed stay frozen until you sign them again.

Problems that are not vulnerabilities

A refused route, a session held down, a prefix alert you cannot explain, a repository that has gone stale or two validators that disagree is not always a vulnerability, but we want to hear about it just as quickly. Write to the same address.