2025-02 New Policy Proposal (Revocation of Persistently Non-functional Delegated RPKI CAs)
Dear colleagues, A new RIPE Policy Proposal, 2025-02, "Revocation of Persistently Non-functional Delegated RPKI CAs" is now available for discussion. This proposal suggests providing a mandate to the RIPE NCC to revoke resource certificates associated with longtime non-functional CAs to reduce Relying Party workloads. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2025-02/ As per the RIPE Policy Development Process (PDP), the purpose of the Discussion Phase is to discuss the proposal and provide feedback to the proposers. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 We encourage you to review this proposal and send your comments to routing-wg@ripe.net before 4 July 2025. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC
On 5 Jun 2025, at 10:35, Angela Dall'Ara <adallara@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2025-02, "Revocation of Persistently Non-functional Delegated RPKI CAs" is now available for discussion.
This proposal suggests providing a mandate to the RIPE NCC to revoke resource certificates associated with longtime non-functional CAs to reduce Relying Party workloads.
Hi Angela, Thanks for this new PDP, I agree with Job and Nick, this is definitely something that RIPE NCC should implement. It will reduce the NCCs cloud costs, and for each and every relying party (read: every ISP in the world) reduce the overhead from attempting to contact ISPs who do not have a properly functioning RP. It thus will also speed up processing of each round of reaching out to al RPs. It will make RPKI more stable and reliable. Thus this is a good move to do. One could weasel a wee bit around the words in the doc, but the intent should be clear for the NCC: revoke after 90 days of instability. Thanks Job and Nick for submitting this PDP: for a better Internet. Regards, Jeroen
On 5 Jun 2025, at 10:35, Angela Dall'Ara wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2025-02, "Revocation of Persistently Non-functional Delegated RPKI CAs" is now available for discussion.
Hi, Thanks, Job and Nick for making this proposal, it has my support. I’m afraid this problem will only grow bigger if nothings changes, so reducing the overhead caused to others is a good idea. 3 months to fix this sounds reasonable to me. Best regards, -- Teun Vink BIT | teun@bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE
Hi, On Thu, Jun 05, 2025 at 10:35:07AM +0200, Angela Dall'Ara wrote:
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2025-02/
Support. Bad data is not serving any useful purpose, and the suggested criteria for recognizing that "something" is now "bad data" (delegations not working more than 3 months) seems a fairly safe and still effective approach. Looking at my rpki-client and routinator logs, quite some cleanup is needed, so this is indeed a problem visible to relying parties today. Gert Doering -- does BGP sometimes -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, 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
hi Angela, +1, should be implemented ASAP with the increasing number of delegated CAs the time required to validate increases, keeping non-functional CAs serves no purpose, adding even more delays for unresponsive repositories. worth mentioning that the number of non-functional CAs is larger in the RIPENCC service region, perhaps indicating some additional issues causing this that could be addressed. 3 months is reasonable, i would not oppose a shorter (30 days) period. nitpicking: to avoid CAs being deregistered at different intervals after short months like February the 3 months could be specified as 90 days. best, Radu On 6/5/2025 10:35 AM, Angela Dall'Ara wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2025-02, "Revocation of Persistently Non- functional Delegated RPKI CAs" is now available for discussion.
This proposal suggests providing a mandate to the RIPE NCC to revoke resource certificates associated with longtime non-functional CAs to reduce Relying Party workloads.
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2025-02/
As per the RIPE Policy Development Process (PDP), the purpose of the Discussion Phase is to discuss the proposal and provide feedback to the proposers.
At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781
We encourage you to review this proposal and send your comments to routing-wg@ripe.net before 4 July 2025.
Kind regards,
Angela Dall'Ara Policy Officer RIPE NCC
----- 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/
Radu Anghel via routing-wg wrote on 06/06/2025 11:33:
nitpicking: to avoid CAs being deregistered at different intervals after short months like February the 3 months could be specified as 90 days.
"more than three months" should give the RIPE NCC enough leeway not to be forced to take action on specific days which was a bad idea, for example, having a revocation happen on a public holiday and that sort of thing. The point is that the delegation is revoked after notice, and enough time for the operator in question to take action. The specific day is not that relevant, i.e. if it's + a couple of days, that's not that big a deal. Nick
public holidays in NL are not always the same as in other countries, this could generate complaints. having the thing automated removes the burden of checking worldwide public holiday calendars from the NCC and gives nice fixed numbers to work with. 24x7 NOCs are there on public holidays too, in case they miss all of the pre-revocation notifications. there are probably more arguments for both options, the revocation should happen anyway to clean things up, +/- a few days make no difference when you have unresponsive CAs since 2023. best, Radu On 6/6/2025 1:18 PM, Nick Hilliard wrote:
Radu Anghel via routing-wg wrote on 06/06/2025 11:33:
nitpicking: to avoid CAs being deregistered at different intervals after short months like February the 3 months could be specified as 90 days.
"more than three months" should give the RIPE NCC enough leeway not to be forced to take action on specific days which was a bad idea, for example, having a revocation happen on a public holiday and that sort of thing.
The point is that the delegation is revoked after notice, and enough time for the operator in question to take action. The specific day is not that relevant, i.e. if it's + a couple of days, that's not that big a deal.
Nick
----- 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/
Yes there's usually a lot to think about in terms of implementation specifics. I'd be of the opinion that it would best to leave this to the RIPE NCC to work out what's the most sensible thing to do. Tying operational details down in a policy statement is usually not a good idea unless the person writing the policy has a complete view of all the subtleties in question, which personally I don't, or where it's operationally advisable to specify the details in policy, which I don't see a case for here. I'm happy for the RIPE NCC to handle the specifics in this situation. If it turns out that this causes problems for operators in the future, that discussion can happen. Incidentally, iso27001 / soc2 compliance will mean that they'll need internal documentation, so in due course, there'll be an documented procedure for handling this. Nick Radu Anghel wrote on 06/06/2025 12:45:
public holidays in NL are not always the same as in other countries, this could generate complaints.
having the thing automated removes the burden of checking worldwide public holiday calendars from the NCC and gives nice fixed numbers to work with.
24x7 NOCs are there on public holidays too, in case they miss all of the pre-revocation notifications.
there are probably more arguments for both options, the revocation should happen anyway to clean things up, +/- a few days make no difference when you have unresponsive CAs since 2023.
best,
Radu
On 6/6/2025 1:18 PM, Nick Hilliard wrote:
Radu Anghel via routing-wg wrote on 06/06/2025 11:33:
nitpicking: to avoid CAs being deregistered at different intervals after short months like February the 3 months could be specified as 90 days.
"more than three months" should give the RIPE NCC enough leeway not to be forced to take action on specific days which was a bad idea, for example, having a revocation happen on a public holiday and that sort of thing.
The point is that the delegation is revoked after notice, and enough time for the operator in question to take action. The specific day is not that relevant, i.e. if it's + a couple of days, that's not that big a deal.
Nick
----- 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/
On Fri, Jun 6, 2025 at 6:18 AM Nick Hilliard <nick@foobar.org> wrote:
Radu Anghel via routing-wg wrote on 06/06/2025 11:33:
nitpicking: to avoid CAs being deregistered at different intervals after short months like February the 3 months could be specified as 90 days.
"more than three months" should give the RIPE NCC enough leeway not to be forced to take action on specific days which was a bad idea, for example, having a revocation happen on a public holiday and that sort of thing.
The point is that the delegation is revoked after notice, and enough time for the operator in question to take action. The specific day is not that relevant, i.e. if it's + a couple of days, that's not that big a deal.
+1 However, it might also be a good idea for revocations to occur only on a regularly scheduled and published day and time rather than somewhat randomly throughout the month. For example, revocations should occur at noon UTC on the first Tuesday of the month, unless that is a public holiday, then on the second Tuesday of the month. The point being to avoid surprises to the extent possible. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
Hi, On Fri, Jun 06, 2025 at 07:05:01AM -0500, David Farmer via routing-wg wrote:
However, it might also be a good idea for revocations to occur only on a regularly scheduled and published day and time rather than somewhat randomly throughout the month. For example, revocations should occur at noon UTC on the first Tuesday of the month, unless that is a public holiday, then on the second Tuesday of the month. The point being to avoid surprises to the extent possible.
Don't you think it does not matter at all on which time and day you remove a delegation when that has been broken for more than 3 months? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, 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
Happy to see this proposal! Fully in agreement with Nick that bogging down the policy with implementation details is a bad idea. It might be relevant to operators to tie down the "unable to discover" component. What is considered "reasonable efforts" in this context? -- Tom Strickx Principal Network Engineer AS13335 - Cloudflare On Fri, Jun 6, 2025 at 1:05 PM David Farmer via routing-wg < routing-wg@ripe.net> wrote:
On Fri, Jun 6, 2025 at 6:18 AM Nick Hilliard <nick@foobar.org> wrote:
Radu Anghel via routing-wg wrote on 06/06/2025 11:33:
nitpicking: to avoid CAs being deregistered at different intervals after short months like February the 3 months could be specified as 90 days.
"more than three months" should give the RIPE NCC enough leeway not to be forced to take action on specific days which was a bad idea, for example, having a revocation happen on a public holiday and that sort of thing.
The point is that the delegation is revoked after notice, and enough time for the operator in question to take action. The specific day is not that relevant, i.e. if it's + a couple of days, that's not that big a deal.
+1
However, it might also be a good idea for revocations to occur only on a regularly scheduled and published day and time rather than somewhat randomly throughout the month. For example, revocations should occur at noon UTC on the first Tuesday of the month, unless that is a public holiday, then on the second Tuesday of the month. The point being to avoid surprises to the extent possible.
Thanks
-- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ----- 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/
On Fri, Jun 6, 2025 at 7:23 AM Gert Doering <gert@space.net> wrote:
Hi,
On Fri, Jun 06, 2025 at 07:05:01AM -0500, David Farmer via routing-wg wrote:
However, it might also be a good idea for revocations to occur only on a regularly scheduled and published day and time rather than somewhat randomly throughout the month. For example, revocations should occur at noon UTC on the first Tuesday of the month, unless that is a public holiday, then on the second Tuesday of the month. The point being to avoid surprises to the extent possible.
Don't you think it does not matter at all on which time and day you remove a delegation when that has been broken for more than 3 months?
If the CA has been broken for 3 months, it is broken and can be removed. However, it doesn't need to happen exactly at 90 days. And it is probably a bad idea to do it on a public holiday or the weekend. All I'm suggesting is that good change practices are followed and that the change occurs regularly on a well-known, published day and time. That way, if something unforeseen happens, we don't have to wonder if a revocation occurred, unless it is that day of the month. Do I expect anything to happen? No! But! Further, this doesn't need to be in the policy itself; I trust the NCC to do the right thing, but it doesn't hurt to communicate our expectations. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
On Fri, Jun 06, 2025 at 01:29:14PM +0100, Tom Strickx via routing-wg wrote:
Happy to see this proposal! Fully in agreement with Nick that bogging down the policy with implementation details is a bad idea.
Thanks!
It might be relevant to operators to tie down the "unable to discover" component. What is considered "reasonable efforts" in this context?
Speaking as RPKI operator I'd expect RIPE NCC to make reasonable efforts to discover new Manifests, for example, by corroborating information from multiple vantage points. The NCC could run a handful of validator instances (produced by different vendors) in different geographical regions behind different providers, then when a 100% of those instances report the CA was non-functional for 100% of all indidividual measurements for a 3+ month period, conclude the Delegated CA is kaput. 5 instances times 4 runs per hour times 3 months = 44,640 measurements. If the NCC makes more than 44,000 attempts to discover+validate a CA's Manifest from more than 4 countries, I'd say that is more than reasonable. Should this policy proposal advance, RIPE NCC themselves can probably shed more light on how they'd approach measuring whether a CA is non-functional or not. Kind regards, Job
Hi, I support this proposal as it addresses a "missing" lifecycle part for more reliable function of the RPKI ecosystem. In our team, we are sometimes faced with the question of whether an unreachable or invalidly configured RPKI repository is indeed non-functional or just temporarily unavailable. RIPE NCC may decide to provide a public status dashboard in this matter - Current status of all delegated CAs (functional/at-risk/revoked) - Historical uptime data and validation success rates - Clear timestamps when monitoring failures began - Notification timeline for each at-risk CA This data may be also used in the LIR portal as well. Best regards, Fedor Vompe On Thu, Jun 5, 2025 at 10:35 AM Angela Dall'Ara <adallara@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2025-02, "Revocation of Persistently Non-functional Delegated RPKI CAs" is now available for discussion.
This proposal suggests providing a mandate to the RIPE NCC to revoke resource certificates associated with longtime non-functional CAs to reduce Relying Party workloads.
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2025-02/
As per the RIPE Policy Development Process (PDP), the purpose of the Discussion Phase is to discuss the proposal and provide feedback to the proposers.
At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781
We encourage you to review this proposal and send your comments to routing-wg@ripe.net before 4 July 2025.
Kind regards,
Angela Dall'Ara Policy Officer RIPE NCC
----- 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/
This all sounds entirely reasonable. I'd love for the NCC to document their solution in a similar fashion if/when this proposal is accepted. -- Tom Strickx Principal Network Engineer AS13335 - Cloudflare On Fri, Jun 6, 2025 at 2:31 PM Job Snijders <job@sobornost.net> wrote:
On Fri, Jun 06, 2025 at 01:29:14PM +0100, Tom Strickx via routing-wg wrote:
Happy to see this proposal! Fully in agreement with Nick that bogging down the policy with implementation details is a bad idea.
Thanks!
It might be relevant to operators to tie down the "unable to discover" component. What is considered "reasonable efforts" in this context?
Speaking as RPKI operator I'd expect RIPE NCC to make reasonable efforts to discover new Manifests, for example, by corroborating information from multiple vantage points.
The NCC could run a handful of validator instances (produced by different vendors) in different geographical regions behind different providers, then when a 100% of those instances report the CA was non-functional for 100% of all indidividual measurements for a 3+ month period, conclude the Delegated CA is kaput.
5 instances times 4 runs per hour times 3 months = 44,640 measurements.
If the NCC makes more than 44,000 attempts to discover+validate a CA's Manifest from more than 4 countries, I'd say that is more than reasonable.
Should this policy proposal advance, RIPE NCC themselves can probably shed more light on how they'd approach measuring whether a CA is non-functional or not.
Kind regards,
Job ----- 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/
participants (10)
-
Angela Dall'Ara -
David Farmer -
Fedor Vompe -
Gert Doering -
Jeroen Massar -
Job Snijders -
Nick Hilliard -
Radu Anghel -
Teun Vink -
Tom Strickx