[lacnog] RTBH y RPKI

Lun Ago 10 11:28:17 -03 2026

Hola Douglas y estimados,

Justamente desde hace unos días, en los tiempos que me voy haciendo, estoy
probando una solución bastante parecida a eso, usando posiblemente FORT y
SLURM.

Vamos a ensayar algo con Carlos M. sobre esto y les contamos más cuando
tengamos algo más concreto, técnicamente sólido, escalable y probado!

Saludos,
Nico

El El lun, ago 10, 2026 a la(s) 10:13, Douglas Fischer <
fischerdouglas en gmail.com> escribió:

> Sería un excelente proyecto para dedicar varias horas.
> Un proyecto que creo que podría incluso tener un resultado mucho-mucho
> elegante.
>
> Si yo tuviese un proyecto con la meta de resolver esto, ahora?
> ¡Ciertamente iría con esto!
>
> Seguiría con la idea de sesión BGP MP-BGP en un Route-Server dedicada para
> recibir RTBH y Flowspec.
> Esto tras mucha flexibilidad a la solución.
> Y principalmente trás un alcance mucho más robusto de validación de los
> prefixos frente a múltiples demandas como:
> - Comparar RTBH con ruta recibidas de Downstream y validar si las rutas
> efectivas cubren la RTBH.
> - Dejar RTBH como RTBH mismo y aplicar en su propia FIB?
> - Crear un IP de Blackhole Blackhole dedicado a cada Cliente, de manera
> generar información al cliente de cuanto fuera a blackhole.
> - Exportar RTBH para los Upstreams que aceptan?
> - Convertir RTBH en FlowSpec simple-drop y aplicar solo en los puertos de
> salida a lo downstream?
> Y también conceptos similares aplicados a FlowSpec.
>
>
>
>
> Em seg., 10 de ago. de 2026 às 09:38, Carlos Martinez <carlos en cagnazzo.uy>
> escreveu:
>
>> Entiendo, mas ahora… lo seria?
>>
>> --
>> Sent from Canary <https://canarymail.io>
>>
>> On Monday, Aug 10, 2026 at 9:33 AM, Douglas Fischer <
>> fischerdouglas en gmail.com> wrote:
>> Seria! Seria lindo!
>> Pero, apesar de ser de 2018 la https://www.rfc-editor.org/rfc/rfc8416.txt
>> ...
>> Em 2022 quando yo estaba procurando una solucion para esto, nadie existia
>> como código listo.
>>
>> Entonces fue a BIRD.
>> Aprovechando que Bird aun no tenía RTR.
>>
>>
>> Em seg., 10 de ago. de 2026 às 09:13, Carlos Martinez <carlos en cagnazzo.uy>
>> escreveu:
>>
>>> No seria un buen caso de uso de SLURM este ?
>>>
>>> --
>>> Sent from Canary <https://canarymail.io>
>>>
>>> On Monday, Aug 10, 2026 at 8:47 AM, Douglas Fischer <
>>> fischerdouglas en gmail.com> wrote:
>>> La forma más efectiva que encontré para solucionar esto es ir más allá
>>> del protocolo RTR.
>>> No podrás evitarlo con equipos que operen estrictamente dentro de las
>>> definiciones de RFC.
>>>
>>> P.S.: Por lo tanto, recomiendo otra sesión BGP, con un servidor de
>>> rutas, en eBGP MultiHop, dedicada a RTBH (y quizás flowspec).
>>>
>>> Necesitarás una Engine BGP BGP software-based para gestionar las rutas y
>>> un deamon de validación RPKI para gestionar las ROA y no solo las VRP.
>>> Y con esta información, en los casos en que el prefijo sea inválido,
>>> tendrás que investigar por qué se clasificó como inválido.
>>>
>>> Ejemplos:
>>> - Si el prefijo es inválido porque las fechas del certificado han
>>> expirado o la ROA ha sido revocada... Entonces no hay nada que puedas hacer.
>>> - Lo mismo se aplica si el ASN de la ruta IPv4 /32 no contiene el ASN
>>> que coincide con el ROA que cubre esa /32.
>>>
>>> Pero si el motivo de la clasificación como inválida es únicamente la
>>> longitud de la máscara... Si existe un VRP que cubre la ruta IPv4 /32 menos
>>> específica, coincide con el ASN y cumple con las especificaciones del
>>> certificado...
>>>
>>> Entonces, dentro de la interpretación individual del RFC RPKI.
>>> Dentro de las definiciones de autonomía de un ASN, se puede optar por
>>> aceptar rutas /32 (IPv4) que tengan un blackhole BGP de comunidad válido
>>> dentro de su ASN y que se clasifiquen como inválidas en RPKI solo debido a
>>> la longitud del prefijo, siendo válidas para todos los demás aspectos.
>>>
>>> Em seg., 10 de ago. de 2026 às 08:44, Douglas Fischer <
>>> fischerdouglas en gmail.com> escreveu:
>>>
>>>> Lo cierto es que el ROA de RPKI estaba mal diseñado desde su creación.
>>>>
>>>> P.S.: Ahora, algunos que no me conocen me tacharán de negacionista de
>>>> RPKI.
>>>> Yo... Que creo que participé directamente en la implementación de RPKI
>>>> (ROA y filtrado) de más de 400 ASNs.
>>>>
>>>> Los ROA de RPKI ya cuentan con LE (Less Equal).
>>>> Lo que realmente le falta a RPKI es GE (Greater Equal).
>>>>
>>>> Creo que es importante que quien hable de esto sepa que fue uno de los
>>>> temas más candentes en los intercambios de correo electrónico durante las
>>>> discusiones del Draft de RPKI. Y que, prácticamente de forma arbitraria, se
>>>> dejó de lado la idea de lo GE. Mucho con el argumento de "economía de
>>>> recursos computacionales".
>>>>
>>>> Si se hubiera incluido GE, como se discutió durante el período de Draft
>>>> de la RFC... Solo se necesitaría algo como:
>>>> - ROA 198.18.80.0/22 LE 24
>>>> - ROA 198.18.80.0/22 GE 32 LE 32
>>>> Y eso habría resuelto el problema de RTBH y algunos otros.
>>>>
>>>>
>>>>
>>>> Em sáb., 8 de ago. de 2026 às 15:47, Salvador Bertenbreiter <
>>>> salvadorb en gmail.com> escreveu:
>>>>
>>>>> Hola a todos,
>>>>>
>>>>> Una consulta para quienes usan RTBH junto con RPKI.
>>>>>
>>>>> ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el
>>>>> prefijo tiene un ROA con maxLength /24 o /48?
>>>>>
>>>>> Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence
>>>>> porque también haría válidos otros more-specifics.
>>>>>
>>>>> La otra sería mantener el ROA como está y anunciar igual el host route
>>>>> para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente
>>>>> hacen alguna excepción para rutas marcadas como blackhole, o las descartan
>>>>> antes por RPKI?
>>>>>
>>>>> Crear un ROA específico en el momento tampoco parece muy práctico por
>>>>> los tiempos de propagación.
>>>>>
>>>>> ¿Cómo lo están manejando ustedes en producción?
>>>>>
>>>>> Saludos,
>>>>>
>>>>> Salvador
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260810/de3f73d6/attachment-0001.htm>