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

[Maria Matejka]

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 <green at qrator.net> wrote:
>
>     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+ <http://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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20240125/f3861bff/attachment.htm>