So perhaps RPKI-valid-of-more-specific is safer.
The problem I see with performing originAS-only RPKI validation on more-specific routes—something DE-CIX route servers do [1] using a BIRD config knob [2]—is that some networks might use that originAS-only validation in their (wide) configurations to make things "easier" for themselves. This could become especially true if vendors adopt a configuration allowing the loose validation of more-specifics' originAS similar to the BIRD config. This would obviously go against RFC9319 and make maxLength protections ineffective within the AS doing filtering. To solve for RTBH, the immediate options I see are: 1. Job's proposal that relies on the covering route having already passed through filters, RPKI validation, etc. and compares the recent historical next hop (AS) lookups to assume customer authorization to announce more-specific routes. OR 2. Perform originAS-only route validation for RTBH routes specifically, where the well-known BLACKHOLE [2] community must be present on the routes. Any widely-adopted RTBH filtering solution that ignores maxLength and relies only on originAS MUST require the BLACKHOLE community be attached. Everyone is leveraging that community by now, right? :) Again I feel the need to reiterate the "slippery slope" of #2 if it isn't strictly paired with BLACKHOLE community usage, especially if vendors offer a shortcut configuration for this in the future. It's also noteworthy that #2 cannot safely account for the "TE" use-case, as described earlier in this thread. I still question the validity of that "feature" by which prefixes are internally floated in an AS and externally rpki-invalid, as it could just be an issue of operator BGP prefix mismanagement that made this feature attractive in the first place. #1 could solve for the TE use-case as well, but my opinion of it is no ISP should accept these more-specific invalids until they have implemented proper safeguards that implement BGP hijacks. IRR will continue to not offer sufficient filter generation for that use-case in addition to RTBH. [1]: https://docs.de-cix.net/article/o80or2w5dl-de-cix-chicago-globepeer-route-se... [2]: https://bird.network.cz/pipermail/bird-users/2021-March/015314.html [3]: https://datatracker.ietf.org/doc/html/rfc7999 -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Mon, Mar 2, 2026 at 7:15 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Mon, 2 Mar 2026 at 15:09, Job Snijders via NANOG <nanog@lists.nanog.org> wrote:
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.
Yes. Sort of pretending ROA allowed to /32 or whatever the specific may be, IFF there is a blackhole community attached.
Ignoring active path.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TK6KESEB...