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