[lacnog] RPKI ROAs - Blackhole - Maximum prefix length

[Fernando Frediani]

Hello Job

On 17/05/2019 02:44, Job Snijders wrote:

> 3) If you are an IXP and want to offer blackhole related services,
> implemented it like proposed here
> https://mailman.nanog.org/pipermail/nanog/2014-October/070310.html
> United IX implemented a trick where the route server listens for
> blackholing requests, but does not redistribute them to other route
> server participants, instead the blackhole routes are converted into
> ACLs and applied *inside* the layer-2 fabric. This way the blackholing
> does not require coordination, cooperation, validation, and is always
> 100% effective
> https://www.unitedix.net/tech/tech/#incoming-bgp-community-actions
Well, that's a beautiful way of doing, actually pretty smart and 
effective in my opinion, but I guess that may not always be available to 
any IXP out-of-the-box. Specially for smaller ISPs that are still 
sorting technology used and bringing up the bare minimal to operate or 
that may not have all pieces necessary to automate and apply these 
filters in Layer 2 fabric. For example there are switches that may have 
limits on the Layer 2 ACL size or even doesn't have enough automation 
available in order to integrate the route servers to do this layer-2 
magic. That's where probably a router server doing a all-in-one job 
would still be the point.

I am thinking here if a separate route server exclusively for this 
propose with different filters would be a middle-term for those who 
still cannot implement such filters in layer-2.


> Kind regards,
>
> Job
>
> On Fri, May 17, 2019 at 01:39:09AM -0300, Douglas Fischer wrote:
>> Durante el LACNIC 31 hubo una sesión interesantísima de orientación
>> práctica de creación de ROAs para RPKI.
>>
>> En esa sesión tuve la oportunidad de conocer la herramienta que LACNIC
>> desarrolló para evitar que "RPKI noobies" cometan errores.
>> P.S .: Los desarrolladores de esta mágica herramienta merecen fuertes
>> elogios! Excelente usabilidad.
>>
>> En esta sesión también surgió una discusión interesante sobre el tamaño
>> máximo de la máscara que se definió en la publicación del ROA.
>> En un ejemplo hipotético de un prefijo IPv4:
>> "X.Y.Z.0 /20 le /24" o "X.Y.Z.0/ 20 le /32"
>>
>> La pregunta se deriva de la validación RPKI em sistemas de Remote Triggered
>> Black Hole, generalmente a través de anuncios /32 con las respectivas
>> communities.
>>
>> ¿Cómo sería la validación de origen de anûncios de blackhole, que
>> generalmente son /32, considerando que la mayoría de los ROA se crean con
>> LE /24?
>>
>> El que está bajo algún tipo de ataque que dependa de Blackhole para
>> amenizar los impactos de ese ataque, no puede esperar hasta 24h para que un
>> ROA /32 criad de emergencia sea replicado por los cachés de los servidores
>> de RTR.
>>
>> Esto significa que los anuncios de BlackHole no podría pasar por la
>> comprobación de RPKI?
>> Y su yo fuera un tipo malvado y quisiera usar eso para crear problemas con
>> direcciones de alto uso como 8.8.8.8 1.1.1.1 4.2.2.2 9.9.9.9 y similares?
>> ¿Cómo queda la validación de origen en este caso?
>>
>> O la recomendación de que el LE maximo utilizado sea / 24 (v4) debería
>> revisarse?
>> P.S .: Se debe tener en cuenta que permitir una máscara más grande, a pesar
>> de resolver el problema de la validación RPKI de Blackhole / 32, crea el
>> problema de secuestro a través de más específico en la disputa de AS-Path.
>>
>>
>> Ante estas dudas, me gustaría escuchar la opinión de los colegas.
>>
>> -- 
>> 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