Hi all, I saw the bat signal from a mix of RTBH + lack of “route validation” —
They were being asked to simply accept anything based on a AS path check. I would assume most are using strict prefix lists. I saw the recent thread about using ROA as a check but that has some hurdles without config knobs or tricks to relax constraints.
I’ve accepted the fact that RTBH isn’t going anywhere. It’s useful to many small to medium networks as a real, valid means of responding to DDoS attacks. My number one problem with RTBH today is a lack of route origin validation. RTBH hijacks are real, and those coming to NANOG 98 will get to hear me talking about real examples where major networks are accepting these blackhole route hijacks ( https://nanog.org/events/nanog-98/content/5843/ ). Most big ISPs are doing IRR-only filtering on BLACKHOLE routes, no origin validation or AS_PATH checking to speak of. 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. Let’s talk about this more at NANOG 98. 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. Thanks, -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Tue, Jul 28, 2026 at 9:40 AM Phil Bedard via NANOG <nanog@lists.nanog.org> wrote:
RTBH certainly has its place in the toolbox for DDoS mitigation but it is a bit of a hammer.
Flowspec can be used to simply remark traffic into scavenger and on their own network many do that today. But like you mention the ability to put more granular guardrails on what gets accepted from others else isn’t really baked into the standards. FS can have more complex resource implications. You create a FS policy that has 6 match conditions and it will take up a lot more TCAM space. There were also some highly publicized outages caused by it early on when people did try using it downstream->provider.
Maybe orthogonal but I had a question from an operator recently about validating RTBH prefixes from a downstream. They were being asked to simply accept anything based on a AS path check. I would assume most are using strict prefix lists. I saw the recent thread about using ROA as a check but that has some hurdles without config knobs or tricks to relax constraints.
Phil
From: Saku Ytti via NANOG <nanog@lists.nanog.org> Date: Tuesday, July 28, 2026 at 3:23 AM To: Barry Greene <bgreene@senki.org> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Saku Ytti <saku@ytti.fi> Subject: Re: RTBH Support Across the Industry
Suggesting to replace RTBH with flowspec will not be marketable, many people, rightly, are worried about flowspec, because it has a huge bug surface and some serious design mistakes and implementation mistakes which make it poor fit for environments which lack in trust.
Replacing blackhole community with QoS downgrade community is much more marketable in comparison, and infact one large tier1 used to offer this on a beta basis maybe 15-20 years ago. Sadly it is not commonly available.
On Tue, 28 Jul 2026 at 11:15, Barry Greene <bgreene@senki.org> wrote:
Suggestion …. Walk through the APRICOT 2022 talks with DDoS.
[image: hqdefault.jpg]
APRICOT 2022 - DDoS Resiliency Workshop < https://www.youtube.com/playlist?list=PLTAhO9aX5q8X5IS9M3m4fLtvQdjBp1UZ0> youtube.com < https://www.youtube.com/playlist?list=PLTAhO9aX5q8X5IS9M3m4fLtvQdjBp1UZ0> < https://www.youtube.com/playlist?list=PLTAhO9aX5q8X5IS9M3m4fLtvQdjBp1UZ0>
What I’m seeing in this conversation is the missing tools in the DDoS Toolkit that get integrated into DDoS playbooks.
RTBH was just the first element. We then had sRTBH when we created loose uRPF. Then we taught peers how to take dRTBH and sRTBH and redirect traffic to a network sinkhole set up to track the attacks once redirected. Then we had BGP community-based rate limiting. Chris Morrow (UUNET) and Job Snijders (NTT) then set up customer-based RTBH - where you, as a customer, can set up a BGP community and have it blocked at your upstream edge (giving you space to work the attack).
Then we had work at Cisco and Arbor on industry-wide mitigation approaches. This would take time, so Flow-Spec was created as a stopgap. That Cisco/Arbor work was migrated into DOTS in the IETF.
Listen to the sessions, especially the interviews.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OANHMCEU... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2W7COW7Z...