Re: Securing EBGP while getting rid of big IRR-based prefix-list-filters (Was: How long AS-PATH policies have you used)

On Fri, 27 Feb 2026 at 10:50, James Bensley via NANOG
<[email protected]> 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
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/HHWZH76ST7XWQJYMZ4TZVRMEHAEF7APJ/