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