Re: RTBH Support Across the Industry

[James Bensley via NANOG <nanog () lists nanog org>]

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.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/FOLCSZM5I237XSVDRMZBYSMDM2XCJLSP/