On Thu, Jan 25, 2024 at 6:11 PM Maria Matejka <maria.mate...@nic.cz> wrote: > > On 2024-01-25 17:08, Alexander Zubkov wrote: > > But I think the problem with no filters is bigger when the RTR server is out. > It is not just the short period of time when the peer can announce anything. > If rpki autoreload is on it will cause all bad announces that was rejected > before to pass the filter now. And if we turn rpki autoreload off, it might > work like a classical filter, but than we cannot do additional actual origin > validation using rpki. > > On Thu, Jan 25, 2024, 14:41 Alexander Zubkov <gr...@qrator.net> wrote: >> >> AFAIK in RPKI AS0 means implicit invalid. >> >> On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users >> <bird-users@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. > > I may have not written it completely. I would add the "::/0+ as 0", or "::/0+ > as 65535" if AS0 is too shady, to the IRR RTR feed itself, not as a static > record. > > This way, if the RTR feed fails, the first roa_check fails and the second one > is not performed at all, therefore nothing is rejected. OTOH, if the RTR feed > works, the first roa_check is always true and the second one matters. > > Do I miss something?
I think the idea was that (::/0+ AS0) is addet to RTR. Then every valid tuple (prefix, ASN) will return VALID, and others will fall at least under ::/0+ and because of AS0 will return INVALID. When the feed is off, the rpki check will return UNKNOWN. > > 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. > > -- > Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
