<!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 17:08, Alexander Zubkov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABr+u0akEvbZdNr05c4n2QLwh-ah4_OkqWnHhiFLZ7WVTv3KyQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>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.<br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jan 25, 2024,
14:41 Alexander Zubkov <<a
href="mailto:green@qrator.net" target="_blank"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">green@qrator.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">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">
<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+"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">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>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>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.</p>
<p>Do I miss something?</p>
<p>Maria</p>
<p><br>
</p>
<p><br>
</p>
<br>
<blockquote type="cite"
cite="mid:CABr+u0akEvbZdNr05c4n2QLwh-ah4_OkqWnHhiFLZ7WVTv3KyQ@mail.gmail.com">
<div dir="auto">
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<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_-4711174239285827996m_3143357575759631542m_-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"
rel="noreferrer noreferrer noreferrer"
target="_blank" 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 cols="72">--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</pre>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</pre>
</body>
</html>