Re: RTBH Support Across the Industry

[James Bensley via NANOG <nanog () lists nanog org>]

On Wednesday, July 29th, 2026 at 11:37, Job Snijders via NANOG <nanog () lists nanog org> wrote:
> On Tue, Jul 28, 2026 at 12:57:42PM -0400, Bryton Herdes via NANOG wrote:
> > My number one problem with RTBH today is a lack of route origin
> > validation.

> ... and then you outline a plan to bypass route origin validation??? :-)

I was formerly of the opinion that such a knob from vendors was a good idea, but I've been thinking it over recently 
and I've changed my mind. I think we shouldn't be going down this road. Sorry for the length, but to understand why we 
have to go back to the start.

I think the important question is: what do we want to protect against?

1. Misconfigurations / misoriginations (the origin AS doesn't match the ROA)
2. Intentional origin hijacks (attacker fakes the origin AS to match the ROA)

I think this is important for two reasons:

A. ROAs validate who *MAY* originate a prefix, they don't validate who *IS* originating a prefix. ASPAs validate which 
ASNs *MAY* forward a BGP announcement, they don't validate which ASNs *ARE* forwarding it. Therefore ROAs and ASPAs can 
only protect against (1). To protect against (2) we need something which cryptographically validates the AS_PATH 
attribute (like BGPsec or SCION or similar), but we don't have anything like that widely available today.

B. IMO >95% of the routing issues we want to stop are due to misconfigurations/accidents, whereas intentional hijacks 
only account for a fraction of the issues. I'm not saying that intentional hijacks don't happen or aren't important, 
I'm saying we don't have the tools to fight them yet, and they are the exception. But we do have the tools to fight the 
common case, so let's use those tools to fight the common case in the most effective way, and not try to bend them to 
also fight the corner case.

A key argument for this knob is that a longer maxLength risks intentional hijacks. Because ROAs can't protect against 
intentional origin hijacks, we're only interested in whether the BGP route origin matches the ROA origin, if it doesn't 
match then the maxLength has no bearing here (only when the two match). So the conventional wisdom of "a longer 
maxLength risks hijacks" is not true, because ROAs don't protect against intentional hijacks, only against 
misoriginations, and in this latter case the maxLength actually plays no role.

So if we're just protecting against misoriginations, then IMO the prefix owner should be the one setting their ROA 
maxLength to include longer prefixes, *iff* they are someone that uses RTBH or a similar service.

If we add a knob to ignore maxLength, several bad things happen, which don't happen if instead the prefix owner 
increases their maxLength iff required:

* Every network which implements this knob now ignores my maxLength, even though I know best for my prefixes. And not 
just for my prefixes, for *the entire DFZ*. The prefix length decision has been taken away from the very people who 
know best.

* This is something which will be implemented opaquely; most networks don't publicly document their BGP filtering 
policy, and most networks don't have a public looking glass, but now that networks will start accepting prefixes more 
specific than my ROA permits if the RTBH community is attached. But there is no way to see if this is happening, or 
know why it's happening, and I *explicitly signalled* in my ROA that this should not be happening. Troubleshooting this 
will be a nightmare.

* I'm a hijacker; I announce a more specific prefix than the ROA's maxLength, with a forged origin to match the ROA, 
with the RTBH community attached; my hijack will be more widely accepted *because of this knob* than if it didn't have 
the RTBH community attached, because without the RTBH community it would fail the maxLength check. So this knob 
actually makes sub-prefix origin hijacks attacks more damaging.

* Even if I announce someone else's prefix and fake the origin, but stick to the maxLength of their ROA, and the owner 
is also announcing the same prefix + length + origin (two competing routes); for most networks this will be absolutely 
devastating. The presence of a competing route doesn't provide protection against intentional origin hijacks that are 
ROA valid due to maxLength. The reason is that apart from the top ~20 most interconnected networks on bgp.tools, the 
average network is not that well connected and thus my equal length intentional hijack will win in many networks 
(especially if I'm in a different part of the world to the victim, my route will very likely win in all the networks in 
my region).


Now let's consider increasing the maxLength on ROAs to support RTBH:

* "Intentional origin hijacks are now easier"; no, there is no change here due to the lack of verification of the 
AS_PATH attribute, also see my point above about hijacks of an equal length prefix, you don't even need to hijack a 
more specific to completely hijack the traffic for a prefix.

* We no longer have to skip ROA validation and fall back to IRR based validation (which helps with deprecating IRR 
based filters).

* We don't make more specific hijacks more effective when they are tagged as RTBH routes.

* As the ROA owner I remain in control of how my prefixes are validated.


I think the best way to validate RTBH routes might be maxLength + ASPA + RFC9234 (i.e., the same way as we plan to 
validate non-RTBH routes).

Cheers,
James.
(Again, sorry for the length)

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/Q2GYREV3ZGUIRHF7SHXUPRGFAKRP4WQ4/