Re: RTBH Support Across the Industry

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------f3b4d2979b5ad62f444029adb8d3eb4a0ad647ff2d981107fa6478377b476144
Content-Type: multipart/mixed;boundary=---------------------96f8b8fee62ed722f30dd9b436a64fe8

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

Hey Saku,

On Monday, July 27th, 2026 at 09:49, Saku Ytti <[email protected]> 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 hav=
e you deployed it / why haven't you, what would you need for you to feel c=
omfortable deploying it, what's missing for observability, how should it b=
e secured, and so on). The two things are related but different, so I'm tr=
ying to gather them in two different surveys (2nd one after the summer bre=
ak).


>  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 stra=
tegy is.

Today we have elected to go the route of having a sacrificial edge port; u=
nder 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 witho=
ut 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 require=
s that networks have deployed QoS already (so that makes the barrier to en=
try 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 wit=
h limited technical skills and resources; whilst RTBH does "complete" the =
DDoS attack, you might be happy to just to blackhole that route to save th=
e 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.
-----------------------96f8b8fee62ed722f30dd9b436a64fe8--

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

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

wsG5BAEBCgBtBYJqZxO0CRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3JnOvUft8cAlQ9fnGt2wnnUqtHZZcz+l45s7GG8
dnEcwEgWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAFUgP/1DKzlyFjTysHdkK
ScmFeHPXcy4oyno30fEcaasEME5e73UPjoFiERiAbabwIOny92OlAbqeqW4D
6r2MLCK3DiZbSsgSsQONGo8Hp3jBEsumP/jUY8L8T6NsG/jtTC3mFTCZR3Di
4q8ORU5R/36lGLRAGf7D8NHdQX6gb914wBkQO0U95eNmi9WZJHUoxFyUeXHL
ahMX9Xz68Hc4PqDfogJPY+yzcFOI3KrjepvKdynoBcHWeCgbXkbCt262WRkX
mKAjnjvE0ae20dA6gFfKpfRVjbL+weaCvuQVKZJQg/hRLWCztQOhTPBl8ZIA
ueK4AKldzYaWMnkvg5+UAYxfvmeUkDRIuUFgfHvehU6WRZmnxFsKuUu/cxaU
GQOFzIhD6eyHIjOaifVtbWxOn0HHASJft1soS1cHmHNCWca55o+3DMwr2/D5
/I7pdB19Z1uPoQsuj9OCPo6ZmR8/oRYGVxv4/U6PLChUv3ES3kb+uWkTE86u
MK5xyuGWi0zkj3RBUd71nvZgAySVxNISpWWPNrvJXzgog2gXsa0J6ztiG6Ml
6xc2V3rJZm/WL2UuBK2+0R7jVdnbLVfY05aKM9deUEWsRWp/FbIaE5KAQzfg
sCL96tca5msa6R7sNOgxKbzSy1v+ZQTcu8Jz4DQ4eYlh6qK7DV0v/rjqV/AY
1AA3oxIU
=OrAu
-----END PGP SIGNATURE-----


--------f3b4d2979b5ad62f444029adb8d3eb4a0ad647ff2d981107fa6478377b476144--


--===============4523379800069726611==
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/FOLCSZM5I237XSVDRMZBYSMDM2XCJLSP/
--===============4523379800069726611==--