[lacnog] RTBH y RPKI

Mar Ago 18 15:53:46 -03 2026

On Tue, Aug 18, 2026 at 03:33:33PM -0300, Fernando Frediani wrote:
> Hola
> 
> On 8/18/2026 3:23 PM, Herbert Alexander Faleiros vía LACNOG wrote:
> > Sin embargo, haría una pequeña distinción en la primera opción. Un ROA
> > válido para el /22 no hace que un /32 contenido en él sea RPKI Valid
> > si la longitud no está autorizada. El /32 seguirá siendo Invalid desde
> > el punto de vista de ROV.
> Sí, es correcto. Lo que sugiero es no realizar la validación RPKI basándose
> en el /32. Solo una verificación indirecta: si existe un ROA para un prefijo
> más agregado que contenga ese /32, entonces está bien para aceptarlo.
> > Lo que sí me parece razonable es tratarlo como una excepción explícita
> > de política: aceptar un /32 o /128 RPKI Invalid únicamente cuando se
> > recibe de un participante autorizado, lleva la comunidad
> > BLACKHOLE/RTBH y está contenido dentro de un prefijo que ese
> > participante está autorizado a originar. Es decir, no cambiar la
> > semántica de RPKI, sino separar ROV de la política específica de RTBH.
> Exactamente
> > Además, estas rutas deberían quedar estrictamente limitadas al ámbito
> > necesario para el blackholing y no convertirse en rutas normales
> > propagadas por Internet. Esto también es coherente con RFC 7999, que
> > recomienda limitar la propagación de las rutas BLACKHOLE.
> No es necesario transmitirlos a Internet toda, pero podrían si transmitirse
> a algunos Upstreams que también acepten RTBH para la amplificación de los
> efectos.
> > 
> > Y coincido bastante con el último punto. No hay una razón técnica para
> > que RTBH tenga que significar siempre /32 o /128. Permitir también
> > prefijos agregados puede ser especialmente útil en ataques tipo carpet
> > bombing: si el objetivo es descartar tráfico hacia una parte completa
> > de la red, anunciar un /24 o /25 puede ser mucho más eficiente que
> > introducir cientos de /32. Naturalmente, existe un trade-off de
> > granularidad y posible impacto colateral, pero debería ser una
> > decisión del participante y no una limitación artificial del
> > mecanismo.
> Mucho más.
> 
> Aquí creo que es más una cuestión de costumbre. "Lo hago así porque siempre
> lo he hecho así y nunca aprendí otra manera"
> Una razón similar explica por qué muchas personas siguen asignando prefijos
> IPv4 públicos /30 en lugar de /31 hasta el día de hoy después de más de 20
> años.

Sí, de acuerdo. Y revisando la RFC 7999, creo que en realidad estamos
describiendo casi exactamente lo que ya establece la sección 3.3.

Para aceptar BLACKHOLE, exige que el prefijo esté cubierto por otro
que el vecino esté autorizado a anunciar y además dice explícitamente
que la validación de origen no debe bloquear inadvertidamente anuncios
BLACKHOLE legítimos.

La RFC 9319 refuerza todavía más este punto: considera que RPKI-ROV no
encaja bien para validar rutas RTBH/RTDR y recomienda no crear ROAs no
mínimos ni ampliar maxLength solamente para permitir RTBH.

Así que creo que la separación correcta es precisamente esa: mantener
el resultado RPKI como Invalid cuando corresponda, pero permitir una
excepción de política RTBH bajo condiciones estrictas.

Y sí, respecto de los upstreams, de acuerdo también: no se trata
necesariamente de mantener la ruta dentro del AS, sino de controlar
explícitamente hasta dónde se propaga según los acuerdos de RTBH
existentes.

--
Herbert

> Saludos
> Fernando
> 
> > 
> > --
> > Herbert
> > > Fernando
> > > 
> > > On 8/8/2026 3:46 PM, Salvador Bertenbreiter wrote:
> > > > 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
> > > _______________________________________________
> > > 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

> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog