Considering that this is the second time in less than a week that a company has had their domain taken off line at the Registrar level (https://techcrunch.com/2026/07/14/telegrams-shortlink-domain-is-back-online-...) I do think there is a legitmate technical concern here, though I'd argue it is far from new. It is a scenario that most companies don't account for, but depending on the type of business you are in, it is a very real concern and you should have a response plan in place. allan On Sunday, July 19th, 2026 at 9:08 AM, Andy Ringsmuth via NANOG <nanog@lists.nanog.org> wrote:

Can we keep politics and personal opinions separate and independent of the technical aspects of the issue at hand (if there are any)? Per the NANOG list info page:

"Appropriate topics include: routing; broad-based engineering problems/issues/solutions; outages; performance measurement; evolving wide-area technologies; exchange points; traffic engineering; operational experience; ISP security; and trouble ticket systems."

Is there an actual legit technical issue here that needs discussion or solving?

---- Andy Ringsmuth andy@andyring.com

Love others, encourage others, help others.

...

On Jul 19, 2026, at 6:05 AM, Kevin Tillery via NANOG <nanog@lists.nanog.org> wrote:

A Texas court has suspended the .com domain of a Dutch porn site which doesn't have any business presence in Texas, because it doesn't comply with Texas rules about porn (which are extremely onerous):

https://www.texasattorneygeneral.gov/news/releases/attorney-general-ken-paxt...

Clearly the US is not fit to manage top-level domains (other than .us of course) even though it ended up with them by historical accident. It worked for a while but now it's not working any more. Has anyone come up with any plan to solve this and make the DNS more neutral?

As a first step I'd think about experimenting with a DNS resolver that would move all US TLDs to subdomains of .us. However that obviously would just break the current internet for whoever is using this resolver, at least due to widespread use of vhosts.

Kevin _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/55UTA3Q4...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EJC2UZCJ...

According to the press release, the domain was placed on registry lock by Verisign — it wasn’t done at the registrar. As Verisign is a US company, they probably assume it’s prudent to abide by court orders, so it shouldn’t be too much of a surprise. The Telegram case is a bit more interesting given DomainME (registry, not registrar) is, according to the TechCrunch article, Montenegro-based. This demonstrates that US OFAC sanctions have extra-territorial reach (or perhaps Montenegro has imposed the same sanctions that the US did?). Again, shouldn’t be too much of a surprise, but it often is. Regards, -drc

On Jul 19, 2026, at 6:37 AM, Allan Liska via NANOG <nanog@lists.nanog.org> wrote:

Considering that this is the second time in less than a week that a company has had their domain taken off line at the Registrar level (https://techcrunch.com/2026/07/14/telegrams-shortlink-domain-is-back-online-...) I do think there is a legitmate technical concern here, though I'd argue it is far from new.

It is a scenario that most companies don't account for, but depending on the type of business you are in, it is a very real concern and you should have a response plan in place.

allan On Sunday, July 19th, 2026 at 9:08 AM, Andy Ringsmuth via NANOG <nanog@lists.nanog.org> wrote:

...

Can we keep politics and personal opinions separate and independent of the technical aspects of the issue at hand (if there are any)? Per the NANOG list info page:

"Appropriate topics include: routing; broad-based engineering problems/issues/solutions; outages; performance measurement; evolving wide-area technologies; exchange points; traffic engineering; operational experience; ISP security; and trouble ticket systems."

Is there an actual legit technical issue here that needs discussion or solving?

---- Andy Ringsmuth andy@andyring.com

Love others, encourage others, help others.

...

On Jul 19, 2026, at 6:05 AM, Kevin Tillery via NANOG <nanog@lists.nanog.org> wrote:

A Texas court has suspended the .com domain of a Dutch porn site which doesn't have any business presence in Texas, because it doesn't comply with Texas rules about porn (which are extremely onerous):

https://www.texasattorneygeneral.gov/news/releases/attorney-general-ken-paxt...

Clearly the US is not fit to manage top-level domains (other than .us of course) even though it ended up with them by historical accident. It worked for a while but now it's not working any more. Has anyone come up with any plan to solve this and make the DNS more neutral?

As a first step I'd think about experimenting with a DNS resolver that would move all US TLDs to subdomains of .us. However that obviously would just break the current internet for whoever is using this resolver, at least due to widespread use of vhosts.

Kevin _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/55UTA3Q4...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EJC2UZCJ...

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FARPULLL...

This is indeed. Politics has an annoying tendency to cause technical problems, the current one being how to protect the DNS from political attack. There's nothing new about this - TLS became ubiquitous because of the Snowden leaks. Nobody said "get this TLS talk off my list because it's political" That's why I'm asking if there's something similar people can do to secure DNS? Probably not at the moment and certainly not easily? Although since it isn't about routing I'm not fully sure it's on-topic for NANOG and might be better suited for somewhere like IETF? Kevin On 19 July 2026 18:05:29 CEST, Jay Acuna via NANOG <nanog@lists.nanog.org> wrote:

On Sun, Jul 19, 2026 at 8:08 AM Andy Ringsmuth via NANOG <nanog@lists.nanog.org> wrote:

...

"Appropriate topics include: routing; broad-based engineering problems/issues/solutions; outages; performance measurement; evolving wide-area technologies; exchange points; traffic engineering; operational experience; ISP security; and trouble ticket systems."

The technical issue would be susceptibility of All database to tampering by any authorities who hold legal supremacy/jurisdiction over whichever person(s) or organizations are responsible for specific TLDs, or even the actual org responsible for that registry, for any reason, against the wishes of the domain holder.

Even if the domain holder exists outside that jurisdiction or can legally operate under different rules.

While this can be a serious technical issue; I don't believe there is anything network operators can do about it. You could consider distributed alternatives such as IPNS of the IPFS protocol a cryptographic-based name system, Tor hidden services, etc.

Your best option might be to register your own domains under multiple ccTLDs while ensuring that there is no overlap amongst the registry operators or registrars between any of the chosen TLDs and domains.

...

Andy Ringsmuth -- -JA

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LZL2ZERU...

From: Barry Greene <bgreene@senki.org>

Please take this to ICANN. This is not a technical issue. If you are a business in anywhere in the world who knowingly ignores legal request for other parts of the world _AND_ ignore the “bottom up” community driven ICANN governance processes, then you are an idiot.

just wow!

Clearly the US is not fit to manage top-level domains (other than .us of course) even though it ended up with them by historical accident. It worked for a while but now it's not working any more

The US Department of Justice decided that they could seize any .com domain back in 2012, and have done so with ever-increasing frequency since. Heck, they are flexing literally today by seizing 1,000 more that were streaming World Cup matches. It's news to me that a state court issued a ruling to seize something, but I'm sure it's happened before. The cat has long been out of the bag here. On Sun, Jul 19, 2026 at 7:06 AM Kevin Tillery via NANOG < nanog@lists.nanog.org> wrote:

A Texas court has suspended the .com domain of a Dutch porn site which doesn't have any business presence in Texas, because it doesn't comply with Texas rules about porn (which are extremely onerous):

https://www.texasattorneygeneral.gov/news/releases/attorney-general-ken-paxt...

Clearly the US is not fit to manage top-level domains (other than .us of course) even though it ended up with them by historical accident. It worked for a while but now it's not working any more. Has anyone come up with any plan to solve this and make the DNS more neutral?

As a first step I'd think about experimenting with a DNS resolver that would move all US TLDs to subdomains of .us. However that obviously would just break the current internet for whoever is using this resolver, at least due to widespread use of vhosts.

Kevin _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/55UTA3Q4...

It appears that Eliot Lear via NANOG <nanog@lists.nanog.org> said:

If people want to get away from country ownership, there is a somewhat experimental approach called GNU Name service.  See RFC 9498.  I don't pretend that this is a replacement for the current system, but if anyone wants to get to that replacement, maybe it's worth a read.

It's interesting up to a point, but it has the same scaling issues of any blockchain, or for that matter, of HOSTS.TXT. R's, John

Eliot

On 20.07.2026 02:26, Randy Bush via NANOG wrote:

...

...

A Texas court has suspended the .com domain of a Dutch porn site which doesn't have any business presence in Texas, because it doesn't comply with Texas rules about porn (which are extremely onerous):

https://www.texasattorneygeneral.gov/news/releases/attorney-general-ken-paxt...

Clearly the US is not fit to manage top-level domains (other than .us of course) even though it ended up with them by historical accident. It worked for a while but now it's not working any more. Has anyone come up with any plan to solve this and make the DNS more neutral? first, this is far from new. and it is both a technical and political problem.

the dns is hierarchic, i.e. control is centralized. and centralization and hierarchy are foci for 'attacks'. but be patient, deleg is gonna solve everything :) ...

On Sun, Jul 19, 2026 at 4:05 AM Kevin Tillery via NANOG <nanog@lists.nanog.org> wrote:

A Texas court has suspended the .com domain of a Dutch porn site which doesn't have any business presence in Texas, because it doesn't comply with Texas rules about porn (which are extremely onerous):

https://www.texasattorneygeneral.gov/news/releases/attorney-general-ken-paxt...

Clearly the US is not fit to manage top-level domains (other than .us of course) even though it ended up with them by historical accident. It worked for a while but now it's not working any more. Has anyone come up with any plan to solve this and make the DNS more neutral?

Hi folks, Here's my take on the matter: First, the law impacts network operations. Just as the "wild west" was tamed, the law's long arm will reach us more and more. So long as we can stay focused on the operational issues, I think that discussion is fair game here. And I think that includes discussing how we, as engineers, would like the law to evolve to better support network operations. Regarding the specific incident: .com is operated by a U.S. company and the web site operator (Kick) was sued in a U.S. court. If you want to continue doing business with a U.S. company, directly or indirectly, you can't ignore lawsuits in U.S. court. You have to respond. If you don't, the "prima facie" case goes unrebutted as do the proposed remedies. This is not unique to the United States. No matter which flag the .com operator flies, .com registrants will have to answer legal challenges in that flag's jurisdiction. Had Kick availed themselves of the U.S. legal process, the first thing they'd have done would have been to have the case removed from Texas court to Federal court. Paxton's case would likely have fallen apart from there. Kick didn't and "default judgements" bite hard. That said, I think it's an operational problem that federal law does not require orders compelling action from _TLD domain operators_ to go through federal court, regardless of the outcome of a state or local level case. The TLD operator is fundamentally international in scope. Under the U.S. legal system things that are fundamentally international in their nature are supposed to be exclusively in Federal jurisdiction. Am I wrong? Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/

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 a few include:

* Not all networks support RTBH. * Networks that do support RTBH implement it differently to each other. * There is no one place where one can easily find the info for how to use RTBH with a given network. * Operators have different ideas about how / when / where / why someone should / shouldn't use RTBH.

To this end, below is the first of two surveys. This first one is quantitative 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 own network (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-e...

(^ No login required)

The data ends up in this public repository (you can of course make a pull request directly if you want): https://remotely-triggered-black-hole.github.io/rtbh/

The second survey will be qualitative, to gather information from the industry 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 in to 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 and help, it is appreciated.

With kind regards, James_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LOWUU7RH...

-- ++ytti

Hi all, 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. Simultaneously we need to push harder to adopt uRPF to prevent spoofed attacks. Kind Regards, Dominik Dobrowolski On Mon, Jul 27, 2026 at 10:16 James Bensley via NANOG <nanog@lists.nanog.org> 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._______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FOLCSZM5...

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.

* 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/EKRDNYEG...

RTBH is absolutely used to thwart DDOS attacks right now in production at 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 witnessed this 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 a few

include:

...

* Not all networks support RTBH. * Networks that do support RTBH implement it differently to each other. * There is no one place where one can easily find the info for how to

...

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

To this end, below is the first of two surveys. This first one is quantitative 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 own network (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-e...

(^ No login required)

The data ends up in this public repository (you can of course make a

use RTBH with a given network. pull request directly if you want): https://remotely-triggered-black-hole.github.io/rtbh/

...

The second survey will be qualitative, to gather information from the

industry 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 in to 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 and help,

it is appreciated.

...

With kind regards, James_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LOWUU7RH...

-- ++ytti _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ITDOCC6N...

On Mon, Jul 27, 2026 at 3:48 PM Anne P. Mitchell, Esq. via NANOG <nanog@lists.nanog.org> wrote:

Bill is correct that they should have *removed* it to federal court. Ignoring it was about the most stupid thing they could do, as, again with a nod to Bill, when you default you lose by, well, default.

Hi Anne, My concern, and this is where I think the law could stand improvement, is that the court co-opted a distant third party in its remedy for the dispute. They interfered with a contract between Verisign and one of its registrars, neither of which was a party to the lawsuit about Kick's behavior, neither of which was accused of any wrongdoing, and neither of which was more than tenuously operating within the court's geographical jurisdiction. That doesn't seem like something the law should allow, at least not of a state court. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/

Greetings! Mentions of RTBH or Bogons is like the Bat-signal for us at Team Cymru… In the world outside of Tier 1s, RTBH is one of a few DDOS mitigation techniques that a provider can utilize. Budgets are tight or get eaten up by other priorities so ISPs and enterprise networks have to rely on what their upstream provides in the free-99 realm. I haven’t heard of an upstream provider not offering RTBH (although I am sure it happens). UTRS was the braind-child of JTK and it is still running strong at TC. We see multiple signups weekly. It is a distributed RTBH model, so the null-route is handled by the entire community, not just the immediate upstream of the victim network, and it does support flowspec. Is it perfect or will it replace a scrubber? No, nor was it intended to. But it's efficacy grows with more adoption by larger networks. We will be rolling out some new features later this year so please stay-tuned! https://www.team-cymru.com/ddos-mitigation-utrs-services Thanks, Scott

On Jul 27, 2026, at 5:14 PM, David Bass via NANOG <nanog@lists.nanog.org> wrote:

RTBH is absolutely used to thwart DDOS attacks right now in production at 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 witnessed this 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 a few

include:

...

* Not all networks support RTBH. * Networks that do support RTBH implement it differently to each other. * There is no one place where one can easily find the info for how to

...

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

To this end, below is the first of two surveys. This first one is quantitative 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 own network (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-e...

(^ No login required)

The data ends up in this public repository (you can of course make a

use RTBH with a given network. pull request directly if you want): https://remotely-triggered-black-hole.github.io/rtbh/

...

The second survey will be qualitative, to gather information from the

industry 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 in to 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 and help,

it is appreciated.

...

With kind regards, James_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LOWUU7RH...

-- ++ytti _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ITDOCC6N...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KH6VPK6D...

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 production at 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 witnessed this 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 a few include:

* Not all networks support RTBH. * Networks that do support RTBH implement it differently to each other. * There is no one place where one can easily find the info for how to use RTBH with a given network. * Operators have different ideas about how / when / where / why someone should / shouldn't use RTBH.

To this end, below is the first of two surveys. This first one is quantitative 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 own network (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-e...

(^ No login required)

The data ends up in this public repository (you can of course make a pull request directly if you want): https://remotely-triggered-black-hole.github.io/rtbh/

The second survey will be qualitative, to gather information from the industry 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 in to 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 and help, it is appreciated.

With kind regards, James_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LOWUU7RH...

-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ITDOCC6N...

-- ++ytti

Suggesting to replace RTBH with flowspec will not be marketable, many people, rightly, are worried about flowspec, because it has a huge bug surface and some serious design mistakes and implementation mistakes which make it poor fit for environments which lack in trust. Replacing blackhole community with QoS downgrade community is much more marketable in comparison, and infact one large tier1 used to offer this on a beta basis maybe 15-20 years ago. Sadly it is not commonly available. On Tue, 28 Jul 2026 at 11:15, Barry Greene <bgreene@senki.org> wrote:

Suggestion …. Walk through the APRICOT 2022 talks with DDoS.

[image: hqdefault.jpg]

APRICOT 2022 - DDoS Resiliency Workshop <https://www.youtube.com/playlist?list=PLTAhO9aX5q8X5IS9M3m4fLtvQdjBp1UZ0> youtube.com <https://www.youtube.com/playlist?list=PLTAhO9aX5q8X5IS9M3m4fLtvQdjBp1UZ0> <https://www.youtube.com/playlist?list=PLTAhO9aX5q8X5IS9M3m4fLtvQdjBp1UZ0>

What I’m seeing in this conversation is the missing tools in the DDoS Toolkit that get integrated into DDoS playbooks.

RTBH was just the first element. We then had sRTBH when we created loose uRPF. Then we taught peers how to take dRTBH and sRTBH and redirect traffic to a network sinkhole set up to track the attacks once redirected. Then we had BGP community-based rate limiting. Chris Morrow (UUNET) and Job Snijders (NTT) then set up customer-based RTBH - where you, as a customer, can set up a BGP community and have it blocked at your upstream edge (giving you space to work the attack).

Then we had work at Cisco and Arbor on industry-wide mitigation approaches. This would take time, so Flow-Spec was created as a stopgap. That Cisco/Arbor work was migrated into DOTS in the IETF.

Listen to the sessions, especially the interviews.

-- ++ytti

RTBH certainly has its place in the toolbox for DDoS mitigation but it is a bit of a hammer. Flowspec can be used to simply remark traffic into scavenger and on their own network many do that today. But like you mention the ability to put more granular guardrails on what gets accepted from others else isn’t really baked into the standards. FS can have more complex resource implications. You create a FS policy that has 6 match conditions and it will take up a lot more TCAM space. There were also some highly publicized outages caused by it early on when people did try using it downstream->provider. Maybe orthogonal but I had a question from an operator recently about validating RTBH prefixes from a downstream. They were being asked to simply accept anything based on a AS path check. I would assume most are using strict prefix lists. I saw the recent thread about using ROA as a check but that has some hurdles without config knobs or tricks to relax constraints. Phil From: Saku Ytti via NANOG <nanog@lists.nanog.org> Date: Tuesday, July 28, 2026 at 3:23 AM To: Barry Greene <bgreene@senki.org> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Saku Ytti <saku@ytti.fi> Subject: Re: RTBH Support Across the Industry Suggesting to replace RTBH with flowspec will not be marketable, many people, rightly, are worried about flowspec, because it has a huge bug surface and some serious design mistakes and implementation mistakes which make it poor fit for environments which lack in trust. Replacing blackhole community with QoS downgrade community is much more marketable in comparison, and infact one large tier1 used to offer this on a beta basis maybe 15-20 years ago. Sadly it is not commonly available. On Tue, 28 Jul 2026 at 11:15, Barry Greene <bgreene@senki.org> wrote:

Suggestion …. Walk through the APRICOT 2022 talks with DDoS.

[image: hqdefault.jpg]

APRICOT 2022 - DDoS Resiliency Workshop <https://www.youtube.com/playlist?list=PLTAhO9aX5q8X5IS9M3m4fLtvQdjBp1UZ0> youtube.com <https://www.youtube.com/playlist?list=PLTAhO9aX5q8X5IS9M3m4fLtvQdjBp1UZ0> <https://www.youtube.com/playlist?list=PLTAhO9aX5q8X5IS9M3m4fLtvQdjBp1UZ0>

What I’m seeing in this conversation is the missing tools in the DDoS Toolkit that get integrated into DDoS playbooks.

RTBH was just the first element. We then had sRTBH when we created loose uRPF. Then we taught peers how to take dRTBH and sRTBH and redirect traffic to a network sinkhole set up to track the attacks once redirected. Then we had BGP community-based rate limiting. Chris Morrow (UUNET) and Job Snijders (NTT) then set up customer-based RTBH - where you, as a customer, can set up a BGP community and have it blocked at your upstream edge (giving you space to work the attack).

Then we had work at Cisco and Arbor on industry-wide mitigation approaches. This would take time, so Flow-Spec was created as a stopgap. That Cisco/Arbor work was migrated into DOTS in the IETF.

Listen to the sessions, especially the interviews.

-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OANHMCEU...

On Tue, 28 Jul 2026 at 16:40, Phil Bedard <bedard.phil@gmail.com> wrote:

Flowspec can be used to simply remark traffic into scavenger and on their own network many do that today. But like you mention the ability to put more granular guardrails on what gets accepted from others else isn’t really baked into the standards. FS can have more complex resource implications. You create a FS policy that has 6 match conditions and it will take up a lot more TCAM space. There were also some highly publicized outages caused by it early on when people did try using it downstream->provider.

We are just now looking into FS for an internal use-case, and the person testing the solution immediately got bitten by a customer affecting bug, they weren't trying to break it, they were just trying to make it work. So it still is fragile in 2026. I personally think it was implemented wrong, it should have had a route-target (or filter-target, filter-name, etc community) and by default it does absolutely nothing, until you attach said filter name somewhere in some direction in some way. The basic principle that it sits as a forwarding-plane filter is pretty insane to me, I guess some features community wants depend on ingres lookup happening, so it cannot always appear as ingress filter, but we should have given option do we associate it to given interface or as forwarding-filter with post-lookup keys. Like in Junos parleance filter could be term blaablaa { then { next filter flow-spec-filter microsoft; } } Part of your own filter, which you attach along with other terms in some interface in some direction. -- ++ytti

On Jul 27, 2026, at 5:47 PM, William Herrin <bill@herrin.us> wrote:

On Mon, Jul 27, 2026 at 3:48 PM Anne P. Mitchell, Esq. via NANOG <nanog@lists.nanog.org> wrote:

...

Bill is correct that they should have *removed* it to federal court. Ignoring it was about the most stupid thing they could do, as, again with a nod to Bill, when you default you lose by, well, default.

Hi Anne,

My concern, and this is where I think the law could stand improvement, is that the court co-opted a distant third party in its remedy for the dispute. They interfered with a contract between Verisign and one of its registrars, neither of which was a party to the lawsuit about Kick's behavior, neither of which was accused of any wrongdoing, and neither of which was more than tenuously operating within the court's geographical jurisdiction. That doesn't seem like something the law should allow, at least not of a state court.

Hi Bill! Unfortunately as it stands the remedy for this is for Verisign and/or the impacted registrar to..you got it..sue. They might have been able to file a motion to be joined as a non-party (with a third-party interest) while the suit was live, if they knew about it. Anne -- Anne P. Mitchell, Esq. Internet Law & Policy Attorney, Legislative Advisor Author: Section 6 of the CAN-SPAM Act of 2003 CEO Institute for Social Internet Public Policy Originator of the term 'deliverability'; Co-Founder of the deliverability industry Author: The Email Deliverability Handbook Board of Directors, Denver Internet Exchange Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School Prof. Emeritus, Lincoln Law School Chair Emeritus, Asilomar Microcomputer Workshop Counsel Emeritus, eMail Abuse Prevention System (MAPS)

Yes it is possible in JunOS and BIRD both, JunOS with some hackery. I’m talking about formally supported knobs from the big vendors. If you’re interested in the feature request IDs I’ve submitted to Juniper/HPE and Cisco I’m happy to provide those off-list, or you can see them in my NANOG 98 slides in a few months. -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Tue, Jul 28, 2026 at 2:23 PM Saku Ytti <saku@ytti.fi> wrote:

On Tue, 28 Jul 2026 at 19:58, Bryton Herdes via NANOG <nanog@lists.nanog.org> wrote:

...

I’ve went back and forth on solutions for RTBH, and my latest opinion is vendors should implement a separate knob to bypass maxLength checking for specifically routes tagged as BLACKHOLE, and still validate origin AS via RPKI-ROV. The risk of operators using such a knob in “a bad way” is known, but we need this tool. Let’s talk about this more at NANOG 98.

Yes. And this is possible today on Junos, as Martin Tonusoo shared in this list (not this thread) earlier.

-- ++ytti

On Tue, Jul 28, 2026 at 12:57:42PM -0400, Bryton Herdes via NANOG wrote:

My number one problem with RTBH today is a lack of route origin validation.

... and then you outline a plan to bypass route origin validation??? :-) (I'm being pedantic, a critical component of the RFC 6811 validation process is checking maxLength!)

I’ve went back and forth on solutions for RTBH, and my latest opinion is vendors should implement a separate knob to bypass maxLength checking for specifically routes tagged as BLACKHOLE, and still validate origin AS via RPKI-ROV. The risk of operators using such a knob in “a bad way” is known, but we need this tool.

Can you qualify in what kind of situation this would be "not bad"? Isn't the risk inherit to this kind of knob precisely that operators use the knob to by pass maxLength checking? Almost sounds similar the risks associated with setting & using default passwords? :-) The global deployment of RPKI ROAs & validation brought us is an ability to signal at scale "do not accept more-specific-than-X", this is super useful because the most painful hijacks are the more-specific hijacks: more-specifics win the traffic. I'm concerned about erosion of this property.

Separately and most related to this thread, we shouldn’t encourage aggressively for more networks to support RTBH until we have solved the routing security problem with these route types. It is counterproductive to make the RTBH hijack surface area even larger than it already is.

Makes sense. As it stands RTBH is a pain in the rear. Kind regards, Job

On 29/07/2026 12:32, Bryton Herdes via NANOG wrote:

My interest is the same as yours in needing to preserve maxLength protection properties, but I do find value in being able to bypass the maxLength for BLACKHOLE routes specifically. I see it as the simplest solution if implemented with some belts and braces. We can’t prevent people from deliberately doing silly things like a full bypass for all routes, but we can make it difficult to do so, noting if someone tried hard enough they could already do it in some platforms. +1 on this.

If people want to take off their seatbelts they can already do this by completely skipping ROV in their policies, which is what is currently happening with RTBH routes. Kind regards, Martin

I would imagine most intentional hijacks are looking to do something with the traffic beyond merely blocking it, and those who intent to block it likely have the power to compel the isp's near them to accept their routes overriding any and all filtering (government censorship type hijacks). A hijack using the black-hole community would not lead to see any any traffic as the network accepting the longer prefix for black-holing would black-hole the traffic. I'm also not convinced that such a knob and keeping max length shorter doesn't prevent certain unintentional hijacks, see badly configured route optimizers, yes, those shouldn't ever leak routes and such routes should be such that other networks would not accept them if they did, but we all know how that works in practice. It also seems like not having such overrides would lead to max length being completely useless, almost every rtbh route I've seen was a /32 in ipv4, if everyone set's their maxlength to 32 well why even have the field? I think filtering rtbh on a customer cone or through clearinghouses that filter and only accept tightly scoped routes like I seem to recall team cmyu does is the norm, and so it also should be easier to validate origin AS, especially as most of the time I feel like they only end up making it one or two hops up the AS chain at most, though I may be completely wrong about how that works elsewhere. I also wonder if such a knob may provide a safer option for some other use cases, mostly related to traffic engineering which links with an upstream receive which traffic via longer than dfz acceptable prefixes, I'm betting that currently most connections that accept those bypass roa checks for that completely, where this would allow for only relaxing the roa validation, which feels safer to me in case of an edge case or mistake in the configuration. On 7/29/2026 12:46 PM, James Bensley via NANOG wrote:

On Wednesday, July 29th, 2026 at 11:37, Job Snijders via NANOG <nanog@lists.nanog.org> wrote:

...

On Tue, Jul 28, 2026 at 12:57:42PM -0400, Bryton Herdes via NANOG wrote:

...

My number one problem with RTBH today is a lack of route origin validation.

...

... and then you outline a plan to bypass route origin validation??? :-)

I was formerly of the opinion that such a knob from vendors was a good idea, but I've been thinking it over recently and I've changed my mind. I think we shouldn't be going down this road. Sorry for the length, but to understand why we have to go back to the start.

I think the important question is: what do we want to protect against?

1. Misconfigurations / misoriginations (the origin AS doesn't match the ROA) 2. Intentional origin hijacks (attacker fakes the origin AS to match the ROA)

I think this is important for two reasons:

A. ROAs validate who *MAY* originate a prefix, they don't validate who *IS* originating a prefix. ASPAs validate which ASNs *MAY* forward a BGP announcement, they don't validate which ASNs *ARE* forwarding it. Therefore ROAs and ASPAs can only protect against (1). To protect against (2) we need something which cryptographically validates the AS_PATH attribute (like BGPsec or SCION or similar), but we don't have anything like that widely available today.

B. IMO >95% of the routing issues we want to stop are due to misconfigurations/accidents, whereas intentional hijacks only account for a fraction of the issues. I'm not saying that intentional hijacks don't happen or aren't important, I'm saying we don't have the tools to fight them yet, and they are the exception. But we do have the tools to fight the common case, so let's use those tools to fight the common case in the most effective way, and not try to bend them to also fight the corner case.

A key argument for this knob is that a longer maxLength risks intentional hijacks. Because ROAs can't protect against intentional origin hijacks, we're only interested in whether the BGP route origin matches the ROA origin, if it doesn't match then the maxLength has no bearing here (only when the two match). So the conventional wisdom of "a longer maxLength risks hijacks" is not true, because ROAs don't protect against intentional hijacks, only against misoriginations, and in this latter case the maxLength actually plays no role.

So if we're just protecting against misoriginations, then IMO the prefix owner should be the one setting their ROA maxLength to include longer prefixes, *iff* they are someone that uses RTBH or a similar service.

If we add a knob to ignore maxLength, several bad things happen, which don't happen if instead the prefix owner increases their maxLength iff required:

* Every network which implements this knob now ignores my maxLength, even though I know best for my prefixes. And not just for my prefixes, for *the entire DFZ*. The prefix length decision has been taken away from the very people who know best.

* This is something which will be implemented opaquely; most networks don't publicly document their BGP filtering policy, and most networks don't have a public looking glass, but now that networks will start accepting prefixes more specific than my ROA permits if the RTBH community is attached. But there is no way to see if this is happening, or know why it's happening, and I *explicitly signalled* in my ROA that this should not be happening. Troubleshooting this will be a nightmare.

* I'm a hijacker; I announce a more specific prefix than the ROA's maxLength, with a forged origin to match the ROA, with the RTBH community attached; my hijack will be more widely accepted *because of this knob* than if it didn't have the RTBH community attached, because without the RTBH community it would fail the maxLength check. So this knob actually makes sub-prefix origin hijacks attacks more damaging.

* Even if I announce someone else's prefix and fake the origin, but stick to the maxLength of their ROA, and the owner is also announcing the same prefix + length + origin (two competing routes); for most networks this will be absolutely devastating. The presence of a competing route doesn't provide protection against intentional origin hijacks that are ROA valid due to maxLength. The reason is that apart from the top ~20 most interconnected networks on bgp.tools, the average network is not that well connected and thus my equal length intentional hijack will win in many networks (especially if I'm in a different part of the world to the victim, my route will very likely win in all the networks in my region).

Now let's consider increasing the maxLength on ROAs to support RTBH:

* "Intentional origin hijacks are now easier"; no, there is no change here due to the lack of verification of the AS_PATH attribute, also see my point above about hijacks of an equal length prefix, you don't even need to hijack a more specific to completely hijack the traffic for a prefix.

* We no longer have to skip ROA validation and fall back to IRR based validation (which helps with deprecating IRR based filters).

* We don't make more specific hijacks more effective when they are tagged as RTBH routes.

* As the ROA owner I remain in control of how my prefixes are validated.

I think the best way to validate RTBH routes might be maxLength + ASPA + RFC9234 (i.e., the same way as we plan to validate non-RTBH routes).

Cheers, James. (Again, sorry for the length)

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q2GYREV3...

-- Glenn McGurrin Principal Cloud Optimized SMB LLC Direct: (703) 434-3922 Toll Free: (866) 644-7363 Fax: (703) 439-1636

Every network which implements this knob now ignores my maxLength, even

James, though I know best for my prefixes. And not just for my prefixes, for *the entire DFZ*. The prefix length decision has been taken away from the very people who know best. Just for RTBH, yes, is the proposal. As far as I know, this is already how BLACKHOLE route filtering is being done -- allow upto /32 (or strictly /32's) within covering routes from customers from expanded AS-SET+route/route6. Using ROAs instead of IRR data causes no regression in functionality. Instead, it's an improvement adding originAS-checking versus the status quo.

Now let's consider increasing the maxLength on ROAs to support RTBH

In the conversations I've had regarding RTBH and RPKI, network operators want to abide by the guidance in RFC9319 by signing "minimal ROAs" for prefixes expected to propagate throughout the DFZ. However, they have a different intent for RTBH as a directly-network-adjacent "filtering signal" in BGP. Operators don't want to increase the attack surface area for sub-prefix hijacks by authorizing RTBH routes. A fully separate intent would need something like a DOA and years of adoption (repeat of ROA, for RTBH): https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-doa/ This is why I feel the happy-medium is still a maxLength bypass for RTBH. It just needs implemented in a way that doesn't encourage a bypass for all routes. Repeating myself here, I encourage folks to bring some more discussion to NANOG 98: https://nanog.org/events/nanog-98/content/5843/ as we work on solving this tricky problem. Thanks, -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Wed, Jul 29, 2026 at 12:47 PM James Bensley via NANOG < nanog@lists.nanog.org> wrote:

On Wednesday, July 29th, 2026 at 11:37, Job Snijders via NANOG < nanog@lists.nanog.org> wrote:

...

On Tue, Jul 28, 2026 at 12:57:42PM -0400, Bryton Herdes via NANOG wrote:

...

My number one problem with RTBH today is a lack of route origin validation.

...

... and then you outline a plan to bypass route origin validation??? :-)

I was formerly of the opinion that such a knob from vendors was a good idea, but I've been thinking it over recently and I've changed my mind. I think we shouldn't be going down this road. Sorry for the length, but to understand why we have to go back to the start.

I think the important question is: what do we want to protect against?

1. Misconfigurations / misoriginations (the origin AS doesn't match the ROA) 2. Intentional origin hijacks (attacker fakes the origin AS to match the ROA)

I think this is important for two reasons:

A. ROAs validate who *MAY* originate a prefix, they don't validate who *IS* originating a prefix. ASPAs validate which ASNs *MAY* forward a BGP announcement, they don't validate which ASNs *ARE* forwarding it. Therefore ROAs and ASPAs can only protect against (1). To protect against (2) we need something which cryptographically validates the AS_PATH attribute (like BGPsec or SCION or similar), but we don't have anything like that widely available today.

B. IMO >95% of the routing issues we want to stop are due to misconfigurations/accidents, whereas intentional hijacks only account for a fraction of the issues. I'm not saying that intentional hijacks don't happen or aren't important, I'm saying we don't have the tools to fight them yet, and they are the exception. But we do have the tools to fight the common case, so let's use those tools to fight the common case in the most effective way, and not try to bend them to also fight the corner case.

A key argument for this knob is that a longer maxLength risks intentional hijacks. Because ROAs can't protect against intentional origin hijacks, we're only interested in whether the BGP route origin matches the ROA origin, if it doesn't match then the maxLength has no bearing here (only when the two match). So the conventional wisdom of "a longer maxLength risks hijacks" is not true, because ROAs don't protect against intentional hijacks, only against misoriginations, and in this latter case the maxLength actually plays no role.

So if we're just protecting against misoriginations, then IMO the prefix owner should be the one setting their ROA maxLength to include longer prefixes, *iff* they are someone that uses RTBH or a similar service.

If we add a knob to ignore maxLength, several bad things happen, which don't happen if instead the prefix owner increases their maxLength iff required:

* Every network which implements this knob now ignores my maxLength, even though I know best for my prefixes. And not just for my prefixes, for *the entire DFZ*. The prefix length decision has been taken away from the very people who know best.

* This is something which will be implemented opaquely; most networks don't publicly document their BGP filtering policy, and most networks don't have a public looking glass, but now that networks will start accepting prefixes more specific than my ROA permits if the RTBH community is attached. But there is no way to see if this is happening, or know why it's happening, and I *explicitly signalled* in my ROA that this should not be happening. Troubleshooting this will be a nightmare.

* I'm a hijacker; I announce a more specific prefix than the ROA's maxLength, with a forged origin to match the ROA, with the RTBH community attached; my hijack will be more widely accepted *because of this knob* than if it didn't have the RTBH community attached, because without the RTBH community it would fail the maxLength check. So this knob actually makes sub-prefix origin hijacks attacks more damaging.

* Even if I announce someone else's prefix and fake the origin, but stick to the maxLength of their ROA, and the owner is also announcing the same prefix + length + origin (two competing routes); for most networks this will be absolutely devastating. The presence of a competing route doesn't provide protection against intentional origin hijacks that are ROA valid due to maxLength. The reason is that apart from the top ~20 most interconnected networks on bgp.tools, the average network is not that well connected and thus my equal length intentional hijack will win in many networks (especially if I'm in a different part of the world to the victim, my route will very likely win in all the networks in my region).

Now let's consider increasing the maxLength on ROAs to support RTBH:

* "Intentional origin hijacks are now easier"; no, there is no change here due to the lack of verification of the AS_PATH attribute, also see my point above about hijacks of an equal length prefix, you don't even need to hijack a more specific to completely hijack the traffic for a prefix.

* We no longer have to skip ROA validation and fall back to IRR based validation (which helps with deprecating IRR based filters).

* We don't make more specific hijacks more effective when they are tagged as RTBH routes.

* As the ROA owner I remain in control of how my prefixes are validated.

I think the best way to validate RTBH routes might be maxLength + ASPA + RFC9234 (i.e., the same way as we plan to validate non-RTBH routes).

Cheers, James. (Again, sorry for the length)_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q2GYREV3...