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

Lun Feb 6 22:05:23 -03 2023

Carlos,

No lo minimizamos para nada!! Es justamente todos los registros basura que
mencionamos anteriormente y que creo que ese fué el puntapié inicial para
la creación de RPKI. Sería bueno preguntar a Job et al. qué pusieron en la
balanza pero me imagino que un objeto creado para 100.0.0.0/8 por
charly en altavista.com con comentario "Test de IRR" debe haber pesado
bastante :p

Sumaste un punto que no quería entrar para quedarnos en la AAA y es el de
RPSL. Cuando lo descubrí me pareció maravilloso pero es tan pero tan rico
que en su momento me cansó, o pero creo que termine haciendo cosas como
"FROM .* ACCEPT ANY" y demás disparates.

Saludos,

Tomas

On Mon, Feb 6, 2023 at 1:46 PM Carlos Martinez-Cagnazzo <
carlosm3011 en gmail.com> wrote:

> 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 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/20230206/4e0760b7/attachment.htm>