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. "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
When the deployment of ASPA and RFC9234 (and BGPsec :P) is much higher, the scale will tip. I understand, James, that you are talking about the future, and where we need to be heading, and I’d also like to head there. Doing all of that intermediary work may seem like a waste. I think what Bryton is saying is that we need something to get us there safely, and we may have to waste these resources.
And my two pence is, put that effort into RFC9234 and ASPA, then the combination of RTBH community + ROA maxLength + peer role + OTC check + ASPA validation, means we won't need things like DOAs :) That will be about as good as it can get without introducing some BGPsec like thing (I really thing that should be our long term goal). With kind regards, James Bensley (he/him) ________________________________________ From: Antonis Chariton <daknob@daknob.net> Sent: 25 August 2026 01:13 To: James Bensley <james@inter.link> Cc: Bryton Herdes <bryton@cloudflare.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [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 James, all
On 24 Aug 2026, at 19:15, James Bensley <james@inter.link> wrote:
Similarly, it's also why I think that increasing maxLenght to accommodate RTBH works; because you'd only accept a route >=/25 or >=/48 if it has the RTBH community, _and_ is ROA valid, _and_ is AS path valid, _and_ is not a leak (OTC). In this ideal world, the only chance for hijacks is the one we still have no large scale solution for (cryptographic verification of the AS PATH attribute).
I had to carefully read this thread a couple of times to make sure I understand it correctly but it seems to me that the core of the issue is that ROAs don’t also have a minLength. If I am only advertising a /16 at all times, and I don’t need anything more specific, I currently issue a ROA for the /16 with maxLength /16. If I get a DDoS attack and I need to RTBH, I cannot change the maxLength or issue a new ROA as that would take “ages” to propagate. If I had a minLength, I could issue a second object that I have out there all year round that’s for the /16 and it has minLength=/32 maxLength=/32. This last object is basically the DOA. It’s a ROA with maxed out min/maxLength and constrained to a specific community’s presence. 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 a provider who wants to offer RTBH ability, since I don’t have a magic prefix list that’s known good for every BGP session, I have to rely on all of these technologies you mention above. They are not perfect, attackers can still get through, and my non-magical prefix lists will be my last resort. This is why a lot of networks only offer RTBH for customers. As a network that wants to use an RTBH service and I want it to be available to me to save the rest of my business, I want it to work, but I also don’t want to permanently open up my prefixes to hijacks with very broad ROAs. Also, since I usually have a relationship with the RTBH provider, I can try to make sure they keep their prefix list up to date. They can do an `if (prefix_list_matches() && rtbh_community_found())` before the RPKI check. 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. When the deployment of ASPA and RFC9234 (and BGPsec :P) is much higher, the scale will tip. I understand, James, that you are talking about the future, and where we need to be heading, and I’d also like to head there. Doing all of that intermediary work may seem like a waste. I think what Bryton is saying is that we need something to get us there safely, and we may have to waste these resources. Now DOA will be a new draft and it will take a lot of time to be deployed on its own, if ever, and maybe operators will get tired of all these new object types. Maybe it will arrive later than very broad adoption of AS paths and it will be… DoA. Who knows :) Antonis [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>