On Fri, 20 Feb 2026 at 08:40, Hank Nussbacher via NANOG <[email protected]> wrote:
> Crack in the Armor: Underlying Infrastructure Threats to RPKI > Publication Point Reachability > https://www.ndss-symposium.org/ndss-paper/crack-in-the-armor-underlying-infrastructure-threats-to-rpki-publication-point-reachability/ Interesting (i'm being polite) but hardly important. Everyone knows RPKI does nothing to stop attackers, it stops some class (not all) of configuration mistakes. I keep wondering, why don't we have a reverse AS-SET object? Object which lists which AS-SETs are allowed to have your ASN in them? This way, when you recurse AS-SET into permissible prefixes, you could validate that the far end actually allows you to claim them. In practice, you'd put in your reverse AS-SET object your upstreams, what ever they may be. Naively to me it seems like this could be implemented today, incrementally. If the reverse object does not exist, implicit permission exists. Some benefits: a) hygiene of prefix-lists is good - we regularly generate prefix-lists which are too large for some of our NOS, because AS-SET best practice is 'add-only', you have to have your downstream there, but there is no downside of keeping previous customers there. b) hygiene of AS graph, you could automatically generate 'peer lock' style AS-path filters, which would massively improve RPKI security posture, since I can stop using prefix-list generation entirely, but I can enforce that only allowable AS numbers are behind port. Then if my stubby customer accidentally leaks google through their BGP optimizer, either RPKI drops it, because origin is wrong, or my AS-path filter drops it, because google is not in their AS-SET (even if it is, it is pruned, due to reverse as-set of google) Now we can say that ASPA is coming, or something even better. But in practice it is unclear what is coming and when. This would be simple to implement, requiring no changes in NOS, only in your prefix-list generation logic and we could quickly get commitment from large transit shops to include the prune logic. -- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/ZTGW37TMKF64KVPBAT3BWLRWMOYHDMER/
