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

Jue Feb 16 13:30:51 -03 2023

Yo estoy de acuerdo con Arturo, hace falta por ahora usar una combinación
de ambas herramientas. De hecho no habría problema en seguir utilizando los
IRR como están hoy, si el problema de la autorización y autenticación se
pudiera resolver satisfactoriamente.

El IRR de LACNIC resuelve esto controlando lo que puede hacer cada usuario
contra la propia base de datos de registro.

s2

Carlos

On Thu, Feb 16, 2023 at 11:58 AM Arturo Servin <arturo.servin en gmail.com>
wrote:

>
> 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
>>
> _______________________________________________
> 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
=========================
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20230216/d20ca004/attachment-0001.htm>