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_snijder...
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