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

Jue Feb 16 11:57:44 -03 2023

Soporte de AS-SETs que RPKI no tiene por ahora.

RPKI ASPA esta un poco lejos de ser realmente una opcion.

Saludos
as

On Wed, 15 Feb 2023 at 20:50, Tomas Lynch <tomas.lynch en gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/20230216/7c471ca7/attachment-0001.htm>