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