Re: RTBH Support Across the Industry

[Saku Ytti via NANOG <nanog () lists nanog org>]

Thank you for the clarification.

Additionally if we think of RPKI, ASPA there is a distinct benefit in
downgrading, because it allows you to also downgrade through-traffic
as a service provider. Not on more-specifics though, but it's still
better than nothing.


C1 - P1 - P2 - C2

- C1 is sending DDoS to a single C2 prefix
- C2 is unresponsive
- P2 is congested

P2 shouldn't be able to blackhole, as it violates RPKI and/or ASPA
But P2 could attach QoS downgrade community to C2 prefix


We are currently very likely going to stop P2 from being able to
blackhole, as we do not know how to do it securely and we're uncertain
if P2 even should have the right to do so. But removing services
already used is also possibly very hard to market, so we are thinking
that P2 can only blackhole their own prefixes but can downgrade any
prefix.









On Mon, 27 Jul 2026 at 11:16, James Bensley <lists+nanog () bensley me> 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.



-- 
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/KEJSB3MFH6DOHKKSPM3J7UZYK2TESTSB/