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