[lacnog] RTBH y RPKI
Carlos Martinez
carlos en cagnazzo.uy
Lun Ago 10 09:37:55 -03 2026
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 (mailto: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 (mailto: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 (mailto: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 (mailto: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 (http://198.18.80.0/22) LE 24
> > > > - ROA 198.18.80.0/22 (http://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 (mailto: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 (mailto: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 (mailto: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 (mailto: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/3d496cdd/attachment-0001.htm>
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre : signature.asc
Tipo : application/pgp-signature
Tamaño : 917 bytes
Descripción: no disponible
Url : <https://mail.lacnic.net/pipermail/lacnog/attachments/20260810/3d496cdd/attachment-0001.sig>
Más información sobre la lista de distribución LACNOG