Re: RTBH Support Across the Industry

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============8639997058943966524==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha512;
 boundary="------c07a94ee51e705973feb32935795858100c9f17cf85dcbd2a9b6c894ed210aad";
 charset=utf-8

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------c07a94ee51e705973feb32935795858100c9f17cf85dcbd2a9b6c894ed210aad
Content-Type: multipart/mixed;boundary=---------------------2e50d79c92d28d9aaf33856a6ea81156

-----------------------2e50d79c92d28d9aaf33856a6ea81156
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

On Monday, July 27th, 2026 at 10:26, Dominik Dobrowolski <dobrowolski.domi=
[email protected]> wrote:

> Hi all,

Hi Dominik

> Can=E2=80=99t we implement the natural successor to blackhole meaning bg=
p flowspec? It=E2=80=99s much better with modern attacks such as carpet-bo=
mbs, where attackers attack whole prefixes and we need a more surgical too=
l.

I think that in theory Flowspec is great, and using it internally within y=
our own network is also great. Across networks, is, "not ideal" to give th=
e political answer. I wish it was better but our operational experiences h=
as 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 Flowsp=
ec RFCs. Each vendor is implementing a slightly different set of features,=
 so there is a vendor diagram where only the most basic features are guara=
nteed 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 the=
m a route they can't 100% implement).

* Compression of Flowspec rules is different between vendors; you might se=
nd me one single Flowspec rule which contains a lot of options and prefixe=
s, 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 phe=
nomenon has two issues; firstly if we sell you X Flowspec filters/rules, w=
e 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 hundre=
ds or thousands of TCAM entries needs careful management (most vendors don=
't have rich BGP policy syntax for Flowspec filtering, some of the stuff w=
e do in RCF with Arista isn't documented in any Arista TOI).

* Virtually nobody accepts Flowspec rules; none of our upstreams or PNI pe=
ers support Flowspec. We are trying to get several IXPs to trial Flowspec =
with us, and they are slow burning conversations with no actual trials hap=
pening yet.

> Simultaneously we need to push harder to adopt uRPF to prevent spoofed a=
ttacks.

I agree with you that better Flowspec adoption would be nice, and better a=
nti-spoofing. But on the anti-spoofing point, I think the need for attacke=
rs to spoof IPs will go down in the coming years so I think this preventio=
n mechanism drop in priority (this is an unfounded gut feeling, nothing ba=
cked by data)

Cheers,
James.
-----------------------2e50d79c92d28d9aaf33856a6ea81156--

--------c07a94ee51e705973feb32935795858100c9f17cf85dcbd2a9b6c894ed210aad
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsG5BAEBCgBtBYJqZxrkCRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jn82bt4rHcIwZoYmKPI9jGTNttsOKCLfkGhqdL
fkMsr0wWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAn4AQAJ5b3Bw/yYALSwgp
aGxF1AObLIYR7Hz8iMhzz5Q2tjXB1vQrrrrXhJTduu42S6rdSEOEKP1CI84D
UUe1I37uaiwdRyPoO3FJuEnvSnvNUlGjovIQIZMXWnVsEvcbWEw6qiEXgWWB
7/lFxGEXKyuiVV3xwCBUQ0vEt57lcVovyTRh9YDPdF2RUk6CwtacAVe0n6Ug
OPe18/o3WBVl/PAfB+57mnizJh2GsKde3spyWt83bm2A1RxwwM+PKEGcaMEz
CdwuQ3lh+059Qp4rjlKPCPXDH1DetQyEODFH6oh5Wa+RvstIf6DwdrYyfuEY
hwO+84rhyEXUpxHa+sPO0IuQ8RwUSYL4y5rfckL2knl3dfycSkG5MX4p112e
EeVHnZj6eEo4rfDBFZ7GJUjE89dXC2ns2yjkusasw6l8neJcll+WzmywEYUv
5D3THveInrDb27R3j25q/E7M//99SNwEYKYY1tGJ4i0muIzvWJ510zQ5j6fB
osvDJuYYq84xyjnKT1yCOnIGYgXITD60EOsgzn0IlhDvEW5FB7Xb/MuqyKsS
sToVYoySosgeFRpJJZKWnq8ILappAIxiHRqKP4TiyfdvNiLVAU/4acevH8iQ
+Q94dCbWu2C+kc7q5fQ59DnkwytQ+Tb4d1SSiEVYePhHIHAKaZksPavLLLRa
UB2WJgXH
=v+Tq
-----END PGP SIGNATURE-----


--------c07a94ee51e705973feb32935795858100c9f17cf85dcbd2a9b6c894ed210aad--


--===============8639997058943966524==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/EKRDNYEGFT7KDPEIN6A3X5RO75PXG477/
--===============8639997058943966524==--