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

[Douglas Fischer]

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