nanog mailing list archives
Re: RTBH Support Across the Industry
From: David Bass via NANOG <nanog () lists nanog org>
Date: Tue, 28 Jul 2026 08:33:03 -0500
It’s a part of a security response plan, and the more tools you have the better. 1. I don’t think this is the case, but more a question for the guys who deal with this. Definitely subjective. 2. I don’t agree with this statement, but for sure it depends on the infrastructure being attacked, and how resilient it is to attack. 3. This is true. 4. Also true Like I said, it’s a tool in the toolbox available for use. Is it the best option: depends on the situation. David On Tue, Jul 28, 2026 at 2:38 AM Saku Ytti <saku () ytti fi> wrote:
They David, Yes. We provide RTBH and I know it's being used. I'm asking if it's desirable. Reason why it might not be 1) It helps the attacker 2) It prolongs outage to last longer than actual attack 3) It removes observability 4) It is difficult to impossible to do right, for other than self-originated prefixes, i.e. transit provider protecting themselves from their downstream being attacked Using the BGP community to downgrade the traffic, rather than blackhole, would improve on all these metrics. On Tue, 28 Jul 2026 at 00:14, David Bass <davidbass570 () gmail com> wrote:RTBH is absolutely used to thwart DDOS attacks right now in productionat some extremely large, and constantly attacked organizations that I’ve personally seen.As far as use by attackers…possibly used as well, but haven’t witnessedthis one.David On Mon, Jul 27, 2026 at 2:50 AM Saku Ytti via NANOG <nanog () lists nanog org> 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? 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. On Mon, 27 Jul 2026 at 10:41, James Bensley via NANOG <nanog () lists nanog org> wrote:Dear Community, RTBH is not as effective as it could be, for various reason, just afew include:* Not all networks support RTBH. * Networks that do support RTBH implement it differently to eachother.* There is no one place where one can easily find the info for how touse RTBH with a given network.* Operators have different ideas about how / when / where / whysomeone should / shouldn't use RTBH.To this end, below is the first of two surveys. This first one isquantitative and captures how networks have implemented RTBH and provides (1) a public repository which anyone can use to look-up the RTBH details for their peers/upstreams, and (2) an insight into the (mis-)alignment of RTBH implementations across the industry.Please take the time to fill out the short survey for your ownnetwork (even if you don't support RTBH!), and if you can, please fill it out for other networks where you know how they have implemented RTBH (e.g., peers you use RTBH with): https://docs.google.com/forms/d/e/1FAIpQLScg2Bvr_14onOtZRdoK2SNd0kCHFtqsdw-elsO5miUAO-3zzg/viewform(^ No login required) The data ends up in this public repository (you can of course make apull request directly if you want): https://remotely-triggered-black-hole.github.io/rtbh/The second survey will be qualitative, to gather information from theindustry community on why you do / don't support RTBH, when do you use it, how do you think the routing should be secured, etc.The long term goal is to use the data from both surveys as input into a community effort to improve RTBH alignment across the industry and improve it's effectiveness for all (e.g. maybe produce a new BCOP for implementing RTBH, or usage guidelines for blackholing, or maybe a new RFC is required to secure the filtering; regardless, the first step is to gather data about the status quo and review that data to get a baseline of where we are at today).Any questions, please let me know, and thank you for your time andhelp, it is appreciated.With kind regards, James_______________________________________________ NANOG mailing listhttps://lists.nanog.org/archives/list/nanog () lists nanog org/message/LOWUU7RHOKTYKVGWRHNXQJ3GSJYN3HLE/-- ++ytti _______________________________________________ NANOG mailing listhttps://lists.nanog.org/archives/list/nanog () lists nanog org/message/ITDOCC6N5VELZ56F6ILVZODZSUWH3TNE/ -- ++ytti
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog () lists nanog org/message/LVZFGXNRMFYVBN3SURP6K7ITPB3GJEPY/
Current thread:
- Re: RTBH Support Across the Industry, (continued)
- Re: RTBH Support Across the Industry Saku Ytti via NANOG (Jul 28)
- Re: RTBH Support Across the Industry Bryton Herdes via NANOG (Jul 28)
- Re: RTBH Support Across the Industry Saku Ytti via NANOG (Jul 28)
- Re: RTBH Support Across the Industry Job Snijders via NANOG (Jul 29)
- Re: RTBH Support Across the Industry Bryton Herdes via NANOG (Jul 29)
- Re: RTBH Support Across the Industry Martin Pels via NANOG (Jul 29)
- Re: RTBH Support Across the Industry James Bensley via NANOG (Jul 29)
- Re: RTBH Support Across the Industry Glenn McGurrin via NANOG (Jul 29)
- Re: RTBH Support Across the Industry Bryton Herdes via NANOG (Jul 30)
- Re: RTBH Support Across the Industry Saku Ytti via NANOG (Jul 30)
- Re: RTBH Support Across the Industry David Bass via NANOG (Jul 28)
- Re: RTBH Support Across the Industry Saku Ytti via NANOG (Jul 28)
- Re: New DNS vulnerability: political overreach Anne P. Mitchell, Esq. via NANOG (Jul 27)
- Re: New DNS vulnerability: political overreach William Herrin via NANOG (Jul 27)
- Re: New DNS vulnerability: political overreach Tom Beecher via NANOG (Jul 27)
- Re: New DNS vulnerability: political overreach Anne P. Mitchell, Esq. via NANOG (Jul 28)
- Re: New DNS vulnerability: political overreach Tom Beecher via NANOG (Jul 28)
- Re: New DNS vulnerability: political overreach David Conrad via NANOG (Jul 28)
- Re: New DNS vulnerability: political overreach Tom Beecher via NANOG (Jul 28)
