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

[Maria Matejka]

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/45ead085/attachment.htm>