<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2024-01-25 11:55, Erin Shepherd
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a62442ba-a9e0-48c4-a2b6-fe10d101664a@app.fastmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
<div>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?<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"
cite="mid:a62442ba-a9e0-48c4-a2b6-fe10d101664a@app.fastmail.com">
<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="qt" style="">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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 class="moz-signature" cols="72">--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</pre>
</body>
</html>