Re: RTBH Support Across the Industry

[Bryton Herdes via NANOG <nanog () lists nanog org>]

James,

> 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.

Just for RTBH, yes, is the proposal. As far as I know, this is already how
BLACKHOLE route filtering is being done -- allow upto /32 (or strictly
/32's) within covering routes from customers from expanded
AS-SET+route/route6. Using ROAs instead of IRR data causes no regression in
functionality. Instead, it's an improvement adding originAS-checking versus
the status quo.

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

In the conversations I've had regarding RTBH and RPKI, network operators
want to abide by the guidance in RFC9319 by signing "minimal ROAs" for
prefixes expected to propagate throughout the DFZ. However, they have a
different intent for RTBH as a directly-network-adjacent "filtering signal"
in BGP. Operators don't want to increase the attack surface area for
sub-prefix hijacks by authorizing RTBH routes. A fully separate intent
would need something like a DOA and years of adoption (repeat of ROA, for
RTBH): https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-doa/

This is why I feel the happy-medium is still a maxLength bypass for
RTBH. It just needs implemented in a way that doesn't encourage a bypass
for all routes. Repeating myself here, I encourage folks to bring some more
discussion to NANOG 98: https://nanog.org/events/nanog-98/content/5843/  as
we work on solving this tricky problem.

Thanks,

--
Bryton Herdes
Principal Network Engineer
AS13335 - Cloudflare


On Wed, Jul 29, 2026 at 12:47 PM James Bensley via NANOG <
nanog () lists nanog org> 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/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/56VCY6QPXCEYGVW2RZXBRG34PI2SZVJP/