Re: RTBH Support Across the Industry

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

Hi Job,

> Isn't the risk inherit to this kind of knob precisely that operators use the
knob to by pass maxLength checking?

Yes that’s exactly what “bad” and the risk looks like, bypassing maxLength
checks for all (including regular IP) routes because an operator told the
router to do so via config either accidentally or on purpose.

> Can you qualify in what kind of situation this would be "not bad"?

“Not bad” looks like a tight coupling between the presence of BLACKHOLE
(well-known RFC7999, or configurable) community along with the maxLength
bypass to not lose maxLength-checking properties for all regular routes.

My interest is the same as yours in needing to preserve maxLength
protection properties, but I do find value in being able to bypass the
maxLength for BLACKHOLE routes specifically. I see it as the simplest
solution if implemented with some belts and braces. We can’t prevent people
from deliberately doing silly things like a full bypass for all routes, but
we can make it difficult to do so, noting if someone tried hard enough they
could already do it in some platforms.

Thanks,

--
Bryton Herdes
Principal Network Engineer
AS13335 - Cloudflare

On Wed, Jul 29, 2026 at 5:37 AM Job Snijders <job () bsd nl> 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'm being pedantic, a critical component of the RFC 6811 validation
> process is checking maxLength!)
>
> > I’ve went back and forth on solutions for RTBH, and my latest
> > opinion is vendors should implement a separate knob to bypass
> > maxLength checking for specifically routes tagged as BLACKHOLE, and
> > still validate origin AS via RPKI-ROV. The risk of operators using
> > such a knob in “a bad way” is known, but we need this tool.
>
> Can you qualify in what kind of situation this would be "not bad"?
>
> Isn't the risk inherit to this kind of knob precisely that operators use
> the knob to by pass maxLength checking?
>
> Almost sounds similar the risks associated with setting & using default
> passwords? :-)
>
> The global deployment of RPKI ROAs & validation brought us is an ability
> to signal at scale "do not accept more-specific-than-X", this is super
> useful because the most painful hijacks are the more-specific hijacks:
> more-specifics win the traffic. I'm concerned about erosion of this
> property.
>
> > Separately and most related to this thread, we shouldn’t encourage
> > aggressively for more networks to support RTBH until we have
> > solved the routing security problem with these route types. It is
> > counterproductive to make the RTBH hijack surface area even larger
> > than it already is.
>
> Makes sense. As it stands RTBH is a pain in the rear.
>
> Kind regards,
>
> Job
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/F4JDP7OH522M3PQQICMVGCYJ37EAYMB5/