Re: RTBH Support Across the Industry

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

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/OANHMCEUYYUZOLRQKNAUL3IG36WQPL4D/
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/2W7COW7ZZL25VNMVGKTEZNW2PS65T2RJ/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/VN5U4KHPS5NDKTKBJBVFVZL34JL3XSBF/