Great explanation. Thanks El El sáb, 8 ago. 2026 a la(s) 15:36, Job Snijders <job@bsd.nl> escribió:

Hi Salvador,

On Sat, Aug 08, 2026 at 01:47:17PM -0500, Salvador Bertenbreiter wrote:

...

A quick question for those using RTBH together with RPKI.

How do you handle /32 announcements in IPv4 or /128 in IPv6 when the prefix has a ROA with a maxLength of /24 or /48?

Implementing _safe_ RTBH is a bit tricky, it'll take some effort to set up properly. Sane blackholing requires some network automation. As you already noted violating (ignoring) the maxLength as denoted by the resource holder is a bit capricious, because more-specific and RTBH hijacks are real! So you gotta be careful not to accidentally create a weapon for others to misuse. Perhaps simplest to offer RTBH only to your direct customers, and not try to offer blackholing to customers of customers.

I think there are two angles to consider: reducing the scope of what IPs a neighbor AS is allowed to blackhole, and checking alignment with the forwarding path. I'll elaborate a bit on both.

### Reducing the scope

The idea here is that you only allow the customer to inject blackholes for space that they can originate. How to implement: you could construct an allowlist ('prefix-set' or 'route-filter') which allows the intersection between what is originated directly by the customer AS and what's covered by ROAs authorizing that same customer AS.

For example, if you'd like to offer RTBH capability to your customer AS15562 (let's use my own AS as example here), you could generate a filter like so:

$ bgpq4 -S RPKI -A -r 32 -R 32 -l AS15562-v4 AS15562 no ip prefix-list AS15562-v4-blackholes ip prefix-list AS15562 permit 67.221.245.0/24 ge 32 le 32 ip prefix-list AS15562 permit 165.254.225.0/24 ge 32 le 32 ip prefix-list AS15562 permit 165.254.255.0/24 ge 32 le 32 ...

And then a routing policy like so:

! ip as-path access-list 11 permit _15562$ ! ip community-list standard blackhole permit 65535:666 ! ip route 192.0.2.1 255.255.255.255 null 0 ! route-map ebgp-AS15562-in permit 10 match as-path 11 match community blackhole match ip address prefix-list AS15562-v4-blackholes set community no-export set ip next-hop 192.0.2.1 ! route-map ebgp-AS15562-in deny 20 match rpki invalid ! route-map ebgp-AS15562-in permit 30 match ip address prefix-list... ! regular allow filters go here ... etc ...

You'll have to refresh the 'AS15562-v4' prefix-list periodically. This is where the network automation comes in. I'd run something like bgpq4 every few hours and upload that into your routers.

### Checking alignment between the blackhole and the forwarding path

Another approach is far more involved, and not yet easily feasible on today's COTS BGP routers, but I think that from an operationals perspective the better approach would be that you'd able to match in routing policy on "does the best next less-specific come from the same peer-as or nexthop?".

The principle here would be that _if you were going to send packets to the neighboring AS / nexthop *anyway*_, then you consider them authorized to request you to discard the traffic. Ultimately it doesn't matter much whether the traffic is dropped on your side of the wire or their side of the wire.

This way, any protections you'd implement (such as RPKI ROV, ASPA, etc) would reflect and protect the blackhole routes as well. The idea is that you'd require the customer to be the best path for a less-specific but covering route before you'd accept the more-specific blackhole route. I think this would be a useful protection against unauthorized blackhole routes.

### In closing

I recommend to NOT simply ignore RPKI validation state merely because the blackhole community is present, because that's like having 'welcome01' as default password on your BGP. I strongly recommend to impose additional checks (like the ones I described) so that folks cannot easily misuse your RTBH service.

It also is good practise to capture all BGP information going in and out of your network (with MRT or BMP), so you can retroactively audit the blackholing signals and see if any of your customers was doing funny things.

Kind regards,

Job

ps.

...

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

yes - this is very uncomfortable

On Sat, Aug 08, 2026 at 06:15:08PM -0500, Bryton Herdes via routing-wg wrote:

if you're interested in a router feature knob that could selectively ignore maxLength of ROAs while (only) performing RTBH route validation, I can share at least the Juniper and Cisco feature requests I've submitted. Let me know.

Just ignoring maxLength because it is 'inconvenient' sounds pretty unsafe, right? The resources holder probably didn't set that maxLength to be ignored. What other safeguards will accompany such a risky feature? Kind regards, Job

I agree the peerAS=originAS guardrail would be ideal both because it makes the risks associated with ignoring maxLength (for RTBH) in implementation less, but also I suspect many networks already enforce RTBH routes to have only 1 member in the AS_PATH. The problem then lies with RTBH routes that have >1 AS in the path, what do we do for those? Not support them? If we do support them, we still need route validation. Thanks, -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Sat, Aug 8, 2026 at 7:03 PM Job Snijders <job@bsd.nl> wrote:

On Sat, Aug 08, 2026 at 11:27:05PM +0000, Job Snijders wrote:

...

On Sat, Aug 08, 2026 at 06:15:08PM -0500, Bryton Herdes via routing-wg wrote:

...

if you're interested in a router feature knob that could selectively ignore maxLength of ROAs while (only) performing RTBH route validation, I can share at least the Juniper and Cisco feature requests I've submitted. Let me know.

Just ignoring maxLength because it is 'inconvenient' sounds pretty unsafe, right? The resources holder probably didn't set that maxLength to be ignored.

What other safeguards will accompany such a risky feature?

A potential guardrail maybe is to only ignore maxLength if the peer-as (the neighboring AS from which the blackhole route was received) is the same AS as the Origin AS in the VRP for which the maxLength is ignored?

Then you'd basically have the same setup as the config example I shared previously in this thread, and less need for automation.

Kind regards,

Job

On the "Why not?" One of the obvious reasons that springs to my mind is that you might not want to do this because there are quite a lot of providers in existence that will allow you to announce /25's or smaller within their own internal networks, which means that in theory you can have an invisible /25 mis-origination attack/mistake if you allow /25's (or smaller), even if it won't cross the edge to another provider Given that one of the core reasons that Max Length exists is to prevent more specific hijacks, what you're suggesting here is basically the equivalent of ignoring maxLength anyway On Mon, 24 Aug 2026 at 16:22, James Bensley <james@inter.link> wrote:

Hi Salvador,

...

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

Why not? That is the most optimal solution for secure RTBH filtering in my opinion. Increase your maxLength, plus implement RFC9234 to validate the peer role, and ASPA to validate the path. I think this is the path we as an industry should be going down, not ignoring maxLength or relying on IRR derived prefix filters.

