[lacnog] RPKI ROAs - Blackhole - Maximum prefix length

[Job Snijders]

Dear Douglas,

You raise excellent questions - indeed there are some aspects related to
blackholing that we must reconsider in context of RPKI based Origin
Validation.

At the last IETF meeting I presented on a novel method to incorporate
the concept of blackholing in a world with stricter checks on whether to
accept a request for blackholing or not:

    http://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijders.pdf

My recommendations:

1) create your ROAs as 'strict' as possible, don't do 'upto /32' if you
can avoid it. You are rightly identified that setting the ROAs "too
loose" will open yourself up to certain attacks

2) If you are an IXP - stop offering blackholing via route servers.  The
"blackholing via route servers" was an idea that originated in the
marketing department of a European IXP and was never an effective
solution to begin with. Route servers must not redistribute blackhole
routes, there is no point.

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

4) If you are a transit provider, please wait a few weeks until the
mechanism I described in the IEPG presentation is finished. NTT is right
now working on an open source implementation of this idea with the
intent that anybody can copy the method.

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