[lacnog] Fwd: Calgary Internet Exchange (YYCIX) deploys world's first ASPA-filtering Route Servers

Mie Feb 15 17:49:28 -03 2023

No entiendo por qué los dos. Si te referís a los prefijos "legacy" que no
están en los RIRs entonces mi propuesta sería que los IRR de los RIRs
solamente acepten este tipo de prefijos o una solución parecida con algún
inter-RIR (¿vuelve el RIR intergaláctico?)

On Sun, Feb 12, 2023 at 5:23 PM Hernan Moguilevsky <noc.hernan en gmail.com>
wrote:

> Estimados,
>
> No es Boca vs River (o Peñarol vs Nacional). No creo que sea RPKI *o* IRR.
> Actualmente son *los dos*.
>
> Y hay que tener el mismo cuidado para crear ROAs, como los route(6) que
> vamos a generar.
>
> ALTDb tiene una mínima validación manual de quién está creando los
> objetos, y es con la que más interactué debido a su costo (cero).
>
> Es real que para el ciudadano de a pie, borrar un registro erróneo
> (legacy) en un IRR es una misión, cuanto menos, tediosa. Pero no es
> imposible.
>
> Para el ejemplo de Douglas:
> Mi recomendación es que si vas a anunciar /25, crees los ROA con
> max-length /25 :)
>
> Saludos
>
> HM
>
> On 07/02/2023 05:02, marcelo bagnulo braun wrote:
>
> Hola,
>
> Nosotros intentamos detectar leaks (una de las cosas que hace ASPA) usando
> la informacion del IRR.
> 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.
>
> Los resultados que obtuvimos son, diriamos, ambivalentes....
>
> 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.
>
> 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.
>
> Para quienes esten interesados en los detalles, los pueden encontrar aca:
>
> M. Bagnulo, A. García-Martínez, S. Angieri, A. Lutu, J. Yang, Practicable
> route leak detection and protection with ASIRIA,
> Computer Networks, Volume 211, 2022, 108966, ISSN 1389-1286,
>
> https://doi.org/10.1016/j.comnet.2022.108966.
>
> Saludos, marcelo
>
>
> El 6/2/23 a las 19:45, Carlos Martinez-Cagnazzo escribió:
>
> 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.
>
> 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.
>
> En segundo y tercer orden, para mi los otros problemas de los IRRs son:
>
> - 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.
>
> - 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.
>
> Mis 0.02 :-)
>
> /Carlos
>
> On Mon, Feb 6, 2023 at 1:53 PM Douglas Fischer <fischerdouglas en gmail.com>
> wrote:
>
>> Ya sé lo que estás pensando:
>> "Aquí viene Douglas otra vez hablando de como viejas cosas son mejores
>> que a nuevas..."
>>
>> Esto (max-len) me recordó un problema que RPKI/ASPA no aborda muy bien y
>> es fácilmente tratable con IRR.
>>
>> Pequeños ISP que anuncian bloques más específicos para PNI o cachés de
>> CDN.
>>
>> Por ejemplo:
>> - T.LynchNET con su /23, sus clientes 6K, y sus 2 centros de enrutamiento
>> (Salta y Rosario)...
>> - T.LynchNET tiene todo muy correcto, incluyendo RPKI ROAs para sus rutas.
>> - T.LynchNET cuenta con CacheEnterDeep de FischerEdge en Salta e en
>> Rosario.
>> - 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.
>> - 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.
>> - Para resolver el contenido andando desnecessariamente, T.LynchNET
>> comenzó a anunciar rutas /25 SOLO PARA SESIONES BGP CON CACHÉS de
>> FischerEdge.
>> - Esto resolvió el problema de la fuente de tráfico dentro de los dos
>> nodos FEGC (FischerEdgeGlobalCaching).
>> - 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.
>> - Para "solucionar" esto, T.LynchNET cambió el ROA max-len de sus
>> prefijos a /25.
>> - La alarma DENTRO DE LA RED DE FischerEdge dejó de aparecer...
>> - 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.
>>
>> ¿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?
>>
>> PD: ¡Por supuesto que esto es una broma!
>> Y espero que lo leáis con el mismo buen humor con el que lo escribí...
>>
>> 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.
>>
>> Em seg., 6 de fev. de 2023 às 10:48, Tomas Lynch <tomas.lynch en gmail.com>
>> escreveu:
>>
>>> On Sat, Feb 4, 2023, 10:06 PM Alejandro Acosta <
>>> alejandroacostaalamo en gmail.com> wrote:
>>>
>>>>
>>>> On 4/2/23 4:04 PM, Tomas Lynch wrote:
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>> 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.
>>>>
>>>> Por lo que escucho, veo y leo, IRR no ha bajado su adopción en lo más
>>>> mínimo. ¿Me equivoco?.
>>>>
>>> Alejandro,
>>>
>>> No tengo números exactos. Lo que sé es que cualquier tránsito o peer que
>>> valga la pena 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. 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.
>>>
>>> Nosotros tenemos filtros/policies/route-map que siguen este algoritmo
>>> básico para nuestros peers (hay más líneas, solamente pongo las
>>> interesantes):
>>>
>>>    1. No aceptar bogons, martians, ruta default, ASNs conocidos, etc.
>>>    2. Si el ROA es válido, aceptar
>>>    3. Si no es válido, descartar (acá caen varios "válidos" pero que no
>>>    saben qué es el max-len)
>>>    4. Si es desconocido (unknown), seguir
>>>    5. Si está en el objeto AS, aceptar
>>>    6. Descartar todo lo demás
>>>
>>> Como ves seguimos usando los IRR para filtrar ya que lamentablemente
>>> las ROA no cubren ni el 50% de los anuncios (ver
>>> https://tinyurl.com/yc4t9a2w).
>>>
>>> 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.
>>>
>>> Tomas
>>>
>>>>
>>>> Saludos,
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG en lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>
>
> --
> --
> =========================
> Carlos M. Martinez-Cagnazzo
> h <http://cagnazzo.name>ttp://cagnazzo.me
> =========================
>
> _______________________________________________
> LACNOG mailing listLACNOG en lacnic.nethttps://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
>
> _______________________________________________
> LACNOG mailing listLACNOG en lacnic.nethttps://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20230215/a2ca8bc5/attachment-0001.htm>