(because I'm quite lazy, here is a previous post I wrote explaining why I think this is the way forward: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q2GYREV3...)

With kind regards, James Bensley (he/him)

________________________________________ From: Salvador Bertenbreiter <salvadorb@gmail.com> Sent: 08 August 2026 20:47 To: routing-wg@ripe.net <routing-wg@ripe.net> Subject: [routing-wg] RTBH and RPKI

⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi all, A quick question for those using RTBH together with RPKI.

How do you handle /32 announcements in IPv4 or /128 in IPv6 when the prefix has a ROA with a maxLength of /24 or /48?

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

The other option would be to keep the ROA as it is and still announce the host route for RTBH, but in that case it would be RPKI Invalid. Do upstreams normally make an exception for routes marked as blackhole, or are they dropped by RPKI before the RTBH policy is applied?

Creating a specific ROA at the time of the attack also doesn’t seem very practical because of propagation times.

How are you handling this in production?

Regards,

Salvador [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<mailto:hello@inter.link> | Web: inter.link<https://inter.link> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

I don't think DOAs are the correct way forward because they have exactly the same problems as ROAs (because they are the same technology) when they are relied upon exclusively for RTBH validation: * There is no BGP control plane authentication so I can still inject an RTBH route with a fake AS path that will be DOA valid, just like with ROAs. This is the main problem people have with increasing the maxLength of ROAs, they think the ROA credibility is somehow a function of it's maxLength ,but ROAs (and DOAs) are origin attestations, not BGP UPDATE validations. DOAs improve nothing here. * DOAs did add as AS Path field which has now been superseeded by ASPA. The chance for DOAs to have a different AS path than an ASPA it a problem waiting to happen. * What to do with DOA unmatched prefixes (if no DOA exists), surely reject the RTBH route? So DOAs and ROAs won't behave the same (which will confuse people). I can't see what benefit DOAs add over increasing maxLength + rolling out peer roles + ASPA (maybe I missed it)? With kind regards, James Bensley (he/him) ________________________________ From: Bryton Herdes <bryton@cloudflare.com> Sent: 24 August 2026 17:33 To: Ben Cartwright-Cox <ripencc@benjojo.co.uk> Cc: James Bensley <james@inter.link>; Salvador Bertenbreiter <salvadorb@gmail.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI There are a few different implementation options floated around that get around half of the job done and are relatively safe most of the time. However, this topic and RTBH hijacks are critical enough to require their own intent. Reviving the separate object in RPKI is the only way that separate intent can be supported: https://datatracker.ietf.org/doc/html/draft-spaghetti-grow-rpki-doa-00 -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Mon, Aug 24, 2026 at 10:27 AM Ben Cartwright-Cox via routing-wg <routing-wg@ripe.net<mailto:routing-wg@ripe.net>> wrote: On the "Why not?" One of the obvious reasons that springs to my mind is that you might not want to do this because there are quite a lot of providers in existence that will allow you to announce /25's or smaller within their own internal networks, which means that in theory you can have an invisible /25 mis-origination attack/mistake if you allow /25's (or smaller), even if it won't cross the edge to another provider Given that one of the core reasons that Max Length exists is to prevent more specific hijacks, what you're suggesting here is basically the equivalent of ignoring maxLength anyway On Mon, 24 Aug 2026 at 16:22, James Bensley <james@inter.link> wrote:

Hi Salvador,

...

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

Why not? That is the most optimal solution for secure RTBH filtering in my opinion. Increase your maxLength, plus implement RFC9234 to validate the peer role, and ASPA to validate the path. I think this is the path we as an industry should be going down, not ignoring maxLength or relying on IRR derived prefix filters.

(because I'm quite lazy, here is a previous post I wrote explaining why I think this is the way forward: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q2GYREV3...)

With kind regards, James Bensley (he/him)

________________________________________ From: Salvador Bertenbreiter <salvadorb@gmail.com<mailto:salvadorb@gmail.com>> Sent: 08 August 2026 20:47 To: routing-wg@ripe.net<mailto:routing-wg@ripe.net> <routing-wg@ripe.net<mailto:routing-wg@ripe.net>> Subject: [routing-wg] RTBH and RPKI

⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi all, A quick question for those using RTBH together with RPKI.

How do you handle /32 announcements in IPv4 or /128 in IPv6 when the prefix has a ROA with a maxLength of /24 or /48?

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

The other option would be to keep the ROA as it is and still announce the host route for RTBH, but in that case it would be RPKI Invalid. Do upstreams normally make an exception for routes marked as blackhole, or are they dropped by RPKI before the RTBH policy is applied?

Creating a specific ROA at the time of the attack also doesn’t seem very practical because of propagation times.

How are you handling this in production?

Regards,

Salvador [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<mailto:hello@inter.link<mailto:hello@inter.link>> | Web: inter.link<https://inter.link> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

Hi Tom, Maybe my wording wasn't clear. I will try to re-word, let me know if it's still not clear, I can try again:

...

This is the main problem people have with increasing the maxLength of ROAs, they think the ROA credibility is somehow a function of it's maxLength ,but ROAs (and DOAs) are origin attestations, not BGP UPDATE validations.

I don't follow. The ROA credibility _is_ a function of its maxLength. For prefixes in the DFZ shorter than a /24, reliably preventing more-specific attacks (regardless of origin ASN) is a lifesaver. I don't understand how that could be construed as anything but a function of its maxLength.

After re-read, I think we're mixing up two different things here ^ The first part; "credibility _is_ a function of its maxLength" So of course, when checking a prefix against a ROA, the prefix length is checked, so the maxLength relates to the check being performed, no doubt about that, in this very basic sense, yes of course maxLength is a part of the checking function; but what I meant here is that people seem to think that a longer maxLength is less secure, and a shorter maxLength is more secure. But I don't believe this is not true. I will try and explain why I think this (and I'm happy if you can explain that my understanding is wrong): ROAs are only about who _may_ originate a prefix, not who _is_ originating a prefix, so by definition, maxLength can't affect "hijackability" because if an announcement is or is not a hijack, that is question about who _is_ actually announcing the prefix. And we don't know who_is_ announcing the prefix. To determine who _is_ announcing the prefix, we need something like BGPsec that cryptographically verifies the AS Path attribute. But we have no widely deployable solution for this yet. I can originate a prefix that belongs to you, fake the origin AS, and originate a prefix length that matches your ROA, and if I am better peered that you in the area where I announce that prefix, the hijack will be successful, even if you're announcing the same prefix from your genuine origin. Having a maxLength <=/24 didn't provide any extra protection in this case than if it was set to /32. The second part: "For prefixes in the DFZ shorter than a /24, reliably preventing more-specific attacks (regardless of origin ASN) is a lifesaver" There may have been some misunderstanding; I'm only talking about accepting >/24 or >/48 if the RTBH community is attached, and the route is ROA valid, and ASPA valid, and not a leak, etc. This is a thread about RTBH so I thought that might have been implicit in everyone's context for this discussion, but I should have mentioned that explicitly. Sorry, my bad! I am under no deceptions that accepting longer prefixes when not doing all the RTBH validation steps, just for "normal" routing, is probably a bad idea. Did I clear up anything or just make it more confusing? With kind regards, James Bensley (he/him) ________________________________________ From: Tom Strickx <tstrickx@cloudflare.com> Sent: 24 August 2026 18:33 To: James Bensley <james@inter.link> Cc: Bryton Herdes <bryton@cloudflare.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI   I don't follow. The ROA credibility _is_ a function of its maxLength. For prefixes in the DFZ shorter than a /24, reliably preventing more-specific attacks (regardless of origin ASN) is a lifesaver. I don't understand how that could be construed as anything but a function of its maxLength. --  Tom Strickx Principal Network Engineer AS13335 - Cloudflare On Mon, Aug 24, 2026 at 5:13 PM James Bensley <james@inter.link> wrote: I don't think DOAs are the correct way forward because they have exactly the same problems as ROAs (because they are the same technology) when they are relied upon exclusively for RTBH validation: There is no BGP control plane authentication so I can still inject an RTBH route with a fake AS path that will be DOA valid, just like with ROAs. This is the main problem people have with increasing the maxLength of ROAs, they think the ROA credibility is somehow a function of it's maxLength ,but ROAs (and DOAs) are origin attestations, not BGP UPDATE validations. DOAs improve nothing here. DOAs did add as AS Path field which has now been superseeded by ASPA. The chance for DOAs to have a different AS path than an ASPA it a problem waiting to happen. What to do with DOA unmatched prefixes (if no DOA exists), surely reject the RTBH route? So DOAs and ROAs won't behave the same (which will confuse people). I can't see what benefit DOAs add over increasing maxLength + rolling out peer roles + ASPA (maybe I missed it)? With kind regards, James Bensley (he/him) ________________________________________ From: Bryton Herdes <bryton@cloudflare.com> Sent: 24 August 2026 17:33 To: Ben Cartwright-Cox <ripencc@benjojo.co.uk> Cc: James Bensley <james@inter.link>; Salvador Bertenbreiter <salvadorb@gmail.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI   There are a few different implementation options floated around that get around half of the job done and are relatively safe most of the time.  However, this topic and RTBH hijacks are critical enough to require their own intent. Reviving the separate object in RPKI is the only way that separate intent can be supported:  https://datatracker.ietf.org/doc/html/draft-spaghetti-grow-rpki-doa-00 -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Mon, Aug 24, 2026 at 10:27 AM Ben Cartwright-Cox via routing-wg <routing-wg@ripe.net> wrote: On the "Why not?" One of the obvious reasons that springs to my mind is that you might not want to do this because there are quite a lot of providers in existence that will allow you to announce /25's or smaller within their own internal networks, which means that in theory you can have an invisible /25 mis-origination attack/mistake if you allow /25's (or smaller), even if it won't cross the edge to another provider Given that one of the core reasons that Max Length exists is to prevent more specific hijacks, what you're suggesting here is basically the equivalent of ignoring maxLength anyway On Mon, 24 Aug 2026 at 16:22, James Bensley <james@inter.link> wrote:

Hi Salvador,

...

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

Why not? That is the most optimal solution for secure RTBH filtering in my opinion. Increase your maxLength, plus implement RFC9234 to validate the peer role, and ASPA to validate the path. I think this is the path we as an industry should be going down, not ignoring maxLength or relying on IRR derived prefix filters.

(because I'm quite lazy, here is a previous post I wrote explaining why I think this is the way forward: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q2GYREV3...)

With kind regards, James Bensley (he/him)

________________________________________ From: Salvador Bertenbreiter <salvadorb@gmail.com> Sent: 08 August 2026 20:47 To: routing-wg@ripe.net <routing-wg@ripe.net> Subject: [routing-wg] RTBH and RPKI

⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi all, A quick question for those using RTBH together with RPKI.

How do you handle /32 announcements in IPv4 or /128 in IPv6 when the prefix has a ROA with a maxLength of /24 or /48?

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

The other option would be to keep the ROA as it is and still announce the host route for RTBH, but in that case it would be RPKI Invalid. Do upstreams normally make an exception for routes marked as blackhole, or are they dropped by RPKI before the RTBH policy is applied?

Creating a specific ROA at the time of the attack also doesn’t seem very practical because of propagation times.

How are you handling this in production?

Regards,

Salvador [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<mailto:hello@inter.link> | Web: inter.link<https://inter.link> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

Increasing maxLength for an IPv4 prefix to allow up to /32, doesn't enable the risk you described (this risk is already there). Networks also don't need to allow longer prefixes (/25 or longer) to enable the risk you described (this risk is already there). Both these issues already exist. If I have a ROA for a /16 with maxLength /20, someone else can origin hijack a more specific (e.g. a /20) and attach the no-advertise community to that hijacked a prefix, so it's ROA valid and limits the hijack to a single peer's network only, which as you describe, makes it a very hidden and hard to detect hijack. This is the thing; the size of maxLength (be it shorter or longer) doesn't change how trivial it is to origin hijack a prefix in a way which is ROA valid. Relying on a shorter maxLength to keep prefixes safe is like relying on longer passwords. Eventually we realised we need multifactor auth not longer passwords (origin AS + peer role + AS path). Anyone who believes the maxLength attribute is keeping their prefixes safe has not understood what ROAs are for. With kind regards, James Bensley (he/him) ________________________________ From: Ben Cartwright-Cox <ripencc@benjojo.co.uk> Sent: 24 August 2026 17:27 To: James Bensley <james@inter.link> Cc: Salvador Bertenbreiter <salvadorb@gmail.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI On the "Why not?" One of the obvious reasons that springs to my mind is that you might not want to do this because there are quite a lot of providers in existence that will allow you to announce /25's or smaller within their own internal networks, which means that in theory you can have an invisible /25 mis-origination attack/mistake if you allow /25's (or smaller), even if it won't cross the edge to another provider Given that one of the core reasons that Max Length exists is to prevent more specific hijacks, what you're suggesting here is basically the equivalent of ignoring maxLength anyway On Mon, 24 Aug 2026 at 16:22, James Bensley <james@inter.link> wrote:

Hi Salvador,

...

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

Why not? That is the most optimal solution for secure RTBH filtering in my opinion. Increase your maxLength, plus implement RFC9234 to validate the peer role, and ASPA to validate the path. I think this is the path we as an industry should be going down, not ignoring maxLength or relying on IRR derived prefix filters.

(because I'm quite lazy, here is a previous post I wrote explaining why I think this is the way forward: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q2GYREV3...)

With kind regards, James Bensley (he/him)

________________________________________ From: Salvador Bertenbreiter <salvadorb@gmail.com> Sent: 08 August 2026 20:47 To: routing-wg@ripe.net <routing-wg@ripe.net> Subject: [routing-wg] RTBH and RPKI

⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi all, A quick question for those using RTBH together with RPKI.

How do you handle /32 announcements in IPv4 or /128 in IPv6 when the prefix has a ROA with a maxLength of /24 or /48?

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

The other option would be to keep the ROA as it is and still announce the host route for RTBH, but in that case it would be RPKI Invalid. Do upstreams normally make an exception for routes marked as blackhole, or are they dropped by RPKI before the RTBH policy is applied?

Creating a specific ROA at the time of the attack also doesn’t seem very practical because of propagation times.

How are you handling this in production?

Regards,

Salvador [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<mailto:hello@inter.link> | Web: inter.link<https://inter.link> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

Hi Ben, Maybe I misunderstood your query and that's why my response doesn't make sense to you? I've tried to re-parse your query; I think what you are saying is: * Some networks allow customers to announce longer prefixes than the standard v4 /24 and v6 /48 maximums, as long as those prefixes stay within the network receiving the announcement. * If the announcing customer increases their maxLength on the relevant ROAs, those more specifics can be hijacked either by other another customer attached to the same receiving network, and they'd be ROA valid (making the hijack hard to spot), and/or those more specifics could be hijacked somewhere else on the Internet and be ROA valid hijacks. And for extra spice, if the do-not-announce community is attached, it will be an even harder to spot hijack because it will be hyper localised. Is that what you're saying? If no, then I didn't understand your query 🙂 If yes, then my response is: * A network which doesn't accept longer than /24 and /84 is already susceptible to origin hijacks, accepting longer prefixes doesn't change this. * Increasing maxLength in a ROA beyond /24 or /48 doesn't enable origin hijacks, they are possible with any maxLength. * Anyone that hijacks a prefix can add a do-not-announce community to it, to make it a hard-to-spot / low visibility hijack, regardless of announce prefix length, so again, increasing maxLength doesn't change anything here. * So I'm not seeing the inceased risk? (Sane rules would need to apply, more specifics are only accepted with the RTBH community attached, and as I said before, it should be a combination of ROA valid + peer role + AS path validation). Hope that makes more sense now. With kind regards, James Bensley (he/him) ________________________________ From: Ben Cartwright-Cox <ripencc@benjojo.co.uk> Sent: 24 August 2026 18:11 To: James Bensley <james@inter.link> Cc: routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI To put it simply: wat? I didn't really understand how "this risk is already there" if you have your max length at 24. The literal point of max length is to declare what is the /maximum length/ you are willing to accept as valid to other networks validating routes. Perhaps slightly annoying the I don't have solid data to show you (that I am allowed to share at least) but for the networks that do accept /25's, having your own max length set to /24 does prevent this happening (sometimes, I know that Lumen messed this up somewhat recently) Hope you are good Ben On Mon, 24 Aug 2026 at 16:58, James Bensley <james@inter.link> wrote:

Increasing maxLength for an IPv4 prefix to allow up to /32, doesn't enable the risk you described (this risk is already there).

Networks also don't need to allow longer prefixes (/25 or longer) to enable the risk you described (this risk is already there).

Both these issues already exist.

If I have a ROA for a /16 with maxLength /20, someone else can origin hijack a more specific (e.g. a /20) and attach the no-advertise community to that hijacked a prefix, so it's ROA valid and limits the hijack to a single peer's network only, which as you describe, makes it a very hidden and hard to detect hijack.

This is the thing; the size of maxLength (be it shorter or longer) doesn't change how trivial it is to origin hijack a prefix in a way which is ROA valid.

Relying on a shorter maxLength to keep prefixes safe is like relying on longer passwords. Eventually we realised we need multifactor auth not longer passwords (origin AS + peer role + AS path). Anyone who believes the maxLength attribute is keeping their prefixes safe has not understood what ROAs are for.

With kind regards, James Bensley (he/him) ________________________________ From: Ben Cartwright-Cox <ripencc@benjojo.co.uk> Sent: 24 August 2026 17:27 To: James Bensley <james@inter.link> Cc: Salvador Bertenbreiter <salvadorb@gmail.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI

On the "Why not?"

One of the obvious reasons that springs to my mind is that you might not want to do this because there are quite a lot of providers in existence that will allow you to announce /25's or smaller within their own internal networks, which means that in theory you can have an invisible /25 mis-origination attack/mistake if you allow /25's (or smaller), even if it won't cross the edge to another provider

Given that one of the core reasons that Max Length exists is to prevent more specific hijacks, what you're suggesting here is basically the equivalent of ignoring maxLength anyway

On Mon, 24 Aug 2026 at 16:22, James Bensley <james@inter.link> wrote:

...

Hi Salvador,

...

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

Why not? That is the most optimal solution for secure RTBH filtering in my opinion. Increase your maxLength, plus implement RFC9234 to validate the peer role, and ASPA to validate the path. I think this is the path we as an industry should be going down, not ignoring maxLength or relying on IRR derived prefix filters.

(because I'm quite lazy, here is a previous post I wrote explaining why I think this is the way forward: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q2GYREV3...)

With kind regards, James Bensley (he/him)

________________________________________ From: Salvador Bertenbreiter <salvadorb@gmail.com> Sent: 08 August 2026 20:47 To: routing-wg@ripe.net <routing-wg@ripe.net> Subject: [routing-wg] RTBH and RPKI

⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi all, A quick question for those using RTBH together with RPKI.

How do you handle /32 announcements in IPv4 or /128 in IPv6 when the prefix has a ROA with a maxLength of /24 or /48?

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

The other option would be to keep the ROA as it is and still announce the host route for RTBH, but in that case it would be RPKI Invalid. Do upstreams normally make an exception for routes marked as blackhole, or are they dropped by RPKI before the RTBH policy is applied?

Creating a specific ROA at the time of the attack also doesn’t seem very practical because of propagation times.

How are you handling this in production?

Regards,

Salvador [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<mailto:hello@inter.link> | Web: inter.link<https://inter.link> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

Hi Bryton,

...

Increasing maxLength in a ROA beyond /24 or /48 doesn't enable origin hijacks, they are possible with any maxLength.

Surely we all grasp this already, but the longer prefix hijacks are more effective in sucking in traffic to unauthorized parties. 

Fully agreed, but the more specific hijacks you fell victim to and tested further, weren't because of maxLenght, they were because the origin wasn't being validated at all, and because the AS path wasn't being validated at all (if I remember correctly)? Also, I think that what you're implying is that increasing maxLength enables more specific hijacks. Is that understanding correct (?), if yes; more specifics aren't hijacked because maxLength is longer, they are hijacked because either the entire AS PATH attribute of the BGP UPDATE message (or at least the origin AS) was forged, and we don't currently validate this, and/or the AS PATH was "genuine" (meaning not manipulated) but "wrong" (meaning a route leak) and this was accepted due no to ASPA validation, and/or no peer role validation, and/or no OTC attribute validation. maxLength alone can't be relied upon, regardless of prefix length to protect against hijacks; we need the full chain to protect against this (ROA + peer role + OTC + ASPA). That is why I am saying that we (as an industrying) should be aiming for that full chain of checks, and anyone relying on maxLength _alone_ to prevent a sub-prefix hijack isn't securing their routing. Similarly, it's also why I think that increasing maxLenght to accommodate RTBH works; because you'd only accept a route >=/25 or >=/48 if it has the RTBH community, _and_ is ROA valid, _and_ is AS path valid, _and_ is not a leak (OTC). In this ideal world, the only chance for hijacks is the one we still have no large scale solution for (cryptographic verification of the AS PATH attribute). (to be clear, I'm not suggesting we accept >/24 or >/48 for non-RTBH routes, I assumed that was implicit because this is a thread about RTBH, but in hindsight it could have been more explicit, sorry if that caused confusion). With kind regards, James Bensley (he/him) ________________________________________ From: Bryton Herdes <bryton@cloudflare.com> Sent: 24 August 2026 18:43 To: James Bensley <james@inter.link> Cc: Ben Cartwright-Cox <ripencc@benjojo.co.uk>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI  

Increasing maxLength in a ROA beyond /24 or /48 doesn't enable origin hijacks, they are possible with any maxLength.

Surely we all grasp this already, but the longer prefix hijacks are more effective in sucking in traffic to unauthorized parties. Hence the guidance about signing minimal ROAs. And yes, RPKI-ROV still needs ran against those hyper-specific routes [1] [2]. [1] https://chinog.org/wp-content/uploads/2026/06/bryton_herdes_false_immunity_l... [2] https://nanog.org/events/nanog-98/content/5843/ -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Mon, Aug 24, 2026 at 11:33 AM James Bensley <james@inter.link> wrote: Hi Ben, Maybe I misunderstood your query and that's why my response doesn't make sense to you? I've tried to re-parse your query; I think what you are saying is: Some networks allow customers to announce longer prefixes than the standard v4 /24 and v6 /48 maximums, as long as those prefixes stay within the network receiving the announcement. If the announcing customer increases their maxLength on the relevant ROAs, those more specifics can be hijacked either by other another customer attached to the same receiving network, and they'd be ROA valid (making the hijack hard to spot), and/or those more specifics could be hijacked somewhere else on the Internet and be ROA valid hijacks. And for extra spice, if the do-not-announce community is attached, it will be an even harder to spot hijack because it will be hyper localised.  Is that what you're saying? If no, then I didn't understand your query 🙂 If yes, then my response is: A network which doesn't accept longer than /24 and /84 is already susceptible to origin hijacks, accepting longer prefixes doesn't change this. Increasing maxLength in a ROA beyond /24 or /48 doesn't enable origin hijacks, they are possible with any maxLength. Anyone that hijacks a prefix can add a do-not-announce community to it, to make it a hard-to-spot / low visibility hijack, regardless of announce prefix length, so again, increasing maxLength doesn't change anything here. So I'm not seeing the inceased risk? (Sane rules would need to apply, more specifics are only accepted with the RTBH community attached, and as I said before, it should be a combination of ROA valid + peer role + AS path validation). Hope that makes more sense now. With kind regards, James Bensley (he/him) ________________________________________ From: Ben Cartwright-Cox <ripencc@benjojo.co.uk> Sent: 24 August 2026 18:11 To: James Bensley <james@inter.link> Cc: routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI   To put it simply: wat? I didn't really understand how "this risk is already there" if you have your max length at 24. The literal point of max length is to declare what is the /maximum length/ you are willing to accept as valid to other networks validating routes. Perhaps slightly annoying the I don't have solid data to show you (that I am allowed to share at least) but for the networks that do accept /25's, having your own max length set to /24 does prevent this happening (sometimes, I know that Lumen messed this up somewhat recently) Hope you are good Ben On Mon, 24 Aug 2026 at 16:58, James Bensley <james@inter.link> wrote:

Increasing maxLength for an IPv4 prefix to allow up to /32, doesn't enable the risk you described (this risk is already there).

Networks also don't need to allow longer prefixes (/25 or longer) to enable the risk you described (this risk is already there).

Both these issues already exist.

If I have a ROA for a /16 with maxLength /20, someone else can origin hijack a more specific (e.g. a /20) and attach the no-advertise community to that hijacked a prefix, so it's ROA valid and limits the hijack to a single peer's network only, which as you describe, makes it a very hidden and hard to detect hijack.

This is the thing; the size of maxLength (be it shorter or longer) doesn't change how trivial it is to origin hijack a prefix in a way which is ROA valid.

Relying on a shorter maxLength to keep prefixes safe is like relying on longer passwords. Eventually we realised we need multifactor auth not longer passwords (origin AS + peer role + AS path). Anyone who believes the maxLength attribute is keeping their prefixes safe has not understood what ROAs are for.

With kind regards, James Bensley (he/him) ________________________________ From: Ben Cartwright-Cox <ripencc@benjojo.co.uk> Sent: 24 August 2026 17:27 To: James Bensley <james@inter.link> Cc: Salvador Bertenbreiter <salvadorb@gmail.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI

On the "Why not?"

One of the obvious reasons that springs to my mind is that you might not want to do this because there are quite a lot of providers in existence that will allow you to announce /25's or smaller within their own internal networks, which means that in theory you can have an invisible /25 mis-origination attack/mistake if you allow /25's (or smaller), even if it won't cross the edge to another provider

Given that one of the core reasons that Max Length exists is to prevent more specific hijacks, what you're suggesting here is basically the equivalent of ignoring maxLength anyway

On Mon, 24 Aug 2026 at 16:22, James Bensley <james@inter.link> wrote:

...

Hi Salvador,

...

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

Why not? That is the most optimal solution for secure RTBH filtering in my opinion. Increase your maxLength, plus implement RFC9234 to validate the peer role, and ASPA to validate the path. I think this is the path we as an industry should be going down, not ignoring maxLength or relying on IRR derived prefix filters.

(because I'm quite lazy, here is a previous post I wrote explaining why I think this is the way forward: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q2GYREV3...)

With kind regards, James Bensley (he/him)

________________________________________ From: Salvador Bertenbreiter <salvadorb@gmail.com> Sent: 08 August 2026 20:47 To: routing-wg@ripe.net <routing-wg@ripe.net> Subject: [routing-wg] RTBH and RPKI

⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi all, A quick question for those using RTBH together with RPKI.

How do you handle /32 announcements in IPv4 or /128 in IPv6 when the prefix has a ROA with a maxLength of /24 or /48?

One option would be to extend the ROA to /32 or /128, but I’m not fully comfortable with that since it would also make other more-specifics valid.

The other option would be to keep the ROA as it is and still announce the host route for RTBH, but in that case it would be RPKI Invalid. Do upstreams normally make an exception for routes marked as blackhole, or are they dropped by RPKI before the RTBH policy is applied?

Creating a specific ROA at the time of the attack also doesn’t seem very practical because of propagation times.

How are you handling this in production?

Regards,

Salvador [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<mailto:hello@inter.link> | Web: inter.link<https://inter.link> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

Hi Antonis, I hope all is well with you.

Issuing a /16 ROA with /32 maxLength means that attackers can hijack a /17 to /24 and it would take precedence over my routes. With the *current* deployment of ASPA and RFC9234 they would win. If I have the /16-/16 ROA, they’d have to compete with me for traffic, and because they would also have to add a fake hop behind them, it would increase their AS path, making them even less competitive.

As the excellent team at Cloudflare have already shown us (https://blog.cloudflare.com/enforce-first-as-bgp/) I can fake the AS path and it will be as least as short as your AS path, not longer (this is also the case at various IXPs). Also due to Tier 1 carriers using Local Preference (I'm against LP, that requires a separate email thread), if my T1 is not the same T1 you use, I can fake the announcement to my T1, and they'll prefer it over the genuine announce their receive over their peering with your T1, because of LP on the customer port, and so despite your equal length count announcement, they'll prefer mine and propagate it. A competing announcement really adds no protection. Also, extended that idea to DOAs for a moment (yet another reason why I don't like DOAs): unless you black hole your self continuously, there will be no competing route. With a competing, normal, non-black hole route, my hijack of your prefix will be "quite" effective, it depends on how well peered you are. But plenty effective enough to be devastating for you because the average network isn't that well connected. With DOAs, there is no competing route, so my RTBH hijack will be 100% effective (I must admit, the same is true if we were to use ROAs with maxLength 32 + ASPA + RFC9234 + RTBH community to authenticate the RTBH announcement, but my point being, DOAs added no benefit here).

Eventually it’s a trade off that has to be made. I personally think the risk of more specific hijacks is perceived as greater to companies than the risk of not maintaining a prefix list correctly with their contractual partner. A tight ROA gives them a fighting chance during a hijack, while a broad ROA makes them vulnerable while still not guaranteeing that RTBH will function properly (no false positives or negatives) 100% of the time.

I'm not 100% sure if I followed this, is this what you're saying: "I personally think the risk of more specific hijacks is perceived as greater to companies than the risk of not maintaining a prefix list correctly" -> I think the risk is definitely _perceived_ as worse, but is it _actually_ worse? I don't believe so. The reason being, as I've said several times, maxLength isn't what allows a hijack, the lack of RFC9234 and ASPA is what allows a hijack. Also, many providers are extending prefix filters to match up to /32 or /128 already today, even if you don't want to use RTBH, they open you up to hijacks without your say or control. Moving this into ROA maxLength actually gives you control and the chance to opt out. "A tight ROA gives them a fighting chance during a hijack," -> I think this is a reference to competing announcements? If yes, see my note above, if people believe this it's like believing in longer passwords. "while a broad ROA makes them vulnerable" -> I disagree here; because as above, maxLength isn't what allows the AS path attribute to be manipulated. "while still not guaranteeing that RTBH will function properly (no false positives or negatives) 100% of the time." -> I didn't get this bit, sorry :D

When the deployment of ASPA and RFC9234 (and BGPsec :P) is much higher, the scale will tip. I understand, James, that you are talking about the future, and where we need to be heading, and I’d also like to head there. Doing all of that intermediary work may seem like a waste. I think what Bryton is saying is that we need something to get us there safely, and we may have to waste these resources.

And my two pence is, put that effort into RFC9234 and ASPA, then the combination of RTBH community + ROA maxLength + peer role + OTC check + ASPA validation, means we won't need things like DOAs :) That will be about as good as it can get without introducing some BGPsec like thing (I really thing that should be our long term goal). With kind regards, James Bensley (he/him) ________________________________________ From: Antonis Chariton <daknob@daknob.net> Sent: 25 August 2026 01:13 To: James Bensley <james@inter.link> Cc: Bryton Herdes <bryton@cloudflare.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] RTBH and RPKI ⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi James, all

On 24 Aug 2026, at 19:15, James Bensley <james@inter.link> wrote:

Similarly, it's also why I think that increasing maxLenght to accommodate RTBH works; because you'd only accept a route >=/25 or >=/48 if it has the RTBH community, _and_ is ROA valid, _and_ is AS path valid, _and_ is not a leak (OTC). In this ideal world, the only chance for hijacks is the one we still have no large scale solution for (cryptographic verification of the AS PATH attribute).

I had to carefully read this thread a couple of times to make sure I understand it correctly but it seems to me that the core of the issue is that ROAs don’t also have a minLength. If I am only advertising a /16 at all times, and I don’t need anything more specific, I currently issue a ROA for the /16 with maxLength /16. If I get a DDoS attack and I need to RTBH, I cannot change the maxLength or issue a new ROA as that would take “ages” to propagate. If I had a minLength, I could issue a second object that I have out there all year round that’s for the /16 and it has minLength=/32 maxLength=/32. This last object is basically the DOA. It’s a ROA with maxed out min/maxLength and constrained to a specific community’s presence. Issuing a /16 ROA with /32 maxLength means that attackers can hijack a /17 to /24 and it would take precedence over my routes. With the *current* deployment of ASPA and RFC9234 they would win. If I have the /16-/16 ROA, they’d have to compete with me for traffic, and because they would also have to add a fake hop behind them, it would increase their AS path, making them even less competitive. As a provider who wants to offer RTBH ability, since I don’t have a magic prefix list that’s known good for every BGP session, I have to rely on all of these technologies you mention above. They are not perfect, attackers can still get through, and my non-magical prefix lists will be my last resort. This is why a lot of networks only offer RTBH for customers. As a network that wants to use an RTBH service and I want it to be available to me to save the rest of my business, I want it to work, but I also don’t want to permanently open up my prefixes to hijacks with very broad ROAs. Also, since I usually have a relationship with the RTBH provider, I can try to make sure they keep their prefix list up to date. They can do an `if (prefix_list_matches() && rtbh_community_found())` before the RPKI check. Eventually it’s a trade off that has to be made. I personally think the risk of more specific hijacks is perceived as greater to companies than the risk of not maintaining a prefix list correctly with their contractual partner. A tight ROA gives them a fighting chance during a hijack, while a broad ROA makes them vulnerable while still not guaranteeing that RTBH will function properly (no false positives or negatives) 100% of the time. When the deployment of ASPA and RFC9234 (and BGPsec :P) is much higher, the scale will tip. I understand, James, that you are talking about the future, and where we need to be heading, and I’d also like to head there. Doing all of that intermediary work may seem like a waste. I think what Bryton is saying is that we need something to get us there safely, and we may have to waste these resources. Now DOA will be a new draft and it will take a lot of time to be deployed on its own, if ever, and maybe operators will get tired of all these new object types. Maybe it will arrive later than very broad adoption of AS paths and it will be… DoA. Who knows :) Antonis [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<mailto:hello@inter.link> | Web: inter.link<https://inter.link>

Hey James -

The reason being, as I've said several times, maxLength isn't what allows a hijack, the lack of RFC9234 and ASPA is what allows a hijack.

I can appreciate the optimism about ASPA and RFC 9234. I share the belief that both are critical to Internet routing security, and not a single one alone. That being said, re-purposing the role of maxLength in the ROA is undesirable. It's (already) providing value against sub-prefix hijacks, which we cannot discard during the long-tail of adoption for our chosen path verification mechanisms (ASPA, RFC 9234). I think you may be downplaying maxLength's current value against both unintentional and intentional sub-prefix hijacks. Furthermore, I've gathered that you see a place for RTBH in both the near and far future. If that's true for you and many others, isn't it worth having the separate object in RPKI for storing blackhole/ddos-filtering intent? Thanks, -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Tue, Aug 25, 2026 at 12:59 PM Antonis Chariton via routing-wg < routing-wg@ripe.net> wrote:

Hey James,

On 25 Aug 2026, at 19:03, James Bensley <james@inter.link> wrote:

Hi Antonis,

I hope all is well with you.

Issuing a /16 ROA with /32 maxLength means that attackers can hijack a /17 to /24 and it would take precedence over my routes. With the *current* deployment of ASPA and RFC9234 they would win. If I have the /16-/16 ROA, they’d have to compete with me for traffic, and because they would also have to add a fake hop behind them, it would increase their AS path, making them even less competitive.

As the excellent team at Cloudflare have already shown us ( https://blog.cloudflare.com/enforce-first-as-bgp/) I can fake the AS path and it will be as least as short as your AS path, not longer (this is also the case at various IXPs).

Also due to Tier 1 carriers using Local Preference (I'm against LP, that requires a separate email thread), if my T1 is not the same T1 you use, I can fake the announcement to my T1, and they'll prefer it over the genuine announce their receive over their peering with your T1, because of LP on the customer port, and so despite your equal length count announcement, they'll prefer mine and propagate it. A competing announcement really adds no protection.

Also, extended that idea to DOAs for a moment (yet another reason why I don't like DOAs): unless you black hole your self continuously, there will be no competing route. With a competing, normal, non-black hole route, my hijack of your prefix will be "quite" effective, it depends on how well peered you are. But plenty effective enough to be devastating for you because the average network isn't that well connected. With DOAs, there is no competing route, so my RTBH hijack will be 100% effective (I must admit, the same is true if we were to use ROAs with maxLength 32 + ASPA + RFC9234 + RTBH community to authenticate the RTBH announcement, but my point being, DOAs added no benefit here).

Eventually it’s a trade off that has to be made. I personally think the risk of more specific hijacks is perceived as greater to companies than the risk of not maintaining a prefix list correctly with their contractual partner. A tight ROA gives them a fighting chance during a hijack, while a broad ROA makes them vulnerable while still not guaranteeing that RTBH will function properly (no false positives or negatives) 100% of the time.

I'm not 100% sure if I followed this, is this what you're saying:

"I personally think the risk of more specific hijacks is perceived as greater to companies than the risk of not maintaining a prefix list correctly" -> I think the risk is definitely _perceived_ as worse, but is it _actually_ worse? I don't believe so. The reason being, as I've said several times, maxLength isn't what allows a hijack, the lack of RFC9234 and ASPA is what allows a hijack. Also, many providers are extending prefix filters to match up to /32 or /128 already today, even if you don't want to use RTBH, they open you up to hijacks without your say or control. Moving this into ROA maxLength actually gives you control and the chance to opt out.

"A tight ROA gives them a fighting chance during a hijack," -> I think this is a reference to competing announcements? If yes, see my note above, if people believe this it's like believing in longer passwords.

"while a broad ROA makes them vulnerable" -> I disagree here; because as above, maxLength isn't what allows the AS path attribute to be manipulated.

Let me rephrase: a more specific will always win, regardless of same T1, LP, spoofed AS paths, etc. A competing announcement will split the traffic. I oversimplified quite a bit trying to not be nihilistic. I don’t think anything can provide perfect protection, eliminating more specifics is, imho, significant.

"while still not guaranteeing that RTBH will function properly (no false positives or negatives) 100% of the time." -> I didn't get this bit, sorry :D

As a customer of a provider offering RTBH you want to not only ensure that others can’t trigger RTBH for your prefixes but also that you can always trigger it reliably when you need it.

Antonis

----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

James Bensley wrote on 26/08/2026 09:27:

* What_exactly_ about the existing tooling doesn't solve this?

apologies for parachuting midway into this discussion and asking a potentially stupid question without having looked at the previous context, but I'm curious why the RPKI makes a good tool for handling ddos. Most ddos incidents are fast flux, and the RPKI is not. Ok, there might be prolonged incidents where an RPKI object of some form could provide distributed benefits, but ultimately it takes a while for RPKI objects to be propagated, and this impacts both insertion and removal. Nick

Hi, On Wed, 26 Aug 2026 at 09:40, Nick Hilliard wrote:

I'm curious why the RPKI makes a good tool for handling ddos. Most ddos incidents are fast flux, and the RPKI is not. Ok, there might be prolonged incidents where an RPKI object of some form could provide distributed benefits, but ultimately it takes a while for RPKI objects to be propagated, and this impacts both insertion and removal.

On Wed, Aug 26, 2026 at 10:55:47AM +0100, Ben Cartwright-Cox wrote:

I think this is for customers/suppliers preparing ahead of time for DDoS events (something I am sure we know is hopeful thinking a lot of the time!) rather than the idea of publishing records in immediate response to a attack

In the envisioned normal course of operations you'd create DOAs when you turn up sessions with a new transit provider. (Basically the same moment you'd update your ASPA record to include that new transit provider.) You'd also update your DOA after having received new IP resources from the RIR. This way, the DOA information will have propagated well in advance of eventual RTBH BGP signaling. Kind regards, Job

Hi, On Mon, Aug 24, 2026 at 03:21:57PM +0000, James Bensley wrote:

...

One option would be to extend the ROA to /32 or /128, but I???m not fully comfortable with that since it would also make other more-specifics valid.

Why not? That is the most optimal solution for secure RTBH filtering in my opinion. Increase your maxLength, plus implement RFC9234 to validate the peer role, and ASPA to validate the path. I think this is the path we as an industry should be going down, not ignoring maxLength or relying on IRR derived prefix filters.

I don't want to announce my prefixes as a /32 all the time, just because I might want to get an upstream to accept the /32 when I need it for RTBH (or "please wash DDoS") purposes. Also, I do not want the /32 to be visible world wide. *Not* announcing the /32 globally when there is a valid ROA opens a huge door for everybody and their dog to spoof that /32. Nah. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On Tue, Aug 25, 2026 at 04:09:30PM +0000, James Bensley wrote:

The funny thing here is;

* Any RTBH provider today is taking your route(6) objects, which are for say a /24, and building a prefix filter for up to /32 (or /128).

Route/route6 objects are unsigned information. I'd like the industry to move away from using plain-text information in mission-critical automation.

* Then applying logic similar to the following: "if RTBH community is attached, and prefix size is /32, and prefix matches prefix filter -> then allow".

The resource holder did not authorize this interpretation.

* This happens for all prefixes of all customers all the way down their AS-SET tree.

Indeed, and all those resource holders did not authorize such an interpretation.

* The customer (or customer's customer, etc) get's no say in this prefix length expansion (the up to /32 and up to /128).

Exactly.

* As we know, anyone can add anything they want to their AS-SET.

So for networks which don't use / don't want RTBH, somewhere upstream of them, a provider, without their approval, is allowing more specifics than what that networks announces and has defined in IRR. And they're relying on the non-existing security of AS-SETs.

(I should know, we do it!)

If you moved that into ROA maxLength you would actually improve on the status quo because only networks that want to use RTBH need to increase their maxLength (stopping providers from doing it without asking you, and proving you with a way to opt out).

It is recommended to avoid using the maxLength attribute in ROAs. See BCP 185. https://www.rfc-editor.org/info/rfc9319/ BCP 185 also contains a section on RTBH filtering: https://www.rfc-editor.org/info/rfc9319/#section-6 BCP 185 literally states that ROA-based RPKI-ROV [RFC6811] is a poor fit for the validation of RTBH routes. Thusly, we should investigate the design of a new RPKI-based object type fit for purpose of validation of RTBH routes. The idea of the DOA concept is that the resource holder can issue explicit authorization for more-specifics (and also disallow less-specifics) to exist in BGP RIBs for purposes of blackholing if-and-only-if certain conditions are met (conditions related to AS_PATH and BGP community attribute attached to the route). The DOA object allows resource holders to specify a narrow set of circumstances (much narrower than you'd be able to achieve by misusing ROAs) in which blackholing is deemed permissive by the resource holder. A general note -- We as operator community really are not stuck with ROAs for every imaginable purpose. (See https://en.wikipedia.org/wiki/Law_of_the_instrument) It _is_ possible to extend the RPKI and innovate on manageable time scales. Innovating based on RPKI technology has several benefits: cryptographic assurances and strong object security, a transportation channel to convey information reasonably fast into BGP routers (RTR protocol), efficiency due to binary encodings, quite rapid (but not real-time) global information distribution, etc. I understand ASN.1 syntax can appear offputting and the barriers to define & deploy new RPKI object types may seem insurmountable because of all the binary encodings & cryptography (rather naieve extensions in the simpler plain-text key/value like RPSL offers), but I'd like to assure everyone that on-the-wire encoding actually is the easy part. The harder part (and this is where input from the broader community is super welcome!) is defining the semantic data model: what information do operators believe to be useful to validate RTBH signals? Who needs to authorize what? Just tell me (even expressed as JSON, or RPSL) and I can quite easily flip it into an ASN.1 structure and wire it up to the RPKI authorization model. As an table-top example: should the DOA contain the BGP speaker's IP address so that RTBH requests can be validated by matching on the NEXT_HOP? Easy to add such a field! Personally I don't think putting NEXT_HOP addresses in RPKI objects will operationally spark joy, but I bring this up to show that there is flexibility in what a DOA could look like. We as community decide what a DOA should look like. The objective here is to provide digitally signed means to automatically validate an incoming EBGP route announcement (containing BGP community attribute, an AS_PATH attribute, etc) for purposes of blackholing; so which of that route's data fields should be matched against the hierarchical authorization structure that the RPKI provides? Kind regards, Job

On Wed, Aug 26, 2026 at 02:52:06PM +0200, Havard Eidnes wrote:

...

It is recommended to avoid using the maxLength attribute in ROAs. See BCP 185. https://www.rfc-editor.org/info/rfc9319/

Wait, what?!?

Is that just a wording issue, or did I totally mis-understand the whole purpose of RPKI ROAs?

I'll have to admit that I've not looked too closely under the covers, but to my mind, if I originate 192.168.0.0/16 into the routing system, and do not want to authorize any longer routes in this address space than this /16, do I not then use the maxLength attribute to say "16"? That's certainly what it looks like to me through the RIPE NCC RPKI ROA issuance assistant...

So isn't then the recommendation of BCP 185 to not authorize "too many" un-announced prefixes by having a large difference between the prefix length and maxLength in ROAs, rather than discouraging the use of maxLength altogether?

From an on-the-wire ROA encoding perspective the maxLength field is optional. If you do not wish to authorize longer-than-/16 routes for your /16, then you'd simply omit putting a value in that field. The RIPE NCC RPKI user interface is somewhat confusing in this regard: their ROA creation form mandates that a value be filled in the maxLength input field, and then the sbackend system which generates & signs the ROA will automatically omit the maxLength if the specified maximum length is equal to the prefix length. From a semantic perspective, there is no difference between omitting the maxLength field or explicitly setting the maxLength field to be the prefix length. RFC 9582 specifies: "The maxLength element SHOULD NOT be encoded if the maximum length is equal to the prefix length." source: I co-authored RFC 9582 and RFC 9319 / BCP 185. Kind regards, Job

Just saw this: https://www.virtualizor.com/blog/security-incident-bgp-hijacking/ Real BGP Hijack against Hetzner where the attackers managed to issue real Let’s Encrypt certificates despite the CA checking from multiple vantage points across different RIRs and ASNs. The prefix had ROA, so the attackers spoofed the origin to use Hetzner’s AS. The ROA was up to /24, Hetzner only advertised the /16. The moment the attackers advertised the spoofed /24 with a longer path they attracted 100% of the traffic. Traffic went back to Hetzner within 20’ of them announcing this specific /24 and competing with the hijackers. If that ROA was just for the /16 I bet this wouldn’t have happened, and I’m almost certain Let’s Encrypt would not have issued that certificate. Antonis

On 26 Aug 2026, at 16:13, Tim Bruijnzeels <tbruijnzeels@ripe.net> wrote:

Hi all,

To clarify:

...

On 26 Aug 2026, at 14:52, Havard Eidnes via routing-wg <routing-wg@ripe.net> wrote:

I'll have to admit that I've not looked too closely under the covers, but to my mind, if I originate 192.168.0.0/16 into the routing system, and do not want to authorize any longer routes in this address space than this /16, do I not then use the maxLength attribute to say "16"? That's certainly what it looks like to me through the RIPE NCC RPKI ROA issuance assistant..

The RIPE NCC RPKI Dashboard expects and explicit max length that defaults to the actual prefix length. This is essentially done this way to keep the UI simple. It forces the user to make an explicit choice (go with the default or change it).

On the encoded ROA object the max length is omitted if it matches the prefix length.

Kind regards,

Tim Bruijnzeels Principal Engineer RPKI RIPE NCC

----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

For me, the real question is why did the transit provider accept a the hijacked prefix from someone that's not upstream of the victim?

Yeah... especially since as both AS62390:AS-NEXONHOST and AS-ZETNET do not contain (nor have in the last month) Hetzner, so I assume everything was just unfiltered.

Does anyone know if the transit provider has been asked comments?

ArsTechnica did ask for comment and got none https://arstechnica.com/security/2026/09/well-executed-bgp-attack-uses-hijac... On Thu, 3 Sept 2026 at 11:00, James Bensley <james@inter.link> wrote:

There is a nice write-up here: https://bgpkit.com/blog/virtualizor-bgp-hijack-anatomy/

For me, the real question is why did the transit provider accept a the hijacked prefix from someone that's not upstream of the victim?

Does anyone know if the transit provider has been asked comments?

With kind regards, James Bensley (he/him) ________________________________ From: Bryton Herdes via routing-wg <routing-wg@ripe.net> Sent: 01 September 2026 00:09 To: Antonis Chariton <daknob@daknob.net> Cc: routing-wg@ripe.net <routing-wg@ripe.net> Subject: [routing-wg] Re: RTBH and RPKI

⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. That was quick, good callout!

At the very least, the hijack would have been made much less effective with a /16 minimal ROA and solely an AS_PATH length and route preference battle.

-- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare

On Mon, Aug 31, 2026 at 5:13 PM Antonis Chariton via routing-wg <routing-wg@ripe.net> wrote:

Just saw this:

https://www.virtualizor.com/blog/security-incident-bgp-hijacking/

Real BGP Hijack against Hetzner where the attackers managed to issue real Let’s Encrypt certificates despite the CA checking from multiple vantage points across different RIRs and ASNs.

The prefix had ROA, so the attackers spoofed the origin to use Hetzner’s AS.

The ROA was up to /24, Hetzner only advertised the /16. The moment the attackers advertised the spoofed /24 with a longer path they attracted 100% of the traffic.

Traffic went back to Hetzner within 20’ of them announcing this specific /24 and competing with the hijackers.

If that ROA was just for the /16 I bet this wouldn’t have happened, and I’m almost certain Let’s Encrypt would not have issued that certificate.

Antonis

On 26 Aug 2026, at 16:13, Tim Bruijnzeels <tbruijnzeels@ripe.net> wrote:

Hi all,

To clarify:

On 26 Aug 2026, at 14:52, Havard Eidnes via routing-wg <routing-wg@ripe.net> wrote:

I'll have to admit that I've not looked too closely under the

covers, but to my mind, if I originate 192.168.0.0/16 into the

routing system, and do not want to authorize any longer routes in

this address space than this /16, do I not then use the maxLength

attribute to say "16"? That's certainly what it looks like to me

through the RIPE NCC RPKI ROA issuance assistant..

The RIPE NCC RPKI Dashboard expects and explicit max length that defaults to the actual prefix length. This is essentially done this way to keep the UI simple. It forces the user to make an explicit choice (go with the default or change it).

On the encoded ROA object the max length is omitted if it matches the prefix length.

Kind regards,

Tim Bruijnzeels Principal Engineer RPKI RIPE NCC

----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

[CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link | Web: inter.link ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

Hi Ben, Yeah I had seen that (I wanted to nudge others into doing the same by asking the question on-list); $ whois  -h whois.ripe.net -r AS-ZETNET | grep mod last-modified:  2026-08-27T15:11:13Z $ whois  -h whois.ripe.net -r AS-ZETNET | grep 62390 members:        AS62390:AS-ALL $ whois -h whois.ripe.net -r AS62390:AS-ALL | grep mod last-modified:  2025-11-21T20:28:49Z $ whois -h whois.ripe.net -r AS62390:AS-ALL | grep memb members:        AS62390 members:        AS142019 members:        AS38051 members:        AS213871 members:        AS214209 members:        AS133153 members:        AS213766 members:        AS214209 The hijack started on 2026-08-28 and nether the hijacker nor their transit provider have updated their AS-SETs after this time, to remove Hetzner's AS-SET or ASN from their AS-SETs (in case it ever was in there). A quick look shows that neither Hetzner 's ASN nor AS-SET are in the hijackers AS-SET: $ bgpq4 -f 6204 AS-ZETNET 2>/dev/null | grep 24940 So it looks like no filtering at all. There is a bigger problem here IMO than the conversation we've been having on this list so far: * ROAs and ASPAs are lovely, but... * Nobody is forced to perform ROA/ASPA validation * Even networks which do validation, they aren't forced to reject invalids (some just de-preference) IMO, this wider problem really needs looking at too (MANRS are working on requiring participants to validate and reject invalids, but nobody is forced to be a MANRS participant, which is fair enough). This could make for an interesting discussion/debate at RIPE93; how to pressure networks into validating and rejecting. With kind regards, James Bensley (he/him) ________________________________________ From: Ben Cartwright-Cox <ripencc@benjojo.co.uk> Sent: 03 September 2026 11:07 To: James Bensley <james@inter.link> Cc: Antonis Chariton <daknob@daknob.net>; Bryton Herdes <bryton@cloudflare.com>; routing-wg@ripe.net <routing-wg@ripe.net> Subject: Re: [routing-wg] Re: RTBH and RPKI  

  For me, the real question is why did the transit provider accept a the hijacked prefix from someone that's not upstream of the victim?

Yeah... especially since as both AS62390:AS-NEXONHOST and AS-ZETNET do not contain (nor have in the last month) Hetzner, so I assume everything was just unfiltered.

  Does anyone know if the transit provider has been asked comments?

ArsTechnica did ask for comment and got none https://arstechnica.com/security/2026/09/well-executed-bgp-attack-uses-hijac... On Thu, 3 Sept 2026 at 11:00, James Bensley <james@inter.link> wrote:

There is a nice write-up here: https://bgpkit.com/blog/virtualizor-bgp-hijack-anatomy/

For me, the real question is why did the transit provider accept a the hijacked prefix from someone that's not upstream of the victim?

Does anyone know if the transit provider has been asked comments?

With kind regards, James Bensley (he/him) ________________________________ From: Bryton Herdes via routing-wg <routing-wg@ripe.net> Sent: 01 September 2026 00:09 To: Antonis Chariton <daknob@daknob.net> Cc: routing-wg@ripe.net <routing-wg@ripe.net> Subject: [routing-wg] Re: RTBH and RPKI

⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. That was quick, good callout!

At the very least, the hijack would have been made much less effective with a /16 minimal ROA and solely an AS_PATH length and route preference battle.

-- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare

On Mon, Aug 31, 2026 at 5:13 PM Antonis Chariton via routing-wg <routing-wg@ripe.net> wrote:

Just saw this:

https://www.virtualizor.com/blog/security-incident-bgp-hijacking/

Real BGP Hijack against Hetzner where the attackers managed to issue real Let’s Encrypt certificates despite the CA checking from multiple vantage points across different RIRs and ASNs.

The prefix had ROA, so the attackers spoofed the origin to use Hetzner’s AS.

The ROA was up to /24, Hetzner only advertised the /16. The moment the attackers advertised the spoofed /24 with a longer path they attracted 100% of the traffic.

Traffic went back to Hetzner within 20’ of them announcing this specific /24 and competing with the hijackers.

If that ROA was just for the /16 I bet this wouldn’t have happened, and I’m almost certain Let’s Encrypt would not have issued that certificate.

Antonis

On 26 Aug 2026, at 16:13, Tim Bruijnzeels <tbruijnzeels@ripe.net> wrote:

Hi all,

To clarify:

On 26 Aug 2026, at 14:52, Havard Eidnes via routing-wg <routing-wg@ripe.net> wrote:

I'll have to admit that I've not looked too closely under the

covers, but to my mind, if I originate 192.168.0.0/16 into the

routing system, and do not want to authorize any longer routes in

this address space than this /16, do I not then use the maxLength

attribute to say "16"?  That's certainly what it looks like to me

through the RIPE NCC RPKI ROA issuance assistant..

The RIPE NCC RPKI Dashboard expects and explicit max length that defaults to the actual prefix length. This is essentially done this way to keep the UI simple. It forces the user to make an explicit choice (go with the default or change it).

On the encoded ROA object the max length is omitted if it matches the prefix length.

Kind regards,

Tim Bruijnzeels Principal Engineer RPKI RIPE NCC

----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

[CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link | Web: inter.link ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

On 03/09/2026 12:59, James Bensley wrote: My question is what was the purpose? Obviously, the attacker invested lots of time and effort on setting this up, but "why"? What server in the range https://ipinfo.io/ips/162.55.80.0/24 was the target and what was stolen? softaculous.com? "served a backdoored update to installations that happened to check during the window". No monetary benefit so far. Perhaps some server that updated during the hijack period? But that would be hit or miss - again where is the monetary benefit? I am missing something. Regards, Hank

There is a nice write-up here: https://bgpkit.com/blog/virtualizor-bgp- hijack-anatomy/ <https://bgpkit.com/blog/virtualizor-bgp-hijack-anatomy/>

For me, the real question is why did the transit provider accept a the hijacked prefix from someone that's not upstream of the victim?

Does anyone know if the transit provider has been asked comments?

With kind regards, James Bensley (he/him) ------------------------------------------------------------------------