Re: RTBH Support Across the Industry

[Dominik Dobrowolski via NANOG <nanog () lists nanog org>]

Hi all,

Can’t we implement the natural successor to blackhole meaning bgp flowspec?
It’s much better with modern attacks such as carpet-bombs, where attackers
attack whole prefixes and we need a more surgical tool.

Simultaneously we need to push harder to adopt uRPF to prevent spoofed
attacks.

Kind Regards,
Dominik Dobrowolski

On Mon, Jul 27, 2026 at 10:16 James Bensley via NANOG <nanog () lists nanog org>
wrote:

> Hey Saku,
>
> On Monday, July 27th, 2026 at 09:49, Saku Ytti <saku () ytti fi> wrote:
>
> > Is there consensus that RTBH is desirable?
>
> > Isn't RTBH just aiding the attacker and extending the duration of
> > outage outside the duration of attack?
>
> "If RTBH has been configured at all, and how has it been configured across
> various networks" is the goal of the first survey.
>
> The second survey is aimed at exactly the questions you're asking (why
> have you deployed it / why haven't you, what would you need for you to feel
> comfortable deploying it, what's missing for observability, how should it
> be secured, and so on). The two things are related but different, so I'm
> trying to gather them in two different surveys (2nd one after the summer
> break).
>
>
> >  With RTBH implemented, how do
> > we know when the issue subsides? Do we periodically remove RTBH to
> > check?
>
> > I think downgrading traffic to scavenger class via a BGP community is
> > superior to RTBH, you are transporting as much as you can, but
> > yielding to best effort. This gives you observability, you know when
> > the issue subsides, as you're still getting the packets, so you can
> > automatically remove the downgrade, the moment the attack subsides.
> > On your end you can push this market traffic to monitor box, scrubber
> > box, through ACL, null0 or whatever is locally prudent right now.
>
> I'm in full agreement with you here as to what the optimal mitigation
> strategy is.
>
> Today we have elected to go the route of having a sacrificial edge port;
> under normal circumstance stances we announce no prefixes out of this port,
> when a DDoS occurs, only RTBH routes are send out of this port, but without
> the RTBH community. The port can congest because it's traffic to IPs we're
> blackholing coming in there, but it gives us that signal about weather the
> attack is still on going or not. Also if it's just one port, it's no threat
> to backbone capacity.
>
> Long term we want to migrate to the QoS based approach too. But it
> requires that networks have deployed QoS already (so that makes the barrier
> to entry for some networks even higher if they haven't or can't deployed
> QoS), also it requires that QoS works as desired (cough cough Arista cough
> cough). Also if you're a really small network with a very small team, maybe
> with limited technical skills and resources; whilst RTBH does "complete"
> the DDoS attack, you might be happy to just to blackhole that route to save
> the rest of the customers and not have to think about potentially debugging
> QoS during an incident if other customers are are being impacted. I think
> for some tiny operators that is preferred.
>
> Cheers,
> James._______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/FOLCSZM5I237XSVDRMZBYSMDM2XCJLSP/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/WYZVYG6FYGCJSLCZVM77V2R26ZPZB2D7/