[lacnog] Blackhole announcements larger than /32

[Tomas Lynch]

Fernando,

Yendo a la pregunta: creo que hay algunos upstreams que aceptan enviar
prefijos menores que /32 para hacer black hole. Sobre por qué se eligió un
/32, es para evitar enviar prefijos menores que puedan enviar a null a IPs
que no estén siendo atacadas. Sin embargo no creo que haya una RFC/BCP que
obligue/recomiende un /32.

Creo que tiene la misma lógica de porqué el prefijo mayor que se acepta es
un /24. Están basadas en las antiguas clases C y direcciones de host
traducidas a CIDR sin ninguna otra lógica detrás.

Saludos,

Tomás Lynch


On Wed, Jun 28, 2023 at 2:23 PM Fernando Frediani <fhfrediani en gmail.com>
wrote:

> Exactamente Douglas, esta es la razón.
> Al permitir más anuncios agregados que /32, se reduce el número de rutas
> en la FIB.
>
> El tema de estar en una sesión separada o en la misma sesión BGP solo
> marcando community creo que no hace ninguna diferencia en este contexto si
> la intención es reducir el número de rutas en la FIB y resumir todos
> aquellos bloques que no están en uso por el Downstream.
>
> Si un bloque, digamos /26, está actualmente en completo desuso por parte
> de un Downstream, ¿por qué generar 64 anuncios en lugar de solo uno cuando
> el objetivo es no recibir tráfico a esas IP?
> Al final, como dije, quién sabe si todas las IP están en uso o no es quien
> origina los anuncios de BH, por lo que no debería haber ninguna
> preocupación al respecto de bloqueos indebidos.
>
> Pero la pregunta principal es: ¿hay alguna preocupación o prejuicio por
> parte de Upstream que acepta estos tamaños de anuncios para no hacerlo?
> ¿Por qué siempre se ha acordado /32
>
> Fernando
> On 28/06/2023 15:12, Douglas Fischer wrote:
>
> Por lo que tengo como referencia, el deseo que tienen los Downstreams de
> que sus Upstreams acepten prefijos mayores a /32 en RTBH básicamente se
> deriva de una sola razón... No exceder el Prefix-Limit de la sesión.
>
> Downstream anuncia 200-210 rutas y quiere liberar un límite de 1000
> prefijos para poder anunciar até uns 600-700 IPv4 em BH sem que caia a
> sessão.
> Las empresas que valoran su reputación nunca aceptarán un número tan
> grande.
> Entonces, para evitar esto, los downstream mais criativos intentan
> sumarizar y enviarlo.
> Creo que esto no tiene sentido y estoy en contra de la idea.
>
> Sobre el argumento del número de rutas en la FIB...
> Este es un problema INTERNO del ASN. Si el operador va a sumarizar o no
> las rutas para guardar FIB... Es una decisión que va a tomar cada operador
> de red de acuerdo con lo que sabe de los recursos de sus equipos.
>
>
> Personalmente, me gusta más la idea de una sesión BGP dedicada para
> manejar este tipo de cosas(unwanted traffic).
> Esta sesión podría incluso abordar IPv4 AFI, IPv6 AFI.
> Y talvez hasta AFI de FlowSpec si la empresa cree que esto es una ventaja
> competitiva para ella.
>
> Al tratarse esto de forma centralizada, es posible imponer un rigor más
> intenso en el filtrado de las rutas recibidas.
> Y en este caso, la preocupación por desbordar el límite de prefijos de la
> sesión principal deja de existir.
>
> Em seg., 19 de jun. de 2023 às 11:10, Fernando Frediani <
> fhfrediani en gmail.com> escreveu:
>
>> 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
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
> _______________________________________________
> LACNOG mailing listLACNOG en lacnic.nethttps://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/20230630/3c54aaac/attachment.htm>