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

[Alexander Zubkov]

AFAIK in RPKI AS0 means implicit invalid.

On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users <
bird-users at network.cz> wrote:

> On 2024-01-25 11:55, Erin Shepherd wrote:
>
> 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?
>
> 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
>
> With this, you can just go like
>
>     if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr, net, peerasn)
> != ROA_VALID then reject;
>
> which should do the work, iirc.
>
> Maria
>
>
>
>
> - Erin
>
> On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:
>
> 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
>
> --
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20240125/5c5d1b41/attachment.htm>