Re: RTBH Support Across the Industry

[Glenn McGurrin via NANOG <nanog () lists nanog org>]

I would imagine most intentional hijacks are looking to do something 
with the traffic beyond merely blocking it, and those who intent to 
block it likely have the power to compel the isp's near them to accept 
their routes overriding any and all filtering (government censorship 
type hijacks).  A hijack using the black-hole community would not lead 
to see any any traffic as the network accepting the longer prefix for 
black-holing would black-hole the traffic.  I'm also not convinced that 
such a knob and keeping max length shorter doesn't prevent certain 
unintentional hijacks, see badly configured route optimizers, yes, those 
shouldn't ever leak routes and such routes should be such that other 
networks would not accept them if they did, but we all know how that 
works in practice.  It also seems like not having such overrides would 
lead to max length being completely useless, almost every rtbh route 
I've seen was a /32 in ipv4, if everyone set's their maxlength to 32 
well why even have the field?

I think filtering rtbh on a customer cone or through clearinghouses that 
filter and only accept tightly scoped routes like I seem to recall team 
cmyu does is the norm, and so it also should be easier to validate 
origin AS, especially as most of the time I feel like they only end up 
making it one or two hops up the AS chain at most, though I may be 
completely wrong about how that works elsewhere.

I also wonder if such a knob may provide a safer option for some other 
use cases, mostly related to traffic engineering which links with an 
upstream receive which traffic via longer than dfz acceptable prefixes, 
I'm betting that currently most connections that accept those bypass roa 
checks for that completely, where this would allow for only relaxing the 
roa validation, which feels safer to me in case of an edge case or 
mistake in the configuration.

On 7/29/2026 12:46 PM, James Bensley via NANOG wrote:
> 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)
>
>
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/Q2GYREV3ZGUIRHF7SHXUPRGFAKRP4WQ4/

--
Glenn McGurrin
Principal
Cloud Optimized SMB LLC
Direct: (703) 434-3922
Toll Free: (866) 644-7363
Fax: (703) 439-1636

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