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
Hi Salvador, In our case we always use communities to distinguish between normal routes and RTBH routes. So I guess you dont rreally need to check ROAs as long as routes for RTBH arrive with dedicated communities. Kind regards, Markel Sent from my iPhone
On Aug 8, 2026, at 20:47, Salvador Bertenbreiter <salvadorb@gmail.com> wrote:
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 ----- 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 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
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
RTBH + RPKI is quite the hot topic in recent days! This is a problem without a go-to, standard solution. I wanted to say I’ll be talking about some long-invalid prefixes in October at NANOG 98 ( https://nanog.org/events/nanog-98/content/5843/ ) where one of my focuses is RTBH hijacks and filtering. A recording will be made available afterward. Salvador (or others), 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. Thanks, -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Sat, Aug 8, 2026 at 1:47 PM Salvador Bertenbreiter <salvadorb@gmail.com> wrote:
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 ----- 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 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
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
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
participants (4)
-
Bryton Herdes -
Job Snijders -
Markel Stefo -
Salvador Bertenbreiter