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

On Mon, Mar 02, 2026 at 02:12:37PM +0200, Saku Ytti wrote:
> Active path verification is dicy.
> 
> - you can have multiple active paths, depending on POV

For sure, this while generating a prefix-list per customer, and one
should be cognizant that a given IP prefix destination might appear in
multiple prefix-lists. Indeed, there can be multiple plausible paths
towards a given IP destination. Not a problem, right? 

> - but if you receive more-specific paths, you will likely collapse to 1 POV

Your route collector is assume to be peering with all your routers, one
should be using the MRT UPDATES to generate the lists. Maybe I am
misunderstanding you.

BTW, I merely suggest a batch-processing-oriented workflow leveraging
MRT UPDATE files, because it might lower the barrier to deployment
(compared to, for example, a stream-oriented approach using BMP).
Throughout this conversation I try to encourage people to consider other
(non-IRR!) sources to automatically ascertain the plausibility of
requests for blackholing.

> - is blackhole desirable for all POV?

Great question. Must _every_ request for blackholing be honored?
Probably not. As there is a risk of accepting unauthorized blackholes,
it might be good to err to the side of caution and not be overly liberal
in accepting any and all requests for blackholing.

> Now you are blackholing everywhere, instead of the 1 active port.
> Above issue has happened to us, where the source would not have wanted
> the blackhole to appear.

Please elaborate on this scenario with more words.

> Even without this problem, it's not entirely clear if the middle ASN
> generated blackhole is desirable or permitted by the source ASN.

Yes, for this reason a network operator might implement as their policy
that blackholes are only permitted for routes originating in the
directly adjacent ASN (the customer AS). Operators define the exact
characteristics of the blackholing service themselves.

Section 6 of RFC 7999 states: "The method of validating announcements is
to be chosen according to the operator's routing policy." Darn those RFC
authors for not providing a complete solution! ;-)

> Perhaps if middle ASN thinks it should have this control over source
> ASN, they need to cooperate to figure out how to gain this capability.
> Either additional ROA or some mechanism between middle and source for
> source to generate it as needed.
> 
> So perhaps RPKI-valid-of-more-specific is safer.

I would benefit from a few more words on what exactly you mean with the
above. Do you mean to say that if the customer AS is 65535, you'd only
permit blackholes if they are contained within the prefixes for which
AS65535 is an authorized origin, according to RPKI ROAs? Sure, that
seems a reasonable precaution.

Kind regards,

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