[lacnog] RTBH y RPKI

[Douglas Fischer]

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