SECOND MEASUREMENT SM-014
Brazil’s RPKI registry gives a member five days to fix a lapsed manifest. Validators drop the member’s route authorisations in the first hour. Thirty members lapsed in the week to 3 October; by 8 October twenty had been deleted
The internet’s routing system runs on trust between networks, and RPKI is the paperwork that lets a router check a claim like “this block of addresses belongs to that network” against a signed record. Every publisher of those records keeps a manifest, a signed table of contents with an expiry time, and the rule is plain: publish a new one before the old one expires, because a validator that finds an expired manifest must treat the folder as a failed fetch, and the two validators we read then carry nothing from it. Brazil’s registry, registro.br, lets each member run its own signing software, and its page sets out what happens when one stops: a warning seven hours before the deadline, another after it, and five calendar days to fix it before the registry removes the member’s RPKI configuration. The two validators we read, rpki-client and Routinator, do not wait five days. They drop the member’s route authorisations at hour one. So there is a window of about five days in which the registry treats a member as late and every validator treats it as gone, and nobody owns it. We read every manifest from ten repositories ourselves, straight from the files they publish, with no validation software in between, to count who was in that window. The four big regional registries, RIPE, ARIN, APNIC and LACNIC, had none past expiry. registro.br had 178. Thirty of them had expired in the past week, 29 inside live certificate chains, listing 135 route authorisations for 29 Brazilian networks; our Routinator run carried none of them, and rpki-client’s console all but four, those four only because it validated their two manifests while they were still in date, one of which expired four minutes before the dump’s build time and the other four hours after it. Five days later none of the thirty was still lapsed: ten had recovered and twenty had been removed, and fourteen new members had taken their place in the window. The other 148 expired as long ago as 2020 and are still being served. RIPE and ARIN each run a publication service for members who sign with their own software, and the same thing collects there in a tidier form: 214 of the 563 manifests on RIPE’s are past nextUpdate, 34 of them under certificate authorities RIPE’s own validator was still evaluating and rejecting on 4 October, the rest under chains nothing reaches, some dead for three and a half years. RIPE does not hold those members’ keys, so it cannot re-sign their manifests. It can only stop serving them.
- RFC 9286 section 5.2: “A new manifest MUST be issued and published before the nextUpdate time.” Section 6.3: past nextUpdate “the manifest is stale; the RP MUST treat this as a failed fetch.”
- We decoded 55,426 manifests from the RRDP snapshots of ten repositories on 3 October (04:20 to 04:31 UTC), the five RIR roots and five more (registro.br, the RIPE and ARIN publication services, IDNIC and TWNIC), and compared each nextUpdate with the fetch time.
- RIPE 22,816, ARIN 9,706, APNIC 10,712, LACNIC 3,446: zero expired. Indonesia’s IDNIC and Taiwan’s TWNIC, two more delegated repositories outside the RIRs: zero.
- registro.br: 178 of 3,797 expired. 30 in the last seven days, oldest 113 hours past nextUpdate in a live chain; 148 more with nextUpdate between 2020 and 2023 (1 in 2020, 29 in 2021, 113 in 2022, 5 in 2023). A second read 29 minutes later: identical.
- registro.br’s documented process (its RPKI page): members sign with their own CA software; the registry emails a warning 7 hours before nextUpdate and a “Publicação RPKI em atraso” notice after it, allows 5 calendar days to fix it, then removes the member’s RPKI configuration, “because validators … will start treating the organisation’s RPKI objects as expired … and discard the associated ROAs”. All 29 sit inside that window.
- The 29 live-chain manifests list 135 route authorisations covering 135 prefixes held by 29 networks. 119 of those prefixes are in the global routing table today and 117 validate as “unknown”: live routes with their RPKI protection switched off, for a median of 69 hours at our 04:49 UTC read and about 83 by the time of the routing read that evening. rpki-client’s dump, taken five hours before our read, already marked 27 of the 29 Failed; the other two were still in date when it validated them. Routinator, run after all 30 had expired, keeps none of the 135.
- RIPE’s publication service: 214 of 563 expired, none reached by the console dump, but RIPE’s own validator on 4 October was still evaluating 34 of them, 9 to 331 days past nextUpdate at our 3 October read, and rejecting each with “certificate has expired”, so those 34 publication points, under 18 of the service’s CAs, were still delegated; 13 since 2023, 38 since 2024, 93 since 2025, 70 this year. These are members’ own certificate authorities publishing through RIPE, which serves the files and holds none of the keys. RIPE NCC’s own repository had nothing expired. ARIN’s publication service: 12 expired, 11 of them at least 47 days past, one live and 14 hours past. AFRINIC: 11, dead since 2016 to 2019.
- The repositories do not share a deadline. RIPE NCC’s manifests last 24 hours, ARIN’s 72, LACNIC’s 126 and APNIC’s 168, so APNIC has seven times as long as RIPE NCC before anything can expire. The zeros say what was expired at one moment. They do not rank how carefully each repository is run.
- Daily reads since: manifests expired within the past week at registro.br numbered 23 later on 3 October, then 21, 35, 25, 11 and 19 on the five days after.
Disclosure: Markovian Protocol holds no financial position in any organisation named here, was paid by no one for this work, and showed it to no one before publication except one reviewer, whose check covered the method and the framing, and who put one question of ours to a third party before publication. How we work.
RPKI repositories publish their objects through RRDP: a notification file points at a snapshot, and the snapshot is an XML file carrying every published object, base64-encoded.3 We fetched each repository’s notification and snapshot, took every object whose name ends in .mft, parsed the CMS wrapper and the manifest inside it (RFC 9286 section 4), and recorded manifestNumber, thisUpdate, nextUpdate and the number of files listed. No validator, no cache, no trust anchor: this is what the repository hands anyone who asks, read against the clock. Expired means nextUpdate earlier than the moment we fetched the snapshot. For registro.br we did it twice, 29 minutes apart. To see what validators do with those files we used two independent ones: the public rpki-client console’s object dump from five hours earlier, which records a validation state per manifest and the file list each one carries,4 and a fresh run of Routinator 0.15.2 on this machine over the five trust anchors, exported with the source of every route authorisation (its log and a summary of the export are in the exhibits; the configuration file it read was not kept). The 135 affected authorisations and the networks behind them come from the file names in the expired manifests, which registro.br forms from the prefix, maximum length and AS number of each.
What they said, what we found
| The rule | We found |
|---|---|
| RIPE NCC’s public validator reports the registro.br repository every run; on 4 October 2026 at 01:52 UTC: 3,589 valid manifests, 23 rejected publication points. A 2022 thread on the NLnet Labs list explains why: every Brazilian holder runs its own CA and “a handful are broken at any moment”, and “NIC.br is pretty good at monitoring and chasing this though.”6 | The rejected points are visible; what sits behind them is not. Our recount names the 29 lapsed manifests in live chains, the 135 route authorisations for 29 networks that both validators drop while they lapse, and the registry’s own 7-hour warning and 5-day removal policy against a lapse that had run 113 hours when we read it. |
| RFC 9286 section 5.2: “A new manifest MUST be issued and published before the nextUpdate time.” Section 4.2.1: “Even if no changes are made to objects at a publication point, a new manifest MUST be issued before the nextUpdate time.”1 | registro.br serves 178 manifests past nextUpdate, 30 of them this week; RIPE’s publication service 214; ARIN’s publication service 12; AFRINIC 11. The four RIR root repositories: none. |
| RFC 9286 section 6.3: “If the current time is later than nextUpdate, then the manifest is stale; the RP MUST treat this as a failed fetch.” Section 6.6: the RP continues to use cached objects “until such time as they become stale”.1 | rpki-client: 27 of the 29 live registro.br manifests marked Failed in a dump that still carried the other two, one of which expired four minutes before the dump was built. Routinator: 0 of 135 authorisations. The networks fall to “not found”, the state RPKI was built to replace. |
| RIPE NCC Certification Practice Statement (ripe-851): CRL Next Update “24 hours from the moment of issuance” for its CA, hosted CA and ACA rows; certificates “published within eight hours of being issued” and other objects no later than eight hours after issuance.2 | RIPE’s own repository: 22,815 of 22,816 manifests on a 24-hour window (one on 91 days), none expired, the closest 15.5 hours from its deadline. That promise covers the CAs RIPE runs. The publication service next door carries members’ own CAs: 214 manifests that nobody has reissued since as far back as February 2023, 34 of them under CAs RIPE’s own validator still evaluated and rejected on 4 October, and that RIPE has no key to reissue. |
Ten repositories, one clock
| Repository | Manifests | Window (median) | Expired | This week | In a live chain |
|---|---|---|---|---|---|
| RIPE NCC (rrdp.ripe.net) | 22,816 | 24 h | 0 | 0 | 0 |
| ARIN (rrdp.arin.net) | 9,706 | 72 h | 0 | 0 | 0 |
| APNIC | 10,712 | 168 h | 0 | 0 | 0 |
| LACNIC | 3,446 | 126 h | 0 | 0 | 0 |
| AFRINIC | 1,534 | 48 h | 11 | 0 | 0 |
| registro.br (Brazil, NIC.br) | 3,797 | 26 h | 178 | 30 | 29 |
| RIPE NCC publication service (paas) | 563 | 26 h | 214 | 0 | 0 by the console; 34 by RIPE’s validator |
| ARIN publication service (rps) | 139 | 26 h | 12 | 1 | 1 |
| IDNIC (Indonesia) | 2,316 | 26 h | 0 | 0 | 0 |
| TWNIC (Taiwan) | 397 | 26 h | 0 | 0 | 0 |
The Window column changes how to read the zeros. A window is how long a manifest lasts before it must be replaced. RIPE NCC’s last 24 hours and APNIC’s 168, so APNIC has seven times as long before anything can expire, and a zero from each is a different amount of work. This table reports what was expired at one moment. It does not rank how carefully each repository is run.
Two kinds of expired manifest show up, and they mean different things. A manifest in a live chain, one whose certificate authority is still valid and still delegated from the RIR, that goes past nextUpdate is a CA that stopped signing. Validators drop its contents and the networks it covers lose protection. A manifest whose chain is gone is litter: a customer left, a key was rolled, and the repository kept serving the old files. Validators never reach them. Brazil has both. RIPE’s publication service has both as well: of its 214, the console dump reached none, but RIPE NCC’s own validator was still evaluating 34 on 4 October and rejecting them with “certificate has expired” (Exhibit 6), which it can only do for a CA that is still delegated; the other 180 it did not reach. Those manifests were signed by members’ own certificate authorities with keys RIPE does not hold, so RIPE cannot reissue them. It can stop serving them. Its own repository, next door, had nothing expired.
What stopped in Brazil
The 30 recent expiries at registro.br are 30 separate publication points, one per member organisation, and their last signatures are dated between 25 September and 2 October. That is not a registry outage. Under registro.br’s model each member runs its own certificate authority (the page names Krill) and publishes through the registry’s repository; these are 30 members whose signer stopped. The registry’s page says it watches exactly this, warns the member seven hours before the deadline, and removes the configuration after five days without a fix. So what we measured is the five-day grace period in operation: the registry keeps serving a lapsed manifest for up to five days, and for every one of those days the validators have already dropped it.
| Expired for | Manifests | Files listed | Among them |
|---|---|---|---|
| 96 to 161 hours | 9 | 50 | 187.110.144.0/21 for AS269073 (113 h); 177.39.12.0/22 for AS52790; 2804:8478::/32 for AS272262. The oldest of the nine, at 161 h, is outside any live chain and absent from the console dump, so we never saw its file list; the snapshot says it carries three files |
| 48 to 96 hours | 6 | 57 | AS263546’s single point, 37 authorisations; 190.89.4.0/24 for AS270399 |
| under 48 hours | 15 | 61 | AS262777, 10 authorisations; 177.53.198.0/23 for AS274729 |
Twenty-nine networks, 135 prefixes. AS263546 has 37 of them, AS269073 12, AS262777 10. We then asked RIPE’s routing database what the internet sees of those prefixes right now: 119 of the 135 are being announced in BGP today, and 117 of them validate as “unknown”, the state a route has when no valid authorisation exists for it. For a median of 69 hours at the 04:49 UTC read, and for one network 113, those routes had carried no protection against a hijack while their owners’ signed statements sat in the repository, expired. Two prefixes, both AS266549’s, showed as valid at the routing read (the file was written at 18:58 UTC; we did not log the request time). Its manifest had lapsed only 1.3 hours before our read, the console dump built before that still lists both ROAs as OK (console_roas_as266549.json), and by 8 October the manifest had been reissued; we did not capture whether that happened before the routing read; RIPE’s validator no longer listed its point at 01:52 UTC on 4 October, so the reissue came before that. The three biggest holders of the affected routes are regional operators, whose full names RIPEstat records: Turbonett (AS263546, 30 live prefixes), NipTelecom (AS269073, 12) and Neolink (AS262777, 10). On 3 October at 04:49 UTC, 29 minutes after the first read, the snapshot had moved on by 28 serials and the same 30 manifests were still there, the oldest in a live chain now 113 hours past its time.
Five more days
One read cannot tell a signer that has stopped from one that is a few minutes late. For most of what we found the dates settle it: AFRINIC’s 11 are more than seven years past nextUpdate, all 214 on RIPE’s publication service were more than nine days past on 3 October, and 11 of ARIN’s 12 are at least 47 days past. For the recent Brazilian ones we kept reading. The daily recheck counted 23 manifests expired within the past week later on 3 October, then 21, 35, 25, 11 and 19 on the five days after, on a job scheduled at 14:30 UTC (the history records dates only). On 8 October at 20:21 UTC we read the snapshot again and matched it to the 3 October read manifest by manifest. Of the 30 that had lapsed within the week on 3 October, none was still lapsed. Ten had recovered, 6 by reissuing the manifest and 4 reappeared with a fresh manifest under the same CA directory, which could be a re-key or a removal followed by re-enrolment. The other 20 were gone with their whole directory, which is what registro.br’s page says happens on day five. The 14 lapsed within the week at that 20:21 UTC read were all new, between 1 and 104 hours past nextUpdate. So the daily count is churn, not a stuck set: new members lapse every day and the registry’s page says it removes them five calendar days after its first notice, which goes seven hours before nextUpdate, so about 113 hours after the lapse; one lapsed manifest was still being served at 161 hours, so the five days is not exact. For all of that time the validators had been dropping the member’s authorisations. RIPE’s publication service, which had no recent lapse on 3 October, had six on 8 October, 49 to 98 hours past.
How this ends
For the 20 members whose CA directories were gone by 8 October it has ended the hard way, as far as the repository shows: nothing under their old directory. A member that re-enrolled would appear under a new one, which we did not check, and their routes stay unprotected until they do. For the members lapsing now it ends the same way, or with a reissue inside the five days; the daily recheck counts how many sit in the window. For the registry it ends when its five-day grace matches what validators do, which is to say when it shortens it, or when the notice sent seven hours before nextUpdate is joined by one at the hour validators start dropping the routes; the page will carry its answer either way.
The evidence
Every quote below was copied from the source and checked against a saved copy, fetched 2026-10-03 unless the reference gives another date. Both registro.br reads, the nine other snapshot reads, the validator records and the scripts are published next to this page (SHA256SUMS).
Exhibit 1 · The rule
“A new manifest MUST be issued and published before the nextUpdate time.” … “If the current time is later than nextUpdate, then the manifest is stale; the RP MUST treat this as a failed fetch.”
RFC 9286, sections 5.2 and 6.3 · saved copy rfc9286.txt
Exhibit 2 · registro.br, read twice
rpki-repo.registro.br/rrdp/notification.xml run 1 2026-10-03T04:20:26Z serial 277784 snapshot 84.1 MB manifests 3,797 expired 178 within 7 days 30 run 2 2026-10-03T04:49:39Z serial 277812 snapshot 84.1 MB manifests 3,797 expired 178 within 7 days 30 oldest live-chain expiry nextUpdate 2026-09-28T11:43:31Z 13 files rpki-client: Failed 187.110.144.0/21-24 => 269073, 45.237.124.0/22-24 => 269073, … nextUpdate years of the other 148: 2020 ×1, 2021 ×29, 2022 ×113, 2023 ×5
live routing and validation state of the 135 prefixes (RIPEstat, 3 October) registro_br_live_routes.json · run 1, run 2 · decoded detail registro_br_expired_detail.json · validator records console_manifests_registro_br.json · 8 October re-read registro.br, RIPE publication service, matched by compare_oct8.py
Exhibit 3 · The other nine
repository fetched manifests window expired 7d live-chain ripe 04:27Z 22,816 24.0h 0 0 0 arin 04:30Z 9,706 71.5h 0 0 0 apnic 04:30Z 10,712 168.0h 0 0 0 lacnic 04:30Z 3,446 126.3h 0 0 0 afrinic 04:31Z 1,534 48.0h 11 0 0 (2016–2019) ripe_paas 04:23Z 563 26.2h 214 0 0 (2023: 13, 2024: 38, 2025: 93, 2026: 70) arin_rps 04:23Z 139 25.9h 12 1 1 idnic 04:21Z 2,316 26.2h 0 0 0 twnic 04:22Z 397 26.1h 0 0 0
rrdp_summary.json · per-repository reads in the exhibits folder · console dump build 2026-10-02T23:26:09Z console_manifests_slim.json.gz
Exhibit 4 · registro.br’s own process
“Um aviso ‘Publicação prestes a ficar obsoleta’ é emitido 7 (sete) horas antes do momento esperado para a publicação do próximo manifesto. Após essa data limite, e não sendo publicado um novo arquivo manifesto, um novo aviso é enviado com ‘Publicação RPKI em atraso’. … é necessário sanar os problemas em até 5 (cinco) dias corridos. … Caso o problema não seja resolvido nesse prazo, a configuração RPKI é removida … Porque em caso de problemas, os softwares de validação RPKI (que rodam no mundo inteiro) começarão a alertar que os objetos RPKI da organização estão vencidos … e passarão a considerar como erro, desprezando as ROAs associadas.”
registro.br/tecnologia/numeracao/rpki/ (“Suporte” section; script-rendered, excerpt saved as read 2026-10-03) · saved copy registro_br_rpki_page.txt. Our translation: a warning seven hours before the next manifest is due, a late notice after it, five calendar days to fix, then the RPKI configuration is removed, because validators worldwide will treat the organisation’s objects as expired and discard its ROAs.
Exhibit 5 · RIPE’s own promise
“Each CRL contains a ‘Next Update’ value, and a new CRL will be published at or before that time.” … “Hosted CAs: 24 hours from the moment of issuance” … “publication should happen no later than eight hours after issuance”
RIPE NCC Certification Practice Statement, ripe-851, sections 4.9.7 and 4.3.1 · saved copy ripe-851.html
Exhibit 6 · RIPE’s own validator on its publication service, 4 October 01:52 UTC
rejectedPublicationPoints 38 validManifests 329 staleManifests 0 missingManifests 38 rsync://rsync.paas.rpki.ripe.net/repository/09718f08-bb39-4a09-a4c0-1f40248a6d15/0/ manifest .../F4D1A7E9DFF0D90E760FB87D5605458BA870BF32.mft: certificate has expired. rsync://rsync.paas.rpki.ripe.net/repository/09718f08-bb39-4a09-a4c0-1f40248a6d15/2/ manifest .../BB0B02806AE3C34F453ADEDDE36ADF432FCDF9C4.mft: certificate has expired. (34 of the 38 rejected points carry this message; all 34 are among the 214 expired manifests in our 3 October snapshot)
RIPE NCC RPKI Validator status API, repositories and pubPointIssues for rrdp.paas.rpki.ripe.net · saved copy ripe_validator_status_2026-10-03.json
Our questions
To be sent to NIC.br, which runs registro.br, and to the RIPE NCC’s RPKI team. Answers will be printed here as written.
- registro.br: your page gives a member five calendar days from its first notice, sent seven hours before nextUpdate, before its RPKI configuration is removed, while validators discard the member’s authorisations from the first hour. Is the five-day window deliberate, and have the 30 members whose manifests lapsed between 26 September and 3 October received the “Publicação RPKI em atraso” notice?
- registro.br: 148 manifests with nextUpdate between 2020 and 2023 were still in the snapshot on 3 October, 147 on 8 October. Your page says a configuration that is not fixed within five days is removed; are these removals whose objects were never withdrawn from the repository?
- RIPE NCC: 214 of the 563 manifests on the publication service’s RRDP snapshot are expired, some since 2023, and your own validator was still rejecting 34 of them on 4 October with “certificate has expired”, so those 34 publication points, under 18 CAs, were still delegated 9 to 331 days after their manifests lapsed at our 3 October read. They were signed by members’ own CAs, so only the member can reissue them. Does the service withdraw a member’s objects when the member leaves or its certificate is revoked, and if so what are these?
- Both: RFC 9286 says validators MUST treat a stale manifest as a failed fetch. Is anything on your side monitoring for manifests past nextUpdate, and would you publish that count?
Their reply, scored
Disclosure timeline
| 3 Oct | Measured. |
| 4 Oct | Table and script sent to the reviewer. |
| 6 Oct | Reviewer’s comments: the windows differ, the publication services carry members’ own CAs, and one read cannot show persistence. All three are in the page above. |
| 8 Oct | Reviewer put the question the paper turns on, whether a stale manifest is survivable in practice or only invisible, to a third party; the answer will be printed here. Second read of registro.br: of the 30 lapsed on 3 October, 10 recovered, 20 removed, none still lapsed; 14 new. |
| 9 Oct | The third party’s reading, via the reviewer: section 6.6 as written keeps cached objects until they go stale themselves, and a lapsed manifest does not by itself invalidate a ROA. The reviewer’s check: Routinator’s default policy since 0.8.0 rejects everything under a stale manifest, so the cold cache was not the cause. Our check of rpki-client’s dump: no ROA objects under the 27 Failed points. The review gate then found the mechanism simpler still: the manifest’s signing certificate expires at nextUpdate (section 5.1), so no stale policy gets a say. Limitations corrected; two examples in the Brazil table were in the wrong row and are moved. Neither the reviewer’s nor the third party’s text is published; this row is our record of the relay. |
| 11 Oct | A four-lens review found the RIPE publication-service finding understated: its own validator was still evaluating 34 of the 214 lapsed manifests on 4 October (Exhibit 6), so those chains were delegated, not litter. Corrected here and in the questions. Also corrected: the registry’s five days run from its first notice, seven hours before nextUpdate; the title says authorisations, not routes, since the routes stayed announced; the 69-hour median is tied to the 04:49 read. |
| 12 Oct | The reviewer: “dropped not flagged settles it.” The third party’s second note, via the reviewer, for the page as written: he reads the manifest as a withholding detector and nothing more, so a validator that discards a CA’s objects on a stale manifest is over-interpreting the manifest’s role, which is what the measurements show the two common validators doing in practice; he does not see this as a matter for the RIRs and doubts the IETF would pick it up, so a measurement note that states what the validators do and sets the five days against the zero is the right form. Published the same day; the questions above sent to NIC.br and the RIPE NCC with the scripts attached. |
What we can’t be sure of
- The ten-repository read is one morning from one vantage point. A manifest can sit a few minutes past nextUpdate between expiry and reissue; our read caught none in that state at the RIR repositories. Only registro.br and the two publication services are re-read daily.
- Which validator a network’s upstream runs decides what it sees, but not here. RFC 9286 section 5.1 requires the manifest’s own signing certificate to expire at nextUpdate, and registro.br’s do: for all 29 live-chain manifests the certificate’s notAfter equals nextUpdate to the second (console_manifests_registro_br.json, valid_until). From that second the manifest fails as an expired signature, before any stale-object policy applies. Routinator’s default policy since 0.8.0 rejects stale objects anyway,5 and RIPE’s Routinator gives “certificate has expired” as its reason on 22 of the 23 registro.br points it rejects, 18 of them among our 30.6 rpki-client’s dump lists no ROA object at all under the 27 points it marked Failed, against 4 under the 2 it validated while they were still in date, so under a failed manifest it carries no ROA at all, while elsewhere in the same dump it lists 4,169 ROAs as Failed; we did not capture the dump before the lapse (console_roas_check.py, output). Our own Routinator ran from a fresh install; it did fetch the repository, carrying 21,098 authorisations from registro.br and none from the 30 lapsed points, so the expiry, not the empty cache, is what dropped the 135; the configuration file that run read was not kept, so its settings cannot be shown (log, summary). RFC 9286 section 6.6 lets a validator keep ROAs it fetched earlier until they go stale themselves. The one continuously running validator we read, rpki-client’s console, did not keep them; we have not run a warm Routinator.
- The affected prefixes come from registro.br’s file names, not from decoding each ROA. The names carry prefix, maximum length and AS number by construction; a renamed file would be missed.
- “Live chain” is the console’s view five hours earlier. A CA retired between then and our read would be counted as live here.
- We did not measure whether any of the 135 prefixes was actually hijacked or misrouted while unprotected. The finding is that the protection was off, not that anyone used the window.
Run it yourself
Python 3 with the asn1crypto package for the manifest CMS; everything else is standard library. The ten snapshots are about 1.4 GB; ten minutes.
python3 rrdp_manifests.py registro_br https://rpki-repo.registro.br/rrdp/notification.xml # one repository sh run_rrdp.sh # all ten python3 analyze_rpki.py # the tables; uses console_manifests.json if present for chain and file lists
Ran it? Send the number you got and the date to hello@markovianprotocol.com, subject “Rerun SM-014”. We print it on the track record with your name, or just the date if you prefer, and the first outside rerun of each paper gets the same seal the operators get.
References
- R. Austein, G. Huston, S. Kent, M. Lepinski. Manifests for the Resource Public Key Infrastructure (RPKI), RFC 9286, June 2022. rfc-editor.org/rfc/rfc9286.
- RIPE NCC. RIPE NCC Certification Practice Statement (CPS) for the Resource Public Key Infrastructure (RPKI), ripe-851, 13 January 2026. ripe.net.
- T. Bruijnzeels, O. Muravskiy, B. Weber, R. Austein. The RPKI Repository Delta Protocol (RRDP), RFC 8182, July 2017. rfc-editor.org/rfc/rfc8182.
- rpki-client console. console.rpki-client.org, object dump of 2026-10-02T23:26Z.
- NLnet Labs. Routinator 0.15.2. github.com/NLnetLabs/routinator. Manual page,
--stale=policy: “A policy of reject instructs Routinator to consider all stale objects invalid. This will result in all material published by the CA issuing this manifest and CRL to be invalid including all material of any child CA. … In Routinator 0.8.0 and newer, reject is the default policy if the option is not provided.” routinator.docs.nlnetlabs.nl, read 9 October 2026. - RIPE NCC. RPKI Validator, status API, 4 October 2026, 01:52 UTC. rpki-validator.ripe.net, saved copy ripe_validator_status_2026-10-03.json. A. Band, Re: [RPKI] cannot download the .roa files, with the list of signed bgp prefixes, rpki@lists.nlnetlabs.nl, 26 June 2022. mail-archive.com, saved copy nlnetlabs_rpki_list_msg00281.html.
Cite as
@misc{markovian-sm014,
author = {{Markovian Protocol}},
title = {Brazil's RPKI registry gives a member five days to fix a lapsed manifest. Validators drop the member's route authorisations in the first hour. Thirty members lapsed in the week to 3 October; by 8 October twenty had been deleted},
number = {SM-014},
year = {2026},
month = oct,
url = {https://markovianprotocol.com/measurements/sm-014.html},
doi = {10.5281/zenodo.23319187}
}