[lacnog] Blackhole announcements larger than /32
Fernando Frediani
fhfrediani en gmail.com
Mar Jun 27 15:44:34 -03 2023
Hola Tomás
Dentro de lo backbone de upstream que acepta estos anuncios ciertamente
no estará en uso, solo y quizás dentro de la propia red del anunciante,
pero en este caso es algo que debe ser verificado solo por el downstream
que *origina* el anuncio.
En este caso, *no hay posibilidad* de que otra IP de esa subnet esté en
uso. La intención de anunciar bloques enteros mayores que /32 para
blackhole es que el titular del prefijo se asegure de que *el bloque
completo no esté en uso* y pueda enviar el anuncio de una manera más
agregada al upstream, reduciendo así el número de rutas y hacer un mejor
uso del servicio blackhole que puede tener límites en el número de rutas
anunciadas.
Si todos los bloques anunciados para blackhole NO están actualmente en
uso, no habrá daños de bloqueo indebidos en el destino.
Fernando
On 27/06/2023 11:33, Tomas Lynch wrote:
> Fernando,
>
> No es escalable. Tienes que pensar si el /29 está en uso o no, eso es
> manual. O peor piensas que otra IP no está en uso y si lo está y
> terminas bloqueando un servicio sin que lo estén atacando.
>
> En el momento del ataque lamentablemente no tienes tiempo para pensar
> mucho.
>
> Tomas
>
> On Wed, Jun 21, 2023, 6:52 PM Fernando Frediani <fhfrediani en gmail.com>
> wrote:
>
> Hola Thomas.
> Gracias por la respuesta.
>
> La pregunta de si el atacante ataca ahora un IP luego otra y luego
> otra creo que es algo que tiene una solución sencilla. Ejemplo: si
> tiene un /24 y sabes que un /26 entero de ese /24 no está en uso
> al momento, no hay ningún problema en anunciar todo el /26 en
> blackhole, incluso si solo se está atacando una sola dirección IP
> en ese bloque. El atacante no lo sabe pero tú sí y esto ayuda a
> resumir mejor los anuncios y reducir el número de rutas en la FIB
> cuál es el objetivo principal de mi pregunta sobre cómo permitir
> una mayor flexibilidad en los anuncios de blackhole, pudiendo
> anunciar una cantidad mayor de bloques agregados (bloques más
> pequeños sin uso al momento) y no correr el riesgo de que la
> sesión alcance el límite máximo de prefijos dependiendo de la
> cantidad de IP atacados y anunciados
>
> Fernando Frediani
>
> On 21/06/2023 18:09, Tomas Lynch wrote:
>> Fernando,
>>
>> La primera pregunta es si es común atacar IPs contínuas tal que
>> formen al menos un /29. No tengo esa respuesta.
>>
>> Segundo, creo que el problema es cómo armar la supernet. Atacan a
>> 192.0.2.1/32 <http://192.0.2.1/32>, a los dos minutos atacan a
>> 192.0.2.2/32 <http://192.0.2.2/32>, a los 5 minutos a
>> 192.0.2.10/32 <http://192.0.2.10/32> pero dejan de atacar a
>> 192.0.2.1/32 <http://192.0.2.1/32>. ¿Cuánto tiempo espero para
>> que ataquen a todas las IPs de 192.0.2.0/28
>> <http://192.0.2.0/28>? ¿Cómo es el algoritmo para armar un /27 si
>> ya estoy propagando un /28 y están atacando el /28 contiguo?
>>
>> Me parece que el "downside" viene en el armado de la inteligencia
>> para decretar que están atacando un bloque menor a un /32.
>>
>> Saludos,
>>
>> Tomas
>>
>>
>> On Mon, Jun 19, 2023 at 10:10 AM Fernando Frediani
>> <fhfrediani en gmail.com> wrote:
>>
>> Hello folks
>>
>> I wanted to consult the community about a topic that has been
>> around
>> for a while.
>> Normally when announcing prefixes to an Upstream it is
>> commonly used
>> /32 only which works for a short amount of IP unused
>> addresses but
>> when you or your Downstream customers have a larger amount to be
>> announced it starts to get a lot of prefixes in that BGP session.
>>
>> What downsides do you see in companies allowing announcements
>> marked
>> with the blackhole community (or through a dedicated BH
>> server) to
>> accept prefixes larger than /32 (up to /25) in order to
>> facilitate the
>> consolidation of some unused larger prefixes ?
>>
>> Thanks
>> Fernando Frediani
>> _______________________________________________
>> 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20230627/b9abd071/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG