<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">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">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+" rel="noreferrer noreferrer noreferrer" target="_blank">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_-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">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>