[lacnog] RTBH y RPKI

Lun Ago 10 10:13:23 -03 2026

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