<div dir="ltr">Ya sé lo que estás pensando:<br>"Aquí viene Douglas otra vez hablando de como viejas cosas son mejores que a nuevas..."<br><br>Esto (max-len) me recordó un problema que RPKI/ASPA no aborda muy bien y es fácilmente tratable con IRR.<br><br>Pequeños ISP que anuncian bloques más específicos para PNI o cachés de CDN.<br><br>Por ejemplo:<br>- T.LynchNET con su /23, sus clientes 6K, y sus 2 centros de enrutamiento (Salta y Rosario)...<br>- T.LynchNET tiene todo muy correcto, incluyendo RPKI ROAs para sus rutas.<br>- T.LynchNET cuenta con CacheEnterDeep de FischerEdge en Salta e en Rosario.<br>- T.LynchNET tenía problemas donde el contenido para clientes en Rosario estaba siendo originado por Cache en Salta. Y eso generó tráfico innecesario para T.LynchNET entre sus dos centros de enrutamiento.<br>- FischerEdge ha declarado en su política de enrutamiento público aceptar prefijos hasta /24 en sesiones con DFZ e IXP, y hasta /26 en sus PNI y sus EnterDeep Caches.<br><div>- Para resolver el contenido andando desnecessariamente, T.LynchNET comenzó a anunciar rutas /25 SOLO PARA SESIONES BGP CON CACHÉS de FischerEdge.<br>- Esto resolvió el problema de la fuente de tráfico dentro de los dos nodos FEGC (FischerEdgeGlobalCaching).<br>- Pero comenzó a generar alarmas en el panel isp.fischeredge.example de que se anunciaban rutas RPKI invalidas para los activos de Salta y Rosario.<br>- Para "solucionar" esto, T.LynchNET cambió el ROA max-len de sus prefijos a /25.<br>- La alarma DENTRO DE LA RED DE FischerEdge dejó de aparecer...<br>- Pero ahora T.LynchNET tiene abierta una superficie de ataque de Hijack de tráfico a través de un prefijo más específico.<br><br>¿Cómo podría T.LynchNET decir "este ROA aquí que tiene /25 no es válido para la DFZ, solo para mis PNI y cachés?<br><br>PD: ¡Por supuesto que esto es una broma!<br>Y espero que lo leáis con el mismo buen humor con el que lo escribí...<br><br>Pero si reemplaza algunos nombres en esta pequeña historia, cachés con PNI, será cierto para más de medio centenar de ASN que puedo recordar.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em seg., 6 de fev. de 2023 às 10:48, Tomas Lynch <<a href="mailto:tomas.lynch@gmail.com">tomas.lynch@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 4, 2023, 10:06 PM Alejandro Acosta <<a href="mailto:alejandroacostaalamo@gmail.com" target="_blank">alejandroacostaalamo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p><br>
    </p>
    <div>On 4/2/23 4:04 PM, Tomas Lynch wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr"><br>
        <div class="gmail_quote">
          <div><span style="font-family:monospace,monospace"><span class="gmail_default" style="font-family:monospace,monospace"><br>
              </span></span></div>
          <div><span style="font-family:monospace,monospace"><span class="gmail_default" style="font-family:monospace,monospace">Por ahora lo que
                yo sé es que firmamos ROAs y también registramos objetos
                en los IRR. Sería MUY interesante tener un solo "source
                of truth", creo que con el tiempo este será RPKI.</span></span></div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    Sería interesante tener un histórico de adopción de IRR (de RPKI hay
    muchos).  Hice una búsqueda rápida y no conseguí nada.<br>
    <p>Por lo que escucho, veo y leo, IRR no ha bajado su adopción en lo
      más mínimo. ¿Me equivoco?.</p>
    <p></p></div></blockquote></div></div><div dir="auto"><font face="arial, sans-serif">Alejandro,</font></div><div dir="auto"><font face="arial, sans-serif"><br></font></div><div dir="auto"><font face="arial, sans-serif">No tengo números exactos. Lo que sé es que cualquier tránsito o peer <span class="gmail_default">que valga la pena </span>te pide tu objeto AS para armar sus filtros en forma dinámica. Muy pocos tránsitos filtran por RPKI/ROA pero varios peers si lo hacen. <span class="gmail_default">Aquí quisiera abrir la discusión de tránsitos e incluso IXPs que todavía filtran en forma estática pero es para otro hilo.</span></font></div><div dir="auto"><font face="arial, sans-serif"><br></font></div><div dir="auto"><font face="arial, sans-serif">Nosotros tenemos filtros<span class="gmail_default">/policies/route-map</span> que siguen este algoritmo<span class="gmail_default"> básico para nuestros peers (hay más líneas, solamente pongo las interesantes)</span>:</font></div><div dir="auto"><ol><li><span class="gmail_default"><font face="arial, sans-serif">No aceptar bogons, martians, ruta default, ASNs conocidos, etc.</font></span></li><li><span class="gmail_default"><font face="arial, sans-serif">Si el ROA es válido, aceptar</font></span></li><li><span class="gmail_default"><font face="arial, sans-serif">Si no es válido, descartar (acá caen varios "válidos" pero que no saben qué es el max-len)</font></span></li><li><span class="gmail_default"><font face="arial, sans-serif">Si es desconocido (unknown), seguir</font></span></li><li><span class="gmail_default"><font face="arial, sans-serif">Si está en el objeto AS, aceptar</font></span></li><li><font face="arial, sans-serif"><span class="gmail_default">Descartar todo lo demás</span><br></font></li></ol><div><font face="arial, sans-serif">C<span class="gmail_default">omo ves seguimos usando los IRR para filtrar ya que lamentablemente las ROA no cubren ni el 50% de los anuncios (ver </span><a href="https://tinyurl.com/yc4t9a2w" target="_blank">https://tinyurl.com/yc4t9a2w</a><span class="gmail_default">).</span></font></div><div><font face="arial, sans-serif"><br></font></div><div><span class="gmail_default"><font face="arial, sans-serif">En conclusión, yo estimo que la utilización de IRRs no ha bajado en lo más mínimo y que incluso sigue creciendo gracias a que seguimos acumulando basura en ellos.</font></span></div><div><span class="gmail_default"><font face="arial, sans-serif"><br></font></span></div><div><span class="gmail_default"><font face="arial, sans-serif">Tomas</font></span><font face="monospace, monospace"></font></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p><br>
    </p>
    <p>Saludos,</p>
  </div>

_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" rel="noreferrer" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div></div></div>
</div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>