<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Spitballing slightly here, but could you avoid this problem by adding 0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?<br></div><div><br></div><div>Obviously the disadvantage here is that if your IRR RTR server goes down you're basically unfiltered, but it at least avoids the availability problem<br></div><div><br></div><div>- Erin </div><div><br></div><div>On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:<br></div><blockquote type="cite" id="qt" style=""><div>On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:<br></div><div>> a quick stab at generating the slurm file:<br></div><div><br></div><div>why use SLURM though? SLURM doesn't have a 'maxLength' field like the<br></div><div>regular JSON input formatted in this style has:<br></div><div><a href="https://console.rpki-client.org/rpki.json">https://console.rpki-client.org/rpki.json</a> - which might help with<br></div><div>aggregation.<br></div><div><br></div><div>More importantly, a risk I perceive with overloading RTR functionality<br></div><div>to load IRR data into routers is in the realm of fail-safes:<br></div><div><br></div><div>For RPKI-derived data, most ISPs do something along the lines of:<br></div><div><br></div><div>   if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;<br></div><div><br></div><div>For IRR-derived data, you'd have to do:<br></div><div><br></div><div>   if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;<br></div><div><br></div><div>The above means that suddenly your EBGP routers/route servers have a<br></div><div>very hard dependency on the IRR RTR session being up in order to accept<br></div><div>routes (fail closed), whereas how the RPKI-derived data is used is in a<br></div><div>'fail open' fashion.<br></div><div><br></div><div>The above friction goes back to RPKI ROAs being defined as "if ROAs<br></div><div>exist, all BGP routes that do not match any of the ROAs are invalid"<br></div><div>(following the RFC 6811 algorithm), but for IRR route/route6 objects<br></div><div>such a definition was never established, those predate the RFC 6811<br></div><div>algorithm.<br></div><div><br></div><div>Kind regards,<br></div><div><br></div><div>Job<br></div><div><br></div></blockquote></body></html>