How to validate blackhole routes? (Was: trouble letting go of IRR)

Hello James,

On Sat, Feb 28, 2026 at 10:25:26AM +0000, James Bensley via NANOG wrote:
> > I don't want to de-rail, but two of these AS-SET use-cases are
> > extremely frightening and need better solutions.
> 
> I am in agreement with you. I'm not saying they're fantastic, my
> intent was just to provide some use cases because nobody else has
> been. 

Yes, and in context of this discussion it probably is incumbent on you
to provide such details :-)

> > https://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijders.pdf
>
> is Interesting read; maybe Job can clear it up for me...
> 
> * Slide 8 -> do all these things need to be logically AND'ed together before the RTBH is accepted?
> * The summary on the last slide seems to suggest "yes"

The summary on the last slide is key!

Seven years ago, I intended to convey that perhaps the validation of
customer requests for traffic blackholing should be reconsidered: rather
than constructing a separate set of filters distinct from 'normal
routing', the act of honoring blackholes should be made contigent on
whether IP traffic is even being forwarded at all to the requesting
customer. Now, if I were to re-create these slides in 2026, I would
drop the "did you register the destination in IRR" bullet point. :-)

So, this slidedeck should be considered a tabletop exercise, rather than
something you can take and verbatim deploy. Implementing the spirit of
this slidedeck will require a modest effort to build some software.

> Again, a real world use case that we have...

No worries, Network Engineers Without Borders to the rescue!

> A customer has two connections to us in active/standby or
> primary/secondary, whatever you want to call it, but traffic always
> goes to one link. So all the DDoS traffic is going there, it's
> congested, maybe it's flapping up and down due to BGP timeouts, and
> the result is that they can't get a BGP update to us over this link to
> initiate RTBH. They can send us RTBH via the 2nd link, but it's not
> the best path to them, so in Job's design, would we accept the RTBH
> route?

I will offer some tangible suggestions for your consideration on how to
implement RTBH validation in a way that does not depend on IRR data.
See, I am not against using lists of prefixes in the router's
configuration, I'm merely advocating that prefix lists used to validate
blackholes probably shouldn't be constructed using IRR-derived data
(because that IRR data is arbitrary unsigned data of unknown provenance).

When validating, what's important is whether the customer ASN is the
next-hop AS (the active path), it is not so relevant which of their IP
next-hops exactly is/was the active one in case there are multiple
interconnections between your network and the customer network.

STEP 1: RECORD ALL BLACKHOLE REQUESTS IN MRT FORMAT

eh... no, scratch the above. If one starts recording, might as well
record it all. :-)

STEP 1: JUST RECORD ALL BGP UPDATES RECEIVED FROM CUSTOMERS IN MRT FORMAT

I consider it good practise for (transit) ISPs to record BGP messages,
in order for operators to be able to post-hoc debug issues such as BGP
hijacks or unauthorized blackholing. A simple implementation would be to
have all the BGP routers peer with a central route collector and
configure the route collector to write the received messages in MRT
format to durable storage.

STEP 2: USING A SLIDING TIME WINDOW, USING THE MRT DATA FROM STEP 1,
	CONSTRUCT A LIST OF IP PREFIXES, PER CUSTOMER, FOR WHICH THE
	CUSTOMER WAS THE ACTIVE PATH

The operative theory here is that if the customer somehow managed to
become the active path for 'normal routing' (e.g., your routers actually
forwarded IP traffic to the Customer's AS somewhere in the last 12 or 24
hours), they have gained the privilege to instruct your network to
discard IP traffic in their behalf. "Normal routing" can be protected
using RPKI ROV, ASPA, RFC 9234, Peerlock, Maximum Prefix Limits, etc.

Of course, if a customer wasn't using your network for reachability,
then their requests for IP blackholing should be considered "already
fullfilled": your network wasn't sending them IP packets destined for
the IP to be blackholed anyway.

The concept here is that the "blackholing service" provided by many
transit providers isn't so much that forwarding of traffic for a given
IP destination must completely cease within the transit provider's
network, but rather that the transit provider is requested not to
deliver that IP traffic across the customer's port.

In other words: blackholing offered by IP transit providers is not a
global censorship tool, it is a facility of last resort to attempt to
reduce collateral damage.

STEP 3: UPLOAD THE CONSTRUCTED PREFIX LISTS AS CUSTOMER-SPECIFIC
        PREFIX-LIST FILTERS FOR BLACKHOLING.

Your (publicly documented?) routing policy could be to permit customers
to request blackholing, provided that they were on the active path for
the given IP destination at some point in the last 12 or 24 hours. The
exact timing paramters should be subject to further research.

STEP 4: REPEAT THE ABOVE EVERY FEW HOURS.

Kind regards,

Job
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/GVXS6PMK5NDZZDYJYMCKHJ2P6QCM3543/