<div dir="auto">AFAIK in RPKI AS0 means implicit invalid.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users <<a href="mailto:bird-users@network.cz">bird-users@network.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<div>On 2024-01-25 11:55, Erin Shepherd
wrote:<br>
</div>
<blockquote type="cite">
<div>Spitballing slightly here, but could you avoid this problem
by adding <a href="http://0.0.0.0/0+" target="_blank" rel="noreferrer">0.0.0.0/0+</a> ::0/0+ AS0 RoAs to the table and accepting
ROA Unknowns?<br>
</div>
<div><br>
</div>
<div>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<br>
</div>
</blockquote>
<p>With this, you can just go like<br>
</p>
<p> if roa_check(irr, ::/0, 0) = ROA_VALID &&
roa_check(irr, net, peerasn) != ROA_VALID then reject;</p>
<p>which should do the work, iirc.</p>
<p>Maria<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div><br>
</div>
<div>- Erin </div>
<div><br>
</div>
<div>On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users
wrote:<br>
</div>
<blockquote type="cite" id="m_-4839903830166300959qt">
<div>On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via
Bird-users wrote:<br>
</div>
<div>> a quick stab at generating the slurm file:<br>
</div>
<div><br>
</div>
<div>why use SLURM though? SLURM doesn't have a 'maxLength'
field like the<br>
</div>
<div>regular JSON input formatted in this style has:<br>
</div>
<div><a href="https://console.rpki-client.org/rpki.json" target="_blank" rel="noreferrer">https://console.rpki-client.org/rpki.json</a>
- which might help with<br>
</div>
<div>aggregation.<br>
</div>
<div><br>
</div>
<div>More importantly, a risk I perceive with overloading RTR
functionality<br>
</div>
<div>to load IRR data into routers is in the realm of
fail-safes:<br>
</div>
<div><br>
</div>
<div>For RPKI-derived data, most ISPs do something along the
lines of:<br>
</div>
<div><br>
</div>
<div> if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID)
then reject;<br>
</div>
<div><br>
</div>
<div>For IRR-derived data, you'd have to do:<br>
</div>
<div><br>
</div>
<div> if (roa_check(irr, net, peerasn) != ROA_VALID) then
reject;<br>
</div>
<div><br>
</div>
<div>The above means that suddenly your EBGP routers/route
servers have a<br>
</div>
<div>very hard dependency on the IRR RTR session being up in
order to accept<br>
</div>
<div>routes (fail closed), whereas how the RPKI-derived data is
used is in a<br>
</div>
<div>'fail open' fashion.<br>
</div>
<div><br>
</div>
<div>The above friction goes back to RPKI ROAs being defined as
"if ROAs<br>
</div>
<div>exist, all BGP routes that do not match any of the ROAs are
invalid"<br>
</div>
<div>(following the RFC 6811 algorithm), but for IRR
route/route6 objects<br>
</div>
<div>such a definition was never established, those predate the
RFC 6811<br>
</div>
<div>algorithm.<br>
</div>
<div><br>
</div>
<div>Kind regards,<br>
</div>
<div><br>
</div>
<div>Job<br>
</div>
<div><br>
</div>
</blockquote>
</blockquote>
<pre cols="72">--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</pre>
</div>
</blockquote></div>