Hi Bryton,
If that's true for you and many others, isn't it worth having the separate object in RPKI for storing blackhole/ddos-filtering intent?
I think this is an instance of solution-before-problem. I've provided several reasons throughout this thread why I think DOAs aren't the way forward. I'm very very happy to be told I'm wrong and have my ideas challenged, because then I learn something. So far my criticisms of DOAs haven't been challenged :) Let me say it like this... If you believe a new object in the RPKI is the way forward (and maybe not DOAs, maybe some other yet-to-be-defined object), then you must already have answers to these questions: * What _exactly_ is the problem that needs to be solved? * What _exactly_ about the existing tooling doesn't solve this? * How _exactly_ does a new object in the RPKI solve this? Convince me, I'm all ears :) With kind regards, James Bensley (he/him) ________________________________________ From: Bryton Herdes <bryton@cloudflare.com> Sent: 25 August 2026 22:49 To: Antonis Chariton <daknob@daknob.net> Cc: James Bensley <james@inter.link>; Routing WG <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: 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. Hey James -
The reason being, as I've said several times, maxLength isn't what allows a hijack, the lack of RFC9234 and ASPA is what allows a hijack.
I can appreciate the optimism about ASPA and RFC 9234. I share the belief that both are critical to Internet routing security, and not a single one alone. That being said, re-purposing the role of maxLength in the ROA is undesirable. It's (already) providing value against sub-prefix hijacks, which we cannot discard during the long-tail of adoption for our chosen path verification mechanisms (ASPA, RFC 9234). I think you may be downplaying maxLength's current value against both unintentional and intentional sub-prefix hijacks. Furthermore, I've gathered that you see a place for RTBH in both the near and far future. If that's true for you and many others, isn't it worth having the separate object in RPKI for storing blackhole/ddos-filtering intent? Thanks, -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Tue, Aug 25, 2026 at 12:59 PM Antonis Chariton via routing-wg <routing-wg@ripe.net> wrote: Hey James, On 25 Aug 2026, at 19:03, James Bensley <james@inter.link> wrote: Hi Antonis, I hope all is well with you. Issuing a /16 ROA with /32 maxLength means that attackers can hijack a /17 to /24 and it would take precedence over my routes. With the *current* deployment of ASPA and RFC9234 they would win. If I have the /16-/16 ROA, they’d have to compete with me for traffic, and because they would also have to add a fake hop behind them, it would increase their AS path, making them even less competitive. As the excellent team at Cloudflare have already shown us (https://blog.cloudflare.com/enforce-first-as-bgp/) I can fake the AS path and it will be as least as short as your AS path, not longer (this is also the case at various IXPs). Also due to Tier 1 carriers using Local Preference (I'm against LP, that requires a separate email thread), if my T1 is not the same T1 you use, I can fake the announcement to my T1, and they'll prefer it over the genuine announce their receive over their peering with your T1, because of LP on the customer port, and so despite your equal length count announcement, they'll prefer mine and propagate it. A competing announcement really adds no protection. Also, extended that idea to DOAs for a moment (yet another reason why I don't like DOAs): unless you black hole your self continuously, there will be no competing route. With a competing, normal, non-black hole route, my hijack of your prefix will be "quite" effective, it depends on how well peered you are. But plenty effective enough to be devastating for you because the average network isn't that well connected. With DOAs, there is no competing route, so my RTBH hijack will be 100% effective (I must admit, the same is true if we were to use ROAs with maxLength 32 + ASPA + RFC9234 + RTBH community to authenticate the RTBH announcement, but my point being, DOAs added no benefit here). Eventually it’s a trade off that has to be made. I personally think the risk of more specific hijacks is perceived as greater to companies than the risk of not maintaining a prefix list correctly with their contractual partner. A tight ROA gives them a fighting chance during a hijack, while a broad ROA makes them vulnerable while still not guaranteeing that RTBH will function properly (no false positives or negatives) 100% of the time. I'm not 100% sure if I followed this, is this what you're saying: "I personally think the risk of more specific hijacks is perceived as greater to companies than the risk of not maintaining a prefix list correctly" -> I think the risk is definitely _perceived_ as worse, but is it _actually_ worse? I don't believe so. The reason being, as I've said several times, maxLength isn't what allows a hijack, the lack of RFC9234 and ASPA is what allows a hijack. Also, many providers are extending prefix filters to match up to /32 or /128 already today, even if you don't want to use RTBH, they open you up to hijacks without your say or control. Moving this into ROA maxLength actually gives you control and the chance to opt out. "A tight ROA gives them a fighting chance during a hijack," -> I think this is a reference to competing announcements? If yes, see my note above, if people believe this it's like believing in longer passwords. "while a broad ROA makes them vulnerable" -> I disagree here; because as above, maxLength isn't what allows the AS path attribute to be manipulated. Let me rephrase: a more specific will always win, regardless of same T1, LP, spoofed AS paths, etc. A competing announcement will split the traffic. I oversimplified quite a bit trying to not be nihilistic. I don’t think anything can provide perfect protection, eliminating more specifics is, imho, significant. "while still not guaranteeing that RTBH will function properly (no false positives or negatives) 100% of the time." -> I didn't get this bit, sorry :D As a customer of a provider offering RTBH you want to not only ensure that others can’t trigger RTBH for your prefixes but also that you can always trigger it reliably when you need it. Antonis ----- 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/ [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> | Web: inter.link<https://inter.link>