On Thu, 30 Jul 2026 at 21:14, Ben Cartwright-Cox via routing-wg <routing-wg@ripe.net> wrote:
I know that you have specifically said that you do not want your routers to depend on the reachability of infrastructure that you operate yourself, but you really should actually just run a RPKI Validator yourself.
1) You almost certainly do not have any contractual agreement with cloudflare that they are going to operate a service that will stay online and correct (in a way that does not damage your business!)
2) Running such infrastructure is typically quite easy, especially in the case of Routinator or rpki-client + StayRTR (the latter I'm pretty sure being what cloudflare uses anyway), I /personally/ wouldn't recommend FORT
Running rpki-client + StayRTR reliably is non-trivial, because when rpki-client stops completing validation for whatever reason, StayRTR keeps serving VRP's. Only since StayRTR v0.6.3 is a local json file discarded after 24 hours and the stale VRPs are withdrawn. That's a good safeguard, hopefully everyone rewriting a RTR server from scratch will implement this as well (and not rely only on per VRP expiration). In older releases, because everything apparently keeps working, this is often not noticed. I'm not talking about not noticed for a couple of days, but it could be weeks or months. And this leads to missing routes in your routing table, because people do change ROA configurations and sometimes remove ROAs. This is especially true during prefix transfers or M&A which happen all the time., I was immediately able to find 6 missing BGP prefixes in a Tier 1 network (present in every other Tier 1 network) that I suspected had a hung validation with StayRTR, which was indeed the case. It took a couples of days to find the right person, and I don't think I found the issue just when rpki-client stopped validating, so it was probably hung for a while (likely months). There are many reasons rpki-client could stop validating. Connectivity issues, upstream FW changes, read-only FS, no enough memory, not enough disk space, bugs, permission problems, "it's a container so nobody understands what is going on, but the lights are all green". All in one software stacks will crash and tear down RTR sessions with them in most of those situations. With StayRTR v0.6.3+ your RTR count will go to 0, the RTR connection will keep running. Also something you'd wanna know, and it will probably not generate syslogs on your router. Therefor this setup requires monitoring that triggers when the validation does not complete successfully (rpki-client exit code with a dead man switch). And additionally it requires monitoring the RTR endpoint, triggering when RTR serial stays the same for too long [1]. Serving stale VRP's has an impact. A different validator/RTR servers keeps uptodate VRPs on the router - great, but that doesn't help the folks that had to remove the ROA due to a transfer and can't enable ROAs yet for whatever reason. Every RTR server should be monitored against a never changing RTR serial, but the all in one validation + RTR packages are a lot less [1] https://github.com/lukastribus/rtrcheck