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