Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Job Snijders]

On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:
> a quick stab at generating the slurm file:

why use SLURM though? SLURM doesn't have a 'maxLength' field like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json - which might help with
aggregation.

More importantly, a risk I perceive with overloading RTR functionality
to load IRR data into routers is in the realm of fail-safes:

For RPKI-derived data, most ISPs do something along the lines of:

   if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;

For IRR-derived data, you'd have to do:

   if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;

The above means that suddenly your EBGP routers/route servers have a
very hard dependency on the IRR RTR session being up in order to accept
routes (fail closed), whereas how the RPKI-derived data is used is in a
'fail open' fashion.

The above friction goes back to RPKI ROAs being defined as "if ROAs
exist, all BGP routes that do not match any of the ROAs are invalid"
(following the RFC 6811 algorithm), but for IRR route/route6 objects
such a definition was never established, those predate the RFC 6811
algorithm.

Kind regards,

Job