Re: RTBH Support Across the Industry

[Tom Beecher via NANOG <nanog () lists nanog org>]

> * Not all networks support RTBH.

It sounds like you believe every upstream / transit provider SHOULD. I
don't agree.

* Networks that do support RTBH implement it differently to each other.
>

Of course. Every network is different. So will implementations.


> * There is no one place where one can easily find the info for how to use
> RTBH with a given network.

I don't believe this is important to have. I need to know how to use RTBH
for the networks I use that I COULD use it on. I don't care about the info
for everyone else out there.

* Operators have different ideas about how / when / where / why someone
> should / shouldn't use RTBH.


Again normal. Different operators have different opinions on many things
for various reasons. Technical, business, religious, etc.



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

> On Monday, July 27th, 2026 at 10:26, Dominik Dobrowolski <
> dobrowolski.domino () gmail com> wrote:
>
> > Hi all,
>
> Hi Dominik
>
> > 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.
>
> I think that in theory Flowspec is great, and using it internally within
> your own network is also great. Across networks, is, "not ideal" to give
> the political answer. I wish it was better but our operational experiences
> has shown the opposite.
>
> We're an IP transit provider and DDoS protection provider (who also offers
> Flowspec), some lessons learned from our Flowspec adventures;
>
> * To my knowledge, no vendor implements 100% of the features in the
> Flowspec RFCs. Each vendor is implementing a slightly different set of
> features, so there is a vendor diagram where only the most basic features
> are guaranteed to work between vendors, and the more "fringe" features are
> pot luck. Customers send us Flowspec routes from a different vendor and we
> see we can't implement 100% of what's in the route (vice verse, we could
> send them a route they can't 100% implement).
>
> * Compression of Flowspec rules is different between vendors; you might
> send me one single Flowspec rule which contains a lot of options and
> prefixes, in a single BGP Flowspec "route", but my vendor explodes that
> into 100 TCAM entries for the single route, or vice verse, you send me
> several very similar routes and I can compress then into a single TCAM
> entry. This phenomenon has two issues; firstly if we sell you X Flowspec
> filters/rules, we can't agree on how many you've consumed, we have two
> different views on that. Secondly, TCAM space is extremely expensive, so
> giving the customers the option to send a small number of routes which can
> explode into hundreds or thousands of TCAM entries needs careful management
> (most vendors don't have rich BGP policy syntax for Flowspec filtering,
> some of the stuff we do in RCF with Arista isn't documented in any Arista
> TOI).
>
> * Virtually nobody accepts Flowspec rules; none of our upstreams or PNI
> peers support Flowspec. We are trying to get several IXPs to trial Flowspec
> with us, and they are slow burning conversations with no actual trials
> happening yet.
>
> > Simultaneously we need to push harder to adopt uRPF to prevent spoofed
> attacks.
>
> I agree with you that better Flowspec adoption would be nice, and better
> anti-spoofing. But on the anti-spoofing point, I think the need for
> attackers to spoof IPs will go down in the coming years so I think this
> prevention mechanism drop in priority (this is an unfounded gut feeling,
> nothing backed by data)
>
> Cheers,
> James._______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/EKRDNYEGFT7KDPEIN6A3X5RO75PXG477/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/LH3PP53TQ25XBBDHDCX46HXOEKRNDAT4/