<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hola,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Nosotros intentamos detectar leaks (una
de las cosas que hace ASPA) usando la informacion del IRR. <br>
</div>
<div class="moz-cite-prefix">Pensamos que uno de los problemas que
tiene ASPA es que a dia de hoy no hay muchos registros de ASPA por
lo que su efectividad en el corto plazo seria limitada, mientras
que los IRRs contienen mucha informacion disponible ya, y podria
usarse para obtener algo de proteccion.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Los resultados que obtuvimos son,
diriamos, ambivalentes....</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Para ser concretos, hemos vistos que en
caso de un leak de toda la tabla BGP por parte de un cliente,
usando la informacion disponible en los IRRs, em media podemos
detectar un 17% de las rutas generadas en el leak. Asimismo, que
un 20% de los ASes, pueden detectar al menos un 40% de la rutas
involucradas en un leak por parte de un cliente que les envia toda
la tabla de rutas.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Creo que estos resultado reflejan un
poco las dos posiciones. Es decir, si, hay informacion que es
util, pero debido a la cantidad y calidad de la informacion, su
utilidad es mucho menos de lo que se podria esperar.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Para quienes esten interesados en los
detalles, los pueden encontrar aca:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">M. Bagnulo, A. García-Martínez, S.
Angieri, A. Lutu, J. Yang, Practicable route leak detection and
protection with ASIRIA,<br>
Computer Networks, Volume 211, 2022, 108966, ISSN 1389-1286,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><a class="moz-txt-link-freetext" href="https://doi.org/10.1016/j.comnet.2022.108966">https://doi.org/10.1016/j.comnet.2022.108966</a>.<br>
</div>
<br>
<div class="moz-cite-prefix">Saludos, marcelo</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">El 6/2/23 a las 19:45, Carlos
Martinez-Cagnazzo escribió:<br>
</div>
<blockquote type="cite"
cite="mid:CA+z-_EUMJuC+EGWY4W3x=J73XfwcGc8WA90hLbwkNZB0pSi10Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">El gran problema de los IRR es la falta de
autenticación y autorización (el viejo AAA). En la charla
anterior veo que el tema se minimizó, pero cualquiera que haya
tenido que perseguir a un operador de un IRR para que borre un
objeto creado por un fulano cualquiera hace 23 años sabe que es
un problema bien serio.
<div><br>
</div>
<div>En RADB hasta hace relativamente poco quedaban objetos
creados por mi, con un mail que ya no existe, y del que no
existe más siquiera el dominio. RIPE se encontró con un
problema gigante vinculado a esto, lo que llevó a la creación
del origen RIPE-NONAUTH.</div>
<div><br>
</div>
<div>En segundo y tercer orden, para mi los otros problemas de
los IRRs son:</div>
<div><br>
</div>
<div>- Cualquiera puede operar uno. Esto puede operar a favor o
en contra. Hasta ahora ha funcionado en contra, debido a falta
de transparencia y debilidades en la operación. Si eso se
pudiera subsanar, podría ser hasta una ventaja. Resolver el
tema del AAA es clave para que esto sea una ventaja,
justamente para que no venga cualquier fulano y cree objetos
para gente que ni sabe que esos objetos están siendo creados.</div>
<div><br>
</div>
<div>- RPSL es demasiado rico. Demasiado. Es el refrán de "te da
suficiente cuerda para que ahorques". Esto lleva a poca
estandarización en su uso, excesivas variantes entre lo que
piden los carriers, etc. Esto se podría resolver o al menos
mitigar creando un "perfil" de RPSL que acote las
construcciones que se pueden usar, algo de eso tratamos de
hacer con el IRR de LACNIC.</div>
<div><br>
</div>
<div>Mis 0.02 :-)</div>
<div><br>
</div>
<div>/Carlos</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Feb 6, 2023 at 1:53 PM
Douglas Fischer <<a href="mailto:fischerdouglas@gmail.com"
moz-do-not-send="true" class="moz-txt-link-freetext">fischerdouglas@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 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" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
</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" moz-do-not-send="true"
class="moz-txt-link-freetext">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></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"
moz-do-not-send="true"
class="moz-txt-link-freetext">LACNOG@lacnic.net</a><br>
<a
href="https://mail.lacnic.net/mailman/listinfo/lacnog"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">Douglas Fernando Fischer<br>
Engº de Controle e Automação<br>
</div>
</div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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">--<br>
=========================<br>
Carlos M. Martinez-Cagnazzo<br>
<a href="http://cagnazzo.name" target="_blank"
moz-do-not-send="true">h</a>ttp://<a
href="http://cagnazzo.me" target="_blank"
moz-do-not-send="true">cagnazzo.me</a><br>
=========================</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>