On Fri, 27 Feb 2026 at 10:50, James Bensley via NANOG <nanog@lists.nanog.org> wrote:
* We are years away from rejecting ROA unknowns, because this requires like >95% of prefixes to have a ROA.
I would again like to mention a) RTR Real RPKI + AS_SET Prefix-list b) RTR Real RPKI + RTR AS_SET Gaps + AS_SET AS_PATH Origin If we look at these options unemotionally, and not get flustered about violating the purity of RPKI. We can easily see that b) offer superior security posture, while removing AFI specific prefix-lists. 1) Both have same quality and security for prefix check for valid+invalid+unknown RPKI 2) b) improves unknown security posture, by validating route object origin as well Objecting on this feels purely emotional, when objectively it achieves more while emitting less config (which in our case has caused inability to commit config regularly). Of course we should continue to pursue all these other superior avenues, but the idea that we can get rid entirely of AS_SET, while I'd like to, does not seem marketable today for networks that connect customers (I'd love to be wrong, I'd love if my customers will tell me, go ahead, stop filtering on AS_SET, we don't care). And if we cannot get rid of AS_SET, can we still do something better? And I think the above is a clear indication, yes, we can do something better while solving acute problems I have. Now if you are doing RTBH, the above falls apart, because you need to match 'RPKI-valid or-longer if blackhole community', which you cannot do against RTR data, as policy language doesn't offer that tooling. So most cannot migrate to b), because they want to offer RTBH and their NOS policy language isn't flexible enough to do it without duplicating prefix-lists. For RTBH part our intention is to solve them like so: RTR -> BMP:Pmacct:BGP -> RTR That is we reject route, Pmacct receives it, checks if it is BGP blackhole, checks that it is more specific of RPKI valid, if it passes these tests, it re-emits it back to RTR on BGP session where we will not check RPKI and will accept the blackhole. But the community at large will likely need to ask NOS vendors to support policy language ways to do RTBH for 'RPKI or more-specific'. Since the RTBH+prefix-list will by-pass RPKI validity check entirely, which we currently actively suffer from, by getting bad RTBH request we honor, problem that both above Pmacct solution will fix, and policy language support for 'valid or longer with blackhole community' would solve. -- ++ytti