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/