policy proposal: "Automatic Revocation of Persistently Non-functional Delegated RPKI CAs"
Dear all, I'd like to propose a mechanism to automatically prune dead branches in the RPKI directly subordinate to RIPE NCC. Below is the policy proposal text that I have in mind. In short: RIPE NCC should revoke a Delegated CA's certificate when absolutely no "sign of life" (valid Manifest) has been observed for over a 100 days. It probably is good to have some discussion around: * should perpetually broken Delegated CA setups be culled at some point? * is the continuous lack of a valid current manifest for a 100 day period of time a good indicator for "Delegated CA brokenness"? Your feedback is most welcome! Kind regards, Job ------------------- Policy Proposal Name: Automatic Revocation of Persistently Non-functional Delegated RPKI Certification Authorities Author: a. name: Job Snijders b. email: job@sobornost.net Proposal Version: (to be assigned by the RIPE NCC) Submission Date: February 25th, 2025 Suggested RIPE WG for discussion and publication: RIPE Routing Working Group Proposal Type: NEW Policy Term: Indefinite Summary of proposal: RIPE NCC offers users of its RPKI certification service two deployment models: "Hosted CA setup" and "Delegated CA setup". In the Hosted setup RIPE NCC is responsible for timely issuance and publication of new RPKI Manifests and CRLs, but in the Delegated setup users themselves manage their CA on their own infrastructure. It is possible for Delegated CA infrastructure to be offline for extended periods of time or for the contents of publication repositories to become stale or otherwise invalid. This proposal suggests to provide mandate to RIPE NCC to revoke resource certificates associated with longtime non-functional CAs to reduce Relying Party workload. This policy proposal targets only pathologically non-functional CAs. An example of a situation considered out-of-scope for this policy would be a publication repository service advertised to also be available via IPv6 and RRDP but in practise only reachable via IPv4 and Rsync: the associated CA would still be considered functional (provided a valid and current Manifest could somehow be retrieved and validated sometime in the previous one hundred days). In other words: this policy proposal isn't about CAs that didn't achieve 100% uptime, but about CAs that are down all the time. Policy text: If RIPE NCC is unable to discover and validate a Delegated RPKI Certification Authority's (CA's) current Manifest and CRL for one hundred consecutive days, that Delegated CA's resource certificate shall be revoked by the RIPE NCC. RIPE NCC shall make reasonable efforts to discover new Manifests, for example, by corroborating information from multiple vantage points. After revocation, the Resource Holder may either reinitialize the Delegated CA setup or choose the Hosted CA setup. Rationale: a. Arguments supporting the proposal Persistently Non-functional Delegated CAs (PNDCs, for short) have subtle effects within the RPKI ecosystem which may become more pronounced over time. * PNDCs offer nothing of value to RPs (because without a current valid Manifest any signed payloads are unavailable). * RP synchronisation becomes more economic with fewer purposeless caRepositories to traverse. * PNDCs besmirch Relying Party (RP) syslog message archives and waste RP CPU cycles and network traffic. * Automatic revocation is only a minor inconvenience for CAs (that already were non-functional to begin with), but a big deal for RPs - especially when taking into account many future synchronisation attempts over long periods of time. b. Arguments opposing the proposal * Resource holders might require more than one hundred days to complete the initial Delegated CA setup. (Counterpoints: initial setup procedures usually only takes a few minutes. Resource holders are free to simply retry the delegated CA setup procedure following automatic revocation.) Additional opposing arguments to be determined.
Dear all, To foster informed discussion about the policy proposal at: https://mailman.ripe.net/archives/list/routing-wg@ripe.net/thread/USQUMNOE3L... I've collected and analysed data from the field to provide insight into the current state of 'non-functional CAs' (using data from http://www.rpkiviews.org/) Over 20,000 full snapshot files from the period January 1st, 2024 through February 24th, 2025 (inclusive) were processed. As of yesterday (2025-02-24T23:38:26Z), 271 Delegated CA setups existed under RIPE NCC's Trust Anchor. Of those, 56 currently are "non-functional" (20%), 28 have been non-functional for more than 100 days (10%), . Kind regards, Job rpki.ripe.net/repository/DEFAULT/Uzah3JxThY9dQ3VRBRuyFL8cWrs.cer broken for more than 421 days https://console.rpki-client.org/krill.ca-bc-01.ssmidge.xyz/repo/SsmidgeLLC/0... rpki.ripe.net/repository/DEFAULT/Jp4Tjp_GB5I1RfeaOGhKZNlDmAQ.cer broken for more than 421 days https://console.rpki-client.org/rpkica.mckay.com/rpki/MCnet/Jp4Tjp_GB5I1Rfea... rpki.ripe.net/repository/DEFAULT/SvoHcYEuZjfYsYof9Q9B80mGaak.cer broken for more than 421 days https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/32bfd357... rpki.ripe.net/repository/DEFAULT/xVV8l9e7_0fKIq1fufBYn6rxWb0.cer broken for more than 421 days https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/32bfd357... rpki.ripe.net/repository/DEFAULT/_F7x9mT2uw4a972lPWfgWJuJXh8.cer broken for more than 421 days https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/ad0eb3cf... rpki.ripe.net/repository/DEFAULT/q0wWl7GMPHFVUyBsTDm76eUvZYs.cer broken for more than 421 days https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/d2288b0e... rpki.ripe.net/repository/DEFAULT/ENrGqvlAx8X_G4Pso1JtRrpHUJM.cer broken for more than 421 days https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/240ce547... rpki.ripe.net/repository/DEFAULT/UvTKqH0IH8Jd3xF76Kn-mQqhILw.cer broken for more than 421 days https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/ad0eb3cf... rpki.ripe.net/repository/DEFAULT/WT6ByS75j5EwrENkGq6AIlRun0o.cer last sighting of a valid manifest 20240303T170549Z 358 days ago https://console.rpki-client.org/rpki.netiface.net/repo/Civilized/0/593E81C92... rpki.ripe.net/repository/DEFAULT/xZR-zIaDrQ282VqPMy8MqhNXR5A.cer last sighting of a valid manifest 20240420T123556Z 311 days ago https://console.rpki-client.org/rpki.netiface.net/repo/Civilized/0/C5947ECC8... rpki.ripe.net/repository/DEFAULT/naI8ws-IrkWFz4qvmnFKmtLm8Zg.cer last sighting of a valid manifest 20240426T173605Z 304 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/a4c6bdc5... rpki.ripe.net/repository/DEFAULT/74jXus0opsOTvMwR3GTd53t-xJs.cer last sighting of a valid manifest 20240518T093553Z 283 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/509e44a5... rpki.ripe.net/repository/DEFAULT/w9a4Z_-YTcfF6szS2j-Szzxnfas.cer last sighting of a valid manifest 20240519T010546Z 282 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/c58479df... rpki.ripe.net/repository/DEFAULT/Lh7egGQMn0hPdd05wT7Wxw4HSgM.cer last sighting of a valid manifest 20240630T023703Z 240 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/330c7f5c... rpki.ripe.net/repository/DEFAULT/fFzcP9UWU7USC06-3S-jgiQKWGg.cer last sighting of a valid manifest 20240630T023703Z 240 days ago https://console.rpki-client.org/rpki.0i1.eu/repo/h45/0/7C5CDC3FD51653B5120B4... rpki.ripe.net/repository/DEFAULT/fduZ9z57WCw1KJDjrVeF02efiJE.cer last sighting of a valid manifest 20240630T023703Z 240 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/b64c075f... rpki.ripe.net/repository/DEFAULT/7gktbstSvJmjn6ZnevvunkG64Nk.cer last sighting of a valid manifest 20240930T060419Z 148 days ago https://console.rpki-client.org/rpki.athene-center.net/repo/rpki-athene-cent... rpki.ripe.net/repository/DEFAULT/XPV2zob5WC3QMZpOmiXs23s17Dg.cer last sighting of a valid manifest 20241004T143642Z 143 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/2fd217e5... rpki.ripe.net/repository/DEFAULT/lFAxyyKjXNts5XnLcCcOp7Oomic.cer last sighting of a valid manifest 20241004T143642Z 143 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/c5592a54... rpki.ripe.net/repository/DEFAULT/1kJOUxpa1qyAryDw1twssYcyLsE.cer last sighting of a valid manifest 20241004T143642Z 143 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/30df2d1b... rpki.ripe.net/repository/DEFAULT/suTT3a_E97-6XbYHoDPzYhCMqFA.cer last sighting of a valid manifest 20241008T080637Z 140 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/e292649c... rpki.ripe.net/repository/DEFAULT/sy4-N1Phw0647Ando2PwbGe324o.cer last sighting of a valid manifest 20241013T090705Z 135 days ago https://console.rpki-client.org/pub.krill.ausra.cloud/repo/Ausra-Systems-Int... rpki.ripe.net/repository/DEFAULT/6bdZEvynibhszqOx4J8bW_qEtQM.cer last sighting of a valid manifest 20241014T220355Z 133 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/378e5eb0... rpki.ripe.net/repository/DEFAULT/PN7Cc4Sq3lyggJ_W8W0ryhi-tlk.cer last sighting of a valid manifest 20241020T030414Z 128 days ago https://console.rpki-client.org/rsync.rpki.tianhai.link/repo/TianhaiRpki/0/3... rpki.ripe.net/repository/DEFAULT/PjLaO53JVfls8b9YxXSLe4D8t5g.cer last sighting of a valid manifest 20241019T140355Z 128 days ago https://console.rpki-client.org/rsync.rpki.tianhai.link/repo/TianhaiRpki/2/3... rpki.ripe.net/repository/DEFAULT/kR4YAUXmj3MV2jqyIA0YZnH_51s.cer last sighting of a valid manifest 20241019T213358Z 128 days ago https://console.rpki-client.org/rsync.rpki.tianhai.link/repo/TianhaiRpki/1/9... rpki.ripe.net/repository/DEFAULT/_XqMEQpihGk3hXKikYZT9vjXJtI.cer last sighting of a valid manifest 20241029T223405Z 118 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/d88b854e... rpki.ripe.net/repository/DEFAULT/yJsxCB1b3QjRj7zY-r7oHE-wUUY.cer last sighting of a valid manifest 20241031T020400Z 117 days ago https://console.rpki-client.org/rpki01.hel-fi.rpki.win:44595/repo/as60900/0/... =========================================================================================================== =============== POLICY TARGET CUT-OFF ===================== =============== THE BELOW CAs HAVE BEEN NON-FUNCTIONAL FOR LESS THAN ONE HUNDRED DAYS ===================== =============== AND WERE INCLUDED ONLY FOR INFORMATIONAL PURPOSES ===================== =========================================================================================================== rpki.ripe.net/repository/DEFAULT/_zZQWJdnAfshmkFt2OfvSAokiIY.cer last sighting of a valid manifest 20241126T183422Z 90 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/d3cc54ec... rpki.ripe.net/repository/DEFAULT/aW3TxBt37bvdN9fk0CADnUAtS4U.cer last sighting of a valid manifest 20241126T190428Z 90 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/d3cc54ec... rpki.ripe.net/repository/DEFAULT/6IPR0jE6FOhln2BKZdZc45o_gms.cer last sighting of a valid manifest 20241205T210706Z 81 days ago https://console.rpki-client.org/rpki.folf.systems/repo/Folf-Systems/0/E883D1... rpki.ripe.net/repository/DEFAULT/aCf2BHqADr5LDcYpnAhO8F4Kqt4.cer last sighting of a valid manifest 20241214T060423Z 73 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/9af6c38e... rpki.ripe.net/repository/DEFAULT/HICFhJKexkMiDWmnfl4FDh0J2Wk.cer last sighting of a valid manifest 20241230T170649Z 56 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/fd30a818... rpki.ripe.net/repository/DEFAULT/Wr5-CR2hOR8CTsDPfY428NI1d4o.cer last sighting of a valid manifest 20250101T120719Z 55 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/f0f5aca9... rpki.ripe.net/repository/DEFAULT/J322q3eePVMzyXqyKFuYgAHF4MY.cer last sighting of a valid manifest 20250107T130548Z 49 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/74c1572c... rpki.ripe.net/repository/DEFAULT/A24viOVshqQ2o8THq3cPp4vGhso.cer last sighting of a valid manifest 20250111T233549Z 44 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/b277449f... rpki.ripe.net/repository/DEFAULT/LKugISeSXZmIcQ7uWgpZsATGtrE.cer last sighting of a valid manifest 20250112T223552Z 43 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/02c72b7c... rpki.ripe.net/repository/DEFAULT/PeC3hjOq8QqbIqHpJe680e12sK8.cer last sighting of a valid manifest 20250116T210542Z 39 days ago https://console.rpki-client.org/rpki-rps.arin.net/repository/8a848adf914e0aa... rpki.ripe.net/repository/DEFAULT/ewjibqnz2CXszWTl_cNVyFKnr1Q.cer last sighting of a valid manifest 20250116T233541Z 39 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/c99265ef... rpki.ripe.net/repository/DEFAULT/2T7wcB6Mpu0KDm1Go4uNjPMJEoU.cer last sighting of a valid manifest 20250117T060546Z 39 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/c99265ef... rpki.ripe.net/repository/DEFAULT/IUQgQoqlbnXGmG8810rcA6Hx_7I.cer last sighting of a valid manifest 20250119T023546Z 37 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/e1a3b0bc... rpki.ripe.net/repository/DEFAULT/w_ThZ6axYzN5uZgdilZbevuB3JA.cer last sighting of a valid manifest 20250120T123547Z 36 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/4bfa7a9f... rpki.ripe.net/repository/DEFAULT/s0CjI3bSG3QyCZU1brqFtAZT5nI.cer last sighting of a valid manifest 20250131T073907Z 25 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/8188cf9f... rpki.ripe.net/repository/DEFAULT/vutLWV6eCEZJ0Kvlt3uN_3NtA_M.cer last sighting of a valid manifest 20250202T123643Z 23 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/bcbbf0bf... rpki.ripe.net/repository/DEFAULT/ajEwrPv7qQF63e9jes0xL8djgpo.cer last sighting of a valid manifest 20250202T013647Z 23 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/22a80682... rpki.ripe.net/repository/DEFAULT/l8F1AF96ubadzbTzpgj8eP5ap8c.cer last sighting of a valid manifest 20250207T023654Z 18 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/47cfdd4f... rpki.ripe.net/repository/DEFAULT/XwGuGDbX2nd-u5Ch6pfTfDABGOg.cer last sighting of a valid manifest 20250209T200651Z 15 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/09f71023... rpki.ripe.net/repository/DEFAULT/uCiOqePWfcPTj6d1GBxLLIdym98.cer last sighting of a valid manifest 20250209T200651Z 15 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/3c8e4e11... rpki.ripe.net/repository/DEFAULT/raot9Pn38bEDMMOrDORZjVnf_aA.cer last sighting of a valid manifest 20250209T173652Z 15 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/98826bce... rpki.ripe.net/repository/DEFAULT/qd2fa2VJHZDE4Z6clgJSRmwsnRI.cer last sighting of a valid manifest 20250214T020629Z 11 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/24db6e0e... rpki.ripe.net/repository/DEFAULT/EwZxu09jgBL4KLuizOeFwXJTDAI.cer last sighting of a valid manifest 20250213T173605Z 11 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/24cc8de5... rpki.ripe.net/repository/DEFAULT/s-r7uHz_75QBhnWfCKeBXxxnpyk.cer last sighting of a valid manifest 20250215T170716Z 9 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/c974e2af... rpki.ripe.net/repository/DEFAULT/d13RfhRQYORZmmWRzA5orCrm7Ds.cer last sighting of a valid manifest 20250218T213609Z 6 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/f9719fb9... rpki.ripe.net/repository/DEFAULT/sdMEmrkLczFPKt_K1jkzbZMgs14.cer last sighting of a valid manifest 20250219T160634Z 5 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/80a6dc53... rpki.ripe.net/repository/DEFAULT/1JD4VvgOgHtxgO9G4wSPxfKM-DI.cer last sighting of a valid manifest 20250222T100827Z 3 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/5440d602... rpki.ripe.net/repository/DEFAULT/x0asRzYFI6jYF8XqY4rhhpEmGcE.cer last sighting of a valid manifest 20250223T063836Z 2 days ago https://console.rpki-client.org/rsync.paas.rpki.ripe.net/repository/0157647c...
Dear all, Someone asked me for more information about the 28 CAs that have been non-functional for more than one hundred days. Below is a table of the CA certificate filenames, their subordinate AS & IP addresses, and hyperlinks to a real-time decoding & validation of those certs. None of the below CAs have produced valid ROAs or ASPA objects in the last one hundred days. For a ROAs or other signed objects to be valid, a current & valid Manifest must exist. Kind regards, Job rpki.ripe.net/repository/DEFAULT/Uzah3JxThY9dQ3VRBRuyFL8cWrs.cer [{asid:60900}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/Uzah3JxThY9... rpki.ripe.net/repository/DEFAULT/Jp4Tjp_GB5I1RfeaOGhKZNlDmAQ.cer [{asid:50763},{ip_prefix:37.1.88.0/21},{ip_prefix:185.128.248.0/22},{ip_prefix:193.107.204.0/22},{ip_prefix:2a00:5540::/29}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/Jp4Tjp_GB5I... rpki.ripe.net/repository/DEFAULT/SvoHcYEuZjfYsYof9Q9B80mGaak.cer [{asid:213045}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/SvoHcYEuZjf... rpki.ripe.net/repository/DEFAULT/xVV8l9e7_0fKIq1fufBYn6rxWb0.cer [{asid:213045}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/xVV8l9e7_0f... rpki.ripe.net/repository/DEFAULT/_F7x9mT2uw4a972lPWfgWJuJXh8.cer [{asid:200335}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/_F7x9mT2uw4... rpki.ripe.net/repository/DEFAULT/q0wWl7GMPHFVUyBsTDm76eUvZYs.cer [{asid:200210}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/q0wWl7GMPHF... rpki.ripe.net/repository/DEFAULT/ENrGqvlAx8X_G4Pso1JtRrpHUJM.cer [{asid:197438}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/ENrGqvlAx8X... rpki.ripe.net/repository/DEFAULT/UvTKqH0IH8Jd3xF76Kn-mQqhILw.cer [{asid:199751}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/UvTKqH0IH8J... rpki.ripe.net/repository/DEFAULT/WT6ByS75j5EwrENkGq6AIlRun0o.cer [{asid:216360}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/WT6ByS75j5E... rpki.ripe.net/repository/DEFAULT/xZR-zIaDrQ282VqPMy8MqhNXR5A.cer [{asid:216360}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/xZR-zIaDrQ2... rpki.ripe.net/repository/DEFAULT/naI8ws-IrkWFz4qvmnFKmtLm8Zg.cer [{asid:57565},{ip_prefix:109.70.72.0/24},{ip_prefix:2a13:ee40::/29}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/naI8ws-IrkW... rpki.ripe.net/repository/DEFAULT/74jXus0opsOTvMwR3GTd53t-xJs.cer [{asid:215731}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/74jXus0opsO... rpki.ripe.net/repository/DEFAULT/w9a4Z_-YTcfF6szS2j-Szzxnfas.cer [{asid:215126}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/w9a4Z_-YTcf... rpki.ripe.net/repository/DEFAULT/Lh7egGQMn0hPdd05wT7Wxw4HSgM.cer [{asid:215755}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/Lh7egGQMn0h... rpki.ripe.net/repository/DEFAULT/fFzcP9UWU7USC06-3S-jgiQKWGg.cer [{asid:207939},{ip_prefix:2001:67c:a74::/48}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/fFzcP9UWU7U... rpki.ripe.net/repository/DEFAULT/fduZ9z57WCw1KJDjrVeF02efiJE.cer [{asid:210397}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/fduZ9z57WCw... rpki.ripe.net/repository/DEFAULT/7gktbstSvJmjn6ZnevvunkG64Nk.cer [{asid:208162},{asid:212795},{asid:213242},{ip_prefix:45.155.128.0/22},{ip_prefix:158.220.128.0/17},{ip_prefix:160.200.0.0/16},{ip_prefix:161.51.128.0/18},{ip_prefix:193.162.137.0/24},{ip_prefix:2a10:9040::/29}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/7gktbstSvJm... rpki.ripe.net/repository/DEFAULT/fduZ9z57WCw1KJDjrVeF02efiJE.cer [{asid:210397}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/fduZ9z57WCw... rpki.ripe.net/repository/DEFAULT/XPV2zob5WC3QMZpOmiXs23s17Dg.cer [{asid:211481}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/XPV2zob5WC3... rpki.ripe.net/repository/DEFAULT/lFAxyyKjXNts5XnLcCcOp7Oomic.cer [{asid:41732},{asid:211940}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/lFAxyyKjXNt... rpki.ripe.net/repository/DEFAULT/1kJOUxpa1qyAryDw1twssYcyLsE.cer [{asid:61302}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/1kJOUxpa1qy... rpki.ripe.net/repository/DEFAULT/suTT3a_E97-6XbYHoDPzYhCMqFA.cer [{asid:214819}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/suTT3a_E97-... rpki.ripe.net/repository/DEFAULT/sy4-N1Phw0647Ando2PwbGe324o.cer [{asid:60234},{asid:197993}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/sy4-N1Phw06... rpki.ripe.net/repository/DEFAULT/6bdZEvynibhszqOx4J8bW_qEtQM.cer [{asid:215258}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/6bdZEvynibh... rpki.ripe.net/repository/DEFAULT/PN7Cc4Sq3lyggJ_W8W0ryhi-tlk.cer [{ip_prefix:194.127.229.0/24},{ip_prefix:2a13:1800::/29}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/PN7Cc4Sq3ly... rpki.ripe.net/repository/DEFAULT/PjLaO53JVfls8b9YxXSLe4D8t5g.cer [{asid:209417}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/PjLaO53JVfl... rpki.ripe.net/repository/DEFAULT/kR4YAUXmj3MV2jqyIA0YZnH_51s.cer [{asid:209306}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/kR4YAUXmj3M... rpki.ripe.net/repository/DEFAULT/_XqMEQpihGk3hXKikYZT9vjXJtI.cer [{asid:214393}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/_XqMEQpihGk... rpki.ripe.net/repository/DEFAULT/yJsxCB1b3QjRj7zY-r7oHE-wUUY.cer [{asid:199177}] https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/yJsxCB1b3Qj...
On Tue, Feb 25, 2025 at 12:05:21PM +0000, Job Snijders wrote:
b. Arguments opposing the proposal
* Resource holders might require more than one hundred days to complete the initial Delegated CA setup.
(Counterpoints: initial setup procedures usually only takes a few minutes. Resource holders are free to simply retry the delegated CA setup procedure following automatic revocation.)
Additional opposing arguments to be determined.
I could see some cases where due to political instability where one may not want to automatically trigger this, but it also seems that should the resource(s) come back online re-enabling the delegation shouldn't be too difficult. We have seen several cases where extended outages due to natural disasters have caused extended duration outages, but a dialogue should be possible to occur prior to this to make a decision. I can imagine a few other cases where a company may be in receivership but also think these are likely limited enough whereby there would be a chance for discussions on the operational side to give the option to remove the delegation until the delegated CA can be restored or decomissioned. I support this proposal but want to leave some discretion at the hands of RIPE staff to not have a hard timer remove a delegation if it is still in the process of being restored. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Dear Jared, others, Thanks for the feedback! On Tue, Feb 25, 2025 at 03:30:41PM +0000, Jared Mauch wrote:
On Tue, Feb 25, 2025 at 12:05:21PM +0000, Job Snijders wrote:
b. Arguments opposing the proposal
* Resource holders might require more than one hundred days to complete the initial Delegated CA setup.
(Counterpoints: initial setup procedures usually only takes a few minutes. Resource holders are free to simply retry the delegated CA setup procedure following automatic revocation.)
Additional opposing arguments to be determined.
I could see some cases where due to political instability where one may not want to automatically trigger this, but it also seems that should the resource(s) come back online re-enabling the delegation shouldn't be too difficult.
We have seen several cases where extended outages due to natural disasters have caused extended duration outages, but a dialogue should be possible to occur prior to this to make a decision.
I can imagine a few other cases where a company may be in receivership but also think these are likely limited enough whereby there would be a chance for discussions on the operational side to give the option to remove the delegation until the delegated CA can be restored or decomissioned.
Allowing for a 100 day period should be ample for most transcient outages. Keep in mind that these delegations _already were non-functional_ prior to revocation. This means that for more than 100 days no ROAs, nor RSCs, nor ASPAs, nor BGPsec router keys could be validated via the CA in question. In other words, even when political reasons cause the extended outage, already during that outage RPKI validators couldn't extract information signed by that CA. The proposal is about cleaning up what's already broken (for very extended periods of time), cognizant that the affected resource holder can always re-instate a Delegated CA setup with just a few mouse clicks in a manner of minutes.
I support this proposal but want to leave some discretion at the hands of RIPE staff to not have a hard timer remove a delegation if it is still in the process of being restored.
Point of clarification: whether a CA ought to be classified as 'non-functional' or 'functional' is not a matter of something being online or offline, but rather "has the CA managed to sign and publish a new Manifest at any point in the last 100 days"? For example, this ancient manifest still is available 'online': $ rsync -t rsync://rpkica.mckay.com/rpki/MCnet/Jp4Tjp_GB5I1RfeaOGhKZNlDmAQ.mft -rw-r--r-- 1,946 2022/03/04 00:27:02 Jp4Tjp_GB5I1RfeaOGhKZNlDmAQ.mft however, the above Manifest hasn't been valid since Fri 04 March 2022 06:27:02 (UTC). The proposal text states that resource holders can just reinitialize the Delegated CA setup process after revocation (or use the Hosted CA setup). So when a delegation 'lapses', the resource holder can easily get things going again following normal procedures. Kind regards, Job
On Tue, Feb 25, 2025 at 03:30:41PM +0000, Jared Mauch wrote:
I can imagine a few other cases where a company may be in receivership but also think these are likely limited enough whereby there would be a chance for discussions on the operational side to give the option to remove the delegation until the delegated CA can be restored or decomissioned.
My personal experience reaching out to operators of non-functional Delegated CAs has mostly been "we have no idea what you are talking about". For example, it is not too far-fetched to imagine a situation where someone tried to set up a Delegated CA as part of an internship and then left the company. Imagine that as part of offboarding process all the intern's VM were destroyed. In such situations, the only remnant of that delegated CA is the (now dangling) reference from RIPE NCC's systems towards what the intern set up in the past. Without an (automated) revocation mechanism, such dangling delegations could exist in perpetuity, wasting resources of all the validators on this planet. Kind regards, Job
Job Snijders wrote on 25/02/2025 16:23:
Without an (automated) revocation mechanism, such dangling delegations could exist in perpetuity, wasting resources of all the validators on this planet.
garbage collection is good engineering. Couple of suggestions for the proposal:
certificate shall be revoked by the RIPE NCC. RIPE NCC shall make reasonable efforts to discover new Manifests, for example, by corroborating information from multiple vantage points. After
Can I suggest removing the "for example [...]" bit? It's better for policy to state the principles of what needs to be done rather than dabbling in procedure. Secondly in terms of timelines, the NCC will have some form of communication details for the CAs, as part of setting them up in the first place. I'd suggest a graduated approach to this: 1. notification after X months of fresh manifest non-availability 2. warning after Y months 3. removal after Z months If delegation is removed without warnings, this will invite people to complain. Nick
Dear Nick, On Tue, Feb 25, 2025 at 05:59:14PM +0000, Nick Hilliard wrote:
Job Snijders wrote on 25/02/2025 16:23:
Without an (automated) revocation mechanism, such dangling delegations could exist in perpetuity, wasting resources of all the validators on this planet.
garbage collection is good engineering.
Couple of suggestions for the proposal:
certificate shall be revoked by the RIPE NCC. RIPE NCC shall make reasonable efforts to discover new Manifests, for example, by corroborating information from multiple vantage points. After
Can I suggest removing the "for example [...]" bit? It's better for policy to state the principles of what needs to be done rather than dabbling in procedure.
I personally think it is helpful for both the community and RIPE NCC to have an inkling of an idea what 'reasonable efforts' might constitute, to shape expectations.
Secondly in terms of timelines, the NCC will have some form of communication details for the CAs, as part of setting them up in the first place. I'd suggest a graduated approach to this:
1. notification after X months of fresh manifest non-availability 2. warning after Y months 3. removal after Z months
If delegation is removed without warnings, this will invite people to complain.
Sure, but does that need to be part of the policy? What's the difference between step 1 and step 2 in your listing? What if the notification emails can't be delivered, should that delay the revocation? Kind regards, Job
Job Snijders wrote on 25/02/2025 18:40:
I personally think it is helpful for both the community and RIPE NCC to have an inkling of an idea what 'reasonable efforts' might constitute, to shape expectations.
yep, agreed. As I understand it, the RIPE NCC often uses WG discussions to shape their opinions on how to build working procedures.
Secondly in terms of timelines, the NCC will have some form of communication details for the CAs, as part of setting them up in the first place. I'd suggest a graduated approach to this:
1. notification after X months of fresh manifest non-availability 2. warning after Y months 3. removal after Z months
If delegation is removed without warnings, this will invite people to complain.
Sure, but does that need to be part of the policy?
I'd suggest putting in some text to cover this, for example: If RIPE NCC is unable to discover and validate a Delegated RPKI Certification Authority's (CA's) current Manifest and CRL for one hundred consecutive days, that Delegated CA's resource certificate shall be revoked by the RIPE NCC. RIPE NCC shall make reasonable efforts to discover new Manifests, to notify the Delegated CA operator if a current Manifest and CRL cannot be validated, and to notify the operator if the delegation is revoked." Minor nit: it would be more normal to use calendar months for longer time periods instead of base-10 numbers of days. I'd suggest reconsidering the 100 days thing, especially if there's a gradual response approach implemented, e.g. 1 month between notification, warning and revocation.
What's the difference between step 1 and step 2 in your listing?
1. "hey, we've noticed that there's a problem" 2. "this is going on too long. as it has operational consequences for other operators, if you don't fix this by date XXXX, the delegation will be revoked". 3. "still broken, so we've pulled the delegation."
What if the notification emails can't be delivered, should that delay the revocation?
1. it's the responsibility of the resource holder to ensure that their contact details are accurate and 2. no, it shouldn't delay the revocation. There is an option to add delegated CA contact checks into the ARC. I don't know whether this would add enough value to justify it. Nick
Nick, I concur with your text and the intent behind this to help clean up the ecosystem. I view this similar to many other registration vs delegation, eg: if you delegate a domain name to servers that don't respond, I would support removing that delegation but not the associated registration. Same for delegated PTR/in-addr services. I like the idea of approximately 3 months but for practical reasons think it could be shorter or left with an advisory range for implementation. You want enough to cover a short leave of absence/august in Europe but not so long that the domain names could expire 😊 I would also provide some guidance of automatic removal of delegations if the domain registration fails to exist after 7 days. I see this as common sense but likely worthwhile to write down to avoid the principle of least surprise. - Jared Sent via RFC1925 compliant device
On Feb 25, 2025, at 5:10 PM, Nick Hilliard <nick@foobar.org> wrote:
If RIPE NCC is unable to discover and validate a Delegated RPKI Certification Authority's (CA's) current Manifest and CRL for one hundred consecutive days, that Delegated CA's resource certificate shall be revoked by the RIPE NCC. RIPE NCC shall make reasonable efforts to discover new Manifests, to notify the Delegated CA operator if a current Manifest and CRL cannot be validated, and to notify the operator if the delegation is revoked."
Minor nit: it would be more normal to use calendar months for longer time periods instead of base-10 numbers of days. I'd suggest reconsidering the 100 days thing, especially if there's a gradual response approach implemented, e.g. 1 month between notification, warning and revocation.
Jared Mauch wrote on 26/02/2025 13:42:
I like the idea of approximately 3 months but for practical reasons think it could be shorter or left with an advisory range for implementation.
yep, the suggested policy text deliberately doesn't specify the notification / revocation time period, just that reasonable attempts need to be made. Policy needs due diligence. Shorter would be better for the rest of the internet. I'd say it would be difficult to argue against revoking something which is hard down for 3 months, and where the people responsible have received multiple notification. Nick
Hi, On Tue, Feb 25, 2025 at 12:05:21PM +0000, Job Snijders wrote:
* should perpetually broken Delegated CA setups be culled at some point? * is the continuous lack of a valid current manifest for a 100 day period of time a good indicator for "Delegated CA brokenness"?
Support! I'm perfectly fine to leave the actual wordings and the mechanics to people with more time at their hand - but the general principle "do not delegating to something that will not serve a useful purpose, but create friction for all the software trying to work with it" is what I find a useful goal. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Support and agreement from my side as well.
Am 26.02.2025 um 15:27 schrieb Gert Doering <gert@space.net>:
Hi,
On Tue, Feb 25, 2025 at 12:05:21PM +0000, Job Snijders wrote:
* should perpetually broken Delegated CA setups be culled at some point? * is the continuous lack of a valid current manifest for a 100 day period of time a good indicator for "Delegated CA brokenness"?
Support!
I'm perfectly fine to leave the actual wordings and the mechanics to people with more time at their hand - but the general principle "do not delegating to something that will not serve a useful purpose, but create friction for all the software trying to work with it" is what I find a useful goal.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Dear Job, Thank you for your proposal on revoking non-functional Delegated RPKI CAs. I fully support the idea of introducing a lifecycle for this Delegate CA-s. From an operational perspective, there is a clear benefit in processing only valid RPKI data. As of today the RPKI validators software is already facing with a big volume of RPKI data that must be processed and validated, and it takes no less than 5-7 minutes to process the whole RPKI data set. Simply having a policy and revoking the above 30 broken MANIFEST entries will improve run times and performance of all validators in the world. The proposed 100-day threshold is a reasonable grace period to ensure that non-functional CAs will be treated as indeed non-functional and will not indefinitely remain in the system. On the other hand, operators should have the possibility to re-enable their CA-s if they wish to do so. Best regards, Fedor Am Di., 25. Feb. 2025 um 13:05 Uhr schrieb Job Snijders <job@sobornost.net>:
Dear all,
I'd like to propose a mechanism to automatically prune dead branches in the RPKI directly subordinate to RIPE NCC. Below is the policy proposal text that I have in mind.
In short: RIPE NCC should revoke a Delegated CA's certificate when absolutely no "sign of life" (valid Manifest) has been observed for over a 100 days.
It probably is good to have some discussion around:
* should perpetually broken Delegated CA setups be culled at some point? * is the continuous lack of a valid current manifest for a 100 day period of time a good indicator for "Delegated CA brokenness"?
Your feedback is most welcome!
Kind regards,
Job
-------------------
Policy Proposal Name:
Automatic Revocation of Persistently Non-functional Delegated RPKI Certification Authorities
Author: a. name: Job Snijders b. email: job@sobornost.net
Proposal Version: (to be assigned by the RIPE NCC)
Submission Date: February 25th, 2025
Suggested RIPE WG for discussion and publication: RIPE Routing Working Group
Proposal Type: NEW
Policy Term: Indefinite
Summary of proposal:
RIPE NCC offers users of its RPKI certification service two deployment models: "Hosted CA setup" and "Delegated CA setup". In the Hosted setup RIPE NCC is responsible for timely issuance and publication of new RPKI Manifests and CRLs, but in the Delegated setup users themselves manage their CA on their own infrastructure.
It is possible for Delegated CA infrastructure to be offline for extended periods of time or for the contents of publication repositories to become stale or otherwise invalid. This proposal suggests to provide mandate to RIPE NCC to revoke resource certificates associated with longtime non-functional CAs to reduce Relying Party workload.
This policy proposal targets only pathologically non-functional CAs. An example of a situation considered out-of-scope for this policy would be a publication repository service advertised to also be available via IPv6 and RRDP but in practise only reachable via IPv4 and Rsync: the associated CA would still be considered functional (provided a valid and current Manifest could somehow be retrieved and validated sometime in the previous one hundred days). In other words: this policy proposal isn't about CAs that didn't achieve 100% uptime, but about CAs that are down all the time.
Policy text:
If RIPE NCC is unable to discover and validate a Delegated RPKI Certification Authority's (CA's) current Manifest and CRL for one hundred consecutive days, that Delegated CA's resource certificate shall be revoked by the RIPE NCC. RIPE NCC shall make reasonable efforts to discover new Manifests, for example, by corroborating information from multiple vantage points. After revocation, the Resource Holder may either reinitialize the Delegated CA setup or choose the Hosted CA setup.
Rationale: a. Arguments supporting the proposal
Persistently Non-functional Delegated CAs (PNDCs, for short) have subtle effects within the RPKI ecosystem which may become more pronounced over time.
* PNDCs offer nothing of value to RPs (because without a current valid Manifest any signed payloads are unavailable).
* RP synchronisation becomes more economic with fewer purposeless caRepositories to traverse.
* PNDCs besmirch Relying Party (RP) syslog message archives and waste RP CPU cycles and network traffic.
* Automatic revocation is only a minor inconvenience for CAs (that already were non-functional to begin with), but a big deal for RPs - especially when taking into account many future synchronisation attempts over long periods of time.
b. Arguments opposing the proposal
* Resource holders might require more than one hundred days to complete the initial Delegated CA setup.
(Counterpoints: initial setup procedures usually only takes a few minutes. Resource holders are free to simply retry the delegated CA setup procedure following automatic revocation.)
Additional opposing arguments to be determined. ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Dear Job, and Routing Working Group, I have been reading this thread with interest! As RIPE NCC employee I am happy to see this as a proposed policy. In my role I do not want to comment on the merit of the policy itself, at least not in any formal sense, but I believe that sharing technical and/or implementation related observations would be helpful. I am responding to the original email, not because I am unware of valuable comments that were made, but because I would like to make some additional technical observations that were not yet raised. See in-line:
On 25 Feb 2025, at 13:05, Job Snijders <job@sobornost.net> wrote:
Dear all,
I'd like to propose a mechanism to automatically prune dead branches in the RPKI directly subordinate to RIPE NCC. Below is the policy proposal text that I have in mind.
In short: RIPE NCC should revoke a Delegated CA's certificate when absolutely no "sign of life" (valid Manifest) has been observed for over a 100 days.
It probably is good to have some discussion around:
* should perpetually broken Delegated CA setups be culled at some point?
I will leave the policy answer to this to the community. But let me share "prior art": From my previous employment I know that nic.br have a similar process for their member CAs. All of their member CAs are "delegated". This may not be apparent because most of them publish through a publication server and repository provided by nic.br. In any case, nic.br monitors for CAs that have gone offline and "prune" them if they are not restored in a given time. I am not entirely sure what timeline they use, and if it's an automated or manual process, but I believe it is less than 100 days.
* is the continuous lack of a valid current manifest for a 100 day period of time a good indicator for "Delegated CA brokenness"?
This is one way to do this. It requires that the parent CA (RIPE NCC in this case) monitors the repositories for member CA certificates that it issues to delegated CAs. These CAs may use the Publication-as-a-Service (PaaS) provided by RIPE NCC, or they could run their own publication server. If they run their own publication server then it may be that the delegated CA itself is available, and as a parent we see it connecting regularly through RFC 6492 (provisioning protocol) exchanges, but their repository is unavailable. In such cases, it may be better to advise these CAs to migrate to using the RIPE NCC provided PaaS instead. Another thing to note here is that revoking a CA certificate will stop RPKI validators from trying to get the content, and it will silence the warnings in the logs, but if these CAs use a shared repository - such as the PaaS, then the content will still be there until that is also actively removed. Delegated CAs can delegate... A member that uses a delegated CA may delegate all or some of their resources to "child" CAs of their own. Those CAs may publish at the PaaS (we currently allow the member to configure up to 10 publishers), or publish in their own repositories. It may happen that the member CA issued under RIPE NCC is functioning correctly, but their delegated CAs (or "grandchildren" etc) are having an issue. I think we should have clarity to the RIPE NCC what to do in such cases: - Is this out-of-scope? - Should the RIPE NCC monitor the entire delegated member tree? - Should the RIPE NCC revoke a member CA with broken delegated CAs? - Should the RIPE NCC actively engage with such member CAs, but leave the actions to them? If the RIPE NCC is to monitor the entire tree under a certificate issued to a delegated member CA, then this could amount to significant work. On the other hand, another advantage of such a process could be that the RIPE NCC can also monitor (re-actively, because it is always after the fact) for other bad things that can happen, such as CAs issuing an enormous amount of objects or delegating to a vast number of CAs - which may also impact RPKI validators and perhaps should warrant some kind of action. Finally, I also want to mention PaaS - once more. What may happen here is that a delegated member CA delegates to a CA of their own that also publishes at the PaaS. If the member CA then removes the delegated CA (revokes it) - that may actually continue to function and publish at the PaaS, or they may simply not remove their old content. The latter can be detected relatively easily (no more RFC 8181 interactions, and the manifests in the (sub-)repo are old). But the former is harder from the RIPE NCC perspective. The result of not doing anything here is having content in the PaaS repository that is unreferenced in the RPKI tree. It may not result in warnings in RPKI validators, but it adds to their burden in terms of data usage for RRDP snapshot downloads, full rsync, and local storage in the validators. In short, this may also warrant thought. I hope these observations are helpful. And I hope it is clear that they are not intended to dissuade people from the policy. There are many corner cases that we can consider, and many ways that we can deal with them. It may be hard to enumerate them all in a policy. In that I would like to echo a comment made earlier that if the policy describes the problem to solve rather than the solution this may leave us at the RIPE NCC more room to come up with a good solution and adjust it over time. Of course any such implementation of policy requirements would be published publicly and open to community feedback. Kind regards, Tim Bruijnzeels (Principal Engineer RPKI, RIPE NCC)
Your feedback is most welcome!
Kind regards,
Job
-------------------
Policy Proposal Name:
Automatic Revocation of Persistently Non-functional Delegated RPKI Certification Authorities
Author: a. name: Job Snijders b. email: job@sobornost.net
Proposal Version: (to be assigned by the RIPE NCC)
Submission Date: February 25th, 2025
Suggested RIPE WG for discussion and publication: RIPE Routing Working Group
Proposal Type: NEW
Policy Term: Indefinite
Summary of proposal:
RIPE NCC offers users of its RPKI certification service two deployment models: "Hosted CA setup" and "Delegated CA setup". In the Hosted setup RIPE NCC is responsible for timely issuance and publication of new RPKI Manifests and CRLs, but in the Delegated setup users themselves manage their CA on their own infrastructure.
It is possible for Delegated CA infrastructure to be offline for extended periods of time or for the contents of publication repositories to become stale or otherwise invalid. This proposal suggests to provide mandate to RIPE NCC to revoke resource certificates associated with longtime non-functional CAs to reduce Relying Party workload.
This policy proposal targets only pathologically non-functional CAs. An example of a situation considered out-of-scope for this policy would be a publication repository service advertised to also be available via IPv6 and RRDP but in practise only reachable via IPv4 and Rsync: the associated CA would still be considered functional (provided a valid and current Manifest could somehow be retrieved and validated sometime in the previous one hundred days). In other words: this policy proposal isn't about CAs that didn't achieve 100% uptime, but about CAs that are down all the time.
Policy text:
If RIPE NCC is unable to discover and validate a Delegated RPKI Certification Authority's (CA's) current Manifest and CRL for one hundred consecutive days, that Delegated CA's resource certificate shall be revoked by the RIPE NCC. RIPE NCC shall make reasonable efforts to discover new Manifests, for example, by corroborating information from multiple vantage points. After revocation, the Resource Holder may either reinitialize the Delegated CA setup or choose the Hosted CA setup.
Rationale: a. Arguments supporting the proposal
Persistently Non-functional Delegated CAs (PNDCs, for short) have subtle effects within the RPKI ecosystem which may become more pronounced over time.
* PNDCs offer nothing of value to RPs (because without a current valid Manifest any signed payloads are unavailable).
* RP synchronisation becomes more economic with fewer purposeless caRepositories to traverse.
* PNDCs besmirch Relying Party (RP) syslog message archives and waste RP CPU cycles and network traffic.
* Automatic revocation is only a minor inconvenience for CAs (that already were non-functional to begin with), but a big deal for RPs - especially when taking into account many future synchronisation attempts over long periods of time.
b. Arguments opposing the proposal
* Resource holders might require more than one hundred days to complete the initial Delegated CA setup.
(Counterpoints: initial setup procedures usually only takes a few minutes. Resource holders are free to simply retry the delegated CA setup procedure following automatic revocation.)
Additional opposing arguments to be determined. ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Dear Tim, others, Thank you for sharing your feedback! On Thu, Mar 06, 2025 at 11:01:25AM +0100, Tim Bruijnzeels wrote:
It probably is good to have some discussion around:
* should perpetually broken Delegated CA setups be culled at some point?
I will leave the policy answer to this to the community.
But let me share "prior art":
From my previous employment I know that nic.br have a similar process for their member CAs. All of their member CAs are "delegated". This may not be apparent because most of them publish through a publication server and repository provided by nic.br. In any case, nic.br monitors for CAs that have gone offline and "prune" them if they are not restored in a given time. I am not entirely sure what timeline they use, and if it's an automated or manual process, but I believe it is less than 100 days.
ah yes, yup, good to know!
* is the continuous lack of a valid current manifest for a 100 day period of time a good indicator for "Delegated CA brokenness"?
This is one way to do this.
It requires that the parent CA (RIPE NCC in this case) monitors the repositories for member CA certificates that it issues to delegated CAs. These CAs may use the Publication-as-a-Service (PaaS) provided by RIPE NCC, or they could run their own publication server.
Correct.
If they run their own publication server then it may be that the delegated CA itself is available, and as a parent we see it connecting regularly through RFC 6492 (provisioning protocol) exchanges, but their repository is unavailable. In such cases, it may be better to advise these CAs to migrate to using the RIPE NCC provided PaaS instead.
100% - I'd consider it a net positive whenever Delegated CAs migrate towards using RIPE NCC's PAAS instead of running their own.
Another thing to note here is that revoking a CA certificate will stop RPKI validators from trying to get the content, and it will silence the warnings in the logs, but if these CAs use a shared repository - such as the PaaS, then the content will still be there until that is also actively removed.
Yes, your observation is correct. To this point I'd argue that RPs (and also publication point operators) simply are no worse off, as with (or without) a revocation policy, such content continues to be distributed. Cleaning up 'useless data in PAAS' probably is a good next policy proposal to consider (after having established consensus & implementation of an non-functional CA revocation policy).
Delegated CAs can delegate...
A member that uses a delegated CA may delegate all or some of their resources to "child" CAs of their own. Those CAs may publish at the PaaS (we currently allow the member to configure up to 10 publishers), or publish in their own repositories. It may happen that the member CA issued under RIPE NCC is functioning correctly, but their delegated CAs (or "grandchildren" etc) are having an issue.
I think we should have clarity to the RIPE NCC what to do in such cases: - Is this out-of-scope?
I believe "Subjects of RIPE NCC's direct subjects" are out of scope, quite literally - because RIPE NCC's CA cannot revoke child-of-child certificates; such certificates simply are not within the scope of RIPE NCC's CRL.
- Should the RIPE NCC monitor the entire delegated member tree?
Personally I'd monitor _at least_ the directly subordinate subjects, but there may be advantages to having (separate?) instances monitor as much as possible.
- Should the RIPE NCC revoke a member CA with broken delegated CAs?
In short: no. I think strong arguments can be made that - when there is no current valid Manifest/CRL for an extended period of time - nothing of value is lost by revoking that non-functional CA. On the other hand, the moment a CA is functional (functional enough to have delegated some authority to other CAs), the CA might serve some purpose to someone, even though (a subset of) its subordinate products are broken in one way or another. Perhaps in excess - of course a non-functional CA cannot delegate authority, because functional delegation requires a functional CA :)
- Should the RIPE NCC actively engage with such member CAs, but leave the actions to them?
Such an initiative probably doesn't need to be ratified in this policy proposal, but in general it probably is good to attempt to understand _why_ certain forms of brokenness exist in the ecosystem. Questions such as "is the PAAS too hard to use?" "is there some kind of unforeseen friction in one of RIPE NCC's RPKI services?" etc I suspect most of the time things are just broken because someone didn't clean up the leftovers of a study / experiment - but who knows? :-)
If the RIPE NCC is to monitor the entire tree under a certificate issued to a delegated member CA, then this could amount to significant work. On the other hand, another advantage of such a process could be that the RIPE NCC can also monitor (re-actively, because it is always after the fact) for other bad things that can happen, such as CAs issuing an enormous amount of objects or delegating to a vast number of CAs - which may also impact RPKI validators and perhaps should warrant some kind of action.
Yes, that certainly is an advantage. If I were to technically implement this I'd advocate for separate monitoring pipelines so that one doesn't block the other. The rpki-client implementation allows the RP operator to exactly specify (through an allowlist/blocklist) how 'deep' to traverse the tree. So it is conceivable to have instances that monitor "only the directly subordinate CAs" and separate instances that monitor "everything under the RIPE NCC TAL".
Finally, I also want to mention PaaS - once more.
Given that Easter is just around the corner, I anticipate that the Dutch word 'paas' will be mentioned many many times in the coming weeks ;-)
What may happen here is that a delegated member CA delegates to a CA of their own that also publishes at the PaaS. If the member CA then removes the delegated CA (revokes it) - that may actually continue to function and publish at the PaaS, or they may simply not remove their old content. The latter can be detected relatively easily (no more RFC 8181 interactions, and the manifests in the (sub-)repo are old). But the former is harder from the RIPE NCC perspective.
Yeah it sounds like a separate initiative to 'automatically clean PaaS' is warranted down the road. Where the CA's functional/non-functional state can be deducted from the observability of a current valid Manifest/CRL, for PaaS detecting the "liveliness of a publication client" might need to be inferred from 8181 interactions. I think you raise important questions which suggest there is more work to be done, I suspect it would be good to attempt that tackle that after dealing with non-functional CAs first.
The result of not doing anything here is having content in the PaaS repository that is unreferenced in the RPKI tree. It may not result in warnings in RPKI validators, but it adds to their burden in terms of data usage for RRDP snapshot downloads, full rsync, and local storage in the validators. In short, this may also warrant thought.
I've been tracking 'unreferenced objects' over time and have reached out to RIRs where the number was higher than 'the usual churn'. Situations in which excessive numbers of unreferenced objects existed were all resolved in a timely fashion. In this context 'excessive' was tens-of-thousands of objects.
I hope these observations are helpful. And I hope it is clear that they are not intended to dissuade people from the policy.
Yes, thank you for chiming in.
There are many corner cases that we can consider, and many ways that we can deal with them. It may be hard to enumerate them all in a policy. In that I would like to echo a comment made earlier that if the policy describes the problem to solve rather than the solution this may leave us at the RIPE NCC more room to come up with a good solution and adjust it over time. Of course any such implementation of policy requirements would be published publicly and open to community feedback.
Yup - we should try to avoid painting ourselves into a corner by having to re-do the PDP because the first attempt was overly prescriptive. :) In closing - I want to mention I have already implemented my own "non-functional CA detection system" and currently run two independent instances in two cities. If this policy moves forward to the point that RIPE NCC actually starts to study implementation, from my side there will be an opportunity to compare notes and verify that both our implementations arrive at the exact same outcome. I can check your homework and you can check mine! :-) I'm happy to explain (in-person?) how my detection system works, share my code, and provide access to the ongoing measurements. Kind regards, Job ps. Here is an overview of the top 10 locations' current number of 'unreferenced files' in the global RPKI. Unref_Objects Publication_FQDN Size 2065 rpki.apnic.net 12MB 1776 rpki-repo.registro.br 14MB 619 rsync.paas.rpki.ripe.net 4.4MB 206 rpki.sub.apnic.net 1.4MB 202 rpki.afrinic.net 1.2MB 144 rpki-rps.arin.net 1.1MB 39 rpki.cnnic.cn 775KB 23 r.magellan.ipxo.com 130KB 21 rpki.apernet.io 125KB 20 repo.kagl.me 116KB The total number of objects is around 5,500 - which is not perfect, but certainly not as bad as it has been in the past.
برنامه ای ک نتونه ی گوشی روازطریق شماره سریال وکد۱۵رقمی وشماره تلفنش ردیابی کنه برنامه نیست در تاریخ پنجشنبه ۶ مارس ۲۰۲۵، ۱۷:۵۸ Job Snijders <job@sobornost.net> نوشت:
Dear Tim, others,
Thank you for sharing your feedback!
It probably is good to have some discussion around:
* should perpetually broken Delegated CA setups be culled at some
On Thu, Mar 06, 2025 at 11:01:25AM +0100, Tim Bruijnzeels wrote: point?
I will leave the policy answer to this to the community.
But let me share "prior art":
From my previous employment I know that nic.br have a similar process for their member CAs. All of their member CAs are "delegated". This may not be apparent because most of them publish through a publication server and repository provided by nic.br. In any case, nic.br monitors for CAs that have gone offline and "prune" them if they are not restored in a given time. I am not entirely sure what timeline they use, and if it's an automated or manual process, but I believe it is less than 100 days.
ah yes, yup, good to know!
* is the continuous lack of a valid current manifest for a 100 day period of time a good indicator for "Delegated CA brokenness"?
This is one way to do this.
It requires that the parent CA (RIPE NCC in this case) monitors the repositories for member CA certificates that it issues to delegated CAs. These CAs may use the Publication-as-a-Service (PaaS) provided by RIPE NCC, or they could run their own publication server.
Correct.
If they run their own publication server then it may be that the delegated CA itself is available, and as a parent we see it connecting regularly through RFC 6492 (provisioning protocol) exchanges, but their repository is unavailable. In such cases, it may be better to advise these CAs to migrate to using the RIPE NCC provided PaaS instead.
100% - I'd consider it a net positive whenever Delegated CAs migrate towards using RIPE NCC's PAAS instead of running their own.
Another thing to note here is that revoking a CA certificate will stop RPKI validators from trying to get the content, and it will silence the warnings in the logs, but if these CAs use a shared repository - such as the PaaS, then the content will still be there until that is also actively removed.
Yes, your observation is correct. To this point I'd argue that RPs (and also publication point operators) simply are no worse off, as with (or without) a revocation policy, such content continues to be distributed.
Cleaning up 'useless data in PAAS' probably is a good next policy proposal to consider (after having established consensus & implementation of an non-functional CA revocation policy).
Delegated CAs can delegate...
A member that uses a delegated CA may delegate all or some of their resources to "child" CAs of their own. Those CAs may publish at the PaaS (we currently allow the member to configure up to 10 publishers), or publish in their own repositories. It may happen that the member CA issued under RIPE NCC is functioning correctly, but their delegated CAs (or "grandchildren" etc) are having an issue.
I think we should have clarity to the RIPE NCC what to do in such cases: - Is this out-of-scope?
I believe "Subjects of RIPE NCC's direct subjects" are out of scope, quite literally - because RIPE NCC's CA cannot revoke child-of-child certificates; such certificates simply are not within the scope of RIPE NCC's CRL.
- Should the RIPE NCC monitor the entire delegated member tree?
Personally I'd monitor _at least_ the directly subordinate subjects, but there may be advantages to having (separate?) instances monitor as much as possible.
- Should the RIPE NCC revoke a member CA with broken delegated CAs?
In short: no.
I think strong arguments can be made that - when there is no current valid Manifest/CRL for an extended period of time - nothing of value is lost by revoking that non-functional CA.
On the other hand, the moment a CA is functional (functional enough to have delegated some authority to other CAs), the CA might serve some purpose to someone, even though (a subset of) its subordinate products are broken in one way or another.
Perhaps in excess - of course a non-functional CA cannot delegate authority, because functional delegation requires a functional CA :)
- Should the RIPE NCC actively engage with such member CAs, but leave the actions to them?
Such an initiative probably doesn't need to be ratified in this policy proposal, but in general it probably is good to attempt to understand _why_ certain forms of brokenness exist in the ecosystem. Questions such as "is the PAAS too hard to use?" "is there some kind of unforeseen friction in one of RIPE NCC's RPKI services?" etc
I suspect most of the time things are just broken because someone didn't clean up the leftovers of a study / experiment - but who knows? :-)
If the RIPE NCC is to monitor the entire tree under a certificate issued to a delegated member CA, then this could amount to significant work. On the other hand, another advantage of such a process could be that the RIPE NCC can also monitor (re-actively, because it is always after the fact) for other bad things that can happen, such as CAs issuing an enormous amount of objects or delegating to a vast number of CAs - which may also impact RPKI validators and perhaps should warrant some kind of action.
Yes, that certainly is an advantage.
If I were to technically implement this I'd advocate for separate monitoring pipelines so that one doesn't block the other. The rpki-client implementation allows the RP operator to exactly specify (through an allowlist/blocklist) how 'deep' to traverse the tree. So it is conceivable to have instances that monitor "only the directly subordinate CAs" and separate instances that monitor "everything under the RIPE NCC TAL".
Finally, I also want to mention PaaS - once more.
Given that Easter is just around the corner, I anticipate that the Dutch word 'paas' will be mentioned many many times in the coming weeks ;-)
What may happen here is that a delegated member CA delegates to a CA of their own that also publishes at the PaaS. If the member CA then removes the delegated CA (revokes it) - that may actually continue to function and publish at the PaaS, or they may simply not remove their old content. The latter can be detected relatively easily (no more RFC 8181 interactions, and the manifests in the (sub-)repo are old). But the former is harder from the RIPE NCC perspective.
Yeah it sounds like a separate initiative to 'automatically clean PaaS' is warranted down the road. Where the CA's functional/non-functional state can be deducted from the observability of a current valid Manifest/CRL, for PaaS detecting the "liveliness of a publication client" might need to be inferred from 8181 interactions.
I think you raise important questions which suggest there is more work to be done, I suspect it would be good to attempt that tackle that after dealing with non-functional CAs first.
The result of not doing anything here is having content in the PaaS repository that is unreferenced in the RPKI tree. It may not result in warnings in RPKI validators, but it adds to their burden in terms of data usage for RRDP snapshot downloads, full rsync, and local storage in the validators. In short, this may also warrant thought.
I've been tracking 'unreferenced objects' over time and have reached out to RIRs where the number was higher than 'the usual churn'. Situations in which excessive numbers of unreferenced objects existed were all resolved in a timely fashion. In this context 'excessive' was tens-of-thousands of objects.
I hope these observations are helpful. And I hope it is clear that they are not intended to dissuade people from the policy.
Yes, thank you for chiming in.
There are many corner cases that we can consider, and many ways that we can deal with them. It may be hard to enumerate them all in a policy. In that I would like to echo a comment made earlier that if the policy describes the problem to solve rather than the solution this may leave us at the RIPE NCC more room to come up with a good solution and adjust it over time. Of course any such implementation of policy requirements would be published publicly and open to community feedback.
Yup - we should try to avoid painting ourselves into a corner by having to re-do the PDP because the first attempt was overly prescriptive. :)
In closing - I want to mention I have already implemented my own "non-functional CA detection system" and currently run two independent instances in two cities. If this policy moves forward to the point that RIPE NCC actually starts to study implementation, from my side there will be an opportunity to compare notes and verify that both our implementations arrive at the exact same outcome. I can check your homework and you can check mine! :-)
I'm happy to explain (in-person?) how my detection system works, share my code, and provide access to the ongoing measurements.
Kind regards,
Job
ps. Here is an overview of the top 10 locations' current number of 'unreferenced files' in the global RPKI.
Unref_Objects Publication_FQDN Size 2065 rpki.apnic.net 12MB 1776 rpki-repo.registro.br 14MB 619 rsync.paas.rpki.ripe.net 4.4MB 206 rpki.sub.apnic.net 1.4MB 202 rpki.afrinic.net 1.2MB 144 rpki-rps.arin.net 1.1MB 39 rpki.cnnic.cn 775KB 23 r.magellan.ipxo.com 130KB 21 rpki.apernet.io 125KB 20 repo.kagl.me 116KB
The total number of objects is around 5,500 - which is not perfect, but certainly not as bad as it has been in the past. ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
tim, lots of good points
It requires that the parent CA (RIPE NCC in this case) monitors the repositories for member CA certificates that it issues to delegated CAs. These CAs may use the Publication-as-a-Service (PaaS) provided by RIPE NCC, or they could run their own publication server.
i am of two minds on this. while i like publication at reliable PPs, i am not fond of over-centralisation and spsof. originally, we hoped for a dozen or two PaaS providers. randy
participants (9)
-
elahemosavi -
Fedor Vompe -
Gert Doering -
Jared Mauch -
Job Snijders -
Nick Hilliard -
Randy Bush -
Sebastian Becker -
Tim Bruijnzeels