I don't think DOAs are the correct way forward because they have exactly the same problems as ROAs (because they are the same technology) when they are relied upon exclusively for RTBH validation: * There is no BGP control plane authentication so I can still inject an RTBH route with a fake AS path that will be DOA valid, just like with ROAs. This is the main problem people have with increasing the maxLength of ROAs, they think the ROA credibility is somehow a function of it's maxLength ,but ROAs (and DOAs) are origin attestations, not BGP UPDATE validations. DOAs improve nothing here. * DOAs did add as AS Path field which has now been superseeded by ASPA. The chance for DOAs to have a different AS path than an ASPA it a problem waiting to happen. * What to do with DOA unmatched prefixes (if no DOA exists), surely reject the RTBH route? So DOAs and ROAs won't behave the same (which will confuse people). I can't see what benefit DOAs add over increasing maxLength + rolling out peer roles + ASPA (maybe I missed it)? With kind regards, James Bensley (he/him) ________________________________ From: Bryton Herdes <bryton@cloudflare.com> Sent: 24 August 2026 17:33 To: Ben Cartwright-Cox <ripencc@benjojo.co.uk> Cc: James Bensley <james@inter.link>; Salvador Bertenbreiter <salvadorb@gmail.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI There are a few different implementation options floated around that get around half of the job done and are relatively safe most of the time. However, this topic and RTBH hijacks are critical enough to require their own intent. Reviving the separate object in RPKI is the only way that separate intent can be supported: https://datatracker.ietf.org/doc/html/draft-spaghetti-grow-rpki-doa-00 -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Mon, Aug 24, 2026 at 10:27 AM Ben Cartwright-Cox via routing-wg <routing-wg@ripe.net<mailto:routing-wg@ripe.net>> wrote: On the "Why not?" One of the obvious reasons that springs to my mind is that you might not want to do this because there are quite a lot of providers in existence that will allow you to announce /25's or smaller within their own internal networks, which means that in theory you can have an invisible /25 mis-origination attack/mistake if you allow /25's (or smaller), even if it won't cross the edge to another provider Given that one of the core reasons that Max Length exists is to prevent more specific hijacks, what you're suggesting here is basically the equivalent of ignoring maxLength anyway On Mon, 24 Aug 2026 at 16:22, James Bensley <james@inter.link> wrote:
Hi Salvador,
One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.
Why not? That is the most optimal solution for secure RTBH filtering in my opinion. Increase your maxLength, plus implement RFC9234 to validate the peer role, and ASPA to validate the path. I think this is the path we as an industry should be going down, not ignoring maxLength or relying on IRR derived prefix filters.
(because I'm quite lazy, here is a previous post I wrote explaining why I think this is the way forward: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q2GYREV3...)
With kind regards, James Bensley (he/him)
________________________________________ From: Salvador Bertenbreiter <salvadorb@gmail.com<mailto:salvadorb@gmail.com>> Sent: 08 August 2026 20:47 To: routing-wg@ripe.net<mailto:routing-wg@ripe.net> <routing-wg@ripe.net<mailto:routing-wg@ripe.net>> Subject: [routing-wg] RTBH and RPKI
⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi all, A quick question for those using RTBH together with RPKI.
How do you handle /32 announcements in IPv4 or /128 in IPv6 when the prefix has a ROA with a maxLength of /24 or /48?
One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.
The other option would be to keep the ROA as it is and still announce the host route for RTBH, but in that case it would be RPKI Invalid. Do upstreams normally make an exception for routes marked as blackhole, or are they dropped by RPKI before the RTBH policy is applied?
Creating a specific ROA at the time of the attack also doesn’t seem very practical because of propagation times.
How are you handling this in production?
Regards,
Salvador [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<mailto:hello@inter.link<mailto:hello@inter.link>> | Web: inter.link<https://inter.link> ----- 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/
----- 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/