[lacnog] Fwd: Calgary Internet Exchange (YYCIX) deploys world's first ASPA-filtering Route Servers
Hernan Moguilevsky
noc.hernan en gmail.com
Dom Feb 12 19:23:04 -03 2023
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
>> algoritmobá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 <http://cagnazzo.me>
>> =========================
>>
>> _______________________________________________
>> 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/20230212/c00cbc55/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